Six phases, eleven coverage classes, three approval gates, and one rule about what may be called a finding. Written for the person assessing the vendor rather than for the person booking the scan.
The phases do not change between coverage classes or between delivery models. What happens inside them changes completely, and that difference is the part this page sets out.
The six phases
The order is the method. Each phase consumes what the one before it produced, and no phase is skipped because a target looks simple.
Discovery
Takes in the authorised scope — the targets, the credentials, the window, and the authority it was signed under. Produces the reachable set: the hosts, applications and endpoints that answer, and the roles that can reach each of them. That reachable set is what gets tested, rather than what the asset inventory says exists.
Planning
Takes in the reachable surface. Produces a mindmap of the target and the test cases generated from that map, so the checks belong to this target rather than to targets in general.
Scanning
Takes in the generated test set. Produces candidates: places where the behaviour suggests something is wrong. Nothing that leaves this phase is counted, reported or put in front of you.
Exploitation
Takes in the candidates. Produces proved findings, each one carrying the exploit that proved it and the steps a reviewer can follow to run it again. Three actions stop here and wait for your written approval.
Reporting
Takes in the proved findings. Produces the report and the matching dashboard entries, each with its evidence attached, so the engineer who has to fix a finding opens the proof itself. In the fully autonomous model every finding passes an independent automated cross-check before it is reported.
QA
Takes in the report as written. Produces the report you receive — or a finding sent back to the phase that produced it, with the report corrected rather than annotated. You do not hold the report at this point, which is what makes this a gate rather than a review.
A quality gate placed mid-pipeline has nothing in front of it to check, because no report exists yet; holding work back is the only thing it can do. Ours runs on the finished report: the artefact as you would read it, with its findings, its evidence and its severities already written.
The report has not been handed over when this happens. A finding that does not survive the gate returns to the phase that produced it, and the correction lands in the copy you receive rather than in a note appended after you have filed it.
That is the whole of the distinction, and it is worth checking in any methodology you are handed: a step called quality assurance that runs after delivery is a review, and a review cannot stop anything.
The drop rule
Scanning and exploitation are separate phases because they produce different things. One produces leads; the other produces evidence. A candidate is proved by exploitation or it is dropped, and those are the only two outcomes available to it.
The cost of the rule is that anything we could not prove does not appear at all. The benefit is that every line in the report has an exploit behind it, and a reviewer can test that claim directly: pick a finding, follow its steps, and watch it reproduce.
Constant phases, different work
The phase names hold whatever is being tested. The work inside them does not: discovery against a running application, against an address range and against a source repository takes a different input, runs different work and produces a different map. Three of the eleven classes are worked through below as examples.
| Phase | A web application | An external address range | A source repository |
|---|---|---|---|
| Discovery | Routes, parameters and roles enumerated from the running application, including client-side code read for endpoints the interface never links to. | What actually answers: live hosts, the services on them, and the versions those services advertise — worked out from responses rather than from the asset list. | Languages, frameworks and entry points in the tree, and which of them take input from outside the application. |
| Discovery is where the three diverge furthest. One starts from a URL, one from an address range and one from a checkout, and each produces a different kind of map for planning to work from. | |||
| Planning | A mindmap of the application, and test cases generated from it with one credential per role in hand. | Per-service test sets, ordered by what the exposed surface actually offers rather than by a fixed checklist. | The sinks worth reaching, and the candidate paths that might reach them from an entry point. |
| Scanning | The generated cases worked against the running application; behaviour that suggests a defect becomes a candidate. | Service and configuration checks across the hosts that responded, producing candidates per host and per port. | Data flow traced from entry point to sink across the tree. Each trace is a candidate, and none of them is a finding yet. |
| Exploitation | The candidate is exploited against the live application, with the request and the response captured as they happened. | Entry is proved against the exposed service. Movement past the host it landed on is an approval gate rather than a default. | Reachability is proved: the file, the line, and the path that reaches that line. A path nothing can reach is dropped. |
| Reporting | Findings against the application, each with its exploit artefact, a CVSS v4.0 vector and the CWE. | Findings against the host and the service, with the proof of entry and the same severity and CWE record. | The file, the line, the reaching path and the change that closes it, written against the idiom the repository already uses. |
| QA | That every finding reproduces against the application as it was scoped. | That each proof of entry names the host, the service and the port it was obtained on. | That each finding names a file and a line that exist in the commit that was reviewed. |
| QA is the phase that varies least. In every class the gate runs on the finished report before it reaches you, and a finding that does not hold goes back to the phase that produced it. | |||
What each phase does against three of the eleven coverage classes
Discovery
Discovery is where the three diverge furthest. One starts from a URL, one from an address range and one from a checkout, and each produces a different kind of map for planning to work from.
Planning
Scanning
Exploitation
Reporting
QA
QA is the phase that varies least. In every class the gate runs on the finished report before it reaches you, and a finding that does not hold goes back to the phase that produced it.
Those three columns are web application penetration testing , external network penetration testing and secure code review . Each of those pages sets out what its own phases do in detail.
The other eight classes run the same six phases against their own inputs: a signed mobile release build, a distributed thick client package, an API with an authorisation matrix written before anything is tested against it, a cloud tenancy, an Active Directory estate, an internal network reached from a deployed position, an authorised social engineering population, and an application built on a language model.
One exclusion holds across all eleven and is stated the same way on every class page: physical, hardware and wireless testing are out of scope for the platform.
The three gates
The same three on every coverage class and in all three delivery models. They are the whole of what B-52 stops for, and their terms are set when you sign the scope rather than negotiated while a run is going.
A gate is a stop rather than a warning: the run waits until the approval is given in writing. In the two autonomous models the approved action is then taken by the platform, and in the human-led model by the senior auditor running the engagement.
What the record of an approval holds, and who can read it back afterwards, is set out on the approvals and audit trail page. That is the page to attach where a questionnaire asks how the testing itself was controlled.
Scope sign-off is the one thing every model asks of you before a run starts. From then on, the fully autonomous model comes back to you only at these three points.
What a finding carries
The record is the same in all three delivery models. What differs between them is whose signature the report carries, never what a finding contains.
A finding closes on a retest that cannot reproduce it. Closure is the outcome of running the original exploit again, not a status somebody sets when the ticket is tidied away.
| State | What it means | What follows |
|---|---|---|
| Open | Reported to you with its evidence attached. Nothing has changed on the target yet. | Waits for a fix. |
| Fixed | Your team has made the change and marked the finding fixed. | Goes to retest. |
| Retested | The exploit that proved the finding is attempted again against the changed system. | Closes if it cannot be reproduced. Returns to open if it can. |
| Closed Terminal | The exploit no longer reproduces. | No state follows. |
In the fully autonomous model, the median observed from scope sign-off to report is one to three business days — an observed median rather than a service level, and it describes that model. The delivery models page sets out which model produces a report that carries an empanelled auditor’s signature.
What the method is worked against
A methodology that cites a standard without its edition is asking you to do the checking. Every edition below was read at its own source in September 2026, and two rows name what the report records instead of a fixed version, because those two publish on a rolling cadence and on a per-provider one.
| Standard | Edition worked against | Where it bears on the run |
|---|---|---|
| OWASP Web Security Testing Guide | v4.2, current stable | The coverage baseline for the web application class, mapped case by case onto the generated test set. |
| OWASP Top 10 | 2025 edition | The risk categories a web application finding is classified into. In this edition SSRF sits inside A01 Broken Access Control, and A07 carries the name Authentication Failures. |
| OWASP ASVS | 5.0.0, May 2025 | Verification requirements across its 17 categories, used where a scope is written against requirements rather than against a risk list. |
| OWASP MASVS and MASTG | v2.1.0 and v2.0.0 | The mobile class, including the MASVS-PRIVACY category added at v2.1.0. Coverage is expressed as testing profiles, which replaced verification levels at v2.0.0. |
| OWASP API Security Top 10 | 2023 edition, current | The risk list API findings are classified against, alongside the authorisation matrix the class is worked from. |
| OWASP Top 10 for LLM Applications | 2025 edition, 12 March 2025 | The ten entries LLM01 to LLM10, for the class that tests an application built on a language model. |
| NIST SP 800-115 | Final, September 2008 | The technical assessment process the phase structure answers to. It remains the current edition. |
| PTES | Current | The execution standard the phase vocabulary is drawn from, which is why the names will be familiar. |
| PCI SSC Penetration Testing Guidance | v1.1, September 2017 | How a test is scoped and evidenced where the target sits in a cardholder data environment. |
| MITRE ATT&CK | v19.2, 6 August 2026 | Technique mapping for network, cloud and Active Directory findings. |
| MITRE ATLAS | The release named in the report | Technique mapping for findings against an application built on a language model. ATLAS publishes on a rolling cadence, so the release is recorded per finding rather than pinned here. |
| CVSS | v4.0, November 2023 | The severity vector carried by every finding. The version is published and maintained by FIRST. |
| CIS Benchmarks | The benchmark and version named in the report | Configuration baselines for cloud findings. CIS publishes one Foundations Benchmark per provider on its own cadence, so the benchmark is recorded per finding. |
Testing standards, their editions, and what each one governs in a run
OWASP Web Security Testing Guide
OWASP Top 10
OWASP ASVS
OWASP MASVS and MASTG
OWASP API Security Top 10
OWASP Top 10 for LLM Applications
NIST SP 800-115
PTES
PCI SSC Penetration Testing Guidance
MITRE ATT&CK
MITRE ATLAS
CVSS
CIS Benchmarks
Regulatory mapping is a separate question and has its own page: PCI DSS, ISO/IEC 27001, SOC 2, GDPR, HIPAA and the Indian regimes, with the control each set of findings is mapped to. The standards mapping sets that out, and the compliance index carries a page per regime.
Security Brigade has been CERT-In empanelled since 2008 and is ISO 27001 certified. Those two instruments are the firm’s, covering how it delivers; the B-52 platform holds no certification of its own and this site claims none for it.
Deliberately excluded
A method is worth what a delivered report proves about it. Scope one target, read what comes back, and hold the report against every claim on this page.