ISO 27001 Penetration Testing Your Auditor Will Accept
Independent, manual penetration testing scoped to your ISMS and mapped to ISO/IEC 27001:2022 Annex A controls. Built for organisations preparing for initial certification and for certified teams that need fresh evidence for surveillance and recertification audits.
Is a Penetration Test Required for ISO 27001?
The honest answer: ISO/IEC 27001:2022 never literally says "you must run an annual penetration test". The standard is risk-based. It asks you to identify risks to the information inside your ISMS scope, choose controls from Annex A (93 controls across four themes: organizational, people, physical and technological) and prove those controls are working.
That last part is where penetration testing comes in. Annex A control A.8.8 requires you to obtain information about technical vulnerabilities, evaluate your exposure and take appropriate action. A.8.29 requires security testing processes to be defined and implemented in the development life cycle. Certification auditors need objective evidence for both, and a policy document on its own is not evidence.
In practice, if your scope includes internet-facing systems, cloud infrastructure or software you build, auditors will usually expect to see a recent independent penetration test report, the remediation that followed and proof that fixes were verified. Skipping it does not automatically fail an audit, but it leaves you defending a technical control with no technical evidence, which often leads to a nonconformity or an awkward observation. For a deeper look at the wording of the standard, read our guide to the ISO 27001 penetration testing requirement.
ISO 27001:2022 Annex A Controls a Pentest Supports
On request, we map findings to the relevant Annex A controls, so your ISMS team can link evidence straight into the Statement of Applicability
| Control | Title | How a penetration test provides evidence |
|---|---|---|
| A.8.8 | Management of technical vulnerabilities | Independent confirmation that exploitable vulnerabilities in in-scope systems are identified, risk-rated and remediated. Retest results show the loop is closed. |
| A.8.29 | Security testing in development and acceptance | Application and API testing before release or after major changes demonstrates that security testing is part of acceptance, not an afterthought. |
| A.8.25 | Secure development life cycle | Findings such as injection, broken access control or insecure design show whether secure coding rules are working, and feed back into your SDLC. |
| A.8.20 | Networks security | External and internal network testing verifies segmentation, exposed services and firewall rules behave as your network security controls describe. |
| A.8.9 | Configuration management | Misconfigurations, default credentials, weak TLS and insecure cloud settings found during testing reveal drift from your documented secure baselines. |
| A.5.35 | Independent review of information security | A third-party test performed by people outside your team is an independent review of how security is implemented in practice. |
| A.5.36 | Compliance with policies, rules and standards for information security | Testing checks whether systems actually comply with your own policies, for example password, encryption and access control standards. |
| A.8.34 | Protection of information systems during audit testing | Our rules of engagement, agreed testing windows and non-destructive approach show that technical testing was planned and authorised by management. |
Control numbers and titles refer to ISO/IEC 27001:2022 Annex A. Which controls apply to you depends on your risk assessment and Statement of Applicability.
What to Test: Scoping From Your ISMS
The pentest scope should follow your ISMS scope statement and asset inventory. Test what holds in-scope information, not a random sample of systems.
| Test area | Include it when your ISMS scope covers | Service |
|---|---|---|
| External network | Any internet-facing IP ranges, VPNs, mail servers or remote access in your ISMS scope. | Network penetration testing |
| Internal network | Offices, data centres or internal environments that store or process in-scope information. | Network penetration testing |
| Web applications | Customer portals, SaaS products and internal web apps that handle in-scope data. | Web application pentesting |
| APIs | Public, partner or mobile backend APIs, especially where tenants or roles must be isolated. | API penetration testing |
| Cloud | AWS, Azure or GCP accounts hosting in-scope workloads, identities and storage. | Cloud security testing |
| Mobile apps | iOS and Android apps used by customers or staff to access in-scope information. | Mobile app pentesting |
A common mistake is testing only the marketing website while the product, admin panels and cloud accounts that hold customer data go untested. Auditors compare the pentest scope with the ISMS scope, so gaps between the two tend to get noticed.
From Scoping to Auditor Evidence
A six-step process designed around the certification cycle, not just the test window
Scoping Against Your ISMS
We review your scope statement, asset inventory and Statement of Applicability, then agree targets, test windows and rules of engagement. You receive a fixed-price quote before any work starts.
Manual Testing
Certified testers attack your systems the way a real adversary would, focusing on access control, authentication, business logic, exposed services and misconfigurations. Testing is non-destructive and coordinated with your team.
Real-Time Findings and Report
Findings appear in the SLASH platform as they are confirmed and sync to Jira, so remediation starts immediately. The final report includes an executive summary, risk-rated findings and, on request, Annex A mapping.
Remediation and Risk Treatment
Your team fixes issues according to severity. Anything you choose not to fix goes into your risk treatment plan with an owner and justification, which is exactly what an auditor wants to see.
Free Unlimited Retesting
Mark an issue as fixed and we retest it within 48 hours, as many times as needed. The report is updated to show verified remediation.
Auditor Evidence Pack
You get the final report and retest results, ready to hand to your certification body and to share with customers during security reviews.
When to Test in the Certification Cycle
Before Stage 1
Stage 1 is largely a documentation review. You do not need a finished pentest yet, but your vulnerability management process and testing plan should be defined, and a booked test shows the auditor the plan is real.
Before Stage 2
This is the key window. Stage 2 assesses whether controls operate effectively. Test early enough to remediate and retest, so you present a closed loop rather than an open list of findings.
Surveillance and Recertification
Surveillance audits in the following years and the recertification audit check that controls keep operating. Retest at the frequency your policy defines, and after significant changes.
Typical durations: web application tests take 1 to 2 weeks, API tests around 1 week and network tests 2 to 3 weeks. Add time for remediation before your Stage 2 date.
What Your Auditor Receives
Evidence that answers the questions auditors actually ask: what was tested, by whom, what was found and what you did about it
Scope and Methodology
Targets, dates, test approach and rules of engagement, so the auditor can match test coverage to your ISMS scope.
Executive Summary
A plain-language view of overall risk for management review, certification bodies and customers.
Risk-Rated Findings
Each vulnerability with severity, affected assets, reproduction steps, evidence and business impact.
Annex A Mapping
On request, findings linked to the relevant ISO/IEC 27001:2022 controls, ready to reference in your SoA and risk treatment plan.
Retest Results
Verification of each fix, showing which issues are closed and which remain under risk treatment.
Remediation Guidance
Practical fix recommendations for each finding, tailored to your stack, so treatment actions are clear and auditable.
We handle your data in line with GDPR, sign NDAs as standard and provide DPAs on request, which also helps you evidence supplier controls for your ISMS.
Why Teams Choose SecurityWall for ISO 27001 Pentests
Certified Testers
OSCP, OSWE and CISSP-certified testers who understand both exploitation and audit expectations.
100% Manual Testing
No scanner output dressed up as a pentest. Every finding is confirmed by a human with evidence.
Retests in 48 Hours
Free, unlimited retesting, so you are never stuck waiting on proof of remediation before an audit.
Safe for Production
Non-destructive techniques and coordinated testing windows keep operations running.
What Drives the Cost of an ISO 27001 Pentest
Every engagement is fixed-price and based on scope, so you know the full cost before testing starts
- Number and complexity of web applications, including user roles and multi-tenant features
- Number of API endpoints and the authentication schemes protecting them
- Size of external and internal network ranges in your ISMS scope
- Cloud accounts, services and identity configurations to review
- Mobile platforms in scope (iOS, Android or both)
- Testing constraints such as out-of-hours windows or production-only environments
Retesting is never a hidden extra: it is free and unlimited. If you already have a quote from another provider, send it over. We beat market pricing for equivalent scope, without cutting testing depth.
ISO 27001 Penetration Testing FAQ
Is penetration testing mandatory for ISO 27001 certification?
ISO/IEC 27001:2022 does not contain a clause that says "perform an annual penetration test". However, Annex A requires you to manage technical vulnerabilities (A.8.8) and to test security in development and acceptance (A.8.29), and certification auditors expect objective evidence that these controls work. For most organisations with internet-facing systems or in-house software, an independent penetration test is the most direct and widely accepted way to provide that evidence.
Which ISO 27001 Annex A controls does a penetration test support?
A pentest primarily provides evidence for A.8.8 Management of technical vulnerabilities and A.8.29 Security testing in development and acceptance. It also supports A.8.20 Networks security, A.8.9 Configuration management, A.8.25 Secure development life cycle, A.5.35 Independent review of information security and A.5.36 Compliance with policies, rules and standards for information security. A properly planned engagement also demonstrates A.8.34 Protection of information systems during audit testing.
When should we run the pentest relative to our Stage 1 and Stage 2 audits?
Ideally, test after your scope and Statement of Applicability are defined and before the Stage 2 audit, leaving enough time to remediate and retest. That way the auditor sees not just a list of findings, but a complete cycle: findings identified, risk treated, fixes verified. For surveillance audits in years two and three, test again so the evidence stays current.
How often should we pentest to maintain ISO 27001 certification?
Most organisations test at least annually and after significant changes such as major releases, new infrastructure, cloud migrations or acquisitions. Your own risk assessment and vulnerability management policy should define the frequency, and the auditor will check that you followed it.
Will an automated vulnerability scan satisfy the auditor?
Regular scanning is a good part of A.8.8, but scans alone rarely demonstrate that security controls actually hold up against a skilled attacker. Scanners miss broken access control, business logic flaws and chained attacks. Auditors generally give more weight to independent, manual testing, ideally alongside your ongoing scan results.
How long does an ISO 27001 penetration test take?
It depends on scope. A web application test typically takes 1 to 2 weeks, an API test around 1 week, and a network test 2 to 3 weeks. Findings appear in real time in our SLASH platform during testing, so remediation can start before the final report is delivered.
Is retesting included, and does the auditor need to see it?
Yes, every engagement includes free, unlimited retesting, and each retest is completed within 48 hours of you marking issues as fixed. Retest results are strong evidence for auditors because they prove that identified vulnerabilities were treated, not just recorded.
Can you test production systems without disrupting operations?
Yes. We use non-destructive techniques, agree testing windows with your team in advance and avoid denial-of-service style tests unless you request them. This planning is also exactly what A.8.34 asks for: audit and testing activities that are agreed with management and minimise impact on operational systems.
Get Audit-Ready Pentest Evidence
Tell us your ISMS scope and audit dates. We will propose a fixed-price test that fits your timeline, with free retests to close every finding before the auditor arrives.
Learn More About ISO 27001 Pentesting
Guides on ISO 27001 pentest requirements and what auditors expect
