Short answer
ISO 27001 does not require a penetration test. It requires you to manage technical vulnerabilities and test security, based on your own risk assessment. A pentest is one of the most common ways to show those controls work, so many certification auditors expect to see one when your Statement of Applicability relies on it.
The current edition is ISO/IEC 27001:2022, with Amendment 1:2024 on climate action. See the ISO 27001 page on iso.org. The accredited certification body DQS describes penetration tests as one optional way to identify vulnerabilities under control 8.8, planned and performed by authorised people; see its guide to controls 8.8 and 8.9.
Annex A controls a pentest supports
| Control | How a pentest helps |
|---|---|
| 8.8 Management of technical vulnerabilities | Finds exploitable weaknesses and shows they were fixed and retested. |
| 8.29 Security testing in development and acceptance | Tests new systems and major releases before or soon after they go live. |
| 5.35 Independent review of information security | An outside tester gives an independent view of how well controls work. |
| 5.36 Compliance with policies, rules and standards for information security | Checks that systems match your own security policies. |
| 8.34 Protection of information systems during audit testing | Tests on live systems are planned and agreed with management first, which signed rules of engagement document. |
Control titles are from ISO/IEC 27001:2022 Annex A. The full text and the ISO/IEC 27002 guidance are sold by ISO and national standards bodies.
Risk treatment and the Statement of Applicability
ISO 27001 works from your risks. Clause 6.1.3 asks you to choose controls to treat them and record the choice in a Statement of Applicability (SoA). If your SoA or risk treatment plan says you run penetration tests, for example annually and after major changes, the pentest becomes part of how you operate that control, and the auditor will check it happened.
Write a cadence you can keep. A promise of quarterly tests that you then miss becomes a nonconformity, where a yearly test you actually run does not.
Where it fits in the audit cycle
- Stage 1 reviews your ISMS design and documents, including the policy that says how you test.
- Stage 2 checks that controls are implemented and working. A recent pentest report and remediation record is strong evidence for 8.8 and 8.29.
- Surveillance audits run at least once a year. Testing a few weeks before each one leaves time to fix and retest.
- Recertification happens every three years.
See LRQA's ISO 27001 FAQ for how a certification body describes the cycle.
What to put in scope
Start from the scope of your ISMS and the risks you rated highest. For most software companies that means:
- The customer-facing web application and its API, tested with accounts for each role.
- The external network: VPN gateways, remote access, and anything else reachable from the internet.
- The cloud account that hosts production, including IAM.
Evidence to keep
Helix gives you the signed rules of engagement, the report itself, and the retest result for every fix. You add the remediation tickets, any risk acceptances, and the line back to the SoA control.
- Signed rules of engagement, which also covers control 8.34.
- The report: scope, methodology, dates, and rated findings.
- Remediation tickets and retest results for each finding you fixed.
- Risk acceptance, signed by the risk owner, for anything you chose not to fix.
- The link from each of these to the SoA control and the risk it treats.
ISO 27001 pentest planning checklist
Your SoA or risk treatment plan says whether and how often you pentest.
The test scope matches the ISMS scope and your highest-rated risks.
Testing on live systems is approved in signed rules of engagement.
The test lands early enough before the audit to fix and retest.
Findings feed your vulnerability management procedure under 8.8.
Unfixed findings have a documented risk acceptance.
Report, remediation record, and retest are filed together as evidence.
Frequently asked questions
Is penetration testing mandatory for ISO 27001?
No. ISO/IEC 27001:2022 does not name penetration testing as a requirement. It requires you to manage technical vulnerabilities and to test security in development, and a pentest is one common way to show that those controls work. Your risk assessment decides whether you need one.
How often should we run a pentest for ISO 27001?
The standard does not set a frequency. Many organisations test once a year, before the surveillance audit, and after major changes. Whatever you choose, write it into your policy and follow it, because the auditor will check that you did what you said.
Will the certification auditor ask for a pentest report?
Often, if your Statement of Applicability or risk treatment plan relies on penetration testing for controls such as 8.8 or 8.29. The auditor checks that the control is designed and working, so they will want the report, the findings, and what you did about them.
Do we still need a pentest if we already run vulnerability scans?
Scans find known vulnerable versions and settings across many systems. A pentest checks whether weaknesses can be exploited, including access-control and business-logic flaws no scanner finds. Many organisations use both and describe each in their vulnerability management procedure.
Is our 2013 certificate still valid?
No. The transition to ISO/IEC 27001:2022 ended on 31 October 2025, and certificates against the 2013 version expired or were withdrawn. An organisation with a lapsed certificate is treated as a new client by its certification body.
How much does an ISO 27001 penetration test cost?
For a typical single web app or API, Helix charges $3,000 USD black box, $4,000 USD gray box, and from $7,000 USD white box, with free unlimited retesting. External network tests start at $3,000 USD, internal network and cloud tests at $4,000 USD, and white box at $7,000 USD, priced on the number of hosts or accounts.