Does ISO 27001 Require Penetration Testing? Annex A 8.8, 8.29 and 5.35

Not by name. ISO/IEC 27001:2022 has two layers, and neither contains a clause that says “run a penetration test”.

• Clauses 4 to 10 are the management system requirements. The scope clause, which ISO publishes openly, says that excluding any of them is not acceptable when an organization claims conformity. They cover context, leadership, risk assessment and risk treatment, support, operation, performance evaluation (including internal audit) and improvement.
• Annex A is the reference set of controls. It is normative and lists the 93 controls of ISO/IEC 27002:2022 by title. You determine the controls you need through risk treatment, compare them with Annex A so that none is left out by mistake (clause 6.1.3 c)), and record in the Statement of Applicability which controls apply and why (6.1.3 d)).

None of the 93 control titles is “penetration testing”. The controls that testing usually evidences are 8.8, Management of technical vulnerabilities, and 8.29, Security testing in development and acceptance, with 5.35, Independent review of information security, and 8.34, Protection of information systems during audit testing, close by.

So the honest answer has two halves. Nobody can point to an ISO/IEC 27001 requirement that says “annual penetration test”. And an organization with internet-facing systems that claims 8.8 is implemented and effective, with no technical testing behind the claim, is making the assertion a certification auditor is most likely to probe.

The titles below come from the table of contents of ISO/IEC 27002:2022, which Annex A of ISO/IEC 27001:2022 reproduces. The control text itself is in the paid standard, so read it there before you write your Statement of Applicability.

• 8.8 Management of technical vulnerabilities. The home of vulnerability scanning and the natural place for penetration test results, because a test shows which vulnerabilities can actually be exploited. ENISA's mapping table for the NIS2 Implementing Regulation 2024/2690 maps its vulnerability handling requirement (point 6.10) to 8.8 alone.
• 8.29 Security testing in development and acceptance. As the title says, security testing during development and before acceptance into production; application security tests and pre-release penetration tests are the usual evidence. ENISA maps the Regulation's security testing requirement (point 6.5) to 8.29, 8.33 Test information and 8.34.
• 8.34 Protection of information systems during audit testing. The control to cite when you test live systems. In practice that means agreeing scope, timing and allowed techniques with the people responsible for the systems before the test starts, and writing it down.
• 5.35 Independent review of information security. An independent review of how you manage information security, not a requirement for each technical test. ENISA maps the Regulation's independent review requirement (point 2.3) to clauses 9.2 and 10.1 and to 5.35 and 8.34.

Around them sit the management system clauses that make testing matter: the risk assessment and treatment (6.1.2, 6.1.3, 8.2, 8.3), monitoring and measurement (9.1), internal audit (9.2), management review (9.3) and corrective action (10.2). A test finding that is not fed into the risk treatment plan and followed to closure is a weak piece of evidence.

Certification is optional. ISO does not certify anyone; accredited certification bodies do, and ISO's own guidance is that a certificate from an accredited body adds confidence because an accreditation body has checked the certification body's competence. A certificate is always to a dated edition, today “ISO/IEC 27001:2022”.

What the auditor judges is whether the controls you selected are implemented and effective for your risks. The accreditation rules for the 2022 transition, IAF MD 26, made the point explicitly: the transition audit had to cover the implementation and effectiveness of new or changed controls and “shall not only rely on the document review, especially for reviewing the technological information security controls”.

In practice, expect questions like these on 8.8 and 8.29:

1. Statement of Applicability: are 8.8 and 8.29 included, and if either is excluded, what is the justification?
2. Risk treatment: where do technical vulnerabilities appear in the risk assessment, and which treatment did you choose?
3. Procedure: how do you learn about vulnerabilities, scan, prioritize and patch, and who decides on exceptions?
4. Records: scan results, penetration test reports if your treatment plan says you run them, remediation tickets and re-test results.
5. Changes: what security testing happened before the last significant release or infrastructure change went live?
6. Follow-through: do findings reach internal audit, management review and corrective action?

If your documents say “annual external penetration test” and there is no report for the last year, that is a nonconformity against your own ISMS, whatever the standard says about testing.

Frequency. ISO/IEC 27001:2022 sets no interval for scans or penetration tests. You set it in your risk treatment, and the auditor checks that it follows from the risk assessment, is written down and was met. If you also answer to PCI DSS 11.4 or NYDFS §500.5, their at-least-every-12-months floor is a natural anchor; internet-facing systems and significant changes usually justify more. See the worldwide guide to penetration testing requirements by regulation.

Independence. Nothing in the standard requires an external penetration tester or a particular certification for testers. The independence the standard speaks about is at the level of the management system: internal audit under clause 9.2 and the independent review of 5.35. For a technical test, record who ran it, their qualifications, and why they are not reviewing their own work; an internal team can test, but it should not be the team that built and runs the systems in scope without anyone else looking.

The certification body is independent of you by definition, but it audits your ISMS; it does not run your penetration test and its audit does not replace one.

IAF MD 26:2023, the mandatory document for accredited certification bodies, set a 36-month transition period ending on 31 October 2025. It states that all certifications based on ISO/IEC 27001:2013 shall expire or be withdrawn at the end of the transition period.

For anyone reviewing suppliers, that makes one check simple: an accredited ISO/IEC 27001 certificate presented today should reference the 2022 edition. The transition audit had to cover the gap analysis, the updated Statement of Applicability, the risk treatment plan where it changed, and the implementation and effectiveness of the new or changed controls.

The new control set also changed where testing is recorded. The 2013 edition had 114 controls in 14 clauses; the 2022 edition has 93 in four clauses (organizational, people, physical and technological controls), with 11 new, 24 merged and 58 updated controls according to IAF MD 26. Policies and test reports that still cite 2013 control numbers should be updated to the 2022 numbering.

Written in the standard:

• Clauses 4 to 10, including risk assessment, risk treatment with a Statement of Applicability, performance evaluation, internal audit, management review and corrective action.
• Annex A as a normative reference set that you compare your controls against, with 8.8, 8.29, 8.34 and 5.35 among its 93 controls.

Risk-based, decided by you:

• Whether you run penetration tests at all, their scope, depth and frequency, and whether testers are internal or external, as long as the choice follows from your risk assessment and is documented.

Accreditation rules, not the standard:

• IAF MD 26 on the 2022 transition, including the instruction not to rely only on document review for technological controls.

Not written anywhere:

• A mandatory annual penetration test, a required testing vendor, a tester certification, or a rule that the certification body tests your systems.

1. Put testing in the risk treatment plan. Name the risks it treats (exploitable vulnerabilities in internet-facing and critical internal systems) and link them to 8.8, 8.29 and 8.34 in the Statement of Applicability.
2. Write the method and the cadence. Scans on a schedule and after significant changes; penetration tests at least annually on the systems that matter most, from outside the network and with the access of an ordinary user. See black-box vs gray-box testing and vulnerability assessment vs penetration testing.
3. Plan tests on live systems under 8.34. Scope, timing, allowed techniques and approvals agreed with system owners before the test starts.
4. Test before go-live under 8.29. Tie security testing to releases and infrastructure changes, not only to the calendar.
5. Close the loop. Every finding gets an owner, a date and a re-test; accepted risks get a named approver; results go to internal audit and management review.
6. Keep the file. Reports, tester qualifications, re-test results and exceptions, retained under your documented information rules, ready for the next surveillance audit.

Zero Hunt is an autonomous AI red team for networks and infrastructure: automated penetration testing on an on-premise appliance, on private AI, with a human in the loop. It does not certify anything, is not a certification body, and does not replace your internal audit, the independent review of 5.35, or an independent tester where your risk treatment calls for one. What it changes is how much technical evidence exists between one annual test and the next.

• Annex A mapping. ISO/IEC 27001:2022 is one of the 34 frameworks the engine maps to, covering all 93 Annex A controls. Findings feed 8.8 and 8.29 automatically; controls such as 5.35 and 8.34 are flagged as evidence you supply yourself, and the ISO/IEC 27001 report can be exported.
• Black box and gray box, on a schedule. Campaigns from outside and with standard-user access run once, daily, weekly, monthly or on a custom schedule, and after changes, so testing can follow the cadence your risk treatment sets.
• Exploited, not just detected. Each finding records whether it was actually exploited in your environment, and each fix can be re-tested with the same proof.
• Human approval of risky steps. Five autonomy levels decide what waits for an operator, which is how tests on live systems stay within what was agreed under 8.34. See human in the loop.
• Records that hold up. Every attack attempt is an Ed25519-signed entry in a SHA-256 hash chain, and exported reports are ECDSA-signed.
• No customer data leaves the appliance. The models run on it with no external AI service, so no outside AI provider processes what your tests find.

Zero Hunt's own ISO/IEC 27001 certification is in progress; the current status is on the Trust Center. To see how this fits your Statement of Applicability, book a 30-minute readiness call.

• ISO/IEC 27001:2022, product page and FAQ (ISO)
• ISO/IEC 27001:2022, Online Browsing Platform preview: scope and clause titles (ISO)
• ISO/IEC 27002:2022, Online Browsing Platform preview: introduction (ISO)
• ISO/IEC 27002:2022, product page (ISO)
• IAF MD 26:2023, Transition Requirements for ISO/IEC 27001:2022 (IAF, PDF)
• ENISA, NIS2 Technical Implementation Guidance, June 2025 (ENISA)
• ENISA, mapping table v1.2 to ISO/IEC 27001:2022 and other frameworks (ENISA, XLSX)