ISO 27001 Penetration Testing
ISO/IEC 27001 is the international standard for an Information Security Management System (ISMS). It does not name a clause that says “run a penetration test” — but a penetration test is the expected evidence used to satisfy its technical-vulnerability and security-testing controls and to feed the risk assessment that sits at the heart of the standard.
OraSec delivers manual penetration testing scoped to your ISMS and mapped to the ISO/IEC 27001:2022 Annex A controls your certification body and internal auditors actually look for — principally A.8.8 and A.8.29 — so the report drops straight into your audit file.
Prefer to talk? +1 307 310 7808
Does ISO 27001 require a penetration test?
Strictly speaking, no single clause of ISO/IEC 27001 mandates a penetration test in those words. The standard is risk-based: it requires you to operate an ISMS, to assess information security risks (Clause 6.1.2), to select and implement appropriate controls from Annex A, and to demonstrate that those controls are working. Penetration testing is not a tick-box requirement — it is the practical, widely accepted way to generate the technical evidence those requirements call for.
That distinction matters when you talk to an auditor. A penetration test is best described as expected evidence, not a mandated activity. Certification bodies do not fail you for the absence of a document titled “penetration test”; they look for evidence that you understand your technical vulnerabilities, that you test the security of systems before they go live, and that you act on what you find. A well-scoped penetration test produces exactly that evidence — which is why almost every certified organization runs one.
In other words: the standard requires the outcome (managed technical vulnerabilities and tested systems), and a penetration test is the most credible, independent way to show you have achieved it.
How a pentest maps to Annex A.8.8 & A.8.29
The 2022 revision of the standard reorganized Annex A into four themes. Two technological controls do most of the work in justifying a penetration test, and our reports map findings directly to them.
A.8.8 — Management of technical vulnerabilities
A.8.8 requires the organization to obtain information about technical vulnerabilities, evaluate its exposure, and take action. A penetration test is the most direct way to discover those vulnerabilities in context — chaining issues into real exploit paths rather than reporting isolated scanner hits — and feeds the prioritization and remediation that the control demands.
A.8.29 — Security testing in development and acceptance
A.8.29 expects security testing to be defined and carried out across the development lifecycle, including before a system is accepted into production. Application and API penetration testing satisfies this by validating that new or changed systems meet your security requirements before release, not after an incident.
2013 → 2022 mapping note
If your ISMS documentation still references the 2013 control numbers, the equivalents are straightforward: A.8.8 (management of technical vulnerabilities) corresponds to the old A.12.6.1 (technical vulnerability management), and A.8.29 (security testing in development and acceptance) corresponds to the old A.14.2.8 (system security testing). We can label findings against either numbering scheme so the report lines up with your Statement of Applicability as it stands today.
Scope, the ISMS & your Statement of Applicability
The single most important scoping question in an ISO 27001 penetration test is: what is inside your ISMS? Your certificate covers a defined boundary — the systems, services, locations and information assets in your ISMS scope — and your penetration test should align to that same boundary. Testing assets outside the certified scope adds cost without adding audit value; leaving in-scope assets untested leaves a gap an auditor can challenge.
The Statement of Applicability (SoA) is the bridge between the standard and your environment. It records which Annex A controls you have applied, which you have excluded, and the justification for each. Because A.8.8 and A.8.29 are almost always marked as applicable, the SoA effectively documents your commitment to vulnerability management and security testing — and the penetration test is how you evidence that those applicable controls are operating in practice.
We scope each engagement from your ISMS scope statement and SoA: we confirm which applications, external and internal infrastructure, APIs and cloud environments fall inside the boundary, agree the rules of engagement and test windows, and ensure the resulting report references the controls your SoA lists. The output is built to be filed alongside your SoA and risk assessment, not translated into them afterwards.
Where it fits the certification & surveillance cycle
ISO/IEC 27001 certification follows a predictable rhythm, and a penetration test slots into it at well-defined points. Initial certification is a two-stage audit. Stage 1 is a documentation review — the auditor checks that your ISMS, policies, risk assessment and SoA exist and are coherent. Stage 2 is the implementation audit, where the auditor looks for evidence that the controls are actually operating. A recent penetration test is exactly the kind of evidence Stage 2 relies on to confirm A.8.8 and A.8.29 are working, so we recommend testing before that audit.
After certification, the standard runs on a three-year cycle. Annual surveillance audits in years one and two confirm the ISMS is still operating and improving, and a full recertification audit in year three renews the certificate. A fresh, dated penetration test for each surveillance visit demonstrates continual improvement — that you are still actively finding and fixing technical vulnerabilities rather than resting on the original certification.
Penetration testing therefore supports the test at two recurring moments: Stage 2 at initial certification, and each annual surveillance audit thereafter — with additional targeted testing whenever a significant system changes or goes into production under A.8.29.
What we test
The assets inside an ISMS scope vary, but most ISO 27001 programmes draw on a consistent set of engagements. Each is manual, evidence-driven, and reported against the Annex A controls in your Statement of Applicability.
Web Application Security Testing
Comprehensive web app penetration testing covering OWASP Top 10 and beyond. Find business logic flaws and auth bypasses automated tools miss.
External Penetration Testing
Simulate real-world attacks on internet-facing infrastructure. Manual pentests find vulnerabilities scanners miss before attackers exploit them.
Internal Penetration Testing
Test internal defenses with assumed-breach scenarios. Find lateral movement paths, privilege escalation risks, and Active Directory weaknesses.
API Security Testing
Manual API pen testing by certified testers. We find BOLA, BFLA, and logic flaws automated tools miss — covering OWASP API Top 10 across REST, GraphQL, and gRPC.
Cloud Security Assessment
AWS, Azure, and GCP security assessments covering IAM, network configuration, and data protection. Secure your cloud infrastructure.
Deliverables your certification body & internal auditors expect
An ISO 27001 penetration test is only as useful as the evidence it leaves behind. Every engagement produces a set of artefacts designed to sit directly in your audit file.
Technical report with Annex A mapping
A full findings report where each issue is tagged to the relevant ISO/IEC 27001:2022 Annex A control (principally A.8.8 and A.8.29), so your auditor sees the link between the test and the controls without doing the cross-walk themselves.
Risk-rated findings for the risk assessment
Findings rated by likelihood and impact in a form that drops straight into your information security risk assessment under Clause 6.1.2, feeding the risk treatment plan and Statement of Applicability decisions.
Retest and remediation verification
A documented retest confirming that high and critical findings were remediated — the evidence of action and continual improvement that surveillance auditors look for between certification cycles.
Attestation letter and scope statement
A summary attestation letter and a clear scope statement describing the assets, environments and test windows covered, aligned to your ISMS scope so the certification body can see the test boundary matches the certified boundary.
Get audit-ready ISO 27001 evidence
Tell us where you are in the certification cycle — heading into Stage 2, due for a surveillance audit, or putting a new system into production — and the assets inside your ISMS scope. We will come back with a scoped engagement plan, typically within one business day.
Frequently Asked Questions — ISO 27001
Does ISO 27001 require penetration testing?+
ISO/IEC 27001 does not name a single clause that mandates a penetration test by that word. However, a penetration test is the expected, standard evidence used to satisfy Annex A controls A.8.8 (management of technical vulnerabilities) and A.8.29 (security testing in development and acceptance), and to feed the information security risk assessment under Clause 6.1.2. In practice, certification bodies and internal auditors expect to see independent technical testing, so most certified organizations run penetration tests as part of their ISMS.
Which Annex A controls does a pentest support?+
In the 2022 revision, the most relevant controls are A.8.8 'Management of technical vulnerabilities' and A.8.29 'Security testing in development and acceptance'. In the 2013 version these mapped to A.12.6.1 (technical vulnerability management) and A.14.2.8 (system security testing). A penetration test also supports the broader risk assessment (Clause 6.1.2), the internal audit programme (Clause 9.2) and the continual-improvement cycle (Clause 10).
When in the certification cycle should we test?+
Run a penetration test before your Stage 2 audit, which assesses whether the ISMS is implemented and operating. Stage 1 reviews documentation; Stage 2 reviews implementation and effectiveness, and a recent test gives the auditor concrete evidence that A.8.8 and A.8.29 are operating. Testing before any major system goes into production also satisfies A.8.29's acceptance-testing expectation.
How often should we test for surveillance audits?+
ISO/IEC 27001 certification runs on a three-year cycle with annual surveillance audits and a full recertification in year three. An annual penetration test, plus targeted testing after significant change, aligns naturally with that rhythm and keeps a fresh, dated piece of A.8.8 / A.8.29 evidence available for each surveillance visit. Higher-risk or rapidly changing environments often test more frequently.
How long does ISO 27001 penetration testing take?+
Most ISO 27001-driven engagements run from roughly one to three weeks of active testing, depending on the size and complexity of the assets inside your ISMS scope — a single web application is faster than a full external estate plus internal network and cloud environment. Add a few days for scoping up front and for retesting remediated findings before your audit.