Penetration testing for ISO 27001 certification: what auditors expect

Do you need a penetration test to pass ISO 27001? The standard never uses the words, but in practice the answer is often yes. Auditors want credible technical assurance on the systems that matter, and that takes more than a policy statement or a scanner export.

The real question is not "does ISO/IEC 27001:2022 say penetration test?" It is "can the organisation show that its controls are tested, that findings are acted on, and that residual risk is understood?" Certification is about evidence and consistency, not about repeating the vocabulary of Annex A.

Key takeaways

• ISO/IEC 27001:2022 does not require a penetration test by name, but auditors usually expect credible technical testing on in-scope systems.
• Annex A controls on vulnerability management, security testing and compliance create an indirect expectation of proof, not just policy.
• A certification-ready program combines scoped testing, vulnerability handling, remediation tracking, retesting and residual risk acceptance.
• The strongest audit file is one you can trace end to end: scope, result, fix, retest, and the documented decision if something stays open.

ISO 27001 never says "pentest", auditors still expect proof

What the standard says

Several Annex A controls point toward technical testing without naming it. Annex A 8.8 covers technical vulnerability management, Annex A 8.29 covers security testing in development and acceptance, and Annex A 5.36 covers compliance with policies, rules and standards. In plain terms: you need to know where your weaknesses are, test systems before you rely on them, and keep evidence that your security rules are actually followed. A control does not have to say "pentest" for a certifier to expect technical verification.

If the ISMS cannot show what was tested, when, and what changed afterward, the control is still mostly paper.

What certifiers usually ask for

Certifiers rarely care which vendor ran the test. They care whether the method fits the risk, whether the test covered the right assets, and whether the results fed into remediation and risk treatment. For an internet-facing application, that often means an independent technical test. For a smaller internal system, a lighter but documented approach can be enough. The practical check: can someone else read the file and understand why this evidence supports the scope you declared?

The size of the certified population explains why the question keeps coming up. According to the ISO Survey 2024 figures compiled by Gcerti, there were 96,709 accredited ISO/IEC 27001 certificates worldwide, covering 179,877 sites. That is a lot of audits, and a lot of evidence packs built for systems that change faster than the certification cycle.

Map testing to your Statement of Applicability first

Start from risk and scope

The Statement of Applicability (SoA) is where Annex A becomes operational, so start there before choosing tools or cadence. For every in-scope control, ask what proof shows it works on the assets you run today. For a customer-facing API, that can mean vulnerability scans, code review, runtime testing and a focused penetration test on the riskiest paths. For a less exposed internal system the evidence can be lighter, but it still has to be explicit and current.

Take a SaaS company with a public API, an admin portal and cloud infrastructure. Those are not three separate stories. They belong in one evidence plan, because the API, the admin flow and the cloud permissions usually sit on the same attack path, even when three different teams own them.

Then choose the right test mix

Let the asset type set the depth. Internet-facing apps need direct attack simulation. Internal tools can lean more on scans and code review. Fast-changing systems need retesting after releases. A payment flow that changes every week deserves a different approach from an HR portal touched once a quarter.

The attack surface moves faster than most audit files. Across 250 organisations, Palo Alto Networks Unit 42 found that 20% of cloud services change every month. That is enough to break any audit file built on a single annual snapshot.

Option	Best fit	What it proves	Limit
Scanning only	Low-risk or internal systems	You look for known weaknesses on a schedule	Does not validate exploitability on its own
Targeted penetration test	Public apps, APIs, admin paths	The system resists realistic attack paths	Ages quickly after releases
Change-driven program	Fast-moving product teams	Testing follows material change, not the calendar	Needs clear triggers and ownership

For most teams the change-driven model is the strongest. It matches how modern systems behave, and it gives the auditor a cleaner story than "we tested once because the calendar said so." For where scanning ends and pentesting begins, see our comparison of bug bounty, pentest and DAST.

What testing cadence is usually enough

Annual vs change-driven testing

A common pattern is one penetration test a year plus a retest after major changes, with vulnerability scans running monthly or quarterly depending on exposure. The annual test sets a baseline. The change-driven retest proves the baseline still holds after a new release, a cloud migration, a new authentication layer or a major integration. In practice, that second part is where many teams become audit-ready, because it follows how risk actually moves.

Where frequent checks help

Frequent checks pay off where change is frequent and exposure is public. A payroll backend that changes every quarter does not need the rhythm of a customer portal deployed twice a week. The point is not to test everything all the time. It is to retest the assets that move the most and carry the most risk, so your evidence follows the system instead of the other way round.

What your pentest report must show an auditor

Minimum contents

A usable report needs more than exploit screenshots. It should show scope, methodology, severity, proof of concept, recommendations and a residual risk assessment. No specific framework name is required, but a third party has to be able to follow the logic. The report should answer three questions clearly: what was in scope, what was found, and what did the organisation do next?

ISO 27001 is a management system, not a control list, so the report has to connect to the SoA, the risk treatment plan and any acceptance of residual risk. If a reviewer has to dig through email to understand why an issue stayed open, the evidence is weaker than it should be.

The stakes are not only the certificate. IBM's Cost of a Data Breach Report 2025 puts the global average cost of a breach at USD 4.44 million. Technical assurance is not paperwork theatre.

How to make results usable in the ISMS

Write the summary for someone who was not in the room. A good line reads: critical authentication bypass on the admin portal, owner assigned, fix due in 14 days, compensating control approved, retest pending. Auditors need decisions, dates and accountability, not a wall of raw output. The ticket, the fix, the retest and the residual risk decision should sit in the same file or in directly linked records. That is what turns a test into evidence.

Audit failures are process failures, not tool failures

Weak scoping

The most common failure is not testing too little, it is testing the wrong thing. If the report covers staging while production carries the real risk, the evidence will not hold. The same happens when teams test one application and ignore the identity, cloud or API dependencies that make it exploitable. The auditor follows the attack path, not the org chart.

Unclosed remediation

The classic report ends with advice and never closes the loop: no owner, no due date, no retest, no documented acceptance when the issue stays open. A modest program of scans, targeted tests and revalidation beats one polished PDF that nobody touches after delivery. For the result to count in the ISMS, it has to move through the risk process.

Disconnected evidence

Evidence breaks when findings, fixes and approvals live in different places with no shared reference. That is how teams end up with a good pentest report and a weak audit file. Before the audit, check that:

• The scope matches the SoA and current production assets.
• The report shows methodology, severity, proof of concept and recommendations.
• Every finding has a remediation owner and a due date.
• The retest result is attached or scheduled.
• Residual risk decisions are signed off where needed.
• The evidence sits in one place, not scattered across email and spreadsheets.

Our piece on pentest workflow and audit trails goes deeper on keeping findings, tickets and proof in one chain.

Where Fleuret fits

Fleuret runs agentic pentests on web apps, REST and GraphQL APIs and external infrastructure, with results in hours rather than weeks. Every finding ships with a replayable proof of concept, findings are pushed to Jira, Linear or Slack so they land in the remediation process directly, and a retest after the fix closes the loop. A signed report is available on demand for the audit pack.

That covers the technical-testing part of the ISO 27001 file. The ISMS itself, the SoA and the risk treatment decisions stay with your team and your auditor.

A 90-day plan before your certification audit

Days 1 to 30

Freeze the in-scope systems, update the SoA and map each relevant control to the evidence you will need. Decide which systems get scanning, which get targeted testing, and which justify an independent penetration test. Keep the scope tight and the rationale explicit. Budget should follow risk and change frequency, not vanity coverage of low-value assets. Anything that touches customers, availability or privileged access goes to the front of the queue.

Days 31 to 60

Run the scans and the deeper tests, then log findings into the risk treatment process with owners, deadlines and a retest plan. With several product lines, start with internet-facing assets and the systems holding the most sensitive data. Internal tools come later unless they control production, administration or identity. This is often when teams discover that "we tested everything" really meant "we tested what we already knew about."

Days 61 to 90

Retest the fixed items, capture management acceptance where needed, and assemble the audit pack: report, scope, remediation log, retest proof and residual risk decisions. Keep the format repeatable so the next cycle costs less. Preserve the history, not just the latest status: the auditor cares about the path, not only the final label.

What I recommend

If certification is one or two quarters away, start this week: freeze the scope, update the SoA, and schedule testing on the assets that carry real risk. Do not wait for the perfect toolchain. Build the evidence flow first, then make it repeatable. That is the difference between a report that exists and an ISMS that stands up in front of an auditor.

Fleuret runs agentic pentests that give an ISO 27001 file its technical proof: replayable PoCs, tickets, retest and a signed report. See Fleuret in action.

Sources

• ISO Survey 2024: ISO/IEC 27001 certificates and sites, Gcerti, 2025
• 2023 Attack Surface Threat Report, Palo Alto Networks Unit 42, 2023
• Cost of a Data Breach Report 2025, IBM, 2025