Earthshaker Security Book a scan

← All field notes

Field note 22 September 2026 · 15 min read

Audit Ready ISO 27001 Pentesting: Map Tests to A.8.8 and A.8.29

Make ISO 27001 pentesting audit-ready. Map tests to Annex A controls A.8.8 and A.8.29, align scope and ROE, and keep report, remediation, and retest...

Audit Ready ISO 27001 Pentesting: Map Tests to A.8.8 and A.8.29

ISO 27001 pentesting audit title card

Penetration testing is not named anywhere in ISO/IEC 27001, yet auditors treat a well-scoped pentest as the single most defensible piece of evidence that technical controls actually work. Controls A.8.8 and A.8.29 require you to identify technical vulnerabilities and test security during development and acceptance, and a third-party pentest is the standard way organizations satisfy both. A reasonable default is annual testing plus a retest after any significant infrastructure or application change, backed by a report, remediation log, and retest evidence auditors can trace directly to your risk register.

TL;DR:

  • Auditors expect proof of active vulnerability testing through structured reports, remediation logs, and retest evidence, not just vulnerability scans or code review.
  • The standard recommends testing against a defined scope that matches your ISMS boundary, with scope mismatches being a common nonconformity.
  • Regular testing is typically annual, with additional retests triggered by significant infrastructure or application changes, and continuous testing is encouraged for fast-release environments.
  • A credible pentest report should include an executive summary, scope, methodology, prioritized findings, remediation status, and retest evidence to satisfy audit scrutiny.

Table of Contents

ISO 27001 Pentesting vs. Vulnerability Scanning: What's Actually Different

Penetration testing means a tester actively attempts to exploit weaknesses the way an attacker would, chaining smaller issues into something that compromises data or access. Vulnerability scanning, by contrast, runs automated tools that flag known signatures and misconfigurations without proving whether any of them are exploitable in your specific environment.

Static and dynamic application security testing (SAST and DAST) sit somewhere in between. SAST reviews source code for insecure patterns before deployment; DAST probes a running application from the outside. Both are useful, and Control A.8.29 explicitly expects some combination of these earlier in the development lifecycle. Neither replaces a pentest, because neither demonstrates a real attack chain or tests business logic the way a skilled human tester does.

That distinction is exactly what auditors probe when they ask, "How do you know this vulnerability is actually exploitable?" A scan report answers with a severity score. A pentest report answers with a proof-of-concept.

For ISO 27001 environments, the relevant test types generally include:

Does ISO 27001 Require Penetration Testing?

Not in so many words. ISO/IEC 27001:2022 requires organizations to manage technical vulnerabilities under Control A.8.8 and to build security testing into development and acceptance under Control A.8.29. Neither clause uses the phrase "penetration test." That gap is exactly why so many compliance officers ask the question in the first place, and why the honest answer has two layers: what the text says, and what certification bodies actually expect to see.

In practice, auditors read "identification of technical vulnerabilities" as needing more than a patch management spreadsheet. They want proof someone actively looked for exploitable weaknesses, on a schedule, and did something about what they found. A pentest under Control 8.29 is commonly accepted as that proof because it demonstrates a structured testing strategy across the software development lifecycle, not just a one-time scan before launch.

What this means for certification and surveillance audits:

The standard is deliberately risk-based rather than prescriptive. That flexibility is useful, but it also means the burden of proof sits entirely on your documentation.

Mapping Pentest Results to Annex A Controls and ISMS Records

A pentest only counts as evidence if you can point an auditor to exactly where it lives in your management system. Treat the engagement as producing four linked artifacts, not one report sitting in a folder.

  1. Test report and scope agreement — maps to A.8.8 and A.8.29 as proof that technical vulnerability identification and security testing occurred, with a defined boundary.
  2. Remediation log — shows each finding, its severity, the assigned owner, and the fix date. This is the artifact auditors ask for when a report shows a critical finding with no follow-up.
  3. Retest evidence — a short confirmation report or annotated finding list showing the vulnerability was closed, not just claimed closed.
  4. Security acceptance record — the sign-off, usually from a security lead or CTO, that the system was accepted into production or continued operation despite any residual risk.

Reference all four in your Statement of Applicability under A.8.8 and A.8.29, and link them from your risk treatment plan so the connection between "risk identified" and "risk tested and closed" is visible without explanation.

When an auditor opens a pentest report, they typically look for, in order: the executive summary, the defined scope and dates, the methodology used, a prioritized findings table, and finally the remediation status of each item. A report that buries scope on page 40 or omits dates entirely will slow the audit down even when the testing itself was solid.

Pro Tip: Keep a one-page index in your ISMS evidence folder that lists every pentest, its scope, date, and the ticket number for each remediation item. Auditors reward organizations that can produce this in under a minute.

How to Scope a Pentest So It Matches Your ISMS Boundary

Scope mismatch is one of the most common testing-related nonconformities auditors flag, and it happens for a simple reason: the ISMS scope statement and the pentest scope get written by different people at different times, months apart. Start from the same document every time. Pull your ISMS scope and risk assessment, identify which assets and data flows carry the highest risk, and build the test scope from that list rather than from whatever servers happen to be easiest to test.

Typical in-scope targets for an ISO 27001 environment include:

Your rules of engagement (ROE) document should spell out, in writing, before testing starts:

Pro Tip: If your ISMS scope statement changed in the last 12 months, review your pentest scope before you review anything else. A test that perfectly covered last year's boundary can leave this year's newest system completely untested.

Which Testing Standards Should You Cite: PTES, NIST, OWASP, or OSSTMM?

Naming a methodology in your statement of work does two things: it gives the tester a defensible structure, and it gives your auditor something concrete to check the report against.

Pick the methodology that fits the target, not the one that sounds most impressive, and write it directly into the SOW. A report that states "tested against OWASP ASVS Level 2" is far easier for an auditor to validate than one that just says "comprehensive testing was performed."

How Often Should You Test, and What Triggers a Retest?

There's no fixed interval written into the standard, but a risk-based baseline has become the industry default because it's defensible in front of almost any auditor.

  1. Annual testing covers the baseline expectation for most certified organizations, timed to land before your surveillance audit rather than right after it.
  2. Retesting after significant change covers new production systems, major architecture shifts, cloud migrations, or a merger that brings new infrastructure into scope. "Significant" should be defined in your policy, not decided ad hoc.
  3. Continuous or rolling testing fits fast-release environments better than a single annual snapshot. Pair ongoing automated scanning with quarterly or per-release focused pentests on the highest-risk components instead of trying to pentest everything, every sprint.

Document the trigger list itself inside your security testing policy: what counts as a significant change, who decides, and how quickly a retest must follow. That policy document becomes evidence in its own right, showing the auditor you have a system, not just a habit.

What Auditors Actually Read First in a Pentest Report

Auditors move through a report in a predictable order, and knowing that order helps you commission testing that produces something they can approve quickly rather than something that reads well but stalls the audit.

Present remediation and retest evidence as a direct extension of your risk assessment rather than a separate document. If a finding was accepted as residual risk instead of fixed, that decision needs the same sign-off trail as a remediated one. At minimum, keep the full report, the SOW and ROE, the remediation log, and retest confirmation together in your ISMS evidence repository. Combining automated discovery with manual verification before the report is finalized cuts down on false positives that would otherwise clutter this whole chain with noise.

How to Vet and Commission a Pentest Vendor

Selecting a tester for ISO-aligned work comes down to a short list of checks that separate a credible engagement from a checkbox exercise.

For higher-risk environments, or where regulators or major clients expect it, a red team exercise focused on detection and response earns more credibility than another focused pentest of the same systems tested last year.

Pro Tip: Build a clause into every SOW specifying how discovered sensitive data (customer records, credentials, internal documents) must be handled, redacted in reports, and destroyed after the engagement. This single clause resolves most confidentiality questions auditors raise about third-party testing.

Turning Pentest Findings Into ISMS Evidence

A finding that never makes it into your risk register did not happen, as far as an auditor is concerned. Every finding needs to land somewhere trackable.

  1. Log each finding in the risk register, linked to a remediation ticket with an owner and a time-to-fix target, so severity trends and closure speed are both visible over time.
  2. Route any accepted residual risk through formal sign-off, documented with who approved it, when, and why the risk was accepted rather than remediated.
  3. Require retest evidence for anything rated high or critical before you mark it closed, and store that confirmation alongside the original finding so the full lifecycle is traceable in one place.

This is also where "scope-hopping" tends to bite organizations that test a different slice of infrastructure each year to save budget. It can look efficient, but auditors increasingly challenge the assumption that rotating scopes adds up to full coverage over time, especially if a high-risk system never gets tested twice in a row.

An Auditor-Ready Approach to Blended Testing

Most of the friction in ISO 27001 pentesting comes from reports that read like raw scanner output: long lists of theoretical vulnerabilities with no proof any of them are actually exploitable. One effective approach is to start with automated discovery, then have every finding undergo manual verification before it appears in a report, providing the kind of exploitability evidence auditors prefer over an unfiltered scan dump.

Automated findings checked by manual verification

Reports are often written to address both technical and non-technical audiences, which matters when the same document must satisfy different stakeholders in one pass. Each engagement includes a documented methodology and a re-test once fixes are in place, closing the exact loop auditors check for: report, remediation, retest.

Typical services in this area include:

Readers can request a sample report to see the format before committing to a scope.

What I'd Tell Any Compliance Officer Reading This

Most ISO 27001 testing programs fail quietly, not dramatically. Nobody skips testing outright. They rotate scope every year to save money, treat a vulnerability scan as if it were a pentest, or run the test and never close the loop on remediation. Any one of those looks fine until an auditor asks for the retest evidence that doesn't exist.

Over the next 90 days, do three things: pull your current ISMS scope statement and check it against your last pentest scope for gaps, confirm every open finding from your last test has an owner and a date, and write down your testing frequency policy if it only exists in someone's memory. None of that requires a bigger budget. It requires treating the paperwork with the same seriousness as the testing itself.

— caleb

Get a Sample Report Before Your Next Audit

If you're heading into a certification or surveillance audit and don't yet have testing evidence you'd trust an auditor to read closely, that's the gap to close first, not the last item on the list. Earthshaker Security runs automated discovery through human verification on every engagement, so the report you hand your auditor shows proven exploitability and a documented fix path, not a raw list of theoretical flags.

Earthshaker Security

Start by reviewing the services page to see which engagement fits your scope, whether that's a web application test, API testing, or an external attack surface review. Request a sample report to check the format against what your certification body expects, and check pricing for the Starter engagement at $1,000 one-off or the Retainer option at $795 per month if you need ongoing cadence between surveillance audits. If your next audit is already on the calendar, get a scoping call booked now rather than after the auditor asks for evidence you don't have yet.

Where to Go Deeper on Standards and Methodology

Keep these in your ISMS evidence repository alongside your own testing records. ISO/IEC 27001 is the primary standard text for Annex A controls. NIST SP 800-115 gives the technical detail behind testing methodology and reporting. PTES defines the testing lifecycle referenced in most professional SOWs. The PCI Penetration Testing Guidance covers tester qualifications and rules of engagement in more operational detail than ISO documentation typically provides.

Sources

FAQ

Does ISO 27001 Require Penetration Testing?

Not by name. Controls A.8.8 and A.8.29 require identifying technical vulnerabilities and testing security in development and acceptance, and a pentest is the most common way organizations satisfy both in front of an auditor.

What Is ISO 27001 in Cybersecurity Terms?

ISO 27001 is the international standard for building and running an information security management system (ISMS), covering policies, risk assessment, and technical controls like vulnerability management and security testing. It's the framework organizations get certified against to prove their security practices meet a recognized baseline.

Is Pentesting Being Replaced by AI?

No. Automated and AI-assisted tools speed up discovery and scanning, but auditors still expect human verification of exploitability, business logic testing, and judgment calls that automated tools can't replicate on their own. Earthshaker Security's model of pairing automated discovery with manual verification reflects exactly why that combination, not automation alone, remains the standard auditors trust.

How Hard Is the ISO 27001 Exam?

This depends on which credential you mean. Lead Auditor and Lead Implementer exams require solid familiarity with the full clause structure and Annex A controls, and most candidates study through an accredited training course rather than attempting it from the standard text alone.

How Often Should a Business Run an ISO 27001 Pentest?

A widely accepted defensible baseline is annual testing plus a retest after any significant change to infrastructure or applications. Fast-release environments often pair continuous automated scanning with quarterly or per-release focused pentests on the highest-risk components.

Recommended

Next
Want this run against your app?
Book a scan