ISO 27001 Penetration Testing: Scope, Frequency and Evidence

ISO 27001 penetration testing is a common source of confusion, because the standard never lists a control that says "perform a penetration test". Yet for Australian organisations pursuing or holding certification, testing is effectively expected, because it is the most credible way to show that technical vulnerabilities are managed and that controls actually work.

This guide explains where penetration testing fits within ISO/IEC 27001:2022, what certification auditors look for, and how to think about scope, frequency and evidence. By the end you will understand how to use penetration testing to strengthen both your security and your certification.

How ISO 27001:2022 Treats Technical Testing

ISO/IEC 27001:2022 is built around a risk-based information security management system. You identify risks to your information, decide how to treat them, and demonstrate that your controls are working and improving over time. The standard is deliberately outcome-focused rather than prescriptive, which is why it does not mandate specific techniques like penetration testing by name.

That flexibility is often misread as "testing is optional". In practice, the requirement to assess and treat technical risk means you need credible evidence that your technical controls hold. For internet-facing systems and important applications, penetration testing is the clearest way to produce that evidence.

Where Penetration Testing Fits in Annex A

The 2022 revision restructured Annex A into four themes and consolidated the controls. Several of them are directly supported by penetration testing, with one standing out.

• A.8.8 Management of technical vulnerabilities: This is the most direct link. You must obtain information about technical vulnerabilities, evaluate your exposure and take suitable action. Penetration testing validates which vulnerabilities are genuinely exploitable and how they could be chained.
• Secure development controls: Testing of applications provides assurance that secure development practices produced resilient software.
• Network and application security controls: Testing confirms that segmentation, hardening and application defences behave as intended.
• Logging and monitoring controls: A well-run test also reveals whether your monitoring detected the activity, providing assurance around detection controls.

Above all, penetration testing feeds the risk assessment and risk treatment process at the core of the standard. Findings become inputs to your risk treatment plan, and remediation becomes evidence of continual improvement.

What Certification Auditors Expect

Auditors are not simply looking for a report on file. They want to see that testing is part of a working system. In practice they expect the following.

• Risk-based scope: Testing that targets the assets that matter most to your identified risks, aligned with your management system boundaries.
• Independence and competence: Testing performed by suitably skilled and appropriately independent expert operators, rather than a light self-check.
• A closed loop: Evidence that findings were triaged, prioritised, remediated and retested, not just documented.
• Feedback into risk treatment: Proof that results influenced your risk treatment plan and decisions.
• Sensible cadence: Testing repeated at a justified frequency and after significant change.

The recurring theme is closing the loop. A pile of unremediated findings is a red flag, whereas a clear cycle of identify, treat and verify is exactly what the standard rewards. Auditors also value context, so being able to explain why a particular system was in or out of scope, and how the frequency was chosen, demonstrates the mature, risk-based thinking the standard is built around.

Deciding Scope

Scope should follow the boundaries of your information security management system and be justified against your risk assessment. Testing everything is rarely practical, so focus effort where the risk is greatest.

Common scope elements include:

• Internet-facing applications and infrastructure, which carry the highest exposure.
• Internal networks, to understand what an attacker could achieve after gaining a foothold.
• Key business applications that hold or process sensitive information.
• Cloud environments and their configuration, which are frequently overlooked.
• Remote access and identity systems, given their central role in modern attacks.

Whatever you include, document why. Auditors are comfortable with a scope that excludes lower-risk systems, provided the rationale is clear and the important assets are covered. A structured penetration testing program, supported by ongoing vulnerability assessments, keeps that coverage current between formal engagements.

Deciding Frequency

The standard sets no fixed interval, so frequency is a risk decision you must be able to justify. A widely used approach is:

• At least annual penetration testing across in-scope systems.
• Additional testing after significant change, such as a major release, a cloud migration or a new internet-facing service.
• More frequent testing for higher-risk or rapidly changing systems.

The important point is consistency and rationale. Choose a frequency driven by risk, write down why, and apply it reliably. An auditor is far more comfortable with a justified, repeatable cadence than an ad hoc one.

The Evidence to Keep

Because ISO 27001 is about demonstrating a working system, your evidence trail matters as much as the testing itself. Retain the following for each engagement.

• The penetration test report, describing what was tested and what was found.
• The documented scope and the risk-based rationale behind it.
• Records showing findings were triaged and prioritised.
• Remediation records showing what was fixed and when.
• Retest evidence confirming that significant issues were genuinely resolved.
• Evidence that results were reflected in the risk treatment plan.

Together this shows a complete cycle of identify, assess, treat and verify. It is this cycle, rather than any single report, that satisfies both the letter and the spirit of the standard.

Common Mistakes That Trip Up Certification

Even organisations with strong security can stumble when their testing does not connect cleanly to the management system. A few recurring mistakes are worth guarding against.

• Treating the report as the deliverable: A test report with no evidence of remediation or retesting shows activity, not assurance. Auditors want to see the loop closed.
• Scoping too narrowly to save cost: Excluding important systems to reduce the test window can leave real risks untested and undermine confidence in your management system.
• Testing once and forgetting: A single test years ago does not demonstrate continual improvement. Testing must be repeated at a justified cadence and after significant change.
• Failing to link findings to risk treatment: If test results never appear in your risk assessment or treatment plan, you miss the core purpose of testing under the standard.
• Ignoring cloud and identity: Modern environments hinge on cloud configuration and identity systems, yet these are frequently left out of scope. Their absence is increasingly noticed by auditors.

Addressing these points turns penetration testing from a compliance formality into a genuine driver of security maturity, which is exactly the outcome the standard is designed to encourage.

Turning Testing Into Assurance

ISO 27001 penetration testing works best when it is treated as a core assurance activity rather than a certification chore. Done well, it does more than satisfy an auditor. It gives your leadership genuine confidence that the controls you have invested in stand up to attack, and it feeds a continual improvement loop that keeps your security maturing over time.

If you are preparing for certification or maintaining it, our team of expert operators can help you scope risk-based testing, produce audit-ready evidence and close the loop on remediation. Explore our penetration testing services and maturity level assessments, or get in touch to talk it through. You can also reach StrikeCyber on 1300 654 898.