Penetration testing under ISO 27001: expected by risk, judged by evidence.

ISO 27001 works through risk. You decide what testing is proportionate, record that decision in the Statement of Applicability (SoA), and then the auditor holds you to it. Three controls in the 2022 Annex A are where that decision usually lands.

1. A..1
   8.8 Management of technical vulnerabilitiesFind weaknesses in the systems you run, judge how exposed you are, and act in good time. Scanning answers the routine part; a test shows whether weaknesses can be chained.
2. A..2
   8.29 Security testing in development and acceptanceNew and changed systems are tested for security before they go live. For a product company, this is where an application test before a major release belongs.
3. A..3
   5.35 Independent review of information securityYour approach to security is reviewed by someone outside the work, at planned intervals and after major change. An external test is one input to that review, not the whole of it.

Two neighbours matter too: 8.34, on protecting live systems while audit or test activity runs, and 8.25, the secure development life cycle that 8.29 sits inside. Our pages on vulnerability management and secure development cover each control in full.

• A scope that matches the ISMS. The systems tested sit inside the scope statement, and the in-scope assets left out are explained by risk, not by budget alone.
• Tester independence. The people testing did not build or run what they tested. An internal team can qualify if it is organisationally separate.
• A dated report. Method, dates, the environment used, findings with severity, and who did the work.
• Findings in your process. Each finding appears in your vulnerability or risk tracker, with an owner and a due date set by your policy.
• Remediation or a decision. Fixed through change control, or formally accepted by the risk owner with a reason recorded in the risk treatment plan.
• Retest proof. A retest letter, an updated report, or documented internal verification for each closed high-severity item.

The auditor does not grade the tester's exploits. They want to see that your ISMS took the report in and acted on it. A clean report with no follow-up record is weaker evidence than a report full of findings that were each handled on time.

A scan alone rarely satisfies an auditor for an internet-facing product, and a red team is not a substitute for routine scanning. Most small and mid-size ISMS scopes need the first two and can skip the third.

• Scope set by the tester. The tester picked what to test and nobody checked it against the ISMS scope statement.
• No link to risk. Critical findings never reached the risk register, so the risk picture the auditor reads is out of date.
• Risk accepted by the wrong person. An engineer marked a finding as accepted; only the named risk owner may do that.
• Release testing undocumented. Security checks before go-live happened in conversation, so control 8.29 has no evidence.
• Production put at risk. Testing ran against live systems with no agreed window or rollback plan, which control 8.34 is meant to prevent.

Each of these is cheap to fix before the audit and awkward to explain during it. A one-page test plan signed by the ISMS owner, naming scope, window, contacts and how findings enter the tracker, closes most of them.

1. 01

   Before Stage 2

   Run the first full test early enough to remediate and retest.

   What happens

   • Agree scope from the ISMS scope statement
   • Book the retest at the same time

   You get

   • A closed-out report for the certification audit

   Good practice

   • High findings closed, the rest planned with owners

   Watch for

   • A test that finishes the week before Stage 2

2. 02

   Surveillance years

   Repeat on the rhythm your policy states.

   What happens

   • Refresh scope for new products and infrastructure
   • Track findings through the same tracker

   You get

   • Evidence that the control operates every year

   Good practice

   • Trends across reports shown at the management review

   Watch for

   • Copying last year's scope without checking it

3. 03

   After significant change

   A new platform, a migration or a major release triggers a test or a recorded decision.

   What happens

   • Log the change
   • Decide test or no test, with a reason

   You get

   • A defensible link between change and testing

   Good practice

   • The decision sits in the change record

   Watch for

   • Silent skips

Sources: ISO/IEC 27001:2022 Annex A control titles 5.35, 8.8, 8.25, 8.29 and 8.34 (titles only; the standard's text is not reproduced); ISO/IEC 17021-1 on the certification cycle of initial audit and annual surveillance. Testing rhythms marked "commonly" are market practice, not requirements of the standard.