ISO 27001 and Penetration Testing: What You Decide, What Your Auditor Needs to See
The pre-read list from the auditor has a line that says “evidence of technical security testing”. You have a penetration test report from last spring. Somebody, at some point, decided testing would be annual. You can’t quite point to where that was written down.
That gap is what this piece is about. People look for the clause in ISO/IEC 27001 that says “run a penetration test every year”, and there isn’t one. The standard gives you no test type and no schedule. It asks whether you can show that you chose your testing on purpose, and the report is only one link in that chain. What an auditor follows is the line from risk to test to fix to retest.
What the standard leaves to you
ISO/IEC 27001:2022 is the standard for an information security management system. Certificates issued under the 2013 edition were no longer valid after October 31, 2025, so whatever you hold or are working toward now is against the 2022 edition. Snipeyes is certified to it too. We are a testing firm, not a certification body, so the final word on what counts sits with your auditor.
The standard works through risk. You identify the risks to your information, decide which controls you need to treat them (from any source), and check your list against Annex A so nothing necessary is missed. The statement of applicability records which controls apply, why, and why any Annex A control is left out. Security testing appears in Annex A (8.29), but whether and how much of it a given system needs is your call, and the risk assessment is where you make it.
Two controls, and what could go in the file for each
Two Annex A controls bear on technical testing. The third row of the table isn’t a control at all, but it’s the document the other two depend on.
| Where it lives | What it asks, in plain words | How a penetration test can serve it | Evidence that could go in the file |
|---|---|---|---|
| Annex A 8.8, Management of technical vulnerabilities | Find out about technical weaknesses, work out how exposed you are, act on it | Shows which of the weaknesses found can be exploited, with proof | Test dates and scope. Findings with proof. An owner and a date for each fix. The retest result. |
| Annex A 8.29, Security testing in development and acceptance | Define and carry out security testing as part of how you build and accept systems | Gives a new or changed application a defined security test before go-live | The release it was run against. The method followed (OWASP WSTG for web, for example). The sign-off that followed the result. |
| Risk assessment and statement of applicability | Say which systems justify which kind of testing, and why | The test shows the decision was carried out | A short written rationale, approved by whoever owns the risk. |
Notice what isn’t in the table: a required test type or a frequency. Those are yours to set. NIST SP 800-115 can structure the overall process and OWASP WSTG the web application work, and naming them is your decision.
A testing decision you could write today
A report on its own doesn’t show the reasoning. A paragraph is enough. Something like this, with your own systems and rhythm filled in:
[System A] handles [customer data or payments] and is exposed to the internet. We test it with a penetration test [before each major release and on a regular cycle], by a team independent of the one that built it, following [OWASP WSTG]. Findings rated [high or critical] are fixed by [owner] within [timeframe], then retested. [System B] is internal and lower risk; we run vulnerability scanning on [cycle] and test it after major change. The CISO reviews results and signs off.
If you aren’t sure whether a system needs the test or the lighter check, our comparison of vulnerability assessment and penetration testing lays out what each one delivers.
What the file should show for a finding
For 8.8 the evidence looks different from a release sign-off. In a core banking system we tested, the findings were an over-privileged service account and terminal sessions that could be hijacked. The fixes were locking the credentials away and adding encryption and access rules. For 8.8, the file should show how each was found, who owned the fix, and when it was fixed.
Then comes the last step. A report shows a problem existed; a retest, with a date and a name, shows it stopped existing. We include the retest in our engagements, and it’s the step that closes the record.
When the same test has to satisfy someone else
If you carry other attestations, one well-planned test can feed several reviews, although none of them is bound by what another decided. PCI DSS 4.0.1 is prescriptive: pen testing at least every 12 months and after significant change, by a qualified tester who is organizationally independent, with fixes retested. For SOC 2, CC4.1 lists penetration testing among its example separate evaluations, the points of focus are illustrative, and vulnerability scanning belongs under CC7.1. Our guide to penetration testing evidence for audit sets the three side by side.
Questions readers ask
Does ISO 27001 say how often to run a penetration test? ISO/IEC 27001 sets no test type and no cadence. Your risk assessment decides what is tested, how often and by whom, and your certification body decides whether the record behind that decision holds up.
Can one penetration test serve an ISO 27001 audit and other audits? Yes, if the scope and the report were planned for it. PCI DSS and SOC 2 read the evidence in their own way, and each reviewer makes their own call.
Before the next audit
Write the decision paragraph for your two or three most exposed systems, and make sure each ties to a named test, a fix record and a retest. Ask your testing provider how the report ties findings to the standards you’re audited against. Ours links findings to ISO/IEC 27001:2022, SOC 2, PCI DSS 4.0 and OWASP ASVS. It’s a single report that the executive team, the engineers and your auditor can each pick up and use. Our penetration testing is how we run it.
Bring your testing-decision paragraph to the free 90-minute scoping session and we’ll work through scope against it. Already know what you need? Request a scoped proposal.