1. ISO 27001:2022 Controls That Require Penetration Testing
ISO 27001:2022 is organized around Clauses 4–10 (mandatory requirements) and Annex A (controls). Penetration testing is relevant to several controls across both — but three are central:
The Primary Penetration Testing Control
"Information about technical vulnerabilities of information systems in use shall be obtained in a timely fashion, the organization's exposure to such vulnerabilities evaluated, and appropriate measures taken to address the associated risk." ISO 27002:2022 (the implementation guidance document) explicitly names penetration testing as the preferred method for evaluating actual exposure — distinguishing it from vulnerability scanning, which only identifies potential vulnerabilities without confirming exploitability.
Performance Evaluation Requirement
"The organization shall evaluate the information security performance and the effectiveness of the information security management system." Penetration testing is one of the primary mechanisms for evaluating ISMS effectiveness — because it tests whether security controls are actually preventing unauthorized access, not just whether they are implemented and documented.
Pre-Release Testing Requirements
"Security testing processes shall be defined and implemented in the development life cycle." For organizations with active product development, penetration testing of new features or significant changes to existing systems satisfies this control — demonstrating that security is tested before deployment, not only after.
Compliance Verification
"Compliance with the organization's information security policy, topic-specific policies, rules and standards shall be regularly reviewed." Penetration testing verifies that your documented security policies and controls are actually being enforced at a technical level — closing the loop between policy documentation and operational reality.
2. What ISO 27001:2022 Changed from 2013
The 2022 revision restructured Annex A from 114 controls in 14 domains to 93 controls in 4 themes (Organizational, People, Physical, Technological). The changes most relevant to penetration testing:
- A.8.8 is new and explicit. The 2013 version covered technical vulnerability management under A.12.6. The 2022 revision made it A.8.8 and strengthened the language around evaluating "actual exposure" — language that ISO 27002:2022 interprets to require penetration testing rather than just scanning.
- A.8.29 is a new control for security testing in development. The 2022 version requires organizations with development activities to define and implement security testing in their development lifecycle. This is new territory for companies that previously treated penetration testing only as a post-deployment compliance activity.
- All organizations must transition by October 2025. Companies certified under ISO 27001:2013 must transition to ISO 27001:2022. If your ISMS was built for the 2013 version, your penetration testing program may need to be updated to satisfy the strengthened 2022 requirements.
If your organization was certified under ISO 27001:2013 and has not yet transitioned, your next recertification audit will be assessed against the 2022 standard. Certification bodies have reported that A.8.8 and A.8.29 are among the controls most frequently identified as gaps during transition audits — particularly for organizations that relied on vulnerability scanning rather than penetration testing under the 2013 framework.
3. How Penetration Testing Fits Into Your ISMS
ISO 27001 is not just about individual controls — it is about an operating Information Security Management System. Penetration testing must be integrated into your ISMS, not treated as a standalone compliance activity. This means:
- A documented penetration testing policy or procedure. Your ISMS must include documented procedures for how and when penetration testing is conducted. Auditors will look for this documentation — not just the test reports themselves.
- Integration with risk assessment. Penetration testing findings must feed back into your risk register. If a test identifies a vulnerability, that vulnerability must appear in your risk assessment with a treatment decision — remediate, accept with compensating controls, or transfer.
- Connection to corrective action. Clause 10.1 requires that nonconformities are addressed through corrective action. Penetration test findings that reveal control failures must be tracked through your corrective action process — documented, assigned, and verified.
- Management review input. Clause 9.3 requires regular management reviews of the ISMS. Penetration testing results are relevant input to management review — the outcome of testing (risk posture improvement, residual risk level) should be reported to management.
- Retained as documented evidence. Clause 9.1 requires organizations to retain documented evidence of monitoring and evaluation. Penetration test reports are documented evidence of A.8.8 implementation — they must be retained in your ISMS documentation.
4. Defining Test Scope for ISO 27001
ISO 27001 test scope should align to the scope of your ISMS — the systems and processes covered by your Information Security Management System. Most SaaS companies define ISMS scope as the systems that store or process customer or employee data.
- All systems within ISMS scope. If your ISMS covers your production cloud environment, your test must cover all significant components of that environment — web application, APIs, database access paths, and cloud infrastructure configuration.
- Focus on assets with highest information security risk. ISO 27001 is risk-based. Prioritize testing the assets where a compromise would have the highest impact on information security objectives.
- Include supplier and third-party integrations. A.5.19 (Information Security in Supplier Relationships) and A.5.20 require management of supplier risk. Testing the security of integrations with key suppliers satisfies both this control and A.8.8.
- Test after significant changes. Any significant change to ISMS-scope systems is a trigger for testing. New product deployments, infrastructure migrations, and major architecture changes all create new risk that A.8.8 requires you to evaluate.
5. Frequency and Trigger Requirements
ISO 27001 does not specify an annual penetration testing requirement the way PCI DSS does. The frequency requirement flows from two principles: the risk-based approach and the continuous improvement requirement of Clause 10.
- At minimum once per certification cycle. For a 3-year certification cycle with annual surveillance audits, most organizations conduct penetration testing at minimum annually to ensure each surveillance audit has current testing evidence.
- After significant changes. A.8.8 requires timely evaluation of exposure. "Significant changes" triggering testing include: major new features, cloud provider migrations, new integrations handling sensitive data, and security incidents.
- Aligned to your risk assessment cycle. Your ISMS risk assessment should be reviewed at least annually. Penetration testing provides empirical data to inform that review — so testing should occur before or concurrent with the risk assessment.
- After security incidents. A.5.26 (Response to Information Security Incidents) requires learning from incidents. Post-incident penetration testing confirms that root causes were addressed and no related vulnerabilities remain.
6. What Certification Body Auditors Actually Look For
Certification body auditors evaluating ISO 27001 are evaluating whether your ISMS is operating effectively — not just whether you have a binder of policies. For A.8.8 specifically, auditors look for evidence that you are:
- Identifying technical vulnerabilities in a timely manner. This includes vulnerability scanning, threat intelligence, and penetration testing. Auditors want to see a documented process, not just ad hoc activity.
- Evaluating your actual exposure. A vulnerability scan tells you what might be vulnerable. Penetration testing tells you what is actually exploitable. Auditors increasingly expect to see evidence of exploitation testing, not just scan reports.
- Taking appropriate remediation measures. Findings must be addressed through your risk treatment process. Auditors will sample specific findings and trace them through your corrective action or risk acceptance process.
- Retaining documented evidence. Penetration test reports, risk register entries for findings, corrective action records, and management review minutes referencing testing results are all valid evidence. Auditors may ask for any or all of these.
The most common A.8.8 findings we see in surveillance audits: (1) organizations that conduct vulnerability scanning but no penetration testing and cannot demonstrate actual exposure evaluation; (2) organizations with pentest reports where findings are not traced to the risk register; (3) organizations with findings marked as "accepted" without documented management approval or compensating controls.
7. Building Your ISMS Evidence Package
For ISO 27001 certification or surveillance audits, your penetration testing evidence package should include:
- Penetration testing procedure document. A documented ISMS procedure that defines how penetration testing is planned, executed, and reviewed. Auditors will ask to see this — not just the test report.
- Current penetration test report. The full test report covering systems within ISMS scope, with findings documented by severity and business impact.
- Risk register entries for findings. Each significant finding should appear in your ISMS risk register with a treatment decision. Auditors sample risk register entries against test findings to confirm the connection exists.
- Corrective action records. For findings treated by remediation, corrective action records showing the action taken, the owner, the due date, and verification of completion.
- Management review input. Evidence that penetration testing results were presented to management review — meeting minutes or a written summary showing management was informed of the current security posture.
- Retest evidence. For high-severity findings, retest evidence confirming remediation effectiveness. This can be a standalone retest report or a formal addendum to the original report.
8. How NullStrike Delivers ISO 27001-Aligned Testing
ISMS-Integrated Penetration Testing
NullStrike ISO 27001 engagements are designed to produce evidence that integrates cleanly into your ISMS documentation — not just a technical report that sits in a folder. We structure findings to map directly to ISO 27001 Annex A controls, which means your risk register updates, corrective action records, and management review inputs can be generated from our report without additional interpretation work.
Before testing begins, we review your ISMS scope statement, your risk register (or a relevant excerpt), and your current vulnerability management procedure. This ensures our test coverage aligns to your documented ISMS scope and that our findings language maps to your existing risk treatment categories.
- Annex A control mapping in every report. Every finding includes an "ISO 27001 Control Impact" field referencing the relevant Annex A controls. Risk register entries can be created directly from this mapping.
- Risk register templates provided. We provide a risk register entry template for each finding, formatted to match the typical ISO 27001 risk register structure — risk description, likelihood, impact, current controls, treatment decision. Your ISMS team can populate the risk register without needing to translate from a technical finding format.
- Corrective action evidence support. We provide a corrective action record template for each finding requiring remediation, with the remediation steps pre-populated from our finding guidance. After remediation, we verify and sign off on the corrective action.
- Management review summary. In addition to the full technical report, we provide a one-page management review summary — the executive-level view of testing results designed for management review input, written for non-technical management audiences.
- Post-transition gap analysis. For organizations transitioning from ISO 27001:2013 to ISO 27001:2022, we identify gaps in your current penetration testing program relative to the strengthened 2022 requirements and provide a remediation roadmap.
- Auditor documentation support. If your certification body auditor has questions about our methodology, coverage decisions, or findings, we provide direct written responses. Our reports are designed to answer auditor questions without requiring your ISMS team to serve as interpreter.
Get ISO 27001-Aligned Penetration Testing for Your Next Audit
We structure engagements to produce evidence that integrates directly into your ISMS — risk register entries, corrective action records, and management review inputs included. Share your ISMS scope and audit timeline and we will have a proposal to you within 24 hours.
Summary
ISO 27001:2022 Annex A.8.8 requires organizations to evaluate their actual exposure to technical vulnerabilities — not just identify them. ISO 27002:2022 is explicit that penetration testing is the appropriate mechanism for this evaluation. Certification body auditors expect to see a documented penetration testing procedure, current test evidence, risk register integration, and evidence of remediation tracked through corrective action.
The companies that sail through ISO 27001 surveillance audits on A.8.8 have one thing in common: they treat penetration testing as an ISMS activity, not a standalone compliance task. Their test reports feed directly into their risk registers and their corrective action process. That is the integration NullStrike is built to provide.