Earthshaker Security Book a scan

← All field notes

Compliance 22 September 2026 · 15 min read · Caleb

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...

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:

  • External network testing — probing internet-facing infrastructure and perimeter defenses
  • Internal network testing — simulating an attacker who already has a foothold inside the network
  • Web application testing — covering authentication, session handling, and business logic flaws
  • API and endpoint testing — checking authorization boundaries between services
  • Cloud configuration testing — reviewing IAM policies, storage permissions, and control-plane exposure
  • Red team or social engineering exercises — testing detection and response, not just technical gaps

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:

  • An initial certification audit will usually ask for at least one recent pentest report tied to in-scope systems.
  • Surveillance audits (typically annual, for the life of the certificate) expect to see continuity: another test, or a documented rationale for why nothing changed enough to warrant one.
  • An organization with only vulnerability scans and no pentest history can still pass, but the auditor will likely raise it as an opportunity for improvement or, in stricter cases, a minor nonconformity.
  • Skipping testing after a major architecture change (a new cloud migration, a new customer-facing API) is one of the fastest ways to draw a finding, even with a recent annual test on file.

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:

  • Internet-facing web applications and customer portals
  • APIs that handle authentication tokens or personal data
  • Cloud control planes (AWS IAM, Azure AD, GCP organization policies)
  • Internal Active Directory or network segments, when internal threat scenarios are part of the risk assessment

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

  • In-scope and explicitly out-of-scope systems, with IP ranges or URLs
  • Test windows and any blackout periods (payroll runs, seasonal traffic spikes)
  • How discovered sensitive data will be handled, stored, and eventually deleted
  • A safety stop procedure and emergency contact if a test risks disrupting production

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.

  • PTES (Penetration Testing Execution Standard) lays out a full lifecycle, from pre-engagement and intelligence gathering through exploitation and reporting, and works well as the backbone for most general engagements.
  • NIST SP 800-115 offers detailed technical guidance on testing methods and is a widely recognized reference for how a test report should be structured, which makes it useful when an auditor asks "against what standard was this conducted?"
  • OWASP's ASVS and testing guides are the right fit specifically for web and API application testing, since they break down authentication, session management, and input validation into checkable requirements.
  • OSSTMM leans more operational, covering physical and process-level security testing alongside technical checks, useful when a scope extends beyond pure application or network testing.

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.

  • Executive summary — sets risk context in plain language before any technical detail
  • Scope and dates — confirms the test actually covered in-scope ISMS assets, at a defined time
  • Methodology — ties the engagement to a named standard like PTES or NIST SP 800-115
  • Prioritized findings — severity-ranked, not just a raw list, so the auditor can see triage happened
  • Remediation status — each finding linked to an owner, a fix date, and current status
  • Retest evidence — confirmation, ideally with screenshots or logs, that closed findings stayed closed

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.

  • Ask for a sample report before signing anything. If it's vague on methodology or findings, the final deliverable will be too.
  • Confirm the vendor references a named methodology (PTES, NIST SP 800-115, OWASP ASVS) in their SOW, not just "industry best practice."
  • Check tester certifications and references, and ask directly how they've supported other clients through ISO 27001 audits.
  • Confirm NDAs and insurance are in place before any testing touches production systems or real customer data.
  • Decide internal vs. external testing based on independence requirements. Auditors generally give more weight to external testers precisely because they have no incentive to soften findings.

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:

  • Web application penetration testing
  • API and endpoint testing
  • External attack surface reviews
  • Configuration and hardening audits

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.

Want this run against your app?
Book a scan

Rather have it in your inbox?

We send a note when there is something worth sending. That is a handful of times a year, not a Tuesday newsletter.