Skip to main content
B‑52
Run a scan
Resources · Checklist

Penetration testing checklist: scope it, run it, then grade the report

Three lists rather than one. Thirteen things to settle before anyone tests anything, six things you should be seeing while the engagement runs, and twelve checks to run against the report that comes back.

The third list is the one worth bookmarking. It grades any penetration test report, from any provider, on properties of the document itself — so you can work down it with a PDF open in the other window.

The report checklist Scope and authorisation template

Before the engagement

Thirteen decisions, and none of them is paperwork

Every row below is a decision somebody will make. The only question is whether you make it now, in writing, or whether it gets made for you halfway through a run by the party with the least context on your business.

What to settle before a penetration test begins
Settle before kick-offWhat settled looks likeWhat leaving it open costs you
Scope, written as a list Every host, domain, application, repository or binary named individually. A range is fine where you own the range; a category is not. A scope that reads “the production estate” gets resolved during the test, by the party with the least context on your business — and the report comes back covering something other than what you asked about.
Out of scope, in the same document Third-party services you do not own, shared infrastructure, and any system whose downtime you cannot absorb — named as explicitly as the in-scope list. An exclusion that lives in somebody’s memory is not an exclusion. This is the one part of a scope that cannot be corrected after the fact.
Production or a staging environment Which one is under test, and where the two differ: data, configuration, protective controls in front of them, and whether rate limiting behaves the same way. A staging environment with the protections switched off and seeded data produces findings that do not exist in production, and misses the ones that do.
A working credential for every role One account per role that exists, including the roles only an administrator can create, and confirmation that each one still works on the morning of kick-off. Broken access control sits at A01 in the OWASP Top 10 2025, and it cannot be tested with a single account: the test is what role A can reach that belongs to role B.
Registration, MFA and throttling Whether test accounts self-register, how MFA is satisfied for a test account, and whether the tester’s source addresses need allow-listing. A run that is throttled or blocked returns a clean result that looks identical to a clean system, and you find out which it was only on the next breach.
The movement boundary For any class that starts from a foothold — internal network, Active Directory, cloud where a role can be assumed — the segments, trust boundaries and accounts the test may move towards, agreed in writing beforehand. “How far could an attacker get” becomes a judgement call taken mid-engagement instead of a measured answer against a boundary you set.
Who approves, and how fast Named people with a named channel for the actions that stop and wait, plus a deputy for each. Not a role mailbox. A gate with no named approver stops the engagement rather than guarding it, and the pressure to waive it arrives exactly when you are least able to weigh it.
Evidence handling and residency What the test will hold, which region it is held in, how long it is kept, and how it is destroyed at the end. Evidence of your weakest control, held somewhere nobody agreed to, is a second problem created by the work that was meant to find the first.
The window, and the contacts inside it Start and end dates, the hours testing may run, and one named contact on each side who is reachable during them. An out-of-hours finding with nobody to send it to sits until morning, and the incident it describes does not.
What happens on a critical finding Whether a critical is raised the moment it is proved or waits for the report, to whom, and by what channel. Reading about a proved critical for the first time in a PDF, a fortnight after it was found, is a process failure rather than a testing one.
The deliverable, in detail Report format, the standards it maps to and the version of each, whether raw evidence is attached, and whether the findings also land somewhere your engineers already work. The format is negotiable before the engagement and fixed afterwards. Ask for the standards mapping now, not when the auditor asks you for it.
Retest terms Whether a retest is included, how long you have to use it, what it covers, and what happens when the fix does not hold. A retest quoted as a fresh engagement, after the finding has been open long enough to matter, is the most expensive line item in this table.
The delivery model, and whose signature is on it Whether the output has to be signed for a filing. Where it does, the auditor who signs has to have been inside the engagement — which is a decision taken at scoping, not at delivery. A technically sound report that nobody can sign is a report you have to buy twice.

What to settle before a penetration test begins

Scope, written as a list

What settled looks like
Every host, domain, application, repository or binary named individually. A range is fine where you own the range; a category is not.
What leaving it open costs you
A scope that reads “the production estate” gets resolved during the test, by the party with the least context on your business — and the report comes back covering something other than what you asked about.

Out of scope, in the same document

What settled looks like
Third-party services you do not own, shared infrastructure, and any system whose downtime you cannot absorb — named as explicitly as the in-scope list.
What leaving it open costs you
An exclusion that lives in somebody’s memory is not an exclusion. This is the one part of a scope that cannot be corrected after the fact.

Production or a staging environment

What settled looks like
Which one is under test, and where the two differ: data, configuration, protective controls in front of them, and whether rate limiting behaves the same way.
What leaving it open costs you
A staging environment with the protections switched off and seeded data produces findings that do not exist in production, and misses the ones that do.

A working credential for every role

What settled looks like
One account per role that exists, including the roles only an administrator can create, and confirmation that each one still works on the morning of kick-off.
What leaving it open costs you
Broken access control sits at A01 in the OWASP Top 10 2025, and it cannot be tested with a single account: the test is what role A can reach that belongs to role B.

Registration, MFA and throttling

What settled looks like
Whether test accounts self-register, how MFA is satisfied for a test account, and whether the tester’s source addresses need allow-listing.
What leaving it open costs you
A run that is throttled or blocked returns a clean result that looks identical to a clean system, and you find out which it was only on the next breach.

The movement boundary

What settled looks like
For any class that starts from a foothold — internal network, Active Directory, cloud where a role can be assumed — the segments, trust boundaries and accounts the test may move towards, agreed in writing beforehand.
What leaving it open costs you
“How far could an attacker get” becomes a judgement call taken mid-engagement instead of a measured answer against a boundary you set.

Who approves, and how fast

What settled looks like
Named people with a named channel for the actions that stop and wait, plus a deputy for each. Not a role mailbox.
What leaving it open costs you
A gate with no named approver stops the engagement rather than guarding it, and the pressure to waive it arrives exactly when you are least able to weigh it.

Evidence handling and residency

What settled looks like
What the test will hold, which region it is held in, how long it is kept, and how it is destroyed at the end.
What leaving it open costs you
Evidence of your weakest control, held somewhere nobody agreed to, is a second problem created by the work that was meant to find the first.

The window, and the contacts inside it

What settled looks like
Start and end dates, the hours testing may run, and one named contact on each side who is reachable during them.
What leaving it open costs you
An out-of-hours finding with nobody to send it to sits until morning, and the incident it describes does not.

What happens on a critical finding

What settled looks like
Whether a critical is raised the moment it is proved or waits for the report, to whom, and by what channel.
What leaving it open costs you
Reading about a proved critical for the first time in a PDF, a fortnight after it was found, is a process failure rather than a testing one.

The deliverable, in detail

What settled looks like
Report format, the standards it maps to and the version of each, whether raw evidence is attached, and whether the findings also land somewhere your engineers already work.
What leaving it open costs you
The format is negotiable before the engagement and fixed afterwards. Ask for the standards mapping now, not when the auditor asks you for it.

Retest terms

What settled looks like
Whether a retest is included, how long you have to use it, what it covers, and what happens when the fix does not hold.
What leaving it open costs you
A retest quoted as a fresh engagement, after the finding has been open long enough to matter, is the most expensive line item in this table.

The delivery model, and whose signature is on it

What settled looks like
Whether the output has to be signed for a filing. Where it does, the auditor who signs has to have been inside the engagement — which is a decision taken at scoping, not at delivery.
What leaving it open costs you
A technically sound report that nobody can sign is a report you have to buy twice.

One scoping fact is worth knowing before you write any of this down, because it changes what you ask for: B-52 covers eleven classes of assessment and excludes physical, hardware and wireless testing entirely. Where your programme needs those, they are a separate engagement with a separate scope. The coverage classes page sets out what each of the eleven needs from you before it can start.

The rows above are the ones a scope document has to answer. Our scope and authorisation template is the same list in a form you can send to a vendor, and the delivery models page covers the last row — coverage is identical across all three, so the model is a decision about whose signature the report carries and not about what gets tested.

The three that stop and ask

Three actions no test should take without written approval

Whoever you buy from, settle these three before kick-off. A proposal that does not name them has not been thought through, and that is checkable on the document in front of you today.

01 Gate one

Destructive or state-changing actions

What it covers
Anything that changes state on a live system rather than only reading from it: writing, deleting or modifying records, and any action whose failure mode is downtime.
Settle it here
Who may approve, through which channel, and inside what response time. Write the deputy down as well, because the approver is on leave the week the engagement runs.
What the gate is actually protecting
Your ability to run the test at all. A test that may change production state without asking is a test that gets scoped away from the systems that matter most, which is the opposite of what you bought.
02 Gate two

Persistence, and movement past the entry host

What it covers
Establishing a foothold that survives, and moving from the host first reached towards anything else — another segment, another trust, another account.
Settle it here
The movement boundary from the row above, expressed as named segments, trusts and accounts. Agreed before the run rather than reasoned about during it.
What the gate is actually protecting
The credibility of the answer. Movement inside a boundary you set is a measured result you can act on; movement decided in the moment is an anecdote, and it is the part of the report a board will ask about.
03 Gate three

Live credentials and real customer data

What it covers
Any step that uses a real user’s credentials, or that reaches records belonging to your customers rather than to seeded test accounts.
Settle it here
Whether the answer is simply no. Where seeded accounts and synthetic records answer the same question, they are the cheaper answer and the one with no aftermath.
What the gate is actually protecting
A test that touches real records is itself processing personal data. GDPR Article 32(1)(d) asks for a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures — and the testing it asks for sits under the same regulation as everything else you do with those records.

These are the three gates B-52 holds, and they are the same three on every one of the eleven coverage classes and in all three delivery models. The autonomy boundary sets out what runs without asking and what waits, and how we handle your data covers the evidence row from the table above.

While it runs

Six things you should be seeing before the report exists

An engagement you cannot see is an engagement you can only judge at the end, by which point the only lever left is the invoice. These are in the order they happen.

  1. Day one

    Kick-off confirms the scope you signed, not a new one

    Before anything is tested, the target list in the tester’s hands should be read back to you. Anything discovery turns up that is not on that list is a scope change, and it should reach you as a proposal you can decline rather than as work already done.

  2. Throughout

    You can see what is being tested while it is being tested

    Agreed at scoping and delivered however your vendor works: which targets are in progress and which have completed, at an interval you set. Where the only visibility is the final document, a slipped week and a week of work look exactly the same until the end.

  3. At each gate

    The run stops and waits for you

    The first approval request is the most informative event in the whole engagement, because it is the moment the boundary stops being a paragraph in a proposal. Note how it arrives, how it is described, and how long it waits.

  4. On discovery

    A proved critical reaches you before the report does

    You agreed the channel at scoping. This is where you find out whether it was agreed in practice. The test is whether the message contains enough for your team to act before the write-up exists.

  5. Before reporting

    What could not be proved is dropped, not downgraded

    A candidate that cannot be reproduced should leave the engagement rather than arrive as an informational item with a caveat attached. Ask what was dropped and why: the answer tells you how the severity column was populated.

  6. Close

    You are told what was in scope and never reached

    Coverage is part of the result. A target that was in scope and was not tested — because a credential never worked, or the window closed — is the fact you most need in writing, so ask for it by name at the close.

Whether a run drops what it could not prove is the item that separates two reports with the same finding count. The one that drops them is shorter, and truer. The methodology page sets out the phases behind these moments, and how B-52 runs a test covers where a candidate becomes a finding or leaves the engagement.

The report you get back

Twelve checks that work on anybody’s report

Nothing below depends on who wrote the document. Each check is a property you can confirm or fail with the report open — which is the only kind of check worth putting on a list, because it is the only kind a reader can actually run.

How to grade a penetration test report
What to checkA report that passesA report that fails
An exploit artefact per finding The request that triggered it, the response that came back, and the steps in the order they were taken — attached to the finding rather than available on request. A cropped screenshot of a tool pane, or a paragraph opening “it was observed that”, with nothing an engineer can replay.
Reproducible without calling the vendor Your own engineer follows the steps and sees the same result, using nothing the tester had that you do not. Run this check first, on the finding with the highest severity in the document. Steps that assume the tester’s session, tooling or network position, so the only way to confirm the finding is to book a call.
Severity carries its vector CVSS v4.0 with the full vector string printed beside the score, so you can see which metrics produced it and re-score it against your own environment. The word “High”, with no vector — which cannot be argued with, cannot be adjusted for a compensating control, and cannot be compared with the next report.
CVSS v4.0 was published in November 2023 by FIRST, which maintains the specification. Verified at source on 13 September 2026.
A weakness class, not only an instance A CWE identifier per finding, so the same defect appearing in three places is visibly one defect with three symptoms. Three unrelated-looking findings and three remediation tasks, for one missing check in one shared component.
The standard is named with its version OWASP Top 10 2025, WSTG v4.2, ASVS 5.0.0, API Security Top 10 2023, MASVS v2.1.0 with MASTG v2.0.0, Top 10 for LLM Applications 2025, NIST SP 800-115, PTES — and the ATT&CK or ATLAS release each mapping was made against. “Tested against OWASP.” That names a body, not a document, and a reader cannot tell which of its publications was used or how old it was.
Two version traps worth knowing before you read anyone’s report: WSTG v5.0 is in development, so a report citing it cites something that has not shipped; and the API Security Top 10 is the 2023 edition, so a report citing a later year cites a document that does not exist.
A negative result is recorded What was tested and held, alongside what broke — so a clean area is distinguishable from an area nobody reached. A findings list and nothing else, which reads identically whether the whole scope was covered or the days ran out on the second target.
Remediation is specific to your system The file and line, the parameter, the configuration key or the policy statement — and a fix written against the idiom your codebase already uses. “Implement input validation.” Generic advice is a link to documentation with a severity attached to it, and it moves no ticket forward.
The scope in the report is the scope you signed The target list, the window, the environment and the credentials used, reprinted in the report — with anything in scope that was not reached named explicitly. A scope section that describes the vendor’s offering rather than this engagement, so the document cannot be reconciled with the order you placed.
Findings carry a state, and it changes open, fixed, retested, closed — recorded where both sides can read the current position, rather than reconstructed from an exchange of emails. Findings with no state at all, so the current position lives in a spreadsheet somebody maintains by hand and which is accurate on the day it was written.
A finding closes on a retest Closed is reached only when the original steps have been re-run against the fix and could not reproduce the finding. Closed because a ticket was marked done, a date passed, or somebody said the change had shipped.
Summary and detail agree The counts, the severities and the risk narrative at the front reconcile with the findings behind them, line for line. An executive summary that reads as marketing for the test that produced it, with a total that does not match the table.
You know who stands behind it The report names how the test was run and the people behind it, and where a filing needs a signature, the signing auditor was inside the engagement. A signature block belonging to somebody who never saw the target, on a document produced by a process the report does not describe.

How to grade a penetration test report

An exploit artefact per finding

A report that passes
The request that triggered it, the response that came back, and the steps in the order they were taken — attached to the finding rather than available on request.
A report that fails
A cropped screenshot of a tool pane, or a paragraph opening “it was observed that”, with nothing an engineer can replay.

Reproducible without calling the vendor

A report that passes
Your own engineer follows the steps and sees the same result, using nothing the tester had that you do not. Run this check first, on the finding with the highest severity in the document.
A report that fails
Steps that assume the tester’s session, tooling or network position, so the only way to confirm the finding is to book a call.

Severity carries its vector

A report that passes
CVSS v4.0 with the full vector string printed beside the score, so you can see which metrics produced it and re-score it against your own environment.
A report that fails
The word “High”, with no vector — which cannot be argued with, cannot be adjusted for a compensating control, and cannot be compared with the next report.

CVSS v4.0 was published in November 2023 by FIRST, which maintains the specification. Verified at source on 13 September 2026.

A weakness class, not only an instance

A report that passes
A CWE identifier per finding, so the same defect appearing in three places is visibly one defect with three symptoms.
A report that fails
Three unrelated-looking findings and three remediation tasks, for one missing check in one shared component.

The standard is named with its version

A report that passes
OWASP Top 10 2025, WSTG v4.2, ASVS 5.0.0, API Security Top 10 2023, MASVS v2.1.0 with MASTG v2.0.0, Top 10 for LLM Applications 2025, NIST SP 800-115, PTES — and the ATT&CK or ATLAS release each mapping was made against.
A report that fails
“Tested against OWASP.” That names a body, not a document, and a reader cannot tell which of its publications was used or how old it was.

Two version traps worth knowing before you read anyone’s report: WSTG v5.0 is in development, so a report citing it cites something that has not shipped; and the API Security Top 10 is the 2023 edition, so a report citing a later year cites a document that does not exist.

A negative result is recorded

A report that passes
What was tested and held, alongside what broke — so a clean area is distinguishable from an area nobody reached.
A report that fails
A findings list and nothing else, which reads identically whether the whole scope was covered or the days ran out on the second target.

Remediation is specific to your system

A report that passes
The file and line, the parameter, the configuration key or the policy statement — and a fix written against the idiom your codebase already uses.
A report that fails
“Implement input validation.” Generic advice is a link to documentation with a severity attached to it, and it moves no ticket forward.

The scope in the report is the scope you signed

A report that passes
The target list, the window, the environment and the credentials used, reprinted in the report — with anything in scope that was not reached named explicitly.
A report that fails
A scope section that describes the vendor’s offering rather than this engagement, so the document cannot be reconciled with the order you placed.

Findings carry a state, and it changes

A report that passes
open, fixed, retested, closed — recorded where both sides can read the current position, rather than reconstructed from an exchange of emails.
A report that fails
Findings with no state at all, so the current position lives in a spreadsheet somebody maintains by hand and which is accurate on the day it was written.

A finding closes on a retest

A report that passes
Closed is reached only when the original steps have been re-run against the fix and could not reproduce the finding.
A report that fails
Closed because a ticket was marked done, a date passed, or somebody said the change had shipped.

Summary and detail agree

A report that passes
The counts, the severities and the risk narrative at the front reconcile with the findings behind them, line for line.
A report that fails
An executive summary that reads as marketing for the test that produced it, with a total that does not match the table.

You know who stands behind it

A report that passes
The report names how the test was run and the people behind it, and where a filing needs a signature, the signing auditor was inside the engagement.
A report that fails
A signature block belonging to somebody who never saw the target, on a document produced by a process the report does not describe.

The state row, expanded — because it is where reports quietly fail

A finding with no state is a finding nobody can report on. Four states are enough, and the discipline is entirely in the last one: closed has exactly one route into it.

The four states a finding moves through
StateWhat it meansWhat it gets you
Open Proved, reported, and not yet fixed. The exploit artefact is attached, so an engineer can start on it without a call.
Fixed You have made the change and said so. Your assertion, and nothing has yet been re-run against it. Worth tracking separately for that reason.
Retested The original steps have been run again against the fix. Either the finding reproduces and returns to open, or it does not and it closes.
Closed Terminal A retest could not reproduce it. The only route into this state, which is what makes the count of closed findings worth reporting upwards.
Key
  • Unresolved
  • Asserted by you, not yet verified
  • Under verification
  • Verified, and the only terminal state
  • TerminalNo state follows this one
The standard versions these checks rest on, and the date each was read As of September 2026
  • OWASP Top 10 2025 superseded the 2021 edition in January 2026. SSRF is absorbed into A01 Broken Access Control, and A07 is renamed Authentication Failures. Read 13 September 2026.
  • OWASP Web Security Testing Guide v4.2 is the current stable release. v5.0 is in development, so a report citing v5.0 is citing a document that has not shipped. Read 13 September 2026.
  • OWASP ASVS 5.0.0, May 2025, seventeen categories — the first major release in six years. A report still written against 4.0.3 is working from a superseded document.
  • OWASP MASVS v2.1.0 with MASTG v2.0.0. MASVS-PRIVACY arrived at v2.1.0, and the verification levels became MAS Testing Profiles at v2.0.0 — so “MASVS Level 2” is a retired construct, and a report citing it tells you roughly when it was written.
  • OWASP API Security Top 10 2023 is the current edition, and the only major update since 2019. A report citing a 2025 or 2026 edition is citing a document that does not exist. Read 13 September 2026.
  • OWASP Top 10 for Large Language Model Applications 2025, released 12 March 2025, entries LLM01 to LLM10. Read 14 September 2026.
  • NIST SP 800-115, final, September 2008 — neither withdrawn nor superseded, so the date is not a defect. Read 13 September 2026.
  • CVSS v4.0, November 2023, published and maintained by FIRST. Read 13 September 2026.
  • MITRE ATT&CK v19.2, released 6 August 2026. MITRE ATLAS publishes on a rolling cadence, so a report should name the ATLAS release each finding was mapped against rather than a version fixed here. Read 13 September 2026.
  • PTES is cited as current. CIS Benchmarks are published per cloud provider on separate cadences, so a report should name the benchmark and version it was worked against rather than a single pinned number.

Deliberately excluded

  • PCI DSS, ISO/IEC 27001, SOC 2, GDPR and the HIPAA Security Rule. They set cadence and evidence obligations, so they sit in the table below with the clause each rests on and the date each was read.
  • Any standard no check above rests on. Naming a document nothing here tests against would pad the list and make the rest harder to verify.

Run the list against us as readily as against anyone else. Every B-52 finding leaves with the request, the response and the steps to reproduce it, a CVSS v4.0 vector beside the severity and a CWE beside that; findings carry open, fixed, retested and closed, and close only on a retest that cannot reproduce them. Validation and proof sets out how that is measured, and the glossary defines the terms in the table if any of them are new.

How often

The clause behind the date in your calendar

A cadence is easy to carry as a number someone remembers rather than as a clause someone read. These are the clauses, at the versions in force and each read at source in September 2026, so you can check the date in your programme against the sentence it is supposed to come from.

Penetration testing cadence by framework, and the clause each rests on
FrameworkClauseWhat it asks for
PCI DSS v4.0.1 Requirement 11.4.3 External penetration testing at least once every twelve months, and after any significant infrastructure or application upgrade or change. The v4.x requirements have been in force since 31 March 2025.
The PCI SSC’s own Penetration Testing Guidance, v1.1 of September 2017, is the document a QSA reads alongside the requirement. A report written to it is easier to assess than one that is not.
PCI DSS v4.0.1 Requirement 6.2.3 Bespoke and custom software reviewed prior to release into production. It is a code-review obligation, so it is scoped against your repositories and your release process.
ISO/IEC 27001 2022, with Amendment 1:2024 Ninety-three Annex A controls across four categories. Amendment 1:2024 made the climate-action changes to clause 4.1. Testing produces evidence against those controls; the certificate is issued by a certification body.
SOC 2 CC7.1 and CC4.1 The 2017 Trust Services Criteria with the 2022 revised points of focus: CC7.1 covers vulnerability monitoring, CC4.1 covers evaluations. The report is the service auditor’s; testing evidence feeds it.
GDPR Article 32(1)(d) A process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of processing.
HIPAA Security Rule 45 CFR 164.308(a)(1)(ii)(A) and 164.308(a)(8) A risk analysis, and a periodic technical and non-technical evaluation — the provisions in force today.
The Notice of Proposed Rulemaking published on 6 January 2025 would add six-monthly vulnerability scanning and annual penetration testing. It is a proposal, not law: OMB’s Unified Agenda carries it as RIN 0945-AA22 with a July 2027 target. Plan against it if you wish; do not file against it.

Penetration testing cadence by framework, and the clause each rests on

PCI DSS v4.0.1

Clause
Requirement 11.4.3
What it asks for
External penetration testing at least once every twelve months, and after any significant infrastructure or application upgrade or change. The v4.x requirements have been in force since 31 March 2025.

The PCI SSC’s own Penetration Testing Guidance, v1.1 of September 2017, is the document a QSA reads alongside the requirement. A report written to it is easier to assess than one that is not.

PCI DSS v4.0.1

Clause
Requirement 6.2.3
What it asks for
Bespoke and custom software reviewed prior to release into production. It is a code-review obligation, so it is scoped against your repositories and your release process.

ISO/IEC 27001

Clause
2022, with Amendment 1:2024
What it asks for
Ninety-three Annex A controls across four categories. Amendment 1:2024 made the climate-action changes to clause 4.1. Testing produces evidence against those controls; the certificate is issued by a certification body.

SOC 2

Clause
CC7.1 and CC4.1
What it asks for
The 2017 Trust Services Criteria with the 2022 revised points of focus: CC7.1 covers vulnerability monitoring, CC4.1 covers evaluations. The report is the service auditor’s; testing evidence feeds it.

GDPR

Clause
Article 32(1)(d)
What it asks for
A process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of processing.

HIPAA Security Rule

Clause
45 CFR 164.308(a)(1)(ii)(A) and 164.308(a)(8)
What it asks for
A risk analysis, and a periodic technical and non-technical evaluation — the provisions in force today.

The Notice of Proposed Rulemaking published on 6 January 2025 would add six-monthly vulnerability scanning and annual penetration testing. It is a proposal, not law: OMB’s Unified Agenda carries it as RIN 0945-AA22 with a July 2027 target. Plan against it if you wish; do not file against it.

Findings land on the controls a framework names, and that is where testing stops. A certificate or an attestation is issued by a certification body, or by an auditor appointed for the purpose — separate work, and not work we do. Security Brigade has been CERT-In empanelled since 2008 and holds ISO 27001 certification; where a filing needs a signature under that empanelment, the auditor who signs has to have been inside the engagement.

The standards mapping shows which control each finding class lands on, and the compliance index carries a page per framework with the instrument it rests on and the date that instrument was read.

Take the third list into your next vendor call

Ask any vendor for one finding from a recent report, redacted, with its exploit artefact and its CVSS vector attached. Either it arrives with the request, the response and the steps to reproduce it, or it does not — and that is a shorter conversation than the one you would otherwise have after the engagement.

Run a scan Request a scoping call