Penetration testing for ISO 27001: what the auditor actually expects

The most useful thing to know about penetration testing for ISO 27001 is that ISO 27001 does not require a penetration test. It is not named anywhere in the standard. Nearly everyone who asks us about this believes otherwise, usually because someone told them the auditor would want one. The belief is close enough to true to be useful, and wrong in a way that costs money.

The standard does not name penetration testing

ISO/IEC 27001:2022 is the current version. Read the requirements clauses and the Annex A controls and you will not find a penetration test set out as a mandatory activity. There is no clause telling you to commission one, no stated frequency, no stated methodology, and no stated qualification for whoever carries it out.

If someone tells you the standard requires an annual penetration test, they are adding something it does not say, and it is fair to ask where they are reading it. Once you stop treating a test as a tick against a clause, you can ask the better question: what is the auditor going to look for, and is a test the best way to show it?

What it does ask for, in plain words

Two Annex A controls sit closest to this. A.8.8 covers the management of technical vulnerabilities. A.8.29 covers security testing in development and acceptance. Those are their subjects rather than their wording, because the text is worth reading in the standard itself, and because neither control uses the phrase “penetration test”.

Put plainly, an auditor wants three things. That you find out what technical vulnerabilities exist in the systems inside your scope. That you then do something about them and can show what you did and when. And that things get tested before they go live, rather than after someone notices a problem in production.

A penetration test is the most common way organisations evidence that, because one engagement produces a dated, independent report with findings, severities and a named tester attached. That is convenient, which is why the two have become linked in people's minds. It is not the only evidence, and an auditor whose only question is “where is your pen test report” is taking a shortcut too.

Other things that commonly form part of the same picture:

• Authenticated vulnerability scanning on a defined schedule, run with credentials rather than from the outside only, with the output retained and the patching records lining up with it.
• A record of findings triaged, assigned, fixed and verified as fixed, with dates against each step. Remediation evidence is almost always thinner than discovery evidence, and it is usually what gets probed.
• Security testing inside the release process: a pre-go-live check, code review, dependency scanning, whatever fits how you build and deploy.
• A written decision where something is not being fixed, naming whoever accepted the risk.

None of those is a document you can buy the week before an audit. What is being assessed is whether a process exists and runs. A report with twelve open high findings and no record of what happened next is weaker evidence than a modest scanning programme with everything closed out and dated.

Why this request usually arrives in a hurry

In our experience there are four realistic triggers. A Stage 2 certification audit with a date in the diary. A surveillance audit coming round. A nonconformity raised at the last one, often about vulnerability management or about testing before release. Or a customer asking to see your most recent report as part of their supplier assurance.

In all four cases, establish the date the evidence is actually needed, because it is commonly later than people assume. The Stage 2 audit date is not automatically the deadline. If a nonconformity was raised, the corrective action plan has its own agreed timescale, and that is the date that binds you.

One further point. Where a completed report is not yet available, a test that is scheduled and contracted, with a written remediation plan alongside it, is often accepted as evidence that the process is managed rather than absent. Often, not always: it depends on the auditor, the certification body, and what the finding said. Ask them early rather than assuming. If the report itself is needed by a fixed date, what a genuinely fast test involves is the next thing to read.

Scope is where the money gets wasted

The single most expensive mistake here is testing the whole estate when the ISMS covers part of it. Your scope statement sets out which parts of the organisation, which locations, which services and which systems sit inside the management system. That statement, not the shape of your IT estate, should drive the test scope.

A worked example. A company certifies its SaaS platform and the team that builds and runs it. Inside scope: the production application, its APIs, the cloud environment hosting it, the administrative tooling that team uses. Outside: the office network at a second site, the marketing site on separate hosting, a legacy on-premise system for a different product line. Testing all of it may be sensible for other reasons, but it is not required by the certification, and it can double the cost and the elapsed time at the moment you have neither.

Two caveats. Something outside the scope that can reach something inside it belongs in the conversation, and a good tester will raise it rather than ignore it. And scope is yours to set, so a narrow scope that excludes everything interesting is certifiable and also unpersuasive to anyone reading the certificate. Auditors do look at whether a scope is credible.

Does it have to be CREST?

Not according to the standard, which says nothing about CREST at all. ISO 27001 names no accreditation scheme, no register and no tester qualification. What it cares about is competence, and, where independence is relevant, independence.

A CREST-accredited test is one clean way to demonstrate both. Accreditation is assessed at company level, methodology and reporting are reviewed, and individual testers sit on a register you can check. It shortens an awkward conversation about whether the person testing your systems knew what they were doing. That is a real benefit, and a different claim from saying the standard demands it.

Where a CREST requirement does come from, in practice:

1. Your own policy. If your documented ISMS policy says testing will be carried out by a CREST-accredited provider, the auditor will hold you to what you wrote. That is one of the commoner ways it becomes a real requirement, and it is self-inflicted.
2. A customer contract. Regulated sectors and larger buyers often specify it in supplier terms.
3. A tender clause. Frequently copied from a previous tender by someone who did not write the original requirement.

All three are real obligations. None of them is the standard. It is worth finding out which one applies to you before paying for accreditation nobody asked for, and if you are weighing the two UK schemes against each other, CREST and CHECK serve different purposes.

What is realistic at short notice

Our standard lead time from agreed scope to testing is two to three weeks. At short notice it is often within a week, and occasionally two to three days for a contained scope. There is no rush premium, because charging more for a date in the diary is not a service. The report follows within five working days of testing completing, and anything critical is reported as soon as it is confirmed. A retest is included once the issues are fixed, which is the part that produces your remediation evidence, and that is frequently what the auditor found missing. If your deadline is tight, how urgent engagements are handled covers what can and cannot be compressed.

One disclosure, because it is directly relevant. Solusec does not hold ISO 27001 itself. We hold IASME Cyber Assurance, which is aligned to ISO 27001 and independently audited, and we consider that proportionate for a specialist practice of this size. It is not the same certification and we would not present it as equivalent. If your own supplier policy or a customer contract requires your testing provider to be ISO 27001 certified, we are not the right fit, and it is better for both of us to establish that now rather than at contract stage.

The short version. Find out the real date. Read your scope statement before anyone scopes a test. Check whether the CREST requirement is a customer's or your own, since it is not the standard's. Then buy something you can evidence properly, remediation included.

Common questions