The Complete Guide to Penetration Testing for UK Businesses

Penetration testing is the practice of paying a qualified specialist to attack your own systems, under contract and under control, so that the exploitable weaknesses in them are found by someone who writes a report rather than someone who sells your data. For UK businesses in 2026 it has stopped being an optional maturity exercise and become a routine commercial requirement — written into cyber insurance proposal forms, supplier due-diligence questionnaires, ISO 27001 certification audits and PCI DSS validation.

This guide covers what penetration testing actually is and how it differs from the vulnerability scanning most organisations already run; the main pen testing UK methodologies (external network, internal network, web application, cloud, wireless and social engineering); why CREST penetration testing accreditation matters when you choose a provider and what NCSC CHECK, Tigerscheme and individual assessor certifications add on top; how penetration testing services are scoped and priced in day-rate terms; what a competent report contains and how to read it; and how to build a remediation and retest cycle that stands up in front of a Cyber Essentials Plus assessor, an ISO 27001 auditor or a PCI DSS QSA. By the end you should be able to write a scope, read three quotes side by side, and tell the difference between a genuine test and an automated scan with a cover page.

What is penetration testing? Definition and context

A penetration test is a time-boxed, authorised simulation of an attack against a defined set of systems, carried out by a human tester using the same techniques as a real adversary. The tester enumerates what is exposed, identifies weaknesses, and then — crucially — attempts to exploit them to prove what an attacker could actually reach. The output is evidence: not “this port responds to an outdated TLS version”, but “this outdated component allowed authentication bypass, from which we reached the customer database and extracted the first ten records as proof”.

That word “exploit” is the whole distinction. An automated vulnerability scanner compares software versions and configuration responses against a signature database and produces a list of possible issues, each with a CVSS score. It is fast, cheap, and entirely capable of running weekly. What it cannot do is chain three individually low-severity findings into one critical path, reason about your business logic, or tell you that the “informational” directory listing on a staging subdomain contains a configuration file with a live API key. A penetration test is a person doing that reasoning. The scanner tells you what is unlocked; the tester tells you what is reachable, and what is behind it.

The scope of a test is fixed in writing before anything starts, in a document usually called the rules of engagement. It states which IP ranges, domains, applications and cloud tenants are in scope; which are explicitly out of scope; the testing window; whether denial-of-service techniques are permitted (they almost never are); who the emergency contacts are on both sides; and what happens if the tester finds evidence of an existing compromise. Under the Computer Misuse Act 1990, authorisation is what separates a penetration test from an offence, so this paperwork is not administrative padding — it is the legal basis for the work. Reputable providers will not begin without a signed authorisation from someone with the standing to give it, and if you are testing infrastructure hosted by a third party you may need their written consent too.

Penetration testing also sits at a specific point in a wider security programme, and it is worth being honest about where. It is a point-in-time assessment. It tells you the security posture of a defined scope on the days it was tested. It does not replace patching, monitoring, backup, identity controls or staff awareness training, and a test commissioned before those basics exist tends to produce a report that simply lists the basics. The organisations that get value from testing are the ones that have already done the foundational work — typically the five controls behind Cyber Essentials certification — and now want to know what a capable attacker would find beyond them.

Penetration testing in the UK — the numbers that frame the decision

Before scoping anything, it helps to have a rough sense of the commercial shape of penetration testing services in the UK market. The figures below are indicative planning numbers drawn from typical UK SME and mid-market engagements rather than a national survey, and they exist to help you sanity-check a quote — not to be quoted back at a supplier.

Two of those numbers deserve unpacking. The day rate is the unit that everything else is built from: a penetration test is priced in tester-days, and a quote that arrives as a single fixed price without a stated number of days is a quote you cannot compare with anything. Ask every provider to state days and rate separately. The lead time matters because it is routinely underestimated by businesses trying to satisfy a contractual deadline — if a client contract requires an annual test by the end of the quarter, a provider needs booking well before the last fortnight, and rushed scoping is where scope gaps get introduced.

The retest interval is the one most often argued about. Annual is the floor, not the target. The right cadence is driven by rate of change: an organisation that deploys code weekly and has a substantial internet-facing application estate is testing more than once a year, because the thing tested in January is not the thing running in July. An organisation whose external footprint is a website, a VPN endpoint and a Microsoft 365 tenant that changes rarely can reasonably run annually, provided continuous vulnerability scanning fills the gaps between tests.

Where UK penetration tests actually find their findings

One of the more useful things to understand before commissioning a test is what tests typically find, because it tells you where to spend remediation budget and, more usefully, what you could fix in advance so the test spends its days on harder ground. The pattern below reflects the finding classes that recur most frequently across UK SME and mid-market engagements. Read it as a distribution of common weaknesses rather than a precise national statistic.

The striking thing about that list is how little of it is exotic. Almost none of the highest-frequency findings involve a novel exploit or a zero-day. They involve a patch that was not applied because the server was outside the patching scope, a service account created for a 2019 integration that still holds domain rights, an application endpoint that checks whether you are logged in but not whether the record belongs to you, and an internal network where a compromised laptop in reception can reach the finance file server. This is the uncomfortable and genuinely useful message of most penetration test reports: attackers are not usually beating sophisticated defences, they are walking through gaps in ordinary operational hygiene.

The sixth bar — forgotten assets found during enumeration — is worth calling out separately because it is the finding that most often surprises the board. A test that begins with open-source reconnaissance regularly turns up a legacy marketing microsite on an unmaintained WordPress install, a staging environment indexed by search engines, a decommissioned VPN appliance still resolving in DNS, or a developer test box with an unrestricted management port. Nobody in the business knew these existed, which is exactly why nobody was patching them. Asset discovery is not a bonus deliverable; for many organisations it is the highest-value part of the whole engagement.

The credential and segmentation findings tend to cluster. Once a tester has a low-privilege foothold, a flat internal network converts that foothold into domain-wide access with unnerving speed — which is why network segmentation for UK SMEs so often appears in the remediation section of an internal test report. Similarly, the MFA gap statistic understates the problem, because the gaps that matter are rarely the main sign-in flow. They are legacy authentication protocols, break-glass accounts, service principals and the administrative console that predates the MFA rollout. Organisations that have moved to phishing-resistant MFA and passkeys still get findings here, because coverage is the hard part, not technology choice.

Penetration testing costs in the UK — what you actually pay in 2026

Penetration testing services are almost always priced as consultant days multiplied by a day rate, plus reporting time, plus optional retest. Fixed-price packages exist and are perfectly legitimate at the small end, but underneath them is still a day count — and knowing that count is how you tell a five-day test from a one-day scan sold at five-day prices. The table below sets out the common engagement types with indicative UK pricing for 2026.

A first engagement for a typical 40 to 120 person UK business is usually external network plus one authenticated web application, landing somewhere between £6,000 and £12,000 including reporting and a retest. Add an internal network test and a cloud review and you are in the £12,000 to £20,000 band. Those numbers move with complexity rather than headcount: a 25-person fintech with a customer-facing platform and three cloud environments will cost considerably more to test properly than a 200-person distributor whose entire external footprint is a brochure site and a VPN concentrator.

Three cost lines get missed in budgeting. The first is retesting, which some providers include and some price separately — check, because a report without a verified retest is very hard to present to an auditor or insurer as evidence of closure. The second is remediation itself, which is frequently larger than the test. If the report says the internal network needs segmenting or an unsupported line-of-business application needs replacing, the fix is a project, not a change ticket. Budget for the test and reserve for the outcome. The third is the cost of the internal time the engagement consumes: scoping calls, credential provisioning, a technical contact available during the testing window, and the debrief. Plan for two to four days of someone senior’s attention.

It is also worth being clear about what a very cheap quote is buying. A £750 “penetration test” is an automated scan with the output reformatted. That is not fraud — scanning has real value and running it continuously is good practice — but it is a different product, and it will not satisfy an assessor who asks for evidence of manual testing by a qualified individual. The way to tell them apart at quote stage is simple: ask who the named tester is, what their certifications are, and how many of the days are manual testing versus tooling.

Vulnerability scanning vs penetration testing — how the two compare

The single most common scoping error is buying one when you needed the other, or assuming that having one means you do not need the other. In a mature programme they are complements with different jobs: scanning provides breadth and frequency, testing provides depth and proof. The comparison below sets out how they differ in practice.

The practical answer for most UK businesses is both, sequenced sensibly. Run authenticated vulnerability scanning continuously so that the routine patch and configuration issues are found and fixed on a weekly rhythm. Then commission penetration testing at whatever interval your change rate and compliance obligations demand, and let the tester spend their days on the things a scanner cannot reach. Organisations that do this in the wrong order pay consultant day rates for a tester to write up missing patches — which is an expensive way to buy a patch report, and a waste of the one capability you cannot automate.

There is a third category that sits between the two and is increasingly sold in the UK as “penetration testing as a service” or continuous testing: a scanning platform with periodic manual validation and a portal for tracking findings. These can be good value if the manual component is real and the testers are qualified. Apply the same test as always — how many manual tester days per year, performed by whom, under what accreditation. If the answer is vague, you are buying a scanner with a subscription wrapper.

Choosing a provider — why CREST penetration testing accreditation matters

The UK penetration testing market is unregulated in the sense that anyone may describe themselves as a penetration tester. What fills that gap is a set of accreditation schemes that assess companies and individuals against published standards, and understanding them is the difference between buying assurance and buying a PDF.

CREST is the most widely recognised. It accredits member companies, not just individuals, and the company-level assessment examines methodology, data handling, report quality, legal and insurance arrangements, complaint processes and technical competence. Individual testers hold CREST certifications at graded levels — CREST Practitioner Security Analyst at entry, CREST Registered Tester in the middle, and CREST Certified Tester (infrastructure or web application) at the senior end. When a contract or insurance form asks for CREST penetration testing, it is normally asking for a CREST member company, and the accreditation is what gives a client or an auditor a basis for accepting the work without assessing the tester themselves.

NCSC CHECK is the scheme used where testing touches UK government or public-sector systems, and CHECK Team Leader and Team Member status is held by individuals working for CHECK-approved companies. If you supply the public sector, or your client is a government body, CHECK may be specified explicitly rather than CREST — read the requirement carefully rather than assuming they are interchangeable. Tigerscheme and The Cyber Scheme are further UK certification bodies for individual testers, both mapped to comparable competence levels and both accepted by many buyers. On the individual side you will also see OSCP and its successors, which are hands-on exploitation qualifications well regarded in the industry, though they certify a person rather than a company’s processes.

Accreditation is necessary but not sufficient. A CREST member company can still assign your engagement to its most junior tester, still deliver a report that is a tool export with a logo, and still disappear when you have follow-up questions. The scoring framework below is how to assess the rest — use it to compare quotes on something other than price.

One line in that grid does more work than the rest: critical findings escalated within hours. If a tester discovers on day one that your customer database is reachable from the internet without authentication, you need to know that day — not in the report two weeks later. Any provider who cannot commit to immediate escalation of critical issues, in writing, is prioritising their reporting workflow over your risk, and that tells you what the engagement will be like when something goes wrong.

The data handling row matters more than most buyers realise. During an engagement your tester will hold network diagrams, credentials, screenshots of live systems and, sometimes, extracts of real data used as proof of impact. That is a genuine concentration of risk and it is regulated: under UK GDPR the provider is processing personal data on your behalf, which requires a data processing agreement, and the ICO will expect you to have exercised due diligence on that processor. Ask where evidence is stored, who can access it, how long it is kept and how deletion is confirmed.

The penetration testing engagement timeline — what actually happens, week by week

A well-run engagement follows a predictable arc, and knowing it lets you plan internal resource properly. The timeline below reflects a typical five-to-eight day combined external and web application test for a UK mid-market business, from first conversation to closed retest. Compressing any of these stages is possible; skipping the scoping or the retest is where engagements go wrong.

Note where the elapsed time goes. The testing itself is a week; the engagement is two to three months, most of it remediation. Businesses that book a test to satisfy a contractual deadline in three weeks frequently discover that the deadline was for evidence of a completed remediation cycle, not for a report full of open findings. Read the requirement wording carefully before you plan backwards from the date.

Remediation benchmarks — the KPIs that show a programme is working

A penetration test produces a list. What determines whether the money was well spent is what happens to that list over the following quarter. The benchmarks below are reasonable targets for a UK SME or mid-market organisation running a mature testing cycle, and they are the numbers worth putting in front of a board rather than a count of findings.

Two of those metrics are diagnostic rather than operational. The recurrence rate — how many findings from last year’s report appear again in this year’s — is the clearest single indicator of whether you are fixing causes or symptoms. A patching finding that recurs annually means the patch was applied but the patching process was not changed, and the correct response is to fix the process rather than the server. The unknown-asset rate does the same job for inventory discipline: if the tester keeps finding systems you did not declare, your asset management is the real vulnerability and every future test will be scoped incorrectly.

Root-cause analysis is the discipline that separates organisations whose security posture improves from those that simply re-buy the same test. When a report identifies an unpatched server, the useful question is not “how do we patch it” but “why was this server outside our patching scope, and what else is”. That question typically produces two or three additional fixes that no tester would have found, and it is free.

Retest coverage — the number that decides whether the test was worth buying

If you track one figure from your testing programme, make it this one: the proportion of critical and high findings that have been fixed and independently verified as fixed within 90 days of the report. Not reported as fixed. Verified. A retest that confirms closure is what converts a document listing your weaknesses into evidence of your improvement, and it is the artefact that insurers, auditors and enterprise clients actually want to see.

Ninety per cent is a target rather than a guarantee, and the remaining tenth is not failure — it is the set of findings whose remediation is a genuine project. Replacing an unsupported line-of-business application, re-architecting a flat network, or migrating an inherited legacy platform cannot be done inside a quarter. What matters is that those items are formally risk-accepted at the right level of the organisation, with a documented rationale, a compensating control and a target date, rather than quietly ageing at the bottom of a spreadsheet. An auditor will accept a documented risk acceptance signed by a director. An auditor will not accept silence.

The compensating control point deserves emphasis because it is where testing and the rest of your security programme connect. If a legacy application cannot be patched this year, the mitigations are segmentation so a compromise cannot spread, tightened access so fewer accounts can reach it, and monitoring so an attempt is detected. That is the same set of controls that shows up in a ransomware-resistant backup strategy and in a tested recovery plan — because the honest position is that some findings will be open when an incident happens, and recoverability is what carries you through that.

The penetration testing scoping checklist — 12 points to settle before you sign

Most disappointing engagements are not badly executed; they are badly scoped. The tester tested exactly what was written down, and what was written down did not include the thing that mattered. Work through the following before you approve a quote, and the report you receive will answer questions you actually care about.

1. Write down what you are trying to learn. “Can an attacker on the internet reach customer data?” is an objective. “Test our systems” is not. The objective drives which type of test you buy and what the tester prioritises when days run short.
2. Produce an honest asset inventory. Every internet-facing IP range, every domain and subdomain, every application URL, every cloud tenant and every remote-access endpoint. Include the systems you would rather not think about — the legacy microsite and the old VPN appliance are exactly where findings live.
3. Decide the perspective. Black box means the tester starts with no information, which realistically simulates an outsider but spends days on reconnaissance. Grey box provides credentials and architecture detail so the days go into depth. White box adds source code and full documentation. For most SMEs grey box gives the most findings per pound.
4. Specify authenticated testing and the roles to test. An unauthenticated application test finds a fraction of what is there. Provide test accounts at every privilege level — standard user, elevated user, administrator, and at least two accounts at the same level so the tester can check whether one user can reach another user’s records.
5. Decide production or staging, and record the trade-off. Testing production finds what is genuinely running but carries operational risk. Testing staging is safer but only valid if staging genuinely mirrors production — which it usually does not. If you test staging, document the differences.
6. Agree the testing window and the change freeze. Deploying a release mid-test invalidates findings and wastes days. Freeze changes to in-scope systems for the duration, or accept that the report describes a system that no longer exists.
7. Name the emergency contacts on both sides. Someone reachable outside office hours who can authorise the tester to stop, and someone at the provider who can be reached if a system becomes unstable. Put mobile numbers in the rules of engagement.
8. Confirm what is explicitly out of scope. Third-party SaaS platforms you do not own, shared hosting where other tenants would be affected, denial-of-service techniques, and any system whose failure would be genuinely unacceptable. Out-of-scope lists prevent arguments later.
9. Obtain third-party authorisation where required. If systems are hosted by a provider, check their acceptable use terms. Major cloud platforms permit testing of your own resources under stated conditions, but managed hosting and SaaS vendors often require prior written notice.
10. Decide whether this is also a detection test. If you want to know whether your monitoring notices the attack, do not tell your security team or allowlist the tester’s addresses. If you want maximum coverage of vulnerabilities in the days available, brief the team and allowlist — otherwise days are consumed evading controls rather than finding weaknesses. Both are valid; the mistake is not choosing.
11. Fix the deliverables and the retest terms in the contract. Executive summary, technical detail with reproduction steps, risk ratings with stated methodology, remediation guidance, a debrief session, and a retest with an attestation letter. Confirm whether retest is included or extra.
12. Agree data handling and reserve remediation budget. Where evidence is stored, for how long, under what data processing agreement, and how deletion is confirmed. Then set aside budget and engineering capacity for the fixes — commissioning a test with no capacity to act on it produces a documented list of known weaknesses, which is a worse legal position than not knowing.

Readiness gauge — are you ready to get value from a penetration test?

Testing rewards organisations that have already done the basics. If the fundamentals are missing, a tester will spend the engagement documenting them at consultant day rates and you will receive an expensive list of things you could have found yourself. Score yourself out of 100 across five areas, twenty points each: a maintained asset inventory; patching applied within defined timescales on a defined schedule; MFA on every remote access and administrative path; a working backup with a tested restore; and named ownership of security tasks with time allocated to do them.

Below roughly 40, the productive next step is foundational rather than adversarial. Achieve Cyber Essentials certification, which forces the five basic controls into place, and run authenticated vulnerability scanning for a quarter to clear the routine backlog. Testing after that will find things worth paying for.

Between 40 and 70, a targeted test of your single highest-risk asset is usually the right move — the customer-facing application, or the external perimeter — rather than a broad estate-wide engagement. You will get a shorter, more actionable report and a remediation cycle you can actually finish, which builds the internal habit that makes the next test more valuable.

Above 70, broad scoping pays off. The basics hold, so the tester’s days go into chained attack paths, business logic, privilege escalation and cloud identity — the findings that no scanner and no checklist would ever have produced. This is the point at which penetration testing stops being a compliance purchase and starts being a genuine source of security intelligence about your specific environment.

One caveat on self-scoring: organisations consistently overrate their asset inventory and their patching. A useful reality check is to ask your provider for a short external reconnaissance exercise — a day of enumeration against your public footprint — before committing to a full engagement. If it returns systems you did not know about, your inventory score is lower than you thought, and fixing that first will make the eventual test considerably more useful.

Common penetration testing mistakes to avoid

The failure modes in penetration testing are remarkably consistent across organisations of every size. Almost all of them are decisions made before or after the test rather than during it.

• Buying a scan and calling it a test. The clearest tell is a quote with no stated tester days, no named consultant and a price that looks too good. It will not satisfy an auditor asking for evidence of manual testing, and it will not find the access control flaw in your application.
• Scoping around the awkward systems. Excluding the legacy platform because it might fall over is understandable and precisely counterproductive — that system is the one an attacker will find. If it genuinely cannot be tested live, test a representative copy and document the constraint.
• Providing no credentials. Unauthenticated-only application testing leaves most of the attack surface untouched. If budget is tight, reduce the number of applications tested rather than the depth of testing on each.
• Treating the report as the deliverable. The report is an input. The deliverable is a set of closed findings verified by a retest. Organisations that file the PDF have bought a document describing their weaknesses and changed nothing about them.
• Fixing symptoms rather than causes. Patching the three servers named in the report while leaving the process that missed them unchanged guarantees the same findings next year, and the recurrence rate in the following report will show it.
• Skipping the retest to save money. Remediation frequently misses the mark — a fix applied to one endpoint but not its sibling, a configuration change reverted by a later deployment. Without verification you have an assumption, and an attestation letter is the artefact clients and insurers actually ask for.
• Testing once and stopping. A point-in-time assessment ages. Estates change, dependencies gain vulnerabilities, and cloud configuration drifts. An annual cycle with continuous scanning in between is the minimum viable rhythm for most UK businesses.
• Letting the report circulate freely. A penetration test report is a precise map of how to attack your organisation. Restrict distribution, share it with clients only under NDA or as a summary attestation, never email it unencrypted, and delete old copies when they are superseded.

Real-world example — a mini case study

A 45-person professional services firm in the Midlands commissioned its first penetration test after an enterprise client added an annual testing clause to a renewal contract. The scope was deliberately narrow: the external perimeter and the client portal through which customers uploaded documents, six consultant days, grey box with test accounts at three privilege levels. The internal network was deferred to a second engagement the following quarter.

Reconnaissance on day one produced the first surprise. Alongside the four IP addresses the firm had declared, enumeration identified a staging copy of the client portal on a subdomain that had been created for a redesign eighteen months earlier and never removed. It was running an older version of the application, it was indexed, and it shared a database credential with production. The tester escalated it that afternoon; the subdomain was taken offline within two hours and the credential rotated the following morning.

The most significant finding came on day three and was not something any scanner would have reported. The portal correctly verified that a user was authenticated before returning a document, but did not verify that the document belonged to that user’s organisation — a classic insecure direct object reference. Incrementing a numeric identifier in a request returned other clients’ files. Nothing was misconfigured and nothing was unpatched; the application was working exactly as written, and what was written was wrong. The finding was rated critical, escalated the same day, and fixed with an ownership check in the retrieval path within a week.

The report contained nineteen findings in total: two critical, four high, nine medium and four low. The firm ran a debrief with its development partner and its IT provider, assigned owners, and worked through the critical and high items over five weeks. Three medium findings relating to an unsupported internal application were formally risk-accepted by a director with segmentation and monitoring as compensating controls and a replacement scheduled for the following financial year. A two-day retest confirmed closure and produced an attestation letter, which satisfied the client contract clause. The second engagement, covering the internal network, found that the flat network the first report had flagged as a risk had been segmented in the interim — and consequently spent its days on Active Directory attack paths that would previously have been invisible behind more basic problems.

We assumed the test would tell us to patch things. What it actually told us was that our application had been handing documents to the wrong clients for a year, that we had a copy of our own portal on the internet nobody remembered building, and that our inventory was fiction. None of that would have come out of a scan — and honestly, none of it would have come out of a test we scoped ourselves without the provider pushing back on what we left off the list.

Two things from that engagement generalise. First, the highest-impact finding was a logic flaw, not a missing patch — which is the argument for manual testing in one sentence. Second, the second engagement was more valuable than the first precisely because the first one had been acted on. Testing compounds when remediation is real, and produces the same report annually when it is not.

The main types of penetration test, and when each one earns its budget

“Penetration testing” is an umbrella covering several distinct disciplines. They use different skills, different tooling and different day counts, and buying the wrong one is the most expensive scoping error available. The sections below set out what each type covers, what it typically finds, and the circumstances in which it belongs in your programme.

External network and perimeter testing

The starting point for almost every organisation. The tester works from the internet against your public IP ranges and domains, enumerating what is exposed, fingerprinting the software behind it, and attempting to exploit what is reachable. Typical findings include unpatched edge devices, administrative interfaces that should never have been internet-facing, VPN appliances running versions with known exploitation, weak or expired TLS configuration, mail security gaps in SPF, DKIM and DMARC records, and — frequently — assets nobody remembered owning.

External testing is the right first purchase because it maps directly to how commodity attacks actually begin. It is also the cheapest meaningful test, typically two to four days, which makes it a sensible way to establish the relationship with a provider before committing to larger engagements. Where it is weakest is depth: it tells you what an unauthenticated outsider can reach, and if the answer is “very little”, you have learned something valuable but you have not learned what happens after a phishing email succeeds.

Internal network testing and assumed breach

Internal testing starts from the position that an attacker is already inside — a compromised laptop, a phished credential, a contractor device on the guest network — and asks how far they get. The tester works from a device on the LAN or over VPN, usually beginning with either no credentials or a standard domain user account, and attempts privilege escalation, credential harvesting, lateral movement and access to sensitive data stores.

This is where the most alarming findings usually appear, because internal networks are built for productivity rather than containment. Common outcomes include Active Directory misconfigurations that allow escalation from standard user to domain administrator in a handful of steps, service accounts with excessive rights and passwords unchanged since deployment, credentials cached on shared workstations, legacy authentication protocols left enabled, file shares with wide-open permissions, and network architectures where a device in reception can reach the finance server without crossing a single control.

The assumed-breach framing is deliberate and it is worth defending to sceptical boards. The question is not whether someone will eventually get a foothold — phishing and credential theft succeed against well-run organisations regularly enough that planning otherwise is optimistic. The question is what that foothold is worth. An internal test answers it with evidence, and the remediation almost always centres on segmentation, privileged access management and tiering — structural work with lasting value.

Web application and API testing

Application testing is the deepest and usually the most expensive discipline, and it is where the gap between scanning and testing is widest. A tester works methodically through authentication and session management, authorisation and access control across roles, input handling and injection, business logic, file upload and processing, rate limiting, and the API endpoints behind the interface. The reference framework is normally the OWASP Testing Guide, with OWASP ASVS used where a formal verification level is required.

The findings that matter here are rarely the ones with catchy names. Broken access control — a user reaching another user’s data by changing an identifier, or a standard user invoking an administrative function because the interface hid the button but the endpoint did not check the role — is consistently the most common serious finding in application testing, and it is essentially invisible to automated tools because a scanner has no idea which records ought to belong to whom. Business logic abuse is the same story: applying a discount code repeatedly, skipping a step in a multi-stage process, or manipulating a quantity to a negative number are all valid HTTP requests that only a human recognises as wrong.

If your business runs a customer-facing application that handles personal or payment data, authenticated application testing is not optional and the day count should reflect real coverage. A complex multi-tenant platform tested in three days has been sampled, not tested. Ask the provider what proportion of the OWASP Testing Guide checklist the proposed days actually cover.

Cloud configuration review — Azure, AWS and Microsoft 365

Cloud testing is less about exploitation and more about configuration, identity and blast radius, which is why providers often call it a review rather than a test. The work examines identity and conditional access policies, privileged role assignments and standing administrative access, storage account and bucket exposure, network security group rules, key and secret management, logging and retention coverage, and the tenant-level hardening settings that ship insecure by default.

The recurring themes are over-privilege and drift. Global administrator roles assigned permanently to people who need them twice a year; service principals and application registrations with broad consent granted during a project and never reviewed; storage containers made public for a legitimate reason in 2023 and still public; conditional access policies with exclusions that have quietly grown; and diagnostic logging disabled or retained for a fortnight, so that after an incident there is nothing to investigate. Note that cloud platform providers permit testing of your own resources under stated conditions but not of their underlying infrastructure — check the current terms for your platform before scoping.

Cloud review pairs naturally with identity work. Organisations that have tightened Microsoft 365 email security against phishing and business email compromise have usually addressed the loudest part of the tenant, but conditional access exclusions, legacy authentication and application consent tend to survive that effort and are exactly what a cloud review surfaces.

Wireless testing

Wireless testing is narrow, cheap and periodically decisive. The tester assesses encryption and authentication on corporate networks, checks whether guest wireless is genuinely isolated from the corporate LAN, looks for rogue or misconfigured access points, and tests whether pre-shared keys are shared, weak or unchanged since installation. It is typically one to two days and is most worthwhile for organisations with multiple sites, shared buildings, or a guest network that was configured quickly and never revisited. The classic finding — guest wireless bridged to the internal network at layer 2 — converts a car park into an internal foothold, and it is more common than anyone expects.

Social engineering and phishing simulation

Social engineering tests the human and process layer: targeted phishing campaigns using pretexts built from public information about your organisation, telephone-based pretexting, and in some engagements physical access attempts against reception, tailgating and unattended workstations. The deliverable is a measured click and credential-submission rate plus a narrative of what the tester achieved, and the value lies less in the percentage than in what happened afterwards — whether anyone reported it, how quickly, whether the report reached someone who acted, and whether MFA held when a credential was captured.

Handle this type with care. Social engineering results identify individuals, and using them punitively destroys the reporting culture that is the actual control. Agree in advance that results are aggregated for reporting, that no individual is named to management, and that the follow-up is training rather than sanction. Also confirm the legal and HR position before commissioning physical access testing, and ensure the tester carries a signed authorisation letter to produce if challenged — being detained by your own security team is a bad afternoon for everyone.

Red teaming — and why most UK SMEs should not buy it yet

A red team engagement is objective-led rather than coverage-led: rather than enumerating vulnerabilities in a defined scope, the team is given a goal — reach the payroll system, exfiltrate a specific dataset — and a long window in which to achieve it by any agreed means, while your defenders remain unaware. It tests detection and response as much as prevention, and it is the most realistic simulation available.

It is also the wrong purchase for most organisations, because it answers a question they are not yet asking. Red teaming measures how well your security operations detect and respond. If you do not have security operations — if nobody is watching the alerts — the answer is known in advance and you have paid a premium to confirm it. Red teaming earns its cost once you have a monitoring capability worth testing, a mature vulnerability management programme and several clean penetration testing cycles behind you. Until then, coverage-led penetration testing produces more improvement per pound.

How penetration testing maps to UK compliance frameworks

A great deal of UK testing spend is driven by a compliance requirement rather than a security judgement, and the requirements differ more than buyers assume. Getting the mapping right prevents both under-buying (a scan where a test was mandated) and over-buying (a full test where a scan would have satisfied the control).

Cyber Essentials and Cyber Essentials Plus

Neither Cyber Essentials nor Cyber Essentials Plus requires a penetration test. This surprises people, and it matters commercially. Cyber Essentials is a verified self-assessment against five technical controls. Cyber Essentials Plus adds an independent technical audit — internal and external vulnerability scanning, malware protection tests and a sample of user devices — but that audit is a defined verification exercise, not an adversarial engagement. If a client contract asks for Cyber Essentials Plus, buy the certification; if it asks for an annual penetration test, that is a separate purchase and the certification will not satisfy it.

Where the two connect is sequencing. The five controls behind certification are the foundation that makes testing worthwhile, and organisations that certify first tend to get better value from their first test. If you are working through this, the difference between Cyber Essentials and Cyber Essentials Plus is worth understanding properly before you commit to either, because the gap analysis work is substantially the same and the audit is the only real delta.

ISO 27001:2022

ISO 27001 does not mandate penetration testing in so many words, but two Annex A controls make it the natural means of compliance. Control 8.8, management of technical vulnerabilities, requires that information about technical vulnerabilities in systems in use is obtained and that appropriate measures are taken — which requires a means of obtaining that information. Control 8.29, security testing in development and acceptance, requires security testing processes to be defined and implemented in the development lifecycle. In practice, certification auditors expect to see a documented testing regime, evidence of tests performed, and — the part organisations most often fail on — evidence that findings were tracked to closure through the corrective action process.

The auditor’s interest is therefore less in the report than in the management system around it: a documented rationale for scope and frequency based on risk, a register linking findings to owners and dates, evidence of remediation, and formal risk acceptance for anything outstanding. An organisation with a modest annual test and immaculate follow-through passes comfortably. An organisation with an expensive test and no closure evidence collects a nonconformity.

PCI DSS v4.0.1

PCI DSS is the most prescriptive of the frameworks. Requirement 11.3 mandates internal and external vulnerability scanning at least quarterly and after significant change, with external scans performed by an Approved Scanning Vendor. Requirement 11.4 mandates penetration testing — external and internal, at least annually and after any significant infrastructure or application change — performed using a defined methodology by a qualified resource with organisational independence. Where segmentation is used to reduce the cardholder data environment, segmentation testing is required at least every six months for service providers and annually for merchants, specifically to confirm that the segmentation controls actually isolate the environment.

Two details catch organisations out. First, “after significant change” is a real obligation, not a formality: a major infrastructure change resets the clock regardless of when the annual test was performed. Second, exploitable vulnerabilities found during testing must be corrected and the testing repeated to verify the correction — retesting is mandatory under PCI, not optional, which is one more reason to have it in the contract from the start.

UK GDPR, the ICO and DPA 2018

UK GDPR Article 32 requires appropriate technical and organisational measures, and explicitly includes a process for regularly testing, assessing and evaluating the effectiveness of those measures. It does not name penetration testing, but testing is the most common way organisations demonstrate that they have such a process. The ICO’s enforcement history consistently emphasises whether known weaknesses were addressed — which is why an unactioned report is a worse position than no report, and why documented remediation with dates is the artefact that matters.

Cyber insurance and supplier due diligence

Insurers increasingly ask about testing frequency, scope and remediation on proposal forms, and answers there are warranties rather than aspirations. Answer accurately: stating that you test annually when the last test was three years ago creates a coverage problem at exactly the wrong moment. Supplier due-diligence questionnaires from enterprise clients typically ask for a summary or attestation rather than the full report, and increasingly ask specifically for CREST or CHECK accreditation of the provider — which is worth confirming before you appoint, not after.

The DSP Toolkit for organisations working with NHS data, and the various sector schemes in finance and critical infrastructure, add their own testing expectations. If you operate in a regulated sector, read the specific wording of the obligation before scoping, because the differences between “an annual penetration test”, “an independent security assessment” and “regular vulnerability scanning” are the differences between three quite different purchases.

How to read a penetration test report

Reports vary in quality more than any other deliverable in this field, and knowing what a good one looks like is the best defence against a bad one. A competent report has a clear structure and each part has an audience.

The executive summary should be readable by a director with no technical background and should answer three questions in a page: what was tested, what the overall risk position is, and what the most important actions are. It should not contain CVSS scores, tool output or jargon. If your board cannot understand the first page, the report will not produce a budget decision.

The scope and methodology section records exactly what was and was not tested, the dates, the perspective (black, grey or white box), the credentials supplied, and the methodology followed. This is the section an auditor reads most carefully, because it establishes whether the test covered what the requirement demanded. Check it against your rules of engagement on receipt — discrepancies are much easier to resolve in week three than at audit.

Each finding should carry a title, a risk rating with the rating methodology stated, an affected-systems list, a description of the technical issue, an assessment of business impact in your context rather than generic boilerplate, evidence sufficient for your engineers to reproduce it, and specific remediation guidance. “Apply vendor patches” is not remediation guidance. “Upgrade component X to version Y or later on hosts A, B and C; if the upgrade cannot be scheduled before the next release, restrict access to the interface to the management VLAN as an interim control” is.

Watch the risk ratings sceptically. A finding rated critical by CVSS may be low risk in your environment because the affected system holds nothing sensitive and sits behind two other controls; a medium-rated finding may be your most urgent problem because it sits on the path to your customer data. A good tester adjusts for context and explains the adjustment. If every rating in the report is the raw CVSS score, the tester has not thought about your business, and you will need to do the contextualisation yourself during triage.

Finally, look for what is absent. A report with no low or informational findings has probably been trimmed for presentation; those items are often the early indicators of process problems. A report with no positive observations is similarly incomplete — knowing which controls held up under testing is useful evidence for the board and for insurers, and a tester who noticed only failures was not paying full attention.

At a glance — penetration testing for UK businesses

How Cloudswitched approaches penetration testing

Cloudswitched delivers penetration testing services for UK businesses across external and internal infrastructure, web applications and APIs, Microsoft 365 and cloud environments, with CREST-accredited engagements where a contract, insurer or auditor requires that accreditation and standard engagements where it does not. The starting point is always the scoping conversation described earlier in this guide: what you are trying to learn, what actually exists, and what a realistic day count looks like against your budget — stated as days and rate rather than an opaque total.

Because Cloudswitched also delivers the surrounding IT and security work — patching regimes, identity and MFA rollouts, network segmentation, Microsoft 365 hardening, backup and recovery, and Cyber Essentials certification — the remediation conversation does not stop at the report. Findings are triaged with the people who will act on them, root causes are separated from symptoms, and outstanding items are documented with compensating controls and owners rather than left to age. Retesting closes the loop and produces the attestation letter that clients and insurers ask for.

Frequently Asked Questions

What is penetration testing, in plain terms?

Penetration testing is a controlled, authorised attack on your own systems, carried out by a qualified specialist within a scope and timeframe you agree in advance. The tester looks for weaknesses and then attempts to exploit them, so the report tells you not just what is theoretically vulnerable but what an attacker could genuinely reach and what they would find when they got there. It differs from a vulnerability scan in that a human being is reasoning about your specific environment, chaining minor issues into serious attack paths and testing business logic that no automated tool understands. The deliverable is evidence with reproduction steps, risk ratings adjusted for your context, and specific remediation guidance.

How much do penetration testing services cost in the UK?

Testing is priced in consultant days, typically £650 to £1,200 per day for an accredited UK provider in 2026. An external network test usually runs two to four days, an internal network test three to six, and an authenticated web application test four to ten depending on complexity. A first engagement for a typical SME — external perimeter plus one application, including reporting and a retest — commonly lands between £6,000 and £12,000. Add internal network and cloud reviews and the range moves to roughly £12,000 to £20,000. Always ask for days and day rate separately: a fixed price with no stated effort cannot be compared with a competing quote, and unusually cheap quotes are normally automated scans presented as tests.

What is CREST penetration testing and do I need it?

CREST is an international accreditation body that assesses both testing companies and individual testers. Company accreditation examines methodology, data handling, legal and insurance arrangements, report quality and technical competence, which gives a buyer or auditor a basis for accepting the work without evaluating the tester themselves. You need CREST penetration testing when a client contract, insurance policy, framework agreement or regulator specifies it — and that is increasingly common in enterprise supply chains. If nothing in your obligations names it, a well-qualified non-CREST provider may deliver equally good work, but check the requirement wording before you appoint rather than after, because retrofitting accreditation to a completed test is not possible.

How often should a UK business have a penetration test?

Annually is the accepted baseline and the interval most insurers, auditors and client contracts assume. Beyond that, frequency should follow rate of change: if you deploy application code frequently or your infrastructure changes materially through the year, the system tested in January is not the system running in July, and testing after significant change matters more than testing on a calendar date. PCI DSS makes this explicit by requiring testing at least annually and after any significant infrastructure or application change. Between tests, continuous authenticated vulnerability scanning covers the routine patch and configuration issues, so that manual testing days are spent on the problems scanning cannot reach.

Does Cyber Essentials or Cyber Essentials Plus require a penetration test?

No. Cyber Essentials is a verified self-assessment against five technical controls, and Cyber Essentials Plus adds an independent technical audit consisting of internal and external vulnerability scans, malware protection tests and a sample of user devices. That audit is a defined verification exercise rather than an adversarial engagement, and it does not include exploitation, business logic testing or lateral movement. If a client asks for Cyber Essentials Plus, buy the certification. If they ask for an annual penetration test, that is a separate purchase and the certification will not satisfy it. The two work well in sequence: certify first so the basics are in place, then test so the engagement finds something worth paying for.

What is the difference between black box, grey box and white box testing?

These describe how much information the tester is given. Black box means starting with nothing but your company name, which realistically simulates an external attacker but consumes days on reconnaissance that could have been spent on exploitation. White box provides full documentation, architecture diagrams and often source code, giving maximum coverage but least realism. Grey box sits between the two: the tester receives credentials, architecture detail and an asset list, and spends the engagement on depth. For most UK SMEs grey box produces the most findings per pound, because you are not paying consultant day rates for someone to discover information you could have handed over in an email.

Will a penetration test break our systems?

The risk is real but small and manageable. Professional testers work within agreed rules of engagement, avoid destructive techniques, and exclude denial-of-service testing unless it is explicitly requested. That said, some legacy systems are fragile enough that ordinary enumeration destabilises them, which is why the rules of engagement name emergency contacts on both sides and define a stop procedure. Mitigate sensibly: agree a testing window outside peak hours for sensitive systems, confirm you have a recent verified backup before testing begins, ensure someone technical is reachable throughout, and check that your provider carries professional indemnity and cyber liability cover.

Should we test our production or staging environment?

Production gives genuine results because it is the system that actually faces your users and any attacker. Staging is safer but only meaningful if it truly mirrors production — and in most organisations it does not, differing in configuration, data, patch level, integrations or scale. Findings from a staging environment that differs from production are findings about a system nobody attacks. The usual compromise is to test production for infrastructure and read-only assessment while performing intrusive application testing in a staging environment that has been deliberately synchronised for the purpose, then documenting every known difference in the report scope section so an auditor can judge the coverage.

What should we do first when the report arrives?

Read the executive summary, then hold a debrief with the people who will do the fixing rather than only with management. Triage every finding into three buckets: fix now, schedule, or formally accept with a documented rationale and compensating control. Assign a named owner and a target date to each item within five working days — findings without an owner do not get fixed. Then look past the individual issues for root causes: if three servers were unpatched, the question is why they were outside your patching scope and what else is. Book the retest at the same time, before other work displaces it.

Can we share the report with clients who ask for it?

Be cautious. A full penetration test report is a detailed map of how to attack your organisation, and once it leaves your control you cannot govern how it is stored or who sees it. The normal answer to a client request is an attestation letter from your provider confirming that a test was performed, its scope and methodology, that findings were remediated and that a retest verified closure — without the technical detail. Where a client insists on more, share a redacted summary under NDA. Agree the attestation deliverable with your provider at contract stage, restrict internal distribution of the full report, and never send it unencrypted.

Is a penetration test worth it for a small business?

It depends entirely on what you have already done. If your asset inventory is incomplete, patching is ad hoc and MFA coverage has gaps, a tester will spend the engagement documenting those basics at consultant day rates — you would get more value from Cyber Essentials certification and a quarter of authenticated vulnerability scanning first. If the fundamentals are in place, or you handle customer data through an application you built, or a contract or insurer requires testing, then yes: a narrowly scoped external and application test is a proportionate purchase for a small business and the findings will be specific to you in a way no framework checklist can be.

What is the difference between penetration testing and red teaming?

Penetration testing is coverage-led: within a defined scope and a fixed number of days, the tester finds and validates as many weaknesses as possible, and the deliverable is a comprehensive findings list. Red teaming is objective-led: a team is given a goal, such as reaching a specific system or dataset, and a longer window to achieve it by any agreed means while your defenders remain unaware, so the exercise measures detection and response as much as prevention. Red teaming is the more realistic simulation, but it answers a question most UK SMEs are not yet asking. Without a monitoring capability worth testing, the result is known in advance.

Related reading

These guides cover the controls that penetration testing most often reports on, and the certifications that testing is frequently bought alongside.

• Cyber Essentials Certification: A UK Business Step-by-Step Guide to Passing First Time in 2026
• Cyber Essentials vs Cyber Essentials Plus: Which Certification Does Your UK Business Actually Need in 2026?
• Network Segmentation for UK SMEs: A Practical Guide to Isolating Risk Without Breaking Productivity in 2026
• Phishing-Resistant MFA and Passkeys: The 2026 UK Business Guide
• Email Security in Microsoft 365: A UK Business Guide to Stopping Phishing, Spoofing and Business Email Compromise in 2026

Find out what an attacker would actually find

A well-scoped penetration test tells you which of your weaknesses are genuinely reachable, what sits behind them, and what to fix first — in the order that matters rather than the order a tool ranked them. Cloudswitched scopes, delivers and retests infrastructure, application and cloud engagements for UK businesses, with CREST-accredited testing where your contracts or insurer require it.