Method

How an engagement
runs

Six phases, from the first scoping call to the retest that closes a finding. Written down so you can hold us to it, and so you can ask everyone else you are considering the same questions.

This page is the process. The document it produces, including its structure and eight populated findings, is shown in our complete sample report.

0x01Sequence

The order is fixed.

The boundaries between phases are real. Nothing in a later phase starts before the artefact of the earlier one exists.

01
Scoping
Work out what is worth testing, what it would cost, and whether testing is the right spend at all. Ends with a written scope or with a recommendation to do something else first.
Before anything is signed
02
Authorization
Rules of engagement and a letter of authorization, signed by someone with the standing to authorize it. Nothing is touched before both exist.
Paperwork that constrains the work
03
Pre-flight
Accounts issued, access proven, escalation contacts confirmed, source addresses shared. Every hour of a testing window spent chasing a login is an hour not spent testing.
The week before
04
Testing
The work itself, inside the agreed window and inside the agreed boundary. Anything critical leaves the window immediately.
The window
05
Reporting
A draft for factual review, your corrections, then the final document. The report is the deliverable. Everything before it is work you never see.
Days, not weeks, after
06
Retest
Fixes are attacked rather than replayed against. Findings close out as closed, partially closed, or open, and the retest is issued as its own dated document.
Once fixes are deployed

0x02Phase 01

A conversation, not a questionnaire.

Its job is to find the smallest scope that answers the question you actually have.

What is asked

What the systems actually are

Domains, API base URLs, cloud accounts, network ranges, the tenancy model, and which of them are production. A diagram, even a rough one, saves an hour of questions.

What you are afraid of

The scenario that would ruin the quarter. Testing aimed at a named fear produces sharper findings than testing aimed at a checklist, and it changes what gets prioritised inside the window.

What has already been done

Previous test reports, known issues, the things you already know are broken. Rediscovering a finding you paid for last year is a waste of your budget, not a demonstration of thoroughness.

What the constraints are

Compliance deadlines, release freezes, traffic-sensitive periods, systems that cannot be touched at all. Constraints shape the scope; they do not get discovered mid-window.

What comes out of it

A scope small enough to test properly

A narrow scope tested to depth beats a wide one skimmed. Where the ask is larger than the budget, the recommendation is which part to cut, not which part to rush.

A written statement of what is excluded

Exclusions are agreed up front and reproduced verbatim in the report.

A fixed price and a fixed window

Priced on the scope, not on the findings. There is no incentive here to inflate a finding count, and no change of price if the system turns out to be in better shape than expected.

Sometimes, a recommendation not to buy

Some teams are better served fixing three known things than commissioning a test that will find them again. That gets said during scoping, not after an invoice.

Scoping costs nothing and commits nothing

There is no charge for the scoping conversation and no obligation attached to it. If a specific technical question is the whole of what you need, office hours is the cheaper door and often the right one.

0x03Phase 02

Rules of engagement

The document that turns an attack into authorized testing. It is signed before any packet is sent, and it is reproduced in the report so the engagement can be audited against it afterwards.

A mutual NDA is signed alongside it, always, before scope detail changes hands.

What it fixes in writing

Targets, enumerated exactly: every domain, endpoint, account, range and tenant that is in scope, and nothing implied.
Exclusions, and the reason for each.
The testing window, with timezone, and any period the window must avoid.
Source addresses testing will originate from.
Whether the defenders are told. Detection is only measured honestly when the people being measured do not know the date.
Named escalation contacts on both sides, reachable outside working hours for the duration.
Stop conditions: what causes testing to halt immediately, and who can call it.
Data handling: what may be accessed, what may never be, and what happens to everything captured when the engagement ends.
A letter of authorization signed by someone who can authorize it. Where you do not own the infrastructure, evidence that the owner permits testing.

0x04Phase 03

Pre-flight

A short checklist run in the days before the window opens, because every one of these failing on day one costs a day of testing you have already paid for.

Test accounts issued at every privilege level the scope requires, and each one logged into successfully.
Allowlisting confirmed where a WAF or IP restriction would otherwise make the window a test of the WAF.
Escalation contacts confirmed reachable, by the channel they will actually be reached on.
Our source addresses shared with your team, and the window confirmed against your release calendar.
Staging environments, where they are being used instead of production, confirmed as representative of it.

0x05Phase 04

The part usually sold as a black box.

These are the standards it is held to. They are also the ones worth interrogating in any proposal you are handed.

Agents do the work, a human is accountable for the answer

Agent swarms enumerate, exploit and chain in parallel across the whole surface, at a breadth no human testing window has room for. A human sets the objectives, adjudicates what matters, and signs the report. Nothing the swarm could not demonstrate is reported as a finding. Informational observations are the one exception and sit in their own section.

Coverage is tracked, not claimed

What was reached, what was attempted and not reached, and what was never touched are recorded as the window runs. A report that only lists what was found tells you nothing about what was looked at.

Frameworks as a floor, not a ceiling

OWASP WSTG and ASVS for web and API work, MITRE ATT&CK for adversary simulation, CIS benchmarks for cloud configuration. They guarantee the boring coverage. The findings that matter usually come from business logic no framework enumerates, where the swarm can reach the state and a human has to decide whether reaching it was ever meant to be possible.

Chains, not just individual issues

A Medium that grants a username list and a Low that leaks a tenant identifier can compose into something Critical. Findings are tested against each other, and the chain is written up as the chain.

Root cause over instance count

One defective handler exposed through six endpoints is one finding with six affected instances, not six findings. Inflating a count is the easiest thing in this industry to do and the least useful.

Availability is never the demonstration

Denial of service, destructive payloads and resource exhaustion against production are all off the table. An availability risk is argued from the code, not proven by taking the service down.

0x06Throughout

Proof stops at proof.

What is captured while testing runs, how far a demonstration is allowed to go, and what happens to all of it afterwards.

Captured as it happens

Requests, responses, timestamps and the source address for every action that mattered. If your team asks in three months what hit an endpoint at 14:12, the answer exists.

Proof stops at proof

Impact is demonstrated to the minimum extent that makes it unambiguous, then testing stops. Access to a database is shown. The database is not pulled.

A cleanup list, not a promise

Test accounts, uploaded files, shells and scheduled tasks are removed at the end, and the list is handed over so you can check it yourself.

Negative results count

Where a control was attacked and held, that is recorded. A control that was never reached is recorded as never reached.

How a technical finding reads on the page

See the finding fields, numbered reproduction steps, and control comparisons across eight populated findings in the complete sample report.

0x07Throughout

Silence, then a PDF, is the industry default.

It is not this one. Here is what reaches you while the window is still open.

Critical findings leave the window immediately

Anything unauthenticated and serious (live data exposure, authentication bypass, remote code execution) goes to the escalation contact as soon as it is confirmed, by the channel agreed in the rules of engagement. You act on it while testing continues.

A short written update at each phase boundary

Start of window, mid-window, and end of window. Enough to know whether the engagement is going the way it was scoped, without a standing meeting that costs both sides an hour.

Signs of a real compromise stop everything

If evidence of an intrusion that is not ours turns up, testing halts and you are told that day. Distinguishing our traffic from theirs is exactly why source addresses were shared in advance.

Questions get answered during the window

Where a finding depends on how a system is meant to behave, the question is asked. A misread design decision written up as a vulnerability wastes an engineer's afternoon.

0x08Phases 05 and 06

Reporting and retest

The deliverable has a page of its own. What matters here is the sequence around it.

Reporting

A draft lands within days of the window closing, not weeks.
You review it for factual accuracy: misread architecture, misattributed ownership, an intended behaviour written up as a defect.
Corrections of fact are made. Where we still disagree on severity, both positions are recorded.
The final document is versioned and dated, and it is yours, to send to an auditor as-is or redacted to a customer.
A walkthrough call is offered with it, aimed at whoever has to do the fixing.

Retest

Every Critical and High is retested once fixes are deployed, as part of the engagement rather than as a second purchase.
The fix is attacked, not just the original payload replayed: variants, encodings, and the obvious ways around a patch.
Statuses are closed, partially closed, or open. A partial fix is never written up as a closed one.
Retest criteria are agreed when the finding is written, so "fixed" is not decided afterwards by whoever is keenest.
The retest is its own versioned, dated document, so both stand as audit evidence.

See the section order, finding fields, base scores, and limitations in context in the complete sample report.

0x09Limits

A method with no limits is a sales document.

These are the boundaries of what an engagement here can actually tell you.

We do not test mobile clients

iOS and Android applications are outside the practice. The backend and its APIs, usually where the impactful findings are, stay in scope; the client binary does not. We would rather refer that work out than learn it on your budget.

We are not your compliance auditor

Findings can be mapped to SOC 2, ISO 27001 or PCI DSS controls on request, and the report is written to stand up to an auditor reading it. Whether a control satisfies your regulator is a question for your auditor and your counsel.

A test is a point in time

The report describes the systems as they were, during that window, under that scope. It is evidence about a moment, not a certificate about a system.

Absence of findings is not a clean bill of health

A short findings list means the scope held up under what was attempted in the time available. The report states the coverage behind that number so it cannot be read as more than it is.

The same rules, pointed at us

Scope, boundaries, safe harbour and evidence standards are not things we only ask of clients. Our own systems carry a published vulnerability disclosure policy with the same terms written from the other side.

0x0AStart

Bring a scope and we will size it honestly

Send the systems in question, the boundary you care about, and your timeline. If testing is not the right spend right now, that gets said in the first reply.

Book a scoping call

hello@principlebreach.com +91 92025 01337

How an engagement
runs

Six phases, from the first scoping call to the retest that closes a finding. Written down so you can hold us to it, and so you can ask everyone else you are considering the same questions.

This page is the process. The document it produces, including its structure and eight populated findings, is shown in our complete sample report.

How an engagement runs

The order is fixed.

Scoping

Authorization

Pre-flight

Testing

Reporting

Retest