ISO/IEC 27001:2022 asks you to determine the controls necessary to treat your information security risks, compare them against Annex A, and record the result in a Statement of Applicability. A B-52 engagement produces an input to that record: findings reported under the Annex A control they bear on, each carrying the exchange that proved it and the retest that closed it.
Findings to controls
A test is an input to a control, not the control. What an engagement can do is put the evidence in front of you already carrying its control reference, so the person assembling the evidence pack is not re-deriving it from a finding title.
| Annex A control | What the engagement puts against it |
|---|---|
| Annex A 8.8 — Management of technical vulnerabilities | The finding set itself: what proved exploitable on the systems in scope, each with the request and response that demonstrated it, a CVSS v4.0 severity with the vector printed, and the CWE. Findings carry through open, fixed, retested and closed, so one record shows both what was found and what was subsequently shut. |
| Control number and title read 2026-09-14 from the contents of ISO/IEC 27002:2022, the guidance standard from which Table A.1 of ISO/IEC 27001:2022 is derived. The number is cross-checked against ENISA’s published mapping table, version 1.2, September 2025, which is used here for numbering alone. The control statement sits behind the ISO paywall and is named here rather than quoted. | |
| Annex A 8.29 — Security testing in development and acceptance | An engagement run against a build before that build is accepted, with the scope, the authorisation and the dates recorded beside the result. Where testing forms part of how a release is accepted, this is the artefact that shows it ran and what it covered. |
| Title corroborated in two ISO-published documents, both read 2026-09-14: the contents of ISO/IEC 27002:2022 and of ISO/IEC FDIS 27002. | |
| Annex A 8.33 — Test information | The third approval gate. Where a run would use live credentials or real customer data, it stops and holds until a named person authorises it, and that decision is recorded with its timestamp. The gate applies on every coverage class and in all three delivery models. |
| Title read 2026-09-14 from the contents of ISO/IEC 27002:2022. | |
| Annex A 8.34 — Protection of information systems during audit testing | The first two approval gates. Destructive or state-changing actions stop for authorisation, and so does persistence or movement past the entry host. Each request to proceed, and each refusal, is in the engagement record. |
| Title read 2026-09-14 from the contents of ISO/IEC 27002:2022. ENISA’s mapping table, version 1.2, groups 8.29, 8.33 and 8.34 together under security testing. | |
Annex A 8.8 — Management of technical vulnerabilities
Control number and title read 2026-09-14 from the contents of ISO/IEC 27002:2022, the guidance standard from which Table A.1 of ISO/IEC 27001:2022 is derived. The number is cross-checked against ENISA’s published mapping table, version 1.2, September 2025, which is used here for numbering alone. The control statement sits behind the ISO paywall and is named here rather than quoted.
Annex A 8.29 — Security testing in development and acceptance
Title corroborated in two ISO-published documents, both read 2026-09-14: the contents of ISO/IEC 27002:2022 and of ISO/IEC FDIS 27002.
Annex A 8.33 — Test information
Title read 2026-09-14 from the contents of ISO/IEC 27002:2022.
Annex A 8.34 — Protection of information systems during audit testing
Title read 2026-09-14 from the contents of ISO/IEC 27002:2022. ENISA’s mapping table, version 1.2, groups 8.29, 8.33 and 8.34 together under security testing.
What the mapping is
Clause 6.1.3 b) requires the organisation to “determine all controls that are necessary to implement the information security risk treatment option(s) chosen”. A control determined that way is a standing arrangement: somebody owns it, it operates, and it is audited as something that operates. A penetration test feeds it. The test says what proved exploitable on a given date within a given scope, which is evidence about how the arrangement is performing. So reporting a finding under Annex A 8.8 states where that finding belongs in your control set, and the conclusion about the control stays with the auditors who reach it. The practical effect is small and worth naming: the control reference travels inside the report, your evidence pack assembles faster, and the judgement sits with the people whose judgement it is.
Clause 6.1.3
Information security risk treatment is one clause, and it is the clause that decides which controls your organisation is actually audited against. Read at source on 2026-09-14 in the third edition, dated 2022-10.
6.1.3 b)
The organisation is to “determine all controls that are necessary to implement the information security risk treatment option(s) chosen”. NOTE 1 to the clause provides that controls can be designed as required, or identified from any source.
6.1.3 c)
Then “compare the controls determined in 6.1.3 b) above with those in Annex A and verify that no necessary controls have been omitted”. NOTE 2 describes Annex A as “a list of possible information security controls”, and NOTE 3 provides that additional controls can be included if needed. Annex A carries 93 controls in four categories — organisational, people, physical and technological.
6.1.3 d)
The document a certification audit works from. The clause requires it to contain the necessary controls, “justification for their inclusion”, “whether the necessary controls are implemented or not”, and “the justification for excluding any of the Annex A controls”. That last phrase is what decides how your test evidence is read: a control you have included is a control you will be asked to evidence.
Sourcing
Every clause number, control number and control title above came from one of these, and each was read on the date recorded here.
Deliberately excluded
Whose signature it carries
All three models cover all eleven coverage classes and run the same three approval gates. The choice is about who stands behind a finding when the report goes into a pack somebody outside your team will read.
| State | What it means | What follows |
|---|---|---|
| Autonomous, expert verified | A senior Security Brigade auditor verifies every finding before any of it reaches you, and the report goes out under a name. | The starting point wherever the report is read outside your own team. |
| Human led | A senior auditor runs the engagement with B-52 underneath — sets the scope, directs where the depth goes, and owns what the engagement produces. | For an unusual architecture, or a first certification cycle. |
| Fully autonomous Terminal | Scope sign-off, and then nothing until the findings land. No verifier sits inside the engagement. | Coverage in the months between audits. Entry tier is $500 for one scan of one application or target. |
Routing
The audience for an ISO 27001 evidence pack is not your engineering team. It is an auditor from a certification body, reading a document whose provenance is part of what is being assessed. A finding a senior Security Brigade auditor has verified arrives with a person attached to it; an unverified finding arrives as output. The coverage behind both is identical across the same eleven classes, and the difference is entirely in who stands behind the result — which is why the expert-verified model is the one to start from when the report travels, and why the fully autonomous model earns the months in between. That tier is stronger than its price suggests: run in parallel with Security Brigade’s expert assessment team against the same targets, with both sets of findings pooled and each item counted once, B-52 reached 90–95% of the pooled set. What the verified models add on top of that is the verification itself.
What arrives
The same artefacts on every engagement and in every delivery model. What changes between models is who checked them, never what they contain.
The request that triggered it and the response that came back, with the section demonstrating the defect marked, and reproduction steps written for an engineer of yours who was not in the room when it was found.
CVSS v4.0 with the vector printed rather than the score alone, and the CWE beside it. An auditor who reads the rating differently can see exactly what it was built from.
The control number and its title, inside the report. The mapping travels with the finding instead of living in a spreadsheet somebody maintains separately.
The targets inside the boundary, the named person who authorised them, the dates the testing ran between, and the decision taken at each of the three approval gates while it did.
Findings carry through open, fixed, retested and closed, and close on a retest that cannot reproduce them. A closed finding is a retest result rather than an assertion that somebody fixed it.
Three moments
An evidence pack is read months after the testing, by somebody who was not there. These are the three points where a record is created, and what each one answers when it is opened later.
The boundary
On a standard quoted this widely, the rounding-up a vendor is tempted into happens inside a single word: certified for accredited, or closed for mapped.
| The position | |
|---|---|
| Certificates come from certification bodies | Security Brigade is ISO 27001 certified. It is a certified organisation rather than a certification body, and it issues certificates to nobody. ISO/IEC 27006-1:2024 specifies requirements for bodies providing audit and certification of an ISMS, in addition to the requirements contained within ISO/IEC 17021-1, and a certificate comes from a body meeting them. |
| Scope of ISO/IEC 27006-1:2024, first edition 2024-03, read 2026-09-14. | |
| Certified, not accredited | An organisation is certified. A certification body is accredited. The two words name different parties holding different instruments, and this site uses the first about Security Brigade because that is the one it holds. |
| Mapping, not issuing | Findings are reported under the Annex A control they bear on. That is a mapping, and it produces evidence. Whether a control is implemented and effective is a conclusion reached by the audit that examines it. |
| What a certificate attests | Certification attests that a management system conforming to the standard operates within a defined scope. The scope statement on the certificate is the part worth reading — on ours, and on anybody else’s. |
| The determination is yours | Which controls are necessary for your organisation is settled by your own risk treatment and recorded in your Statement of Applicability, with your auditors. What this page states is what an engagement produces, and which controls the findings are named to. |
Certificates come from certification bodies
Scope of ISO/IEC 27006-1:2024, first edition 2024-03, read 2026-09-14.
Certified, not accredited
Mapping, not issuing
What a certificate attests
The determination is yours
Adjacent obligations
ISO 27001 is an international standard, and it binds a particular organisation through a contract, a tender, or a separate regulation that imports it. That matters here because an ISMS scope can overlap an obligation arriving from somewhere else entirely. An Indian entity filing under a regulator may need the testing itself carried out by a CERT-In empanelled organisation, which is a question about the delivery model rather than about this standard. Security Brigade has been CERT-In empanelled since 2008, and the CERT-In regime page sets out, instrument by instrument, where empanelled delivery is written down. Those two threads meet in the same engagement, and they are answered by the same scoping conversation.
A scoping call settles which systems sit inside your ISMS scope, which coverage classes the engagement needs, and which delivery model the report has to travel under once it leaves your team.