ISO 27001 penetration testing is a pentest scoped to your ISMS and used as evidence that your technical vulnerability controls work. ISO/IEC 27001:2022 does not name penetration testing as a mandatory requirement.
It requires risk-based controls, and Annex A control 8.8, Management of technical vulnerabilities, is where a pentest usually earns its place.
So the honest answer to "do we need one" is that the standard leaves it to your risk assessment. In practice, a pentest is the most direct way to show an auditor that 8.8 is working.
What CodeAnt AI solves here: CodeAnt AI runs black box, gray box and white box pentests that prove what is exploitable. Reports arrive within 48 hours and are mapped to SOC 2 and ISO 27001.
Here is the short version before the detail.
Question | Short answer |
Does ISO/IEC 27001:2022 mandate a pentest? | No. The requirements are risk-based, and the word "penetration" does not appear in ISO's public preview of the standard |
Which Annex A controls does a pentest support? | Mainly 8.8 Management of technical vulnerabilities and 8.29 Security testing in development and acceptance, plus 8.25 and 5.36 |
Can you skip it? | Only with a documented, risk-based justification in your Statement of Applicability and other evidence that 8.8 works |
How often? | The standard sets no frequency. Annual testing plus testing after significant change is common practice |
What do auditors look for? | Scope tied to the ISMS, a frequency your risk assessment justifies, remediation, retest and a competent, independent tester |
What changed from 2013? | Technical vulnerability management moved from A.12.6.1 to 8.8, and 2013 certificates expired or were withdrawn after 31 October 2025 |
Is this true for your app? A free CodeAnt scan gives you a 48-hour report you can hold against control 8.8.
Does ISO 27001 Require Penetration Testing?
No. ISO/IEC 27001:2022, published in October 2022 per its iso.org listing, specifies requirements for an information security management system. It does not prescribe specific tests. The mechanism that matters is clause 6.1.3, risk treatment. You determine the controls your risks need, then compare them with Annex A to "verify that no necessary controls have been omitted".
Clause 6.1.3 then requires a Statement of Applicability. That document lists the controls you need, why you include them, whether they are implemented, and the justification for excluding any Annex A control.
The standard is also explicit that Annex A is a list of "possible information security controls" and is not exhaustive. That wording is visible in ISO's public preview of the 2022 text.
Why a Pentest Ends Up Expected Anyway
Annex A control 8.8 covers the management of technical vulnerabilities. If you hold internet-facing applications and you include 8.8, the auditor will ask how you find vulnerabilities and how you know your fixes worked.
A vulnerability scan answers the first half. A pentest answers both halves, because it proves exploitability and produces a dated retest record. Auditors are not obliged to demand one, and they often ask anyway.
Where the detailed guidance lives…
ISO/IEC 27002:2022 is the companion guidance document. ISO's 27002 page describes it as guidance, while ISO/IEC 27001 sets the requirements. The implementation guidance for each control, including 8.8, sits in the paid text of ISO/IEC 27002. Treat any blog that quotes it at length with care, and buy the standard if your auditor leans on specific wording.
Annex A Controls Where a Pentest Produces Evidence
The control numbers and titles below come from the table of contents in ISO's preview of ISO/IEC 27002:2022. Annex A of ISO/IEC 27001:2022 uses the same numbering.
Control | Title | What a pentest evidences | What the auditor will also want |
8.8 | Management of technical vulnerabilities | Exploitable weaknesses found, rated and fixed, with a retest that confirms closure | Asset inventory, scan records, patch timelines, risk acceptance for anything left open |
8.29 | Security testing in development and acceptance | Security testing of new or changed systems before release | A defined testing process in the SDLC, acceptance criteria, records per release |
8.25 | Secure development life cycle | Findings fed back into secure development rules | Secure development policy, training, code review practice |
5.36 | Compliance with policies, rules and standards for information security | Independent proof that technical controls match what your policies claim | Regular compliance reviews and how gaps were handled |
8.34 | Protection of information systems during audit testing | A test plan that protects production systems during testing | Approval of test scope, timing and access before testing starts |
Control 8.34 is the one buyers forget. An authorization letter, agreed test windows and a named contact satisfy it, and they also keep your on-call engineer from paging the whole company at 2 a.m. The rule of thumb is simple. A pentest is strong evidence for 8.8 and 8.29, supporting evidence for 8.25 and 5.36, and a process obligation under 8.34.
What Auditors Typically Look For
Everything in this section is common audit practice. None of it is a clause in ISO/IEC 27001, and individual certification bodies vary.
Scope that matches the ISMS: the systems tested should match the ISMS scope and the assets your risk assessment ranks highest.
Frequency justified by risk: a test cadence you can defend from your risk assessment, with extra tests after significant change.
Remediation records: each finding has an owner, a fix date or a formal risk acceptance.
Retest evidence: a dated retest showing which findings are closed.
Competence and independence: the tester is qualified and separate from the people who build and run the system.
Feedback into the ISMS: findings update the risk register and, where needed, the Statement of Applicability.
The retest is where audits most often stall. A report full of open criticals with no follow-up says the control exists on paper only. The penetration test retest guide covers how to run that step cleanly.
What a Report Needs to Carry for ISO Evidence
Auditors read the report as evidence, so structure matters. They look for scope, dates, method, tester identity, findings with severity, and remediation status.
Mapping each finding to the Annex A control it affects saves a round of questions. The sibling guide to the penetration testing report lays out every section.
How Often to Run an ISO 27001 Pentest
ISO/IEC 27001 sets no testing frequency. Your risk assessment sets it, and your auditor checks that the cadence you chose follows from that assessment. A yearly test aligned with your audit cycle is a common baseline. Add tests after significant change, such as a new product, a major authentication change, a cloud migration or an acquisition.
Fast-shipping SaaS teams often outgrow the annual model. A yearly report describes a product that changed hundreds of times since, which is why some teams pair it with continuous external testing. Whatever cadence you pick, write it down with the reason. "Annually, plus after significant change as defined in our change policy" is a sentence auditors accept far more readily than "when we get to it".
ISO 27001 vs SOC 2 vs PCI DSS on Pentests
The three frameworks differ most in how explicit they are. PCI DSS is the only one of the three that sets a pentest frequency in its own guidance.
Topic | ISO 27001 | SOC 2 | PCI DSS |
Is a pentest named as mandatory? | No. Risk-based controls, with 8.8 and 8.29 as the main hooks | No named mandate, and auditors commonly accept a pentest as evidence | Yes. Requirement 11.4 covers penetration testing |
Frequency | Set by your risk assessment | Set by your controls and auditor | At least annually and after any significant change, per PCI SSC guidance |
Tester independence | Expected in practice | Expected in practice | Tester must be organizationally separate from management of the target systems, per PCI SSC guidance |
Remediation and retest | Expected as 8.8 evidence | Expected as control evidence | Exploitable findings remediated and retested |
Who judges it | Accredited certification body | CPA firm issuing the report | QSA or internal assessor, per your validation level |
The PCI rows come from the PCI SSC Penetration Testing Guidance, sections 2.6 and 3. If you hold all three, design one test that satisfies PCI's stricter rules and map its findings to the other two.
Detail on each framework lives in the guides to SOC 2 penetration testing requirements, PCI DSS penetration testing requirements and compliance penetration testing in general.
From A.12.6.1 to 8.8 and the Transition Deadline
ISO/IEC 27001:2013 placed technical vulnerability management under control A.12.6.1. The 2022 edition restructured Annex A into four themes, and the same subject now sits at 8.8.
The four themes are organizational (5.1 to 5.37), people (6.1 to 6.8), physical (7.1 to 7.14) and technological (8.1 to 8.34). That adds up to 93 controls, per the ISO/IEC 27002:2022 table of contents. The transition rules come from the International Accreditation Forum. IAF MD 26:2023 set a 36-month transition period ending 31 October 2025.
It also required initial certification and recertification audits against the 2022 edition from 30 April 2024. All ISO/IEC 27001:2013 certificates expire or are withdrawn at the end of the transition period.
One later change is worth knowing. ISO published Amendment 1:2024, Climate action changes, in February 2024. ISO's page states that it applies to ISO/IEC 27001:2022.
What to Update in Your Evidence
Old reports that cite A.12.6.1 still describe real testing. Re-map them to 8.8 in your Statement of Applicability and evidence index so the auditor is not left translating. Refresh your testing procedure at the same time. If it still references 2013 control numbers, it signals a document nobody has reviewed since the transition.
Scoping an ISO 27001 Pentest
Start from the ISMS scope statement and the Statement of Applicability. If a system is in scope for the ISMS and holds sensitive data, it is a candidate for testing.
Rank candidates by exposure and data. Internet-facing applications and APIs, authentication services, and cloud control planes usually come first.
Choose depth per asset. Gray box with accounts for each role finds the access control flaws auditors care about, and white box adds the code root cause your developers need.
Write the scope, rules of engagement and test windows into a statement of work. That document also serves as your 8.34 evidence. The penetration testing scope of work guide has a template.
For applications, a pentest is one layer of a wider testing program. The sibling guide to application security testing services covers how SAST, DAST and code review fill the gaps between tests.
How CodeAnt AI is Sorting an ISO 27001 Program
CodeAnt AI connects what an attacker reaches from the outside with the code, cloud and internal systems behind it. Each finding comes with its root cause and a clear path to fix it.
External pentesting starts with agreed domains and assets. Repository, cloud or internal access is added only for the assessments you authorize, which keeps the 8.34 conversation short.
Reports arrive within 48 hours, mapped to SOC 2 and ISO 27001, and a retest after fixes gives you the closure evidence auditors ask for. Between full tests, CodeAnt monitors your attack surface 365 days a year.
Where This Leaves You
ISO 27001 does not force a pentest, and your risk assessment probably will. Scope it to the ISMS, justify the cadence, close findings with a retest and map everything to 8.8 and 8.29.
Shortlisting providers? Book a pentest scoping call, or run a free scan first and judge the 48-hour report yourself. Want to see the output before you talk to anyone? Open the sample report.
