%20(7)%20(1).avif)
Key takeaways:
- ISO 27001 does not explicitly require penetration testing by name, but to attend to two Annex A controls (A.8.8 and A.8.29), it is highly recommended.
- The most common mistake isn’t skipping the pentest entirely, but rather treating it as a checkbox. ISO 27001 auditors want to see pentest findings feeding into the risk register, risk treatment plan, and Statement of Applicability.
- You need to time your pentesting right: around 6-8 weeks before Stage 2, not the week before. This leaves remediation runway so you can present closed findings, not open ones, to the auditor.
- A vulnerability scan is not a substitute for a manual penetration test. Experienced security professionals can clearly distinguish between the results of an automated scan and a thorough penetration test.
ISO 27001 doesn’t use the word “pentest” anywhere in the standard. However, it is highly recommended not only to implement Annex A controls, but also to demonstrate to enterprise-level customers that your security defences are effective: a penetration test signals maturity.
This post covers both what ISO 27001 requires from a penetration testing perspective and the four errors I most often see in first-time ISO 27001 programs.
If you’re still earlier in the ISO 27001 journey, start here.
Does ISO 27001 require Penetration Testing?
No, ISO 27001 does not explicitly mandate penetration testing by name. The standard takes a risk-based approach. It requires organisations to identify, assess, and treat technical vulnerabilities, and to demonstrate that security controls operate effectively. What it leaves open is the mechanism for doing so.
But two controls in Annex A make penetration testing the most logical and auditor-accepted mechanism for any SaaS startup processing customer data:
Control A.8.8: Management of Technical Vulnerabilities
Requires timely identification of technical vulnerabilities, assessment of your actual exposure to those vulnerabilities, and appropriate measures to address the associated risk.
A vulnerability scan identifies known weaknesses in a database. A penetration test validates whether those weaknesses are genuinely exploitable in your specific environment, which is a materially stronger piece of evidence and preferred by the auditors.
The ISO 27002:2022 implementation guidance, the companion document that explains how to fulfil Annex A controls, explicitly recommends penetration testing as a mechanism for A.8.8. That makes it the recommended approach.
Control A.8.29: Security Testing in Development and Acceptance
Requires that security functionality be tested throughout development and before acceptance into production. For many SaaS products with continuous deployment and an evolving API surface, the easiest way to implement this control is through independent technical testing.
The four mistakes startups make
Mistake 1: Treating the Pentest as a Checkbox Rather Than an ISMS Input
This is the most common mistake, and the one that creates the most problems at Stage 2.
A startup buys a pentest, receives the report, files it away, and moves on. The pentest happened. The box is checked. Except ISO 27001 auditors don’t just want to see a pentest report. They want to see evidence that the findings were integrated into the ISMS.
Three documents the pentest should feed into:
- Risk Register: Each finding represents a validated risk. Critical and high-severity findings should be added to the risk register with the pentest report as supporting evidence. This is significantly stronger than a theoretical risk identified during a risk assessment workshop.
- Risk Treatment Plan: For each finding added to the risk register, a treatment decision must be documented (mitigate, accept, avoid, or transfer) with a named owner and a deadline. Auditors review this document.
- Statement of Applicability: Should explicitly reference the pentest as evidence for controls A.8.8 and A.8.29. The SoA is one of the documents auditors scrutinise most carefully. If the evidence column is empty or says “internal review,” a pentest report with mapped findings is a significantly stronger position.
Mistake 2: Scoping the Test Too Narrowly
Founders assume the pentest only needs to cover what’s formally defined in their ISO 27001 ISMS scope. But auditors look beyond that, at what handles customer data and poses real risk, not just what’s been documented in the scope statement.
Don’t scope the pentest based on what’s most convenient to certify. Rather, scope it to match what your enterprise buyers would consider your attack surface. For most startups, this means the customer-facing application, all APIs that handle customer data, your identity provider, and the cloud infrastructure supporting production.
Mistake 3: Using a Vulnerability Scan Instead of a Manual Pentest
Automated vulnerability scans are certainly faster and cheaper than manual penetration tests, but they don’t identify critical security weaknesses.
Automated scanners identify known vulnerabilities from databases of documented issues. They generate false positives, miss business logic flaws, can’t chain multiple low-risk findings into a meaningful attack path, and produce generic output that doesn’t reflect your specific environment.
Experienced security professionals can clearly distinguish between the results of an automated scan and a thorough penetration test.
A manual penetration test by a qualified tester produces CVSS-rated findings with reproducible steps, remediation guidance, and validated evidence demonstrating A.8.8 compliance.
Mistake 4: Starting Too Late
It’s common to see founders schedule the pentest after they think everything else is ready, which means the report lands days before Stage 2 with no time to remediate findings before the auditor starts.
The right sequencing: complete the pentest 6-8 weeks before Stage 2, review the findings, and remediate critical and high-severity issues. Then document the remediation in the risk treatment plan, present the auditor with both the original report and evidence that the findings were addressed. A closed finding is significantly stronger audit evidence than an open one.
An auditor who arrives at Stage 2 and finds unresolved critical vulnerabilities may issue a major nonconformity, a finding serious enough to prevent certification until it’s resolved. Resolving a major nonconformity typically requires a follow-up audit, adding cost and weeks to your timeline. A penetration test is significantly less expensive than a failed Stage 2.
What auditors look for
Understanding what happens during Stage 2 when the auditor reviews your penetration testing evidence helps you prepare the right documentation rather than discovering gaps under pressure.
The Report Itself
Auditors are experienced enough to distinguish between a genuine manual penetration test and an automated scan report dressed up as a pentest.
A credible report includes: named testers with relevant certifications (OSCP, CREST, CHECK in the UK), a clearly defined scope and methodology, reproducible findings with CVSS severity ratings, specific remediation guidance for each finding, and evidence of retesting where remediation was completed.
How Findings Connect to the ISMS
The auditor will ask to see your risk register and risk treatment plan alongside the pentest report.
If pentest findings aren’t reflected in these documents, it signals that the ISMS isn’t functioning as a live system, rather as a documentation exercise that doesn’t represent how the organisation actually manages security risk.
Frequency
Considering a pentest is not mandatory, there isn’t an established frequency. That being said, here are a few considerations:
- If you affirm in your policy that your pentesting is annual, then the auditor must find evidence that this is what actually happens in real life. If he doesn’t, that is going to be a problem.
- In terms of security, once a year, plus additional tests after significant changes to systems, architecture, or scope, is the minimum recommended.
If you want to know more about penetration testing frequency, check this post.
What type of pentest does ISO 27001 need?
For a typical startup, the right penetration testing scope covers three areas:
Web Application and API Testing
The primary attack surface for any cloud-native SaaS product. Should cover authentication and authorisation logic, session management, input validation, injection vulnerabilities, and business logic flaws.
OWASP Top 10 is the standard reference framework. Auditors recognise it, and it maps cleanly to A.8.29.
APIs are increasingly the most critical attack surface for SaaS products and should never be excluded from scope.
Cloud Infrastructure Configuration Review
Test your AWS, GCP, or Azure environment for misconfiguration, identity and access management, storage permissions, network security groups, logging and monitoring configuration, and public exposure of internal services.
Cloud misconfiguration remains one of the most common sources of material breaches and a consistent area of focus by the auditor under A.8.8.
Internal Network Testing
Less relevant for fully cloud-native startups with no permanent offices, but required if a hybrid infrastructure or office-based development environments are in scope.
If your developers have access to production systems from office networks, those networks represent a meaningful attack path worth testing.
Methodology: Why Grey Box Is Usually Right
Grey box penetration testing, where the tester has application credentials and architectural context but not full source code access, is the recommended approach for most SaaS startups.
It produces deeper, more representative findings than black box testing (which simulates a zero-knowledge external attacker) and at lower cost, because testers spend their time on your actual business logic rather than mapping your attack surface from scratch.
Black box testing is appropriate when you specifically want to simulate an external attacker with no prior knowledge. White box testing (full source code access) is appropriate when you want the most comprehensive code-level review. For ISO 27001 audit purposes, a grey box provides the best balance of depth and efficiency.
How Pentest findings feed into your ISMS
Getting the pentest done is necessary, but getting the findings into your ISMS is what makes it useful as audit evidence.
Risk Register
Each finding from the pentest represents a validated risk, a vulnerability that has been confirmed as exploitable in your specific environment.
Critical and high-severity findings should be added to the risk register with the pentest report as the supporting evidence source.
The risk register entry should record the vulnerability, the affected system, the CVSS score, the exploitability evidence, and the date identified. This turns your risk register from a workshop output into a living document that reflects your actual security posture.
Risk Treatment Plan
For each finding added to the risk register, document the treatment decision: mitigate (remediate the vulnerability), accept (document why the residual risk is acceptable given your context), avoid (remove the at-risk functionality), or transfer (cyber insurance covers the residual risk).
Each entry needs a named owner and a remediation deadline. Auditors examine the risk treatment plan in detail during Stage 2, and during surveillance audits, they’ll check whether previous treatment decisions were implemented on time.
Statement of Applicability
The SoA should explicitly reference the penetration test as evidence for controls A.8.8 and A.8.29.
The evidence column for these controls should cite the pentest report by date and scope. Additional controls that pentest findings may support include A.8.20 (Network Security), A.5.36 (Compliance with Policies), and A.8.25 (Secure Development Life Cycle).
Your compliance partner should map each finding to the relevant Annex A controls as part of the engagement.
At SecureLeap, the pentest report and the ISMS documentation are maintained by the same team. When findings come in, they go straight into the risk register and treatment plan. No gap between the test and the compliance record, which is what makes the difference at Stage 2.
How often should you Pentest for ISO 27001?
ISO 27001 doesn’t prescribe annual penetration testing by name, but the market expectations make it the practical standard. Here’s how to think about frequency:
- Minimum: Annually, aligned with your ISMS review cycle and completed 6-8 weeks before your surveillance or recertification audit.
- After significant changes: A major new product feature, an architecture migration, a new cloud provider, a significant new third-party integration, or a change in ISMS scope all warrant additional testing. Your ISMS should define what constitutes a “significant change” that triggers a new test.
- For regulated sectors: Startups in fintech, healthtech, or govtech, or those processing high volumes of sensitive personal data, should consider quarterly testing or Penetration Testing as a Service (PTaaS) for continuous coverage. Enterprise buyers in these sectors increasingly expect it regardless of ISO 27001 requirements.
For a detailed guide on pentest cadence and what triggers additional testing cycles, check this post.
Choosing the right pentest provider for ISO 27001
Not all pentest providers produce reports that work as ISO 27001 audit evidence. Three things to verify before signing:
- Certifications: The tester should hold OSCP, CREST, or CHECK (the UK standard for government and regulated sector work). Auditors recognise these credentials and may ask specifically who conducted the test.
- Annex A control mapping: Always ask the provider: “Can your report map findings to A.8.8 and A.8.29?”
- ISO 27001 experience: A provider who has supported ISO 27001 certifications before will scope and time the engagement correctly.
For a full comparison of pentest providers serving UK and EU startups, including pricing, accreditation, and compliance alignment, check this post.
How SecureLeap approaches ISO 27001 Penetration Testing
SecureLeap conducts ISO 27001 penetration testing both as part of its full ISO 27001 implementation engagements and as isolated tests.
Our ISO 27001 pentest is scoped to match the ISMS scope, timed 6-8 weeks before Stage 2, and the report is delivered with Annex A control mapping built in, findings mapped to A.8.8 and A.8.29, CVSS-rated severity, and remediation guidance your auditor can trace back to the risk treatment plan.
Because the same team manage pentest and the ISMS, there’s no gap between the test findings and the compliance documentation. The risk register and treatment plan are updated as part of the same engagement. No handover between a pentest provider and a compliance consultant. One team, one program.
Book a free 30-minute consultation, and we’ll tell you how the pentest fits into your specific ISO 27001 timeline and what the scope should cover. Click here and start your pentesting.
Frequently asked questions on pentesting for ISO 27001
Does ISO 27001 require penetration testing?
Not explicitly. ISO 27001 requires organisations to identify and manage technical vulnerabilities and demonstrate that security controls work effectively. Controls A.8.8 and A.8.29 in Annex A create a clear expectation of independent technical testing for any organisation with internet-facing systems handling customer data. ISO 27002:2022 guidance explicitly recommends penetration testing as a mechanism for fulfilling A.8.8.
In real-life scenarios, a pentest report is the most recommended approach to prove these controls.
How often do you need to pentest for ISO 27001?
At a minimum, annually.
Additionally, you should test when significant system changes occur: new major features, architecture migrations, new third-party integrations, or changes to the ISMS scope.
Your risk assessment should formally define the frequency based on your specific risk profile. For startups in regulated sectors or handling high-risk personal data, quarterly testing or PTaaS is increasingly expected by enterprise buyers.
What Annex A controls does a pentest support?
Primarily A.8.8 (Management of Technical Vulnerabilities) and A.8.29 (Security Testing in Development and Acceptance). The pentest report should explicitly map findings to these controls in your Statement of Applicability. Additional controls that pentest findings may support include A.8.20 (Network Security), A.5.36 (Compliance with Policies), and A.8.25 (Secure Development Life Cycle).
What’s the difference between a vulnerability scan and a penetration test for ISO 27001?
A vulnerability scan is an automated tool that identifies known weaknesses from a database of documented vulnerabilities. It’s fast, low-cost, and useful for ongoing monitoring.
A penetration test is a manual engagement where a qualified tester attempts to exploit vulnerabilities, chain findings together, and demonstrate real-world impact.
Experienced security professionals can clearly distinguish between the results of an automated scan and a thorough penetration test.
