Penetration Testing for ISO 27001, SOC 2 and Cyber Essentials: What UK Auditors Expect
Most UK businesses first look into penetration testing because someone asked them to. An auditor, an enterprise customer, or a procurement team wants evidence that your systems have been independently tested. The question that follows is always the same: does my certification actually require a penetration test, and if so, what kind? This guide explains where testing fits into ISO 27001, SOC 2 and Cyber Essentials, and how to scope a test that stands up to review.
The honest answer on requirements
None of these frameworks contains a line that says “you must buy a penetration test.” What they require is that you identify your technical vulnerabilities and manage them. A penetration test is the most credible way to prove you have done that, which is why it has become the practical expectation even where it is not written as a hard rule.
Here is how it plays out in each case.
ISO 27001. The standard expects you to manage technical vulnerabilities and to evaluate whether your controls work. Annex A control 8.8 covers the management of technical vulnerabilities, and testing is how you demonstrate it in practice. Certification bodies increasingly expect to see a recent, independent test, especially for organisations that build or host their own software. A vulnerability scan alone rarely satisfies an experienced auditor.
SOC 2. This is where testing gets real. SOC 2 is a report on your controls written by an auditor, and enterprise buyers read it closely. Many organisations include penetration testing as a control within scope, and auditors want to see that the test happened, that findings were tracked, and that the serious ones were fixed. A clean, well documented test with evidence of remediation is one of the strongest things you can put in front of a SOC 2 assessor.
Cyber Essentials and Cyber Essentials Plus. Standard Cyber Essentials is a self assessment and does not require a penetration test. Cyber Essentials Plus adds a hands on technical audit carried out by an assessor, which includes vulnerability testing of a sample of your systems. That is not a full penetration test, but a prior test helps you pass it first time by clearing the issues an assessor would otherwise flag.
What auditors and clients actually look for
Passing review is not about owning a PDF. It is about showing a working process. Assessors and enterprise security teams tend to look for four things.
First, independence. A test carried out by someone outside the team that built the system carries far more weight than an internal review.
Second, appropriate scope. The test should cover the systems that matter, which usually means your production application, its supporting infrastructure, and any component that handles sensitive data. A test scoped to avoid your riskiest systems is easy to spot.
Third, evidence of remediation. Finding issues is expected. What reassures a reviewer is proof that you triaged them, fixed the serious ones, and can show it. A retest that confirms the critical findings are closed is the gold standard.
Fourth, a sensible cadence. Testing once and never again looks like a box tick. Testing on a regular schedule, and after major changes, looks like a programme.
How to scope a test that passes
Start from the data. Map where your sensitive information lives and how it moves, then make sure the test covers those paths. For most software businesses that means the web application, the APIs behind it, the authentication and access control layer, and the cloud environment it runs in.
Match the depth to the framework. For SOC 2 and ISO 27001, an authenticated test that logs in as different user roles and tries to break access controls gives you the evidence reviewers want. A shallow external only scan usually does not.
Build in a retest from the start. Agree up front that once you have fixed the findings, the provider will confirm the fixes worked. That single document, showing criticals opened and then closed, does more for an audit than the original report on its own.
Keep the paperwork. A prioritised report, a remediation log, and a retest confirmation together tell a complete story. That story is what an auditor is really buying.
How Wolfcore approaches it
We scope every engagement to the framework you are working toward, rather than selling a fixed package that may test the wrong things. Before a full test, we offer a free external vulnerability scan so you can see what is already exposed and plan the scope sensibly. After the test, we retest to confirm your fixes landed, and we write the report so that an auditor or an enterprise buyer can follow it without a translation.
The goal is simple. You should come out of the engagement with the evidence your certification needs, and with your systems genuinely harder to break, not just a document to file.
What to do next
If a client or auditor has asked you for a test, work out which framework is driving the request and scope from there. If you are not sure what your environment exposes yet, start with a free external scan and build the scope around what it finds.
Request your free external vulnerability scan, then talk to us about a compliance ready penetration test.
Wolfcore is a UK based offensive security consultancy working worldwide, specialising in penetration testing, cloud security and AI security. This article is general guidance on how testing supports certification and is not a substitute for advice from your certification body or auditor.