Compliance
ISO 27001 and penetration testing
ISO 27001 never uses the words penetration testing. It is still the reason most of our clients book one, because several Annex A controls are close to impossible to evidence without a test. Here is what the standard actually asks for, and what an auditor actually wants to see.
9 min read
Key takeaways
- Penetration testing is not mandated by ISO 27001. The standard requires that technical vulnerabilities are identified, evaluated and addressed, and leaves the method to you.
- A test is evidence for A.8.8, and for A.8.29 where you build software. Those are the two controls auditors most often probe with a testing question.
- The Statement of Applicability is where you commit to a method. If it says testing, the auditor will ask for the report and the retest.
- Annual is the working norm, plus after significant change. The standard sets no interval, so yours has to come from your own risk assessment and be written down.
- A test cannot certify you. Certification is issued by an accredited certification body after a Stage 1 and Stage 2 audit, and no testing supplier can shorten that.
What the standard actually says
ISO/IEC 27001:2022 does not contain the phrase penetration testing. There is no clause to point at the way PCI DSS has Requirement 11.4. What the standard requires is an information security management system: a risk assessment, a set of controls chosen in response to it, and evidence that the controls work. Testing is one way of producing that evidence, and for some controls it is by far the most direct one.
That is why the honest answer to "is a penetration test mandatory for ISO 27001" is no, and why it is also the wrong question. The useful question is which controls you have declared applicable, and what you intend to show an auditor for each.
The Statement of Applicability is the document that decides this
The SoA lists every Annex A control, whether it applies to you, and how it is implemented. If yours says technical vulnerabilities are managed through periodic independent testing, you have written your own requirement and the auditor will hold you to it. Many organisations write exactly that and are then surprised to be asked for the report.
The controls a test gives you evidence for
Annex A in the 2022 revision has 93 controls across four themes. A penetration test is relevant to a handful of them, and pretending otherwise is how a supplier ends up selling a test as an ISO 27001 solution. These are the ones where a report is genuinely useful evidence.
| Control | Title | What a test contributes |
|---|---|---|
| A.8.8 | Management of technical vulnerabilities | The central one. A test identifies vulnerabilities in systems in use and evaluates exposure to them; the retest evidences that the response happened. |
| A.8.29 | Security testing in development and acceptance | Applies if you build software. A test in a pre-release environment, run to a defined methodology, is the evidence this control describes. |
| A.8.25 | Secure development life cycle | Testing at a defined stage of the lifecycle, rather than only after release, is part of showing the lifecycle exists. |
| A.8.28 | Secure coding | Findings that trace to coding practice support the case; a secure code review evidences it more directly than a black box test. |
| A.5.35 | Independent review of information security | An external tester is independent of the team that built the system, which is the property this control asks for. |
Note what is not on that list. A test says nothing about your access control policy, your supplier relationships, your incident response or your business continuity arrangements. Those are the bulk of Annex A and none of them are evidenced by a report.
What an auditor actually asks to see
Auditors vary, but the sequence is predictable. They start from your SoA, find what you committed to, and ask you to demonstrate it. For a testing commitment that means four things, and the third is the one organisations most often cannot produce.
- The report itself, dated, with a defined scope and a stated methodology.
- Evidence that the scope covers the systems inside your ISMS boundary, rather than a convenient subset of them.
- Evidence that the findings were triaged, assigned and either fixed or formally risk-accepted, with dates.
- Evidence that the fixes were verified, which usually means a retest or a documented equivalent.
The third and fourth items are why a report on its own is a weak answer. A finding list with no disposition shows that you looked; it does not show that you managed anything, and A.8.8 is a management control. Our engagements record the triage and the hand-verified retest alongside the finding, so the trail is one artefact rather than a report plus a spreadsheet somebody maintained separately.
How often, and when
The standard sets no interval. That is genuinely open, and it is also a trap: an interval you cannot justify from your own risk assessment is a finding waiting to happen. In practice three triggers cover most certified organisations.
- Annually, as a baseline, which is what most certification bodies expect to see and what most SoAs end up saying.
- After significant change to a system in scope - a new authentication model, a new public interface, a migration between hosting providers.
- Where your own risk assessment says more often, which for an internet-facing product handling personal data usually means more often than once.
Surveillance audits are annual, so the gap matters
Certification runs on a three-year cycle with surveillance audits in between. A test that lands two months before the surveillance audit and is never repeated leaves the following year thin. Spreading testing across the cycle, or monitoring the estate between engagements, is easier to defend than a single dated report.
Scope: the ISMS boundary against the test scope
The two are not the same thing and the difference is where audits go wrong. Your ISMS boundary is declared in your scope statement and covers people, processes and systems. A test scope is a list of hosts, applications and accounts. The question an auditor asks is whether the second is a defensible sample of the first.
A test scope that survives the question
- Covers the systems that process or store the information the ISMS is there to protect, not only the ones that are easy to test.
- States what was excluded and why, in the report rather than in an email nobody kept.
- Includes internal as well as external attack surface where the boundary includes an internal network.
- Names the environment tested, and if it was not production, says how it differs.
If you are not sure where the line falls, that is a scoping conversation rather than a testing one. Our guide to scoping a penetration test covers what a tester needs to know before quoting.
What a test cannot do for you
ISO 27001 certification is issued by an accredited certification body after a Stage 1 audit of your documentation and a Stage 2 audit of your implementation. No testing supplier can issue it, shorten it, or guarantee its outcome, and any supplier implying otherwise is telling you something about themselves.
What a test does is remove one class of audit finding and give you a defensible answer to a specific set of questions. That is worth buying on its own terms. It is not a certification service, and the same is true of the SOC 2 and PCI DSS engagements alongside it.