ISO 27001 penetration testing: what the standard asks and auditors check

ISO/IEC 27001:2022 does not require a penetration test by name. It requires an information security management system (ISMS) that manages risk. Annex A lists controls. Auditors usually accept pentest evidence for two of them: 8.8 and 8.29.

This page names those controls, shows what each one asks, and lists what to settle with your certification body before you scope a test.

Which Annex A controls relate to penetration testing?#

Three controls in the Technological group (theme 8) relate to pentests. A fourth control covers independent review.

Control 8.29 merges two 2013 controls, A.14.2.8 (system security testing) and A.14.2.9 (system acceptance testing). It is not one of the 11 controls new in 2022. Control 8.8 merges older vulnerability controls.

Does ISO 27001 say "penetration testing"?#

No. The Annex A control text does not name pentests. ISO/IEC 27002:2022, the guidance document, mentions penetration testing as one option in its advice for these controls. Guidance is not a requirement, and a certification audit tests against ISO/IEC 27001, not against each guidance sentence. The accurate statement is: "ISO/IEC 27001:2022 does not name penetration testing as mandatory. Controls 8.8 and 8.29 are where auditors usually accept it as evidence."

What do auditors look for?#

Certification auditors check that your ISMS does what it says. For testing, they usually look for four items:

1. A documented process. A vulnerability management or secure development procedure that says when tests happen and who does them.
2. A link to risk. Your risk assessment and Statement of Applicability say why you chose the test type and frequency.
3. Evidence it happened. A dated report with scope, method and findings.
4. Evidence you acted. Tickets, fixes and retest results, with owners and dates.

After the pentest: remediation and retest covers this loop. An auditor will find a gap in a report with open high findings and no plan.

How do you scope a pentest for 8.8 and 8.29?#

Match the scope to your ISMS scope. If your certificate covers a SaaS product, the test should cover the product's production or production-like environment. If it covers only an office network, a web app test may be out of scope for the audit. The audit scope statement tells you.

Scope checklist:

• ISMS scope statement and the systems it names.
• Environments tested (production, staging) and why.
• Applications and APIs in scope, with the roles and test accounts.
• Out-of-scope items and the reason.
• Test window, and a contact for stop conditions.
• Who does the test and how you verify their competence.

Control 8.34 matters here. Agree the test in writing, limit the access you give, and keep audit trails. Our guide on penetration testing rules of engagement gives an outline.

How often should you test?#

The standard sets no interval. Your risk assessment sets it. A common pattern is one test a year plus tests after major changes, because that is easy to defend. Control 8.29 points to testing when you build or change systems. See how often should you pentest.

Write the interval and its reason into your procedure, then follow it. An auditor checks your own rule, not a rule from the standard.

Pentest, scan or both?#

A vulnerability scan is automated and broad. A pentest is manual and deep. ISO/IEC 27002 guidance discusses both for managing technical vulnerabilities. A common setup uses both: scans on a schedule for 8.8, and a pentest for depth and for 8.29 before releases. NIST SP 800-115 gives a neutral definition of each technique if you need one for your procedure.

What competence evidence helps?#

ISO/IEC 27001 clause 7.2 asks you to confirm that people doing work that affects ISMS performance are competent. Keep simple proof for the tester: relevant experience, the method used, and who reviewed the findings. No ISO text asks for a specific certificate.

What does a worked evidence pack look like?#

An evidence pack for one audit cycle can be small. This example fits a SaaS company whose certificate scope is its product and the team that runs it.

Keep the pack in one folder so you can show the auditor the full path from risk to fix.

What mistakes weaken pentest evidence for ISO 27001?#

• A pentest done, but no procedure that says why and when.
• A report with no link to the risk register.
• Findings closed in a tracker with no evidence of the fix.
• A scope that does not match the ISMS scope.
• A control marked "not applicable" in the Statement of Applicability, while a test report exists for the same area.

How does this relate to SOC 2 and PCI DSS work?#

Teams often hold more than one framework. One test can feed several, if the scope fits each. ISO/IEC 27001 gives the most freedom, because the risk assessment sets the test. PCI DSS sets a fixed interval and tester rules for the cardholder data environment. SOC 2 leaves the evidence choice to the auditor.

Plan one scope that meets the strictest reader, then ask each auditor to confirm it. A report written for one framework may not fit the others, because dates, scope and tester independence may differ.

What should the test not do?#

Control 8.34 reminds you that testing live systems carries risk. Agree limits in writing before the test:

• No denial-of-service tests on production.
• Test accounts and test records only for any change or delete proof.
• A named contact who can stop the test.
• A cap on bulk actions such as password attempts and email sends.
• A rule for what the tester does if real personal data appears.

Questions to take to your certification body#

• Which Annex A controls in our Statement of Applicability need testing evidence?
• Do you accept one annual test plus tests after major releases?
• Do you want the full report or a summary?
• How do you view testers from our own company?
• Which open findings are acceptable at the audit date?
• Do you expect the retest inside the same audit cycle?

For a deeper view of the report form, see how to read a penetration testing report. For the SOC 2 equivalent, see does SOC 2 require penetration testing.