ISO 27001 Audit: What the Auditor Actually Wants From the Pentest

Search ISO 27001 audit guidance and half of what comes back will tell you the standard requires an annual penetration test. It doesn't. Not in those words, not anywhere in ISO/IEC 27001:2022. What the auditor really does is open your Statement of Applicability, find the controls you declared in scope, and ask you to prove you did what you said you'd do. MSP Pentesting writes that proof under your logo, channel-only, so the firm that built and patches the environment isn't also the firm grading it.

The gap between what vendors claim and what an auditor asks for is worth real money to you.

It turns "you have to buy a pentest" into "here's the evidence hole, and here's what fills it."

What ISO 27001 actually says about testing

ISO/IEC 27001:2022 is the requirements standard. Clauses 4 through 10 are the management system. Annex A is a reference set of 93 controls in four themes: organizational, people, physical and technological. It's normative, but it's a list of controls, not an implementation manual. The 2013 edition's control objectives are gone.

Two Annex A controls carry the entire testing conversation.

A.8.8, Management of technical vulnerabilities. You obtain information about technical vulnerabilities in the systems you're using, evaluate your exposure, and take appropriate measures. That's the control. No tool named. No frequency named.

A.8.29, Security testing in development and acceptance. Security testing processes get defined and implemented across the development lifecycle. This is the one that catches clients who ship software, and it's why "we have a customer portal" should change your scoping conversation immediately.

Neither control contains the words "penetration test."

That phrase lives in ISO/IEC 27002:2022, the guidance companion to the standard, which isn't itself certifiable. The 27002 implementation guidance for 8.8 lists penetration testing as one technique among several. Guidance. Not a requirement.

So why does nearly every certified organization end up buying one anyway?

Because the alternative is telling an auditor that a control nobody ever tested is definitely working. That doesn't end well. A scan proves you looked. A test proves somebody tried. Auditors can tell the difference and they've gotten better at asking.

What the auditor is actually auditing

Conformity. Not security.

An ISO 27001 audit checks whether your information security management system does what your own documentation claims it does. Technical people trip on this constantly, because it means a modest, well-run ISMS passes while an expensive, undocumented one fails.

Four things drive the whole event.

• Clause 6.1.3(d), the Statement of Applicability. Every Annex A control, applicable or not, with justification either way and current implementation status. This is the auditor's map. If your SoA marks A.8.8 applicable, you've committed to producing evidence for it.
• Clause 9.2, internal audit. You audit yourself against a program, and across a certification cycle you're expected to cover clauses 4 to 10 plus every applicable control.
• Clause 9.3, management review. The 2022 edition splits this into 9.3.1 general, 9.3.2 inputs and 9.3.3 results. Risk assessment results and risk treatment status are named inputs, which is precisely where your test findings belong.
• Clause 10. Continual improvement, plus nonconformity and corrective action. Findings you ignored show up here as a problem.

The audit runs in stages. Stage 1 is a documentation review to see whether you're ready at all. Stage 2 is the deep one, where the auditor samples evidence against what you claimed. Certificates then run a three year cycle, with surveillance audits at the end of years one and two and a recertification audit in year three. Surveillance audits sample. They don't re-cover everything.

One date worth carrying: the transition window for the 2013 edition closed at the end of October 2025. Everything you support now sits on the 2022 control set. If a client hands you a gap analysis written against the old 114 controls, it's stale.

Five questions that decide whether your pentest counts

Plenty of perfectly good reports don't survive contact with an auditor. Here's where they die.

Does the scope match the Statement of Applicability?

The most common problem isn't a bad test. It's a test of the wrong thing. The SoA covers a customer portal and a payment integration. The report covers an external network range. Those don't line up, and the auditor says so out loud.

Is the tester independent of the builder?

ISO doesn't force anyone to hire outside. It does expect competence and objectivity. If your engineer wrote the firewall rule base and then tested the firewall, you're asking an auditor to accept self-assessment on a technical control. Some will. Most raise an observation, and observations become findings at the next surveillance visit.

How old is the report?

There's no stated shelf life anywhere in the standard, which surprises people. In practice auditors want a report on the current state of the current scope. That usually means inside twelve months and after your last significant change. A report from before a cloud migration says nothing about the environment that exists today.

What happened to the findings?

This is where most evidence packs come apart. A report with eight highs and no treatment record is worse than no report at all, because you've now documented a known exposure you demonstrably didn't act on. Every finding needs a decision. Fix, mitigate, or accept, with a named owner and a date.

Did anyone retest?

"We patched it" isn't evidence. A retest note, a rescan showing closure, or a signed change record is. Build the retest into the engagement instead of trying to sell it as a follow-on six months later.

What vendors claim versus what the standard says

Where MSPs get caught

You're not a neutral party, and the standard has a whole section about you.

A.5.19 through A.5.22 cover supplier relationships, security requirements in supplier agreements, ICT supply chain management, and monitoring of supplier service delivery. If you manage the client's infrastructure, you're a supplier inside their ISMS scope. The auditor will ask how the client oversees you. Some of them ask to see your own security posture.

That cuts two ways, and the second way is good news.

Since you can't be the independent test of your own build, a white-labeled penetration test under your brand kills an objection you'd otherwise argue around. Your engineers stay in the remediation seat, where the margin is, and the report carries a tester who never touched the config.

Second trap: your client's SoA marks A.8.29 applicable because they build a portal, and the pentest you sold them was an external network assessment. That's not a scoping detail. That's a nonconformity waiting for Stage 2.

Third trap: nobody fed the findings into the 9.3 management review. The test happened, the report exists, and the ISMS never noticed. Auditors read the minutes.

What drives ISO 27001 certification cost

Clients ask about ISO 27001 certification cost before they ask about anything else, and most of the answers online are useless because they quote a number without naming the variables.

Three separate buckets, and only one of them is the certificate.

The certification body. Accredited bodies don't price audit days at random. They work from a sizing model keyed to the effective number of people inside the scope, adjusted for complexity, sites and how much of the work is remote. Headcount in scope moves the quote more than the tech stack does. Narrow the scope statement and the day count drops.

Readiness work. Risk assessment, SoA, policy set, internal audit, management review. This is either internal time or a consultant, and it's usually the biggest line in year one.

Evidence generation. Testing, remediation, retest, tooling. Your pentest sits here, and it's a separate line from the audit fee. Nobody's certification body includes it.

Price readiness and evidence as your scope. Leave the certificate to the accredited body. You don't want to compete with them, you want to be the reason the client passes.

The evidence pack, assembled

No auditor reads a 60 page report cover to cover. They open it, look for five things, then look for what you did about them. Build the pack that way and keep it where the client can hand it over on the day.

If you want a structure that already separates scope, method, findings and closure the way an auditor reads them, our penetration test report template is laid out for exactly this.

Where the test lands in the audit calendar

Timing is a lever most MSPs waste. Test too late and you're presenting open highs at Stage 2. Test too early and the environment has drifted by the time the auditor arrives.

Rough rule: test far enough ahead of Stage 2 that you can remediate and retest, then let the surveillance audits set your annual cadence. That's a defensible frequency you never had to invent.

Questions MSPs ask about the ISO 27001 audit

Does ISO 27001 require penetration testing?

No, not by name. The question does ISO 27001 require penetration testing gets a yes from vendors and a no from anyone who's read the text. A.8.8 requires you to manage technical vulnerabilities and A.8.29 requires security testing in development and acceptance. Penetration testing is the method most organizations pick to satisfy both, because it's the easiest evidence to defend. It isn't the only one.

Can we run the test ourselves as the client's MSP?

You can, and the standard won't stop you. Whether it holds depends on the auditor and how close your team sits to the systems under test. If you built it, expect pushback. Splitting the roles is cheaper than arguing.

Does a bad pentest result fail the audit?

Findings don't fail you. Ignored findings do. An auditor who sees five criticals with owners, dates and a partial closure record sees a working ISMS. One who sees five criticals and silence sees a nonconformity under clause 10.

How does this interact with the client's other frameworks?

Most mid-market clients aren't doing ISO alone. Map the test against SOC 2 and PCI DSS obligations first, so one engagement feeds three programs. Start from the client's documented risk assessment and the overlaps show up on their own.

Do surveillance audits need a fresh test every year?

The standard doesn't say so. Your own SoA and vulnerability management procedure might, because you wrote a frequency into them. Read what your client committed to before you promise anything. If the procedure says quarterly and you test annually, that's a nonconformity you created yourself.

Take the SoA into the room

Pull your ISO clients' Statements of Applicability. Find A.8.8 and A.8.29. Check whether the test you last sold them actually covers what they declared, and whether anyone recorded what happened to the findings afterward.

Most of the time, one of those two things is missing.

That's a scope conversation, not a cold pitch. Get a pentest quote that names A.8.8 and A.8.29 on page one, and Stage 2 stops being the first time anyone checks whether the test matches the SoA.