ISO 27001 Penetration Testing: What the Standard Requires

ISO 27001 does not hand you a checklist that says "run a pentest every year." Like SOC 2, it is risk-based. Yet almost every organisation that certifies ends up testing, because penetration testing is the most direct evidence that its technical controls work.

Where penetration testing fits in ISO 27001:2022

ISO 27001 requires an information security management system (ISMS) built on risk assessment and treatment. The Annex A controls are the menu of measures you select based on that risk assessment. Several of them are commonly met, at least in part, with penetration testing:

• A.8.8 Management of technical vulnerabilities. Obtain information about technical vulnerabilities, evaluate exposure and take appropriate measures.
• A.8.29 Security testing in development and acceptance. Define and implement security testing processes in the development life cycle.
• A.5.36 Compliance with policies, rules and standards. Regularly review compliance with your security policies, which may include technical testing.
• A.8.20 to A.8.22 Network security controls. Testing helps show segmentation and network controls work as designed.

Clause 9.1 also requires you to monitor, measure and evaluate the effectiveness of your ISMS. Test results are a practical input to that.

What certification auditors want to see

Auditors look for a consistent story connecting risk, policy and evidence:

1. A policy or procedure that defines when and how you test, for example annually and after significant change.
2. Scope linked to your risk assessment. Critical assets and internet-facing systems should be covered.
3. Reports with findings, severity and dates.
4. Treatment records. Tickets, fixes, retests or documented risk acceptance for each finding.
5. Continual improvement. Evidence that lessons from testing changed something, such as a new secure coding guideline.

Missing treatment records is the most common gap. A report that sits in a folder does not demonstrate that a control operates.

How often should you test?

The standard leaves frequency to you, but auditors expect it to be justified by risk. Common practice is:

• Annually for a full application and infrastructure test.
• After significant changes, such as a new product, major architecture change or cloud migration.
• Continuously for internet-facing assets, using automated testing and attack surface monitoring.

Combining ISO 27001 and SOC 2 testing

If you pursue both, you can use one well-scoped test for both programmes. Make sure the scope covers the systems in your ISO 27001 statement of applicability and your SOC 2 system description, and that the report documents methodology and remediation clearly.

Making testing continuous

Annual tests leave long gaps. Continuous AI pentesting runs every time you ship, so A.8.8 and A.8.29 have fresh evidence all year. SecurityInfinity agents test your web app, APIs and cloud, verify findings, and give a fix for each one, so treatment records are easy to produce. Start free or get a pentest report.

Frequently asked questions

Is penetration testing mandatory for ISO 27001 certification?

Not explicitly. However, auditors expect evidence that technical vulnerabilities are managed and that security testing happens, and a penetration test is the most common way to provide it.

Does the tester need to be accredited?

ISO 27001 does not require a specific accreditation. Some customers or regulators may require particular qualifications, so check contractual requirements.

Can internal staff perform the test?

They can, if they are competent and independent from the systems tested, but external testing is generally viewed as stronger evidence.