Start here
COMPLIANCE // ISO_27001
ISO 27001 Penetration Testing
The honest answer first: ISO 27001:2022 does not mandate a penetration test. Control A.8.8, management of technical vulnerabilities, lists periodic documented penetration testing among the accepted ways to identify vulnerabilities, and certification auditors treat a recent test as the cleanest evidence that the control is actually operating.
This page covers what A.8.8 actually demands, the testing cadence auditors accept, what they sample at Stage 2, and how one fixed-price test maps onto your ISMS evidence trail.
Control A.8.8Annual baselineRetest evidence
THE HONEST ANSWER
Does ISO 27001 require a penetration test?
No clause in ISO 27001:2022 says the words "you must run a penetration test." Any vendor telling you the standard legally forces you to buy one is overselling.
What the standard does require is a working ISMS, and inside Annex A sits control A.8.8, management of technical vulnerabilities. The implementation guidance behind it explicitly lists periodic, documented penetration testing among the methods for identifying technical vulnerabilities, alongside scanning and vendor advisories.
That distinction matters less than it sounds. A certification auditor has to verify that A.8.8 is operating, and a recent, documented, independent test is the single strongest artifact you can put in front of them. The practical result: the standard does not mandate a pentest, and nearly every certified organization runs one anyway.
CONTROL A.8.8
What A.8.8 actually demands
A.8.8 reduces to three obligations: learn about vulnerabilities in time, evaluate your exposure to them, and act. A penetration test produces evidence for all three in one document.
Timely identification
Information about technical vulnerabilities in the systems you use is obtained promptly. Scanning, vendor advisories, and periodic documented penetration testing are the identification methods the guidance names.
Evaluated exposure
Each vulnerability is assessed against your actual assets and risk criteria, not just its generic CVSS score. A severity-ranked findings list is exactly this evaluation, written down.
Action taken
Appropriate measures follow: patch, mitigate, or formally accept the risk with a reason. The auditor reads the trail from each finding to its closure, not the report cover.
One honesty note: A.8.8 spans more than the web layer. Patch management for servers and endpoints sits inside the same control. A web and API pentest evidences the identification method; it does not replace your patching records.
CADENCE
The annual baseline, plus change-triggered tests
The de facto norm certification auditors accept is one documented penetration test every 12 months, plus a test when something significant changes.
The annual rhythm follows the certification cycle itself: a Stage 1 and Stage 2 audit up front, then a surveillance audit every year. A report older than 12 months goes stale at exactly the moment an auditor opens your evidence folder.
Change-triggered testing comes from A.8.29, security testing in development and acceptance. A new customer-facing application, a new API surface, an authentication rework, or a major migration should be tested before it carries in-scope data, not at the next anniversary.
Between formal tests, cheap continuous signals keep the control visibly alive. Our free Ghost Scan checks your public surface across 9 categories, no card and no signup, which is a reasonable way to watch for drift between annual engagements.
AUDIT DAY
What the certification auditor samples
Auditors sample the trail; they do not re-run your test or read every page of the report. At Stage 2 and at surveillance, the usual move is to pick a handful of findings and trace each one: what did you decide, what did you do, and how do you know the fix worked.
Two artifacts decide the outcome. First, remediation status: a record showing each finding was patched, mitigated, or formally risk-accepted with a reason. Second, retest evidence: proof that the fixes were verified, not just claimed. Missing retest evidence is the most common gap we see.
This is why a report full of open criticals from 14 months ago reads worse than no report at all. A documented finding you ignored is a nonconformity waiting to be written up. Our engagement includes a free re-test after you patch, which produces the closure artifact the auditor is actually looking for.
SCOPE
Scoping the test for an ISMS
Test what your ISMS scope statement says you protect, prioritized by risk. For most certified software companies that means the internet-facing applications and the APIs behind them, because that is where scoped data is exposed to strangers.
Internet-facing web applications named in your ISMS scope statement
REST and GraphQL APIs that move in-scope data
Authentication and session management for scoped systems
Business-logic paths that touch assets on your risk register
Up to 3 subdomains per engagement
TLS, DNS, and certificate configuration for scoped domains
Scope honesty: our engagement covers web applications and APIs only. Mobile apps, internal networks, physical security, and red-team exercises are not included. If your ISMS scope includes an internal network, evidence that layer separately through your patching and scanning records.
EVIDENCE MAP
Deliverables mapped to the ISMS evidence trail
Every artifact in the fixed-price engagement lands somewhere specific in your audit folder. An anonymized sample report shows the exact format; the cost guide covers how this price compares to the market.
| Deliverable | Where it lands in your ISMS |
|---|---|
| Executive PDF report (OWASP + NIST 800-115 methodology) | A.8.8 identification and exposure-evaluation evidence |
| Severity-ranked findings with remediation guidance | Feeds your risk treatment plan and corrective-action records |
| Developer JSON + SARIF export | Ties findings into change records and CI history (A.8.29 side) |
| Free re-test and updated clean report | The remediation and retest evidence auditors sample first |
| Signed, dated attestation letter | Independent-testing proof for Stage 2 and surveillance audits |
| Fixed price, whole engagement | $2,499, no hourly billing, no scope creep |
WHO TESTS
Internal vs external testers under A.8.8
A.8.8 does not force you to hire an external firm. It requires competent, authorized, documented testing, and an internal security team that meets that bar can satisfy the control.
Three practical reasons most certified companies buy external anyway. Independence reads better in an audit: developers grading their own code is a fair objection for an auditor to raise. Tooling and time: a real test takes senior attention and a scanner stack most internal teams do not maintain. And the attestation: an external engagement ends with a signed, dated letter that doubles as evidence for enterprise customers and due diligence, which an internal memo cannot.
If you do have a capable internal function, the honest advice is to document its testing properly and use external engagements for the systems where independence matters most.
OTHER FRAMEWORKS
How this differs from SOC 2 and PCI DSS
The technical test is the same; the paperwork around it is not. ISO 27001 certifies your management system against a standard, and the pentest is evidence that one Annex A control operates. SOC 2 is an attestation report on your controls over a period: a pentest is not explicitly required there either, but auditors expect one as monitoring evidence, commonly mapped to CC4.1, and Type I versus Type II timing changes when you should run it. The full breakdown is on our SOC 2 penetration testing page.
PCI DSS is the exception: requirement 11.4 does explicitly mandate penetration testing. Plain statement of our coverage: we handle only the external application-layer slice of 11.4, meaning 11.4.3 and the 11.4.4 retest loop. We do not perform internal penetration testing or segmentation testing. If you need full PCI 11.4 coverage, our test is one piece, not the whole; the complete scope statement is on the pentest page.
REGION
ISO 27001 in South Asia
Across South Asia, ISO 27001 is the certification that actually drives VAPT purchases. Export-facing software companies certify because enterprise buyers in the US, EU, and Australia recognize the badge, and the certification audit is the event that forces the penetration test onto the calendar.
Sri Lanka illustrates the pattern. The Personal Data Protection Act No. 9 of 2022 requires security safeguards and a Data Protection Management Programme but does not explicitly mandate penetration tests. Sri Lanka CERT|CC recommends periodic, at least annual, security assessments and published Web Application Security Guidelines for government organizations in 2022. Neither creates a hard legal pentest mandate, so in practice the ISO 27001 audit is the strongest forcing function local companies face.
We are based in Colombo and deliver worldwide in English. If you are buying locally, start with our penetration testing in Sri Lanka page, or read the full VAPT Sri Lanka guide.
QUESTIONS
ISO 27001 pentest FAQ
Does ISO 27001 require a penetration test?
Not in so many words. No clause in ISO 27001:2022 mandates one. Control A.8.8 (management of technical vulnerabilities) requires timely identification of vulnerabilities, evaluated exposure, and action taken, and its guidance lists periodic documented penetration testing among the accepted identification methods. In practice, most certification auditors expect a recent test because it is the strongest evidence the control is operating.
How often should we run a penetration test for ISO 27001?
Annually as a baseline, plus after significant change. Certification runs on a three-year cycle with surveillance audits every year, so a test older than 12 months goes stale at exactly the moment an auditor looks. A.8.29 (security testing in development and acceptance) covers the change side: new applications, new APIs, and major releases should be tested before they carry scoped data.
Can our internal team run the test under A.8.8?
Yes. A.8.8 requires competent, authorized, documented testing, not an external firm. Auditors do read independent testing as stronger evidence, and an external report comes with a signed attestation you can also hand to customers. If you have a capable internal security function, a properly documented internal test can pass; most small and mid-size teams do not have one.
What pentest evidence does the certification auditor ask for?
Four things, usually sampled rather than read in full: the report with scope and methodology, the severity-ranked findings, records of what you decided and did about each finding, and retest evidence proving the fixes worked. Missing retest evidence is the most common gap.
How much does an ISO 27001 penetration test cost?
Published 2026 cost guides from DeepStrike, Blaze Infosec, Intruder, and Astra put typical web application pentests at roughly $5,000 to $35,000 or more, and Fractional CISO's ranking prices compliance-grade tests around $5,000. Ghost Protocol's fixed price is $2,499 for a web app plus API engagement, including a free re-test after fixes and a signed attestation letter.
Will the same test cover SOC 2?
The technical work is identical; the paperwork differs. SOC 2 does not explicitly require a pentest either, but auditors expect one as monitoring evidence, commonly mapped to CC4.1, and Type I versus Type II timing matters. One report can serve both audits if the scope and dates line up.
Walk into Stage 2 with the evidence trail complete.
Start with the free scan to see your surface the way a tester will. When you need the documented test, the engagement is fixed price, delivers in 5 to 7 days, and ends with a signed attestation and a free re-test.
A.8.8_EVIDENCE // ANNUAL_BASELINE // GLOBAL_DELIVERY