ISO 27001 Penetration Testing Requirements: What Annex A 8.8 Says and What Auditors Ask For
"Where in ISO 27001 does it say we need a penetration test?"
Nowhere. You can read the standard cover to cover and never find the phrase. Teams raise this while planning a certification budget, and as far as the text goes, they are correct. Then the Stage 2 audit arrives, the auditor asks how you verified that your technical controls withstand attack, and a patch report is the only answer available. That conversation typically ends in a finding.
The expectation comes from three requirements working together. Annex A control 8.8 requires you to identify technical vulnerabilities and evaluate your exposure to them. Control 8.29 requires security testing in development and at acceptance. And Clause 9.1, the requirement teams most often overlook, requires you to evaluate whether your controls perform as intended. A scanner can confirm a patch is installed. Only an attack can confirm the control holds. A penetration test is how that evidence gets produced in writing, and auditors treat it as the standard answer.
Two controls added in the 2022 revision feed the same evidence file. A 8.28 (secure coding) is evidenced day to day by code review and SAST tooling, but pentest findings that trace back to coding flaws show whether the control works in practice. A 5.7 (threat intelligence) accepts pentest reports as input, since they document real attack techniques used against your environment.
The six-item evidence set auditors request
Running the test is half the work. Clause 7.5 requires documented information, and in our experience preparing Thai organizations for certification, auditors request the same six items almost every time:
- The methodology and the testers' identity, independent of whoever built the system
- Findings with severity ratings and a risk evaluation for each
- Proof that fixes were applied and retested, per finding
- A vulnerability management process with named remediation owners and severity-based deadlines
- A testing schedule aligned with your risk treatment plan and ISMS scope
- Management review records showing the results reached leadership
Item 3 is where audits most often fail. A pentest report from eleven months ago with ten open critical findings and no retest evidence is worse than no report at all, because it documents that the organization knew and did not act. This is why our PROVE framework treats the retest as the step that closes a finding: the closure evidence it produces is precisely the artifact the auditor asks to see.
Mapping results to controls efficiently
ISMS leads regularly ask how granular the control mapping needs to be, often after someone proposes a control-by-control matrix for every finding. That level of detail is unnecessary. One table in your vulnerability management record covers the requirement:
| Evidence | Primary control | Secondary |
|---|---|---|
| Quarterly VA scan reports | A 8.8 | Clause 9.1 |
| Annual penetration test report | A 8.8, Clause 9.1 | A 5.7 |
| Pre-release pentest of new systems | A 8.29 | A 8.25, A 8.28 |
| Retest and closure evidence | A 8.8 | Clause 10 |
| Findings entered into the risk register | Clause 6.1.2 | A 5.7 |
Beyond that, ask your test provider to include a one-page compliance mapping section inside the report itself. That single page answers the traceability question in nearly every audit. Greater granularity consumes effort without changing the audit outcome.
The errors that genuinely cost certifications are scoping errors, not mapping errors. If your Statement of Applicability covers the customer portal and the internal HR system, a pentest of the portal alone leaves a gap the auditor will examine. Equally, a vulnerability scan is not a substitute for the penetration test: the two answer different halves of A 8.8, and surveillance audits increasingly request both. We cover that distinction in detail in VA vs pentest.
Testing frequency and timing
The standard sets no interval, which means your risk treatment plan must. The cadence that passes audits consistently: a full penetration test annually, timed so the report is current at your certification or surveillance audit; VA scans quarterly, or monthly for internet-facing systems; and a targeted retest after each significant change, meaning a new application, a major release, an infrastructure migration, or a security incident.
Record this cadence in your vulnerability management procedure. Well-executed tests that run ad hoc, with no documented schedule, still draw findings, because the auditor is assessing the management system, and an unscheduled test is evidence the system is not operating.
On timing: test before Stage 2, with enough room to remediate and retest. Three months ahead is comfortable. Three weeks ahead means the report arrives at the audit with open critical findings, which defeats its purpose as evidence.
One test, three regulators
Thai organizations rarely pursue ISO 27001 in isolation, and the overlap works in your favor. BOT's IT risk guidelines independently require annual third-party penetration testing for financial institutions. PDPA Section 37 requires "appropriate" security measures, and when the PDPC evaluates that standard after a breach, a current pentest report is the strongest evidence available. One well-scoped annual test serves all three frameworks: set the boundary at your ISMS scope, add the regulator-specific systems (mobile banking channels for BOT, personal data processing systems for PDPA), and present the same report to each.
The control-by-control breakdown, including what A 8.8 evidence looks like in practice, is on our ISO 27001 penetration testing page.
Preparing for certification and unsure whether your testing evidence will hold up? Send us your audit date. We scope ISO-aligned penetration tests for Thai organizations, include the compliance mapping page auditors ask for, and return a proposal within 48 hours.
Related Reconix services
- Penetration Testing Annual and pre-release testing with PoC evidence and a retest cycle that produces closure documentation
- Vulnerability Assessment Quarterly scanning with expert verification, mapped to A 8.8
- ISO 27001 Compliance Testing Control-by-control evidence requirements and audit-ready reporting
