Penetration Testing Frequency: A UK Business Guide to How Often You Actually Need a Pen Test in 2026

Penetration testing frequency is the question almost every UK business gets wrong in the same direction: they ask how often the rules say they must test, book that many tests, and treat the calendar as the risk model. The honest answer is that there is no single legal interval that applies to a UK company. What exists instead is a small set of compliance regimes that impose hard minimums on specific systems, a much larger set of frameworks that require testing to be “regular” without defining the word, and a simple operational truth that outranks both — a penetration test describes the security of an environment on the day it was tested, and every material change you ship afterwards degrades the accuracy of that description.

This guide sets out the decision logic first, because the logic is what survives when your estate changes. You will get a repeatable way to work out your own cadence from three inputs — the compliance obligations you actually carry, how fast your infrastructure and code change, and how much undetected exposure your board is willing to hold. Then it walks the specifics: what PCI DSS 4.0.1 genuinely requires and on what clock, where Cyber Essentials Plus sits (and why it is not a penetration test), how ISO 27001, the NIS Regulations, DORA and the FCA-supervised schemes treat testing intervals, the difference between a vulnerability scan and a real test, what a significant change is in practice, how to price a multi-test year against a single annual test, and how continuous testing models change the arithmetic. By the end you should be able to write your own testing schedule on one page and defend it to an auditor, an insurer or a customer’s procurement team.

What penetration testing frequency actually means — and why “annual” became the default

A penetration test is a time-boxed, human-led attempt to compromise a defined scope using the techniques a real attacker would use. It is authorised, evidenced and bounded by rules of engagement, and it produces a report that grades what was found and explains how it was achieved. The critical property for this discussion is that the result is a point-in-time statement. A test that concludes on 14 March describes the environment as it stood between the start and end dates of that engagement. It says nothing about the firewall rule added on 2 April, the exposed storage bucket created during a migration in June, or the authentication bypass introduced by a dependency update in September.

The annual test became the industry default for reasons that are historical and commercial rather than technical. Early card-industry rules put testing on a twelve-month clock, most certification cycles renew annually, budgets are set annually, and a single test is the smallest unit that a supplier can profitably sell and a buyer can easily approve. None of that reasoning is about risk. It is about administrative convenience, and it produces a well-recognised failure pattern: an organisation tests in Q1, remediates in Q2, ships eleven months of unexamined change, and books the next test the week before the certificate expires. The report on the shelf is technically valid and practically stale.

The alternative is not “test constantly”, which is unaffordable for most UK SMEs and produces diminishing returns on a static estate. The alternative is to decouple the question into two separate schedules that most organisations never separate. The first is the assurance schedule — testing you perform because a standard, a customer contract, an insurer or a regulator requires evidence on a fixed interval. The second is the risk schedule — testing you perform because something changed that could plausibly have introduced an exposure. The assurance schedule is set by other people and is usually a floor. The risk schedule is set by you, is driven by events rather than dates, and is where the actual security value sits. A mature programme runs both, and the compliance test is very often just the risk test that happened to land in the right month.

Penetration testing frequency in UK businesses — the numbers that matter

Before the frameworks, it is worth grounding the discussion in what UK organisations actually do and what it actually costs, because cadence decisions are made in budget meetings rather than in threat models. The figures below reflect typical mid-market and SME engagement patterns across UK professional services, e-commerce, healthcare supply chain and financial services firms, and they are the baseline this guide argues against for anyone with a fast-changing estate.

Read those four together and the structural problem is visible. The scanning obligation is quarterly; the testing obligation is annual; the change rate in a cloud-hosted estate is weekly or daily. The scan catches known vulnerabilities in known assets. The annual test catches design and chaining problems. Nothing in that model catches the design problem introduced in month three, and that is precisely the class of finding — a permissions chain, a forgotten pre-production host, an authentication flow that behaves differently after a redesign — that automated tooling is least able to surface on its own.

The cost figure is the one that changes behaviour when people see it properly. A small external test is a four-figure purchase, not a five-figure one. The reason many UK businesses run a single annual test is rarely that a second test is unaffordable; it is that the second test was never scoped, so it was never in the budget line. Splitting the same annual spend into a larger primary test and a smaller change-driven retest window is usually cost-neutral and materially changes what the programme detects.

Which factors actually drive the interval

If you strip away the marketing, cadence is a function of a handful of variables. The chart below ranks them by how strongly each one pushes a UK organisation towards more frequent testing, based on how often each factor is the decisive reason an engagement gets booked outside the annual cycle. Compliance is at the top not because it is the best reason to test, but because it is the most common reason a test happens at all.

Two things stand out. The first is how far down the list “new public-facing application release” sits relative to how much risk a release actually carries. A new customer portal changes the attack surface more decisively than almost anything else on the list, yet it triggers a test less often than a procurement questionnaire does. The second is that post-incident testing is rare — not because incidents are rare, but because the budget after an incident usually goes to containment and legal advice, and the assurance test that would confirm the attacker is actually gone gets deferred to the next planning cycle.

Change velocity is the variable that most cleanly separates a business that can defend an annual cadence from one that cannot. A firm running a stable on-premises estate behind a single firewall, with no in-house development and no public applications beyond a brochure website, genuinely changes its attack surface a handful of times a year. An annual external test plus quarterly authenticated vulnerability scanning is a coherent programme for that firm. A business running its own product, deploying weekly, integrating third-party APIs and managing cloud identity across several tenants changes its attack surface continuously. For that business, an annual test is a compliance artefact rather than a security control, and the honest schedule is a smaller, more frequent one anchored to releases. Estates that have moved to identity-centric access models face the same pressure from a different direction — as we covered in our guide to zero trust network access for UK businesses, the control plane becomes policy configuration, and policy configuration changes far more often than a firewall ruleset ever did.

What different testing cadences cost a UK business

Cadence is a budget decision as much as a risk decision, so it helps to see the realistic annual cost of each model rather than the cost of a single engagement. UK penetration testing day rates in 2026 sit broadly between £700 and £1,200 per consultant day for infrastructure and web application work, with accredited providers and specialist disciplines — red teaming, cloud configuration review, thick-client and embedded work — sitting at or above the upper end. The table below prices four common programmes for a mid-sized UK business with one public web application, a Microsoft 365 tenant, a small Azure footprint and around 80 staff.

The most useful line in that table is the third one. Splitting a programme into two half-sized tests rather than one large annual engagement typically costs between one and a half and two times the annual baseline, not double, because scoping, reporting and project management overheads are partly reused and providers discount committed multi-test contracts. In exchange the maximum blind window drops from around eleven months to around five. For most UK businesses that is the single highest-value change available to the testing budget, and it does not require any new tooling, headcount or process.

Two costs are routinely left out of the arithmetic and then arrive as a surprise. The first is retesting. A test that finds eight issues is only useful once those issues are fixed and the fix is verified; if your provider does not include a remediation retest within a defined window, budget for one to two additional days. The second is internal remediation effort, which is almost always larger than the testing fee. A programme that generates findings faster than your team can close them converts a security control into a risk register, and that is the practical ceiling on how frequently a given organisation should test. Testing more often than you can remediate is not a security improvement.

Annual testing versus a split or change-triggered cadence

The comparison below sets the traditional single annual engagement against the split cadence that most mid-market UK businesses should be moving towards. Neither is universally correct. The annual test wins on simplicity and on cost per engagement; the split cadence wins on the metric that matters most in practice, which is the longest period during which an introduced exposure could sit undetected by any human-led assessment.

The rotating scope is the underrated benefit and the reason the split model finds different classes of problem rather than simply finding the same ones twice. An organisation that tests its external perimeter every March for five years builds excellent assurance about the perimeter and none whatsoever about what an attacker achieves once inside, about how its Microsoft 365 tenant is configured, or about whether its build pipeline can be used to reach production. Rotating scope across a two-year window — external, then internal and identity, then application, then cloud configuration — produces a materially more complete picture for the same annual spend. Where accreditation matters to the audience reading the report, our comparison of CREST versus standard penetration testing in the UK sets out which tier of assurance each scope actually needs.

Testing maturity — where UK organisations typically sit

Cadence is only one dimension of a testing programme, and increasing it while the surrounding process stays weak produces reports nobody acts on. The grid below is the assessment we would run against an existing programme before recommending any change to frequency. Read it as a diagnostic: if the first card is red, fixing frequency will not help, because the tests you are already buying are not being converted into fixes.

The pattern in that grid is consistent across UK mid-market estates. Organisations are reasonably good at commissioning tests and reporting them upwards, and weak at the two things that determine whether the money produces security: closing findings with verification, and defining in advance what change should trigger the next test. Both are process problems rather than budget problems, and both should be fixed before frequency is increased.

PCI DSS penetration testing schedule — the clearest rules in UK compliance

If your business stores, processes or transmits payment card data, PCI DSS gives you the least ambiguous testing calendar of any framework a UK organisation is likely to encounter. Version 4.0.1 is the current standard and its Requirement 11 sets separate clocks for scanning and testing, which is where most confusion begins. The requirements below apply to the cardholder data environment and the systems connected to it, not to your whole estate — a distinction that has a direct effect on cost.

External penetration testing must be performed at least once every twelve months and after any significant infrastructure or application upgrade or change. Internal penetration testing carries the same clock: at least every twelve months and after significant change. Both must follow a documented methodology, cover the entire perimeter of the cardholder data environment and its critical systems, include application-layer and network-layer testing, and be performed by a qualified internal resource or a qualified third party with organisational independence from the systems being tested. Exploitable vulnerabilities and security weaknesses found must be corrected and the testing repeated to verify the corrections.

Segmentation testing is where the twelve-month assumption breaks. If you use segmentation to isolate the cardholder data environment from the rest of your network, the controls must be tested at least every twelve months if you are a merchant — and at least every six months for service providers, plus after any change to segmentation controls or methods. That six-month clock catches a surprising number of UK businesses who consider themselves merchants but meet the definition of a service provider because they handle card data on behalf of another entity. Multi-tenant service providers carry a further obligation to support their customers in performing external testing.

Vulnerability scanning runs on a different and faster clock, and it is not a penetration test. Internal scans are required at least every three months, with authenticated scanning where systems accept credentials, and high-risk and critical vulnerabilities resolved and rescanned. External scans must be run at least every three months by an Approved Scanning Vendor, with passing scans achieved, and repeated after any significant change until a passing result is obtained. The practical consequence for a UK card-handling business is a minimum annual programme of four ASV scans, four internal scan cycles, one external test, one internal test, at least one segmentation test, and an unbounded number of change-triggered repeats.

Two further points matter for planning. First, the standard requires testing after significant change but leaves the definition of significant to you — which means you must document that definition and be able to defend it to a Qualified Security Assessor. Second, the annual clock is a floor rather than a target; nothing in PCI DSS prevents a more frequent cadence, and assessors respond well to a programme that tests on change rather than on the anniversary of the last assessment.

What a properly paced testing year looks like

The timeline below is a realistic twelve-month programme for a mid-sized UK business with a public application, a Microsoft 365 tenant, some Azure infrastructure and a moderate release cadence. It assumes the split model from the cost table rather than a single annual engagement, and it deliberately places the heaviest test away from the busiest trading period and away from the month the certification body wants evidence, so the test is done for the right reason and the certificate is a by-product.

The shape of that year is the argument in miniature. Two human-led tests, four scan cycles, a small pool of change-triggered days, and two verified remediation windows. The longest period in which a newly introduced weakness could sit entirely unexamined by a human is about five months rather than eleven, and every engagement covers different ground.

Cyber Essentials Plus, ISO 27001 and the frameworks that do not name an interval

Outside the card industry, most of the frameworks UK businesses work to require testing without fixing a period, and understanding what each one actually asks for prevents both over-buying and a nasty surprise at audit.

Cyber Essentials Plus is the most commonly misunderstood. Certification is valid for twelve months and must be renewed annually, and the Plus tier adds an independent technical audit on top of the self-assessment. That audit is a verification exercise against the five controls — firewalls, secure configuration, user access control, malware protection and security update management — performed on a sample of devices, and it includes authenticated vulnerability scanning and tests of email and browser handling of malicious files. It is not a penetration test. There is no attempt to chain findings, no manual exploitation beyond the defined test cases, no application-layer testing of your own software, and no assessment of what an attacker achieves after initial access. Presenting a Cyber Essentials Plus certificate in answer to a customer question about penetration testing is a common and avoidable procurement failure.

ISO/IEC 27001 requires technical vulnerabilities to be identified, evaluated and addressed, and requires the effectiveness of controls to be evaluated — but it names no interval. In practice, certification bodies expect to see a documented testing policy, evidence that it was followed, and evidence that findings were remediated. An annual test with a written justification for the interval, a change-triggered clause and closed findings passes comfortably. An annual test with twelve open high-severity findings does not, regardless of how frequently you test.

UK GDPR Article 32 requires a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures. Again, no interval — but the ICO assesses the adequacy of measures with the benefit of hindsight after an incident, and “we tested annually because that is what we have always done” is a weaker position than a documented risk-based cadence that accounts for the sensitivity of the data and the rate of change in the estate.

The NIS Regulations place security and testing obligations on operators of essential services and relevant digital service providers, with the competent authority setting expectations sector by sector. Financial services firms supervised by the FCA and the Bank of England face the most demanding regime through threat-intelligence-led testing schemes such as CBEST and the industry-run STAR-FS framework, where engagements are intelligence-led, scoped by the regulator or the scheme, and run on multi-year cycles that sit on top of — not instead of — routine penetration testing. Firms operating in both the UK and the EU should also be tracking DORA, which requires digital operational resilience testing annually for basic testing and threat-led penetration testing on a three-year cycle for entities in scope.

NHS and public sector supply chains generally inherit their obligations from the contract rather than from a statute. The Data Security and Protection Toolkit, NHS supplier requirements and central government frameworks all reference testing, and the specific clause in your contract is the binding one. Read it before you scope, because a surprising number specify not just an interval but the accreditation the tester must hold.

Testing coverage in the average UK estate

Frequency is only meaningful against coverage, and coverage is where most programmes quietly fall short. The bars below show how much of a typical UK mid-market estate is actually included in a standard annual engagement. Anything below the line is a component that exists, is reachable, and has not been assessed by anyone.

The gradient in that list is the coverage problem stated plainly. Testing concentrates where it is easiest to scope and cheapest to buy — the perimeter and the front page of the main application — and thins out precisely where modern attacks land. Identity configuration, cloud permissions and build pipelines are where a competent attacker converts a single phished credential into a full compromise, and they are covered in fewer than a third of standard engagements. Increasing frequency without addressing that gradient means testing the same well-understood 88% more often.

This is also why the rotation plan matters more than the interval for many organisations. If your Entra ID configuration has never been assessed, a one-off identity-focused engagement will almost certainly return more actionable findings than a second perimeter test would. The same logic applies to the resilience side of the estate — controls you have never exercised are assumptions, which is the argument we made in detail for backup and restore testing.

Vulnerability scanning versus penetration testing — two different clocks

Most cadence arguments dissolve once the two activities are separated properly, because they answer different questions and therefore run on different intervals. A vulnerability scan is automated. It compares what it can see against a database of known issues — missing patches, outdated software versions, weak configurations, expired certificates, exposed services — and produces a list. It is fast, broad, cheap enough to run monthly or continuously, and it does not think. It cannot decide that two individually low-severity findings combine into a route to your finance system, and it cannot log in as a standard user and work out that changing a numeric parameter in a URL returns another customer’s data.

A penetration test is human-led. A tester holds a hypothesis about how your environment could be misused, tests it, adapts based on what they find, and chains findings together to demonstrate impact rather than presence. It is slower, narrower, more expensive per unit of coverage, and it finds the classes of problem that matter most: business-logic flaws, broken access control between user roles, privilege escalation paths, trust relationships between systems, and anything that requires understanding what your application is for.

The correct model is not to choose between them. It is to run scanning frequently enough that known-vulnerability exposure is measured in weeks rather than months, and to run testing frequently enough that design and logic problems are caught within an acceptable window. For most UK mid-market businesses that means monthly or continuous authenticated scanning and two to four human-led test cycles per year across rotating scope. Scanning tells you whether you are patching. Testing tells you whether your architecture holds. A programme with only the first has no idea whether it would survive a determined attacker; a programme with only the second is unpatched for eleven months at a time.

The distinction also matters commercially. A provider selling an automated scan with a lightly edited report as a penetration test is a real and persistent problem in the UK market, and the tell is usually the deliverable: a findings list ordered by CVSS score with no narrative of how the tester moved through the environment, no evidence of manual verification, and no false positives removed. A genuine test report describes a route, not just a list. If your annual test produces output that looks like a scan, your effective testing frequency is zero regardless of what you paid.

That figure is the single-annual-test default expressed as a proportion. Roughly three-quarters of UK small and medium businesses that test at all test exactly once. The interesting part is not the number itself but what separates the two groups: the businesses testing more than once are rarely larger or better funded, they simply have a written testing policy with a change-trigger clause in it. The policy is what converts an ad-hoc purchase into a programme, and it costs nothing to write.

Defining significant change — the 12-point trigger checklist

Every framework that requires testing after significant change leaves the definition to you, which means the definition is an artefact you must produce and defend. The list below is a workable starting point for a UK business with cloud infrastructure and a public application. Adopt it, edit the thresholds to match your estate, and put it in the testing policy so that the decision to test is made by the policy rather than by whoever notices.

1. A new public-facing service or hostname is published, including anything a marketing or product team stands up outside the normal change process. New attack surface is the clearest trigger there is.
2. A significant release to a public application that adds or alters authentication, authorisation, payment handling, file upload, data export, or any function that acts on behalf of another user.
3. A change to network segmentation — new VLANs, altered firewall zones, a site-to-site tunnel to a new partner, or the removal of a segmentation control. Under PCI DSS this is an explicit, named trigger.
4. A cloud migration or major re-platforming, including lift-and-shift moves to Azure or AWS, container platform adoption, and any change that moves data across a trust boundary.
5. A change to identity architecture — a new identity provider, federation with a partner tenant, conditional access policy rewrite, changes to privileged role assignment, or the introduction of a new single sign-on integration.
6. A new third-party integration with elevated permissions, particularly OAuth applications granted broad access to a Microsoft 365 or Google Workspace tenant, and any supplier granted network-level access.
7. Acquisition or inheritance of an estate. An acquired network joins your risk surface on the day the deal completes, usually with an unknown patch position and no shared documentation.
8. A material change to the remote access model — replacing a VPN, opening remote desktop access, deploying a new secure access service edge or ZTNA platform, or changing how contractors connect.
9. Introduction of a new data classification into an existing system, for example an application that begins handling special-category personal data or payment card data for the first time.
10. A significant infrastructure upgrade: domain controller replacement, hypervisor or storage platform change, a major firewall or load balancer migration, or an operating system generation change across a server fleet.
11. Any confirmed security incident, including phishing that resulted in credential compromise. Assurance that the attacker no longer has a route back is a testing question, not a monitoring question.
12. Twelve months since the last test of that scope, regardless of change. Time itself is a trigger, because the threat landscape moves even when your estate does not.

Scoring your own cadence — a readiness benchmark

To turn all of this into a decision, score your programme across five dimensions, each out of 100, then average them: interval (how long the maximum blind window is), coverage (how much of the estate any test has ever touched), trigger discipline (whether change-driven testing actually happens), remediation (whether findings close and are verified), and evidence (whether you can produce a policy and a history on request). The gauge below shows the median for UK mid-market organisations running a single annual external test with no written policy.

Forty-two is not a failing organisation. It is a competent one buying the wrong shape of assurance. The two dimensions dragging that score down are almost always trigger discipline and coverage, and both are fixable without increasing spend: write the trigger list, and rotate next year’s scope into ground that has never been tested. Interval usually scores middling, remediation scores well in firms with a functioning service desk, and evidence scores badly everywhere because the testing policy has never been written down.

A score above 70 generally means the programme is defensible to an auditor, an insurer and an enterprise customer without special pleading. Getting there rarely requires the continuous testing tier. It requires two engagements a year with rotating scope, monthly authenticated scanning, a trigger list that people actually follow, verified remediation, and a one-page policy. The organisations that jump straight to a platform-delivered continuous model without fixing remediation capacity usually score worse, not better, because they accumulate open findings faster than they close them.

Common penetration testing frequency mistakes to avoid

These are the recurring patterns that make testing programmes cost money without reducing risk. Every one of them is common in otherwise well-run UK businesses, and every one is a scheduling or scoping decision rather than a technical failure.

• Booking the test to satisfy a date rather than a risk. Testing the week before a certificate expires guarantees the report reflects the estate as it stood eleven months after the last meaningful assessment, and leaves no time to remediate before the assessor arrives.
• Repeating identical scope every year. The fifth consecutive perimeter test tells you almost nothing new. Rotating scope across a two-year cycle produces a fuller picture for the same annual spend.
• Treating Cyber Essentials Plus as a penetration test. It is an audited verification of five specific controls on a device sample. It does not assess your applications, your identity configuration or what an attacker achieves after initial access.
• Buying a scan and calling it a test. If the deliverable is a CVSS-ordered list with no narrative of how the tester moved through the environment and no false positives removed, you have bought scanning at consultancy prices.
• Shrinking scope to hold the price. Removing the authenticated portion of an application test, or excluding the internal network, is the most common way a quote gets to budget. It also removes the part of the test most likely to find something serious.
• No budget for retesting. A finding is not closed because a developer marked the ticket done. Without an independent verification retest there is no evidence of remediation, and no framework accepts self-attestation as equivalent.
• Testing faster than you can remediate. Increasing cadence while the remediation backlog grows converts a security programme into a documented list of unfixed problems, which is a materially worse position after an incident than not having tested.
• Excluding pre-production because it is “not live”. Staging environments routinely hold production data copies, weaker credentials and looser network controls, and they are frequently reachable from the internet. If it is exposed, it is in scope.

A worked example — from one annual test to a defensible cadence

A 140-person UK professional services firm with offices in Leeds and London held a single annual external penetration test, booked each February because the ISO 27001 surveillance audit fell in March. The estate had moved substantially in three years: file services and email had gone to Microsoft 365, a client portal built by an external development partner had launched and was now handling document exchange with clients, remote access had shifted from a hardware VPN to a cloud access platform, and an acquisition had added a 25-person office with its own domain that was trusted by the main one.

None of those changes triggered a test, because there was no policy that said they should. The February engagement covered the same external IP ranges it had covered in the first year, scoped from a document that had not been reviewed since. It returned a small number of medium findings, they were fixed, and the audit passed. On the metrics that mattered, the programme was invisible: the client portal had never been tested by anyone, the acquired domain had never been assessed, and the Microsoft 365 tenant configuration had never been looked at.

The change was not an increase in budget. The annual spend rose from roughly £4,200 to £12,800 — the difference between an annual baseline and a split cadence — but the programme changed shape rather than simply getting bigger. The February external test was kept and shortened. A second engagement was introduced in August with rotating scope, starting with the client portal under authenticated testing across all three user roles, and moving in the following year to internal and identity testing including the inherited domain trust. Monthly authenticated scanning was added across both offices. A twelve-point trigger list, close to the one above, went into a one-page testing policy signed off by the operations director, and eight consultant days were pre-purchased at the start of the year to be drawn down against triggers.

The first authenticated portal test returned findings of a class the perimeter tests had never been positioned to find: a document access control that relied on an unguessable identifier rather than an authorisation check, and an administrative function reachable by a standard client account through a direct URL. Both were remediated and verified within the same quarter. The trigger list was used four times in the first year, mostly for one-day scopes after portal releases and once after the identity platform migration.

We had been buying the same test for four years and calling it a security programme. What actually changed things was writing down what counts as a change worth testing — the rest followed from that one page.

The transferable point is not the specific schedule. It is that the firm stopped asking how often it was required to test and started asking what its longest blind window was, and what was inside it. That question has a different answer for every business, and it is the only version of the frequency question that produces a schedule worth defending.

Penetration testing frequency at a glance

The table below condenses the obligations, intervals and practical guidance covered above into a single reference. Where a framework names no interval, the recommended cadence is the one that is straightforward to defend to an assessor, an insurer or an enterprise customer.

How Cloudswitched approaches penetration testing cadence

Cloudswitched works with UK businesses to set a testing schedule that reflects the estate rather than the calendar — establishing the obligations that genuinely apply, mapping the attack surface that exists today against what was last assessed, agreeing a written definition of significant change, and building a rotation plan so each engagement covers ground the previous one did not. Where testing is already in place, that often begins with a review of the last report and the current scope document rather than a new engagement, because the fastest improvement available to most programmes is a change of shape rather than a change of budget. Testing sits alongside the rest of the security picture — identity, email, patching and recovery — and the schedule is designed so remediation capacity is part of the plan rather than an afterthought.

Frequently Asked Questions

How often should a UK business have a penetration test?

There is no single legal interval that applies to all UK businesses. The defensible answer depends on three inputs: the compliance obligations you carry, how fast your infrastructure and applications change, and how long a window of undetected exposure your organisation is willing to accept. A stable estate with no in-house development and no public applications can usually defend an annual external test supported by quarterly authenticated vulnerability scanning. A business shipping regular change, running cloud infrastructure or handling sensitive personal data should be running at least two human-led tests a year across rotating scope, plus testing after significant changes. The interval matters less than whether the schedule is written down and followed.

Is an annual penetration test a legal requirement in the UK?

No. No general UK statute requires an annual penetration test. UK GDPR Article 32 requires a process for regularly testing and evaluating the effectiveness of security measures without defining an interval, and ISO 27001 requires a testing policy without naming a period. Hard intervals come from specific regimes — PCI DSS for card data, sector requirements under the NIS Regulations, and supervisory schemes in financial services — or from customer contracts and insurance conditions. In practice, contractual and insurance obligations are the strictest requirement most UK SMEs actually carry, and they are the ones least often read before renewal.

What does PCI DSS require for penetration testing frequency?

PCI DSS 4.0.1 requires external and internal penetration testing of the cardholder data environment at least once every twelve months and after any significant infrastructure or application upgrade or change. Segmentation controls must be tested at least every twelve months for merchants and at least every six months for service providers, plus after any change to segmentation. Separately, vulnerability scanning runs quarterly — internal scans at least every three months and external scans at least every three months through an Approved Scanning Vendor with passing results. Exploitable findings must be corrected and testing repeated to verify the correction.

What is the difference between vulnerability scanning and penetration testing?

A vulnerability scan is automated. It compares what it can see against a database of known issues and returns a list of missing patches, outdated versions and weak configurations. It is cheap enough to run monthly or continuously and it covers breadth. A penetration test is human-led: a tester forms hypotheses about how the environment could be misused, verifies them manually, and chains findings together to demonstrate real impact. Testing finds business-logic flaws, broken access control between user roles and privilege escalation paths that scanners cannot reason about. They are complementary, run on different clocks, and neither substitutes for the other.

Does Cyber Essentials Plus count as a penetration test?

No. Cyber Essentials Plus is an annual, independently audited verification of the five Cyber Essentials controls — firewalls, secure configuration, user access control, malware protection and security update management — carried out on a sample of devices, including authenticated vulnerability scanning and defined tests of email and browser handling of malicious files. It does not include manual exploitation, application-layer testing of your own software, assessment of identity configuration, or any evaluation of what an attacker achieves after gaining initial access. Presenting a Cyber Essentials Plus certificate in response to a question about penetration testing is a common procurement error.

What counts as a significant change that should trigger a test?

The frameworks require testing after significant change but leave the definition to you, so you must document it. A practical list includes new public-facing services, releases that alter authentication, authorisation, payments or file handling, changes to network segmentation, cloud migrations, changes to identity architecture or conditional access, new third-party integrations holding elevated permissions, acquisitions, changes to the remote access model, new data classifications entering an existing system, major infrastructure upgrades, and any confirmed security incident. Most triggers justify one to three consultant days against a narrow scope rather than a repeat of the full annual engagement.

How much does it cost to test more than once a year?

UK penetration testing day rates in 2026 typically run between £700 and £1,200 per consultant day, so a small external infrastructure test of four to five days sits around £3,500 to £5,500. Splitting a programme into two smaller engagements six months apart usually costs one and a half to two times the single annual test rather than double, because scoping, reporting and project management overheads are partly reused and providers discount committed multi-test contracts. Budget separately for remediation retests and for the internal engineering effort to fix findings, which is normally larger than the testing fee itself.

Should the same provider test every year?

There are arguments both ways. Retaining a provider builds familiarity with the estate, reduces scoping time and makes year-on-year comparison meaningful. Rotating providers introduces a different methodology and a different set of instincts, and frequently surfaces findings the incumbent had stopped looking for. A common compromise is to keep one provider for the recurring compliance-driven engagement and bring in a second for a rotating specialist scope such as cloud configuration, identity or application testing every second or third year.

Do we need to retest after fixing the findings?

Yes, if the fixes are to count as evidence. A finding marked closed by the team that implemented the change is self-attestation, and no assurance framework treats that as equivalent to independent verification. PCI DSS explicitly requires that exploitable vulnerabilities are corrected and testing repeated to verify the correction. Check whether your provider includes a remediation retest within a defined window — commonly 30 to 90 days — and if not, budget one to two additional consultant days per engagement for it.

Is continuous penetration testing worth it for an SME?

For most UK SMEs, no — not as a first step. Platform-delivered continuous testing generates findings faster than a small team can remediate them, and a programme that accumulates open findings is in a weaker position after an incident than one that tests less often and closes everything it finds. The sequence that works is to fix remediation and verification first, add monthly authenticated scanning, move to two rotating-scope tests a year, and only then consider a continuous model once there is a functioning secure development lifecycle and the capacity to fix at the rate issues arrive.

How long does a penetration test take from booking to report?

For a typical UK mid-market engagement, allow one to two weeks for scoping and contracting, two to four weeks of lead time to a start date with a busy provider, three to five days of testing for a standard external or application scope, and five to ten working days for the report and quality review. Six to eight weeks from decision to final report is realistic. That lead time is the main reason change-triggered testing gets skipped, and it is why pre-purchasing a pool of consultant days at the start of the year is worth the commitment.

What should we do between penetration tests?

Run authenticated vulnerability scanning at least monthly across internal and external assets, monitor your external attack surface for new hosts and services appearing without going through change control, keep patching to a defined SLA for internet-facing systems, and review identity configuration — privileged role assignment, conditional access, and third-party application consents — on a regular cycle. Email remains the most common initial access route, so the controls covered in our guide to Microsoft 365 email security do more to reduce real-world risk between tests than any additional scanning would.

Related reading

Further guides covering the controls, accreditation questions and resilience testing that sit alongside a penetration testing programme.

• CREST vs Standard Penetration Testing: What UK Buyers Are Actually Paying For
• Zero Trust Network Access (ZTNA): A UK Business Guide
• Microsoft 365 Email Security: Stopping Phishing and Business Email Compromise
• Backup and Restore Testing: A UK Business Guide
• Azure Disaster Recovery and Failover Planning: A UK Guide