June 27, 2026 · Compliance

ISO 27001 Penetration Testing Requirements: What the Standard Actually Requires

ISO 27001 is the most widely adopted information security management standard globally, with over 70,000 certified organizations. Yet there is persistent confusion about what it actually mandates for penetration testing. Security teams preparing for ISO 27001 certification or audits frequently over-build or under-build their testing programs because the requirements are spread across the standard in non-obvious ways.

This guide covers what ISO 27001:2022 specifically requires for security testing, which Annex A controls create the testing obligation, what auditors look for as evidence, and how to structure a testing program that satisfies the standard without over-investing.

How ISO 27001 Structures Security Testing Requirements

ISO 27001 does not contain a single "penetration testing" clause. The requirement emerges from the intersection of several controls and the risk management framework at the core of the standard. The relevant requirements come from three sources:

• ISO 27001:2022 Clause 8.1 — Operational planning and control (requires implementation and control of planned processes)
• ISO 27001:2022 Clause 9.1 — Monitoring, measurement, analysis and evaluation (requires measurement of ISMS effectiveness)
• ISO 27002:2022 Annex A — Information security controls (provides the specific technical controls, including 8.8 and 8.29)

ISO 27001 references ISO 27002 for the control set. Organizations select controls from Annex A based on their risk assessment and document which controls they have implemented (and which they have excluded) in the Statement of Applicability (SoA).

The Key Controls: Annex A 8.8 and 8.29

Annex A 8.8 — Management of technical vulnerabilities

Control 8.8 requires organizations to:

• Obtain timely information about technical vulnerabilities in information systems
• Evaluate the organization's exposure to such vulnerabilities
• Take appropriate measures to address the associated risk

This control creates the obligation for vulnerability scanning as a continuous process. Auditors expect to see:

• A defined process for identifying applicable vulnerabilities (NVD feeds, vendor advisories, CVE subscriptions)
• Regular vulnerability scans with documented results
• A remediation process with defined timelines based on severity
• Evidence of remediation (re-scan results confirming fix, or documented risk acceptance for unpatched vulnerabilities)

Vulnerability scanning is mandatory under 8.8. Penetration testing is the recommended mechanism for evaluating exposure — but the control as written focuses on the management process, not the specific testing methodology.

Annex A 8.29 — Security testing in development and acceptance

Control 8.29 requires that security testing be defined and implemented for the development lifecycle. Specifically:

• Security testing should be carried out during development
• Acceptance testing should include security tests before deployment
• Testing plans and results should be documented

For web application security, 8.29 drives DAST/SAST requirements, security code review, and pre-production security assessment. Organizations running internal development of web-facing applications or APIs cannot exclude this control from their SoA without significant justification.

Additional controls that imply testing

Does ISO 27001 Require Annual Penetration Testing?

The short answer: not explicitly, but in practice, yes — for most organizations.

ISO 27001 does not specify frequency for penetration testing. The frequency requirement flows from the risk assessment: if web applications are in scope, the risk register identifies web application attacks as a relevant threat, and the organization has selected 8.8 and 8.29 as applicable controls, then periodic penetration testing is the expected mechanism for demonstrating those controls are effective.

Auditors from major certification bodies (BSI, Bureau Veritas, SGS, TÜV) have generally aligned on expecting:

• Annual penetration testing as the baseline for organizations with internet-facing applications
• Testing after significant changes — new application releases, major infrastructure changes, after security incidents
• Ongoing vulnerability scanning (not just annual) to satisfy the continuous monitoring aspect of 8.8

Organizations that conduct only annual penetration testing without ongoing vulnerability scanning will typically receive a nonconformity under 8.8, because annual testing does not constitute "timely" vulnerability management for actively-exploited CVEs.

What Auditors Look For as Evidence

ISO 27001 auditors verify implementation through document review and interviews. For security testing, expect auditors to request:

Policy and procedure evidence

• Vulnerability management policy defining roles, frequency, and severity-based response timelines
• Penetration testing procedure documenting scope, methodology, and reporting requirements
• Change management procedure that triggers security re-testing after significant changes

Operational evidence

• Penetration test reports (full reports, not just executive summaries) for the audit period
• Evidence of scoping — what was included, what was excluded and why
• Vulnerability scan results showing regular scanning frequency
• Remediation tracking: for each finding in the pentest report, what was the resolution and when?
• Re-test evidence confirming that critical and high findings were remediated
• Risk acceptance documentation for findings not remediated (signed by appropriate risk owner)

Common audit findings that lead to nonconformities

• Pentest conducted but no remediation tracking — the report was filed, findings were not tracked to closure
• Pentest scope excludes production systems — testing staging-only and claiming it satisfies 8.8 for production
• Vulnerability scanning annual only — monthly or quarterly scanning is the expected minimum for most organizations
• No re-testing of critical findings — high-severity vulnerabilities marked as "resolved" with no verification scan
• SoA excludes 8.29 without justification — organizations with in-house development cannot typically justify excluding development security testing

Mapping a Testing Program to ISO 27001

A testing program structured to satisfy ISO 27001 typically has three components:

1. Continuous vulnerability scanning (satisfies 8.8)

Automated vulnerability scanning of in-scope systems on a regular cadence — monthly at minimum, weekly for internet-facing systems. The scans should:

• Cover all systems in the ISMS scope
• Produce documented results that are retained for the audit period
• Feed into a remediation tracking process with defined SLAs (e.g., Critical: 7 days, High: 30 days, Medium: 90 days)
• Include authenticated scans for internal systems where applicable

2. Annual penetration test (satisfies 8.8 evaluation requirement + Clause 9.1)

Annual penetration testing by qualified testers (internal red team or third-party). The scope should include:

• All internet-facing applications within ISMS scope
• Internal network segmentation testing where network segregation controls (8.22) are selected
• Social engineering / phishing assessment if human-factor controls are in scope

The penetration test report serves as primary evidence for Clause 9.1 (evaluating ISMS effectiveness). A report that finds no vulnerabilities is not inherently suspicious — but auditors may probe the testing methodology if all-clear reports are presented repeatedly.

3. Change-triggered testing (satisfies 8.29)

Security testing integrated into the release process for web applications:

• DAST scanning in CI/CD pipelines for pre-production environments
• Security acceptance testing before major releases
• Documentation of what was tested, how, and what the outcome was

This does not require full penetration testing for every release. Automated DAST scanning with manual review of high-risk changes is typically sufficient to satisfy 8.29.

Evidence Retention and Documentation

ISO 27001 Clause 7.5 requires documented information to be retained as evidence of ISMS operation. For security testing, this means:

ISO 27001 vs. Other Frameworks: Testing Frequency Comparison

Practical Notes for ISO 27001 Certification Preparation

Start early. Auditors expect to see a testing program that has been operating, not one that was stood up weeks before the audit. Six months of vulnerability scan history is a reasonable minimum to demonstrate process maturity.

Document scope decisions. If you exclude certain systems from penetration testing scope, document why. "Out of scope: legacy ERP system — isolated network, no internet connectivity, compensating controls in place [link]" is acceptable. Unexplained scope gaps invite follow-up questions.

Track findings to closure. The single most common finding in ISO 27001 surveillance audits is pentest findings that were identified but not remediated or formally risk-accepted. Build a remediation tracking process before you conduct the pentest, not after.

Use automated scanning to fill the gap between annual pentests. Monthly DAST scanning of web applications provides continuous evidence of 8.8 implementation between annual penetration tests. This evidence trail is what turns a vulnerability management policy into a demonstrated, operating control.