ISO 27001 penetration testing is a controlled, simulated attack on the systems inside your ISMS scope, used to prove your security controls work. ISO/IEC 27001:2022 never uses the words “penetration test,” but a pentest is the most direct evidence that controls such as Annex A 8.8 (management of technical vulnerabilities) and 8.29 (security testing in development and acceptance) are effective.
If you are preparing for ISO 27001 certification, or a customer has asked for third-party pentest evidence, this guide covers what the standard says, which controls a pentest supports, how to scope the test and what the report needs to contain to hold up in an audit.
Does ISO 27001 require penetration testing?
No, not by name. ISO/IEC 27001:2022 is a risk-based management system standard. It tells you to identify risks, choose controls and prove those controls are effective. It does not prescribe specific testing methods.
In practice, a penetration test is how most organizations meet three requirements that the standard does make:
- Clause 6.1.2 and 6.1.3 (risk assessment and treatment): you must identify information security risks and justify the controls you selected in your Statement of Applicability (SoA). A pentest shows which technical risks are real and exploitable.
- Clause 9.1 (monitoring, measurement, analysis and evaluation): you must evaluate whether your controls work. A pentest is an independent, evidence-based evaluation.
- Annex A 8.8 (management of technical vulnerabilities): you must obtain information about technical vulnerabilities, evaluate your exposure and take action. Scanning finds known weaknesses; a pentest confirms which ones an attacker can actually use.
So the honest answer for a CISO is this: ISO 27001 does not mandate a pentest, but if you include internet-facing systems, applications or cloud services in your ISMS scope, you will need a credible way to show technical vulnerabilities are managed. A pentest is the most widely accepted way to do that.
Note on versions: ISO 27001:2013 certificates ceased to be valid when the transition period ended on October 31, 2025. Many guides still cite 2013 control numbers such as A.12.6.1. The current numbers are in the table below.
Which ISO 27001:2022 Annex A controls does a penetration test support?
A well-scoped pentest produces evidence for more than one control. ISO 27001:2022 Annex A has 93 controls in four themes: organizational (37), people (8), physical (14) and technological (34). The ones below are where pentest results are most directly useful.
| ISO 27001:2022 control | Former 2013 control | What pentest evidence shows |
|---|---|---|
| 8.8 Management of technical vulnerabilities | A.12.6.1 | Vulnerabilities were identified, rated, prioritized and fixed within your defined timelines |
| 8.29 Security testing in development and acceptance | A.14.2.8, A.14.2.9 | New or changed applications were security tested before release |
| 5.35 Independent review of information security | A.18.2.1 | An independent party evaluated your controls |
| 5.36 Compliance with policies, rules and standards for information security | A.18.2.2, A.18.2.3 | Technical configurations match your own security policies and standards |
| 8.9 Configuration management | New in 2022 | Hardening baselines hold up; misconfigurations are found and corrected |
| 8.20 Networks security / 8.22 Segregation of networks | A.13.1.1 / A.13.1.3 | Network controls and segmentation stop lateral movement between zones |
| 8.2 Privileged access rights / 8.5 Secure authentication | A.9.2.3 / A.9.4.2 | Admin access, MFA and session handling resist realistic attacks |
| 8.25 Secure development life cycle / 8.26 Application security requirements | A.14.2.1 / A.14.1.2, A.14.1.3 | Security requirements were built in and verified, not just documented |
| 5.23 Information security for use of cloud services | New in 2022 | Cloud tenant configuration, identity and access policies were tested |
| 8.34 Protection of information systems during audit testing | A.12.7.1 | The test itself was planned and controlled to avoid disruption |
How to map results without overdoing it. Map each finding to the one control it most directly affects, not to every control it touches. Auditors want to see a clear line from finding → risk register → corrective action (clause 10.2) → retest. A finding mapped to six controls adds noise, not assurance.
Vulnerability scanning and pentesting work together here. Regular scanning covers the “obtain information” part of 8.8 continuously. The pentest validates exploitability and business impact at a point in time. Most ISMSs need both.
What type of penetration testing do ISO 27001 auditors expect?
Auditors don’t expect a specific test type. They expect testing that matches the risks and assets in your ISMS scope. An auditor will compare your pentest scope against your scope statement, asset inventory, risk assessment and SoA. Gaps between them are what draw questions.
Use your scope to decide which tests you need:
| If your ISMS scope includes… | Test to run | Common methodology reference |
|---|---|---|
| Internet-facing IPs, VPN, email and remote access | External network penetration test | NIST SP 800-115, PTES |
| Office or data center networks, Active Directory | Internal network penetration test (often from an assumed-breach position) | NIST SP 800-115, PTES |
| Customer-facing web applications | Web application penetration test (authenticated and unauthenticated) | OWASP Web Security Testing Guide, OWASP ASVS |
| Public or partner APIs | API penetration test | OWASP API Security Top 10 |
| iOS or Android apps | Mobile application penetration test | OWASP MASTG / MASVS |
| AWS, Azure or GCP workloads | Cloud configuration review plus cloud penetration test | Provider security benchmarks (e.g., CIS Benchmarks) |
| Office Wi-Fi in scope | Wireless penetration test | NIST SP 800-115 |
| People and awareness controls (6.3) | Phishing or social engineering assessment | Agreed rules of engagement |
Black box, grey box or white box? For ISO 27001, grey-box testing (testers get user credentials and basic documentation) is usually the best fit. It spends the testing time on finding real weaknesses instead of on reconnaissance, which gives auditors more coverage per day of testing.
Independence matters. Annex A 5.35 calls for independent review. The people testing a system should not be the people who built or run it. A third-party firm is the simplest way to show this, and it is what customers usually ask for in due-diligence questionnaires.
What security testing should a SaaS company run before ISO 27001 certification?
For a typical SaaS company, a defensible baseline is:
- A web application and API penetration test of the production product, covering authentication, authorization and tenant isolation.
- A cloud configuration review of the production AWS, Azure or GCP accounts (identity and access policies, storage exposure, logging, network rules).
- An external network penetration test of everything internet-facing.
- Continuous vulnerability scanning of hosts, containers and dependencies, with documented remediation timelines.
- A mobile application test if a mobile app is in scope.
Add an internal network test if you have office networks or on-premises systems in scope.
How do you scope an ISO 27001 penetration test?
Scope the pentest from your ISMS documents, not from a vendor’s package list. Seven steps:
- Start from the ISMS scope statement. List the locations, business units, systems and services the certificate will cover. Anything outside it does not need testing for certification.
- Pull in-scope assets from your asset inventory. Include domains, IP ranges, applications, APIs, cloud accounts, mobile apps and identity providers.
- Rank assets using your risk assessment (clause 6.1.2). Systems that store customer data or support critical services get deeper testing, such as authenticated testing and more test days.
- Check the SoA. Every technical control you marked as applicable (8.8, 8.9, 8.20, 8.29 and others) should have some testing evidence behind it.
- Pick test types and depth. Use the table above to match assets to tests. Decide on grey-box or black-box and which user roles the testers get.
- Agree rules of engagement. Set testing windows, out-of-bounds systems, emergency contacts, data handling and how critical findings are reported mid-test. This is your evidence for Annex A 8.34.
- Agree the deliverables and retest up front. Confirm the report will include control mapping and that remediation will be verified, so your corrective actions can be closed with evidence.
Scope template checklist (copy into your statement of work):
- ISMS scope statement reference and version
- In-scope assets: domains, IP ranges, applications (with URLs), APIs, cloud accounts, mobile apps
- Explicit exclusions and the reason for each
- Test types and approach (black, grey or white box), with user roles provided
- Testing windows, environments (production or staging) and change freeze dates
- Rules of engagement and emergency contacts
- Methodology the vendor will follow (named standard)
- Report format, Annex A mapping and retest terms
- Target dates relative to your internal audit and Stage 2 audit
Cloud-specific note (AWS, Azure, GCP). Many cloud weaknesses in ISO 27001 scope sit in configuration rather than code: overly broad identity and access policies, publicly exposed storage, missing logging and permissive network rules. A network pentest alone is not designed to find these. Pair it with a configuration review of each in-scope account and map the results to 5.23 and 8.9.
Penetration testing vs. vulnerability scanning vs. compliance testing: what’s the difference for ISO 27001?
These terms get used interchangeably in vendor proposals. They produce different evidence.
| Vulnerability scan | Penetration test | Compliance security testing (ISMS audit) | Red team exercise | |
|---|---|---|---|---|
| What it is | Automated tool checks for known vulnerabilities and misconfigurations | Skilled testers manually exploit weaknesses to show real impact | Review of whether controls are designed, documented and operating | Objective-based simulation of a real adversary, often covert |
| What it proves for ISO 27001 | You are “obtaining information” about vulnerabilities (8.8) | Controls withstand a realistic attack (8.8, 8.29, 5.35) | The ISMS conforms to the standard (9.2 internal audit, certification audit) | Detection and response work (8.16, 5.24–5.26) |
| Depth | Broad, shallow, many false positives | Narrower, deep, validated findings | Process and documentation | Deep along one or more attack paths |
| Typical cadence (common practice) | Continuous, weekly or monthly | Annually and after significant change | Internal audit at planned intervals; certification audit yearly | Optional, for mature programs |
| Needed for certification? | Strongly expected in practice | Strongly expected in practice | Yes (internal audit is mandatory under 9.2) | Not required |
The short version: a scan tells you what might be wrong, a pentest tells you what an attacker can actually do, and an audit tells you whether your management system works. ISO 27001 auditors look at all three, and they read the pentest report as evidence for the other two.
What should an ISO 27001 penetration test report include?
An auditor reads your pentest report to answer one question: can this organization find, assess and fix technical vulnerabilities in its ISMS scope? The report should make that easy. Ask for these ten elements before you sign:
- Executive summary in business terms: overall risk, the most serious issues and what they could lead to.
- Scope statement that names the assets tested and ties them to your ISMS scope, including exclusions.
- Dates and testing windows, plus the environment tested (production or staging).
- Methodology, naming the standard followed (for example OWASP WSTG, NIST SP 800-115 or PTES).
- Tester independence and qualifications, so the report supports Annex A 5.35.
- Findings with severity ratings, using a recognized scale such as CVSS v3.1 or v4.0, adjusted for business context.
- Evidence for each finding: affected asset, reproduction steps and screenshots or request/response samples.
- Remediation guidance specific enough for your engineers to act on.
- Annex A control mapping for each finding, so findings flow straight into your risk register and corrective action log.
- Retest results or a remediation verification letter showing which findings were fixed and confirmed.
What happens with findings after the report?
This is where many audit questions land. Auditors want to see that findings didn’t just sit in a PDF. For each one, keep a record of:
- The risk register entry or update it created (clause 6.1.2)
- The treatment decision: fix, mitigate, transfer or formally accept, with the owner who approved it (clause 6.1.3)
- The corrective action and its due date (clause 10.2)
- The retest evidence that closed it
Accepted risks are fine under ISO 27001, as long as the decision is documented and approved by the risk owner. Open findings from last year’s test with no documented decision are the kind of gap an auditor will ask about.
When and how often should you run a penetration test for ISO 27001?
ISO 27001 does not set a testing frequency. You set it in your own policy, based on risk. The common practice is at least once a year, plus a test after any significant change, such as a major release, a new cloud environment, an acquisition or a network redesign. Whatever frequency you choose, write it into your vulnerability management or security testing policy and follow it, because auditors check that you do what your policy says.
Where the pentest fits in the certification cycle
An ISO 27001 certificate runs on a three-year cycle: an initial certification audit (Stage 1 documentation review, then Stage 2 implementation audit), surveillance audits in years two and three, then recertification. For a first certification, this order gives you time to fix findings before the auditor arrives:
- Risk assessment and SoA complete. You know what is in scope and which controls apply.
- Penetration test. Ideally 8–12 weeks before Stage 2, so there is time to remediate.
- Remediation and retest. Close critical and high findings; document decisions on the rest.
- Internal audit (clause 9.2). The internal auditor reviews the pentest evidence along with the rest of the ISMS.
- Management review (clause 9.3). Leadership sees the results and approves risk decisions.
- Stage 1 and Stage 2 certification audits.
- Ongoing. Repeat the pentest at your policy interval and keep the evidence ready for each surveillance audit.
How do you choose an ISO 27001 penetration testing provider?
ISO 27001 doesn’t accredit or approve pentest firms, so the choice is yours to justify. These questions separate a firm that produces audit-ready evidence from one that hands over scanner output:
| Question to ask | What a good answer looks like |
|---|---|
| How much of the testing is manual? | Most test time is spent on manual exploitation, with scanners used for coverage, not as the deliverable |
| Which methodology do you follow? | A named standard (OWASP WSTG, NIST SP 800-115, PTES) applied to your asset types |
| Who will do the testing? | Named testers with relevant certifications (for example OSCP, OSWE, GPEN or CREST) and experience with your stack |
| Can we see a sample report? | A redacted report with an executive summary, evidence per finding and remediation steps |
| Do you map findings to ISO 27001:2022 Annex A? | Yes, using the 2022 control numbers, not the 2013 ones |
| Is a retest included, and on what terms? | Remediation verification is defined in the statement of work, with a time window |
| How do you handle our data and production systems? | Documented rules of engagement, an NDA, secure evidence handling and an emergency stop process |
| Can you meet our audit date? | A schedule that leaves time to remediate and retest before Stage 2 |
How much does an ISO 27001 penetration test cost?
There is no standard price, because the cost is driven by scope, not by the standard. The main factors are:
- Number and type of assets: IP addresses, applications, API endpoints, mobile apps and cloud accounts
- Application complexity: the number of user roles, multi-tenant logic and integrations
- Testing approach: grey-box authenticated testing takes more effort than an unauthenticated scan-and-verify
- Environment and timing constraints: out-of-hours windows or production-only testing
- Reporting and retest requirements: Annex A mapping, executive readouts and remediation verification
The most useful thing you can do before asking for quotes is complete the scope checklist above. Quotes built on the same scope are comparable; quotes built on different assumptions are not. A low quote often means fewer test days or more automation, so compare test days and methodology, not just the total.
ISO 27001 penetration testing FAQ
Is penetration testing mandatory for ISO 27001 certification?
No. ISO/IEC 27001:2022 does not mention penetration testing. But it requires you to manage technical vulnerabilities (Annex A 8.8) and prove your controls are effective (clause 9.1). For any ISMS with internet-facing systems or applications in scope, a pentest is the most widely accepted way to produce that evidence.
Does ISO 27001 require vulnerability scanning?
Not by name. Annex A 8.8 requires you to obtain timely information about technical vulnerabilities and act on it. Automated vulnerability scanning is the usual way to do that continuously, while a penetration test validates which vulnerabilities are actually exploitable. Most ISO 27001 programs use both.
Which ISO 27001 control covers penetration testing?
In ISO 27001:2022, the main one is Annex A 8.8, management of technical vulnerabilities (formerly A.12.6.1 in the 2013 version). Pentest results also support 8.29 (security testing in development and acceptance), 5.35 (independent review), 8.9 (configuration management) and 5.23 (cloud services).
What is the difference between penetration testing and compliance security testing for ISO 27001?
Penetration testing is a technical exercise: testers attack your systems to find exploitable weaknesses. Compliance security testing, such as an internal audit, checks whether your controls are designed, documented and operating as the standard requires. A pentest is one input to the compliance assessment.
Can one penetration test cover both SOC 2 and ISO 27001?
Usually, yes. Neither framework prescribes a pentest, but both accept one as evidence. In SOC 2, penetration testing appears in the points of focus for CC4.1 (monitoring activities). If one test covers the systems in both scopes and the report maps findings to both frameworks, a single engagement can serve both audits.
Do I need a retest after an ISO 27001 penetration test?
ISO 27001 doesn’t require one, but clause 10.2 requires you to verify that corrective actions worked. A retest, or a remediation verification letter from the testing firm, is the cleanest evidence that critical and high findings were fixed. Agree the retest terms before the engagement starts.
How long does an ISO 27001 penetration test take?
It depends on scope. A single web application or external network test is typically measured in days of testing, while a scope covering applications, APIs, cloud accounts and internal networks takes longer. Allow time after testing for reporting, remediation and retest before your Stage 2 audit.
What should I ask for so auditors accept my pentest report?
Ask for a scope statement tied to your ISMS scope, a named methodology, dated testing windows, severity-rated findings with evidence, remediation guidance, Annex A 2022 control mapping and retest results. Then show the auditor how each finding moved into your risk register and corrective action log.
Get an ISO 27001 penetration test scoped to your ISMS
Canary Trap has been delivering penetration testing since 2020. If you are preparing for ISO 27001 certification or a surveillance audit, Talk to our team about scoping your ISO 27001 penetration test →
