Penetration testing frequency is the question every board eventually asks and almost nobody answers with a number they can defend. The honest answer is that “once a year” is a floor, not a schedule, and that the calendar date matters far less than what changed in your estate since the last report was signed off.
Most businesses arrive at their cadence by accident. An auditor asked for a report, a customer’s security questionnaire demanded one, or an insurer wanted evidence at renewal. The test gets booked, the findings get filed, and twelve months later the same scope is tested again while three new applications, a cloud migration and a merged subsidiary sit outside it entirely.
This guide sets out how to decide your own cadence: the annual baseline and where it comes from, the change events that should force an unscheduled round, what each compliance framework actually demands, realistic costs at each rhythm, and how to build a calendar that survives a year of competing priorities. It is written for organisations that buy penetration testing services rather than run an in-house red team, where the person booking the test also owns the helpdesk and the backups.
Table of contents
- What penetration testing frequency really measures
- How often should a business conduct penetration testing?
- Change triggers that force an unscheduled penetration testing round
- Penetration testing frequency by compliance framework
- Where vulnerability scanning stops and penetration testing starts
- What penetration testing costs at each frequency
- Building a penetration testing calendar that survives the year
- Signs your penetration testing rhythm is wrong
- Frequently asked questions about penetration testing
- References
What penetration testing frequency really measures
A cadence is not a compliance chore. It is a statement about how quickly your organisation believes its own security posture goes stale, and that belief should be evidence-based rather than inherited from whoever set the budget three years ago.
A penetration testing report is a snapshot with a short shelf life
A penetration testing report describes the state of a system on the day it was tested. The moment a developer merges a branch, an administrator opens a firewall rule or a supplier pushes an update, that snapshot starts to age. Penetration testing frequency is really a question about decay: how many days of change can accumulate before the report stops describing reality?
For a static estate with quarterly patching and no in-house development, the answer might be a year. For a product team shipping twice a week, the answer is closer to a fortnight, which is precisely why continuous approaches exist for that profile.
Frequency is a risk decision, not a purchasing one
The instinct is to set the cadence from the budget. The better order is to set it from exposure: what an attacker could reach, what it would cost you if they did, and how fast that attack surface moves. Only then does price enter the conversation.
That reframing changes who owns the decision. A penetration testing cadence chosen by finance produces the cheapest defensible number. A cadence chosen alongside IT security and risk owners produces a schedule that maps onto the things that would actually hurt.
The three inputs that decide your penetration testing rhythm
Every sensible schedule comes down to three variables: rate of change in the estate, the sensitivity of the data behind it, and the compliance obligations attached to the sector. Score each of those honestly and the right frequency usually becomes obvious before anyone opens a price list.
Change rate is the one most often understated. Firms describe themselves as stable, then list four SaaS rollouts, an office move and a payroll migration when asked what happened last year.
How often should a business conduct penetration testing?
The defensible baseline for most organisations is at least once every twelve months, plus an additional test after any significant change. That pairing — a fixed annual round and an event-driven round — is the pattern almost every standard and regulator converges on.
The annual baseline and where it comes from
The twelve-month floor is not arbitrary. It mirrors the audit cycle most organisations already run, it matches insurance and certification renewal periods, and it is the interval written into PCI DSS and the UK government’s own penetration testing standards. The National Cyber Security Centre frames the exercise as analogous to a financial audit: an independent check that the controls you believe are working actually are.
Treating twelve months as a ceiling rather than a floor is where most programmes go wrong. An annual round tells you whether last year’s fixes held. It says nothing about the six months of change that followed the report.
Why “annual only” fails for most modern estates
The average mid-sized business now runs a hybrid estate: an on-premise remnant, two or three cloud tenancies, a dozen SaaS integrations and at least one customer-facing application under active development. That surface changes weekly. An annual penetration testing round leaves an eleven-month blind spot in the parts that move fastest.
The pragmatic fix is not necessarily to test everything more often. It is to split the scope: an annual full-estate round, and a shorter, cheaper cycle aimed only at the components that change.
The cadence most organisations should actually land on
For a typical UK business without a regulated data set, the workable pattern is an annual external and internal infrastructure round, per-release penetration testing on any public-facing application, and an event-driven test whenever the change triggers below are hit. That usually resolves to two or three engagements a year rather than one large annual exercise.
Higher-risk sectors compress that. Financial services, healthcare and anyone processing large volumes of payment data usually move to quarterly rounds or a continuous model, because the cost of a missed exposure dwarfs the difference in testing fees.
Recommended penetration testing frequency by risk tier
| Risk tier | Typical profile | Baseline cadence | Plus |
|---|---|---|---|
| Low | Under 50 staff, no custom software, no regulated data | Annual | After any significant change |
| Moderate | 50-250 staff, one customer-facing app, hybrid cloud | Twice yearly | Per major release |
| Elevated | Payment data, health data, enterprise customers | Quarterly | Segmentation checks, retests |
| High | Regulated finance, critical supplier, weekly releases | Continuous or monthly | Annual deep-dive round |
Change triggers that force an unscheduled penetration testing round
The event-driven half of the schedule is the half that gets skipped, because nobody owns it. A calendar entry has an owner; “after any significant change” has none unless you write the triggers down and attach them to your change process.
What counts as a significant change
The phrase appears in nearly every standard and is defined in almost none of them. A workable definition: any change that alters what an attacker can reach, what they could do once inside, or who is allowed through the door. That covers new internet-facing services, network re-segmentation, authentication changes and major application releases.
It deliberately excludes routine patching, content updates and configuration tweaks inside an already-tested boundary. Without that exclusion, every schedule collapses under its own weight within a quarter.
The trigger list worth adopting
Write these into your change-management process so the question is asked automatically rather than remembered occasionally. Each one materially moves the attack surface, and each is a defensible reason to book an extra round of penetration testing outside the annual cycle.
- A new public-facing application, API or customer portal goes live
- Firewall, VPN or network segmentation is redesigned
- Authentication changes: a new identity provider, single sign-on, or a shift in MFA policy
- A cloud migration, tenancy merge or major infrastructure move completes
- An acquisition brings an unfamiliar estate inside your perimeter
- A serious incident, or a near miss that exposed an unknown path
- A major customer contract imposes new security obligations
Mergers, migrations and the inherited estate
Acquisitions deserve their own mention because they fail so predictably. The acquired network is connected to yours for practical reasons long before anybody has assessed it, and the annual test scope is not updated until the following year. Running scoped penetration testing on the inherited estate before the networks join is far cheaper than discovering the problem afterwards, and it belongs alongside the wider cyber due diligence work.
Migrations carry the same risk in a quieter form. A lift-and-shift into a cloud tenancy rarely reproduces the old firewall rules exactly, and the gaps it opens are invisible from the inside.
Estimated change events per year that warrant a retest
These are planning figures for a typical 200-seat business with one customer-facing product, not survey data — use them to sanity-check whether an annual-only cadence is realistic for your estate.
Penetration testing frequency by compliance framework
Compliance is the reason most first tests get booked, so it is worth knowing exactly what each framework demands before you over-buy. Several are far less prescriptive than vendors imply, and one is considerably stricter.
PCI DSS is the prescriptive one
PCI DSS v4.0.1 requirement 11.4 is the clearest rule in the field. Internal and external penetration testing is required at least every twelve months and after any significant infrastructure or application change. Segmentation controls must be validated at least annually for merchants and at least every six months for service providers.
That six-month segmentation rule catches organisations out repeatedly. It is a separate obligation from the main annual round, and being a service provider is a question of role, not size.
ISO 27001 and SOC 2 ask for evidence, not a date
Neither ISO 27001 nor SOC 2 mandates a specific interval. Both require you to manage technical vulnerabilities and to demonstrate that your controls are effective, which auditors overwhelmingly interpret as annual penetration testing plus evidence that findings were remediated. If your ISO 27001 readiness work has already mapped your controls, the scope of the test usually writes itself.
The trap is assuming that “no stated interval” means “no expectation”. An auditor who sees a two-year gap will ask what changed in between, and the risk assessment had better answer.
Cyber Essentials, NIS2 and sector regulators
Cyber Essentials Plus is a technical verification rather than penetration testing, and its annual assessment does not substitute for a real engagement. NIS2 and the UK’s incoming resilience legislation push regulated and essential-service operators towards documented, risk-based testing regimes, which in practice means more than annual for anything critical.
Sector regulators go further still. Financial services firms in scope of threat-led testing schemes face intelligence-driven exercises on a multi-year cycle, layered on top of ordinary testing rather than replacing it.
What each framework actually requires
| Framework | Stated interval | Event trigger | Practical reading |
|---|---|---|---|
| PCI DSS v4.0.1 | Every 12 months | Any significant change | Plus 6-monthly segmentation tests for service providers |
| ISO/IEC 27001 | Not specified | Risk-assessment driven | Annual is the auditor default |
| SOC 2 | Not specified | Control-effectiveness driven | Annual, with remediation evidence |
| Cyber Essentials Plus | Annual assessment | Recertification | Not a substitute for a real test |
| NIS2 / UK resilience rules | Risk-based | Significant change or incident | Documented regime, usually more than annual |
| UK government services | Every 12 months | Significant service change | CHECK-scheme testers for public sector |
Where vulnerability scanning stops and penetration testing starts
A great deal of wasted spend comes from confusing two different activities. Scanning is cheap, automated and continuous. Penetration testing is expensive, human and periodic. They answer different questions, and using one to justify skipping the other is the most common mistake in the whole discipline.
Scanning tells you what is exposed
An authenticated vulnerability scan enumerates known weaknesses against a signature database. Run it weekly or continuously, because it costs almost nothing per run and catches the missing patch that appeared on Tuesday. What it cannot do is chain three low-severity findings into a domain compromise, or notice that your password reset flow leaks account existence.
Scanning is therefore the thing you increase when budget is tight, because it raises your floor between the periodic rounds without changing your penetration testing frequency at all.
Penetration testing tells you what an attacker could actually do
The value of a human tester is in the logic: business rules, authorisation boundaries, chained weaknesses and the assumptions your developers made without writing down. No scanner finds a checkout flow that lets a customer alter the price in transit. That gap is why the annual round survives even in organisations scanning continuously.
PTaaS and continuous penetration testing
Penetration testing as a service blurs the boundary by keeping a tester engaged on a subscription rather than a project. For fast-moving product teams it is often better value than two large annual engagements, because findings arrive while the code is still fresh in a developer’s mind.
It is not automatically cheaper, and it does not remove the need for a periodic deep-dive with a fresh team. Rotating provider every second or third round is worth the administrative friction; different testers find different things.
Scanning, testing and red teaming compared
| Aspect | Vulnerability scan | Penetration test | Red team exercise |
|---|---|---|---|
| Question answered | What is exposed? | What could be exploited? | Would we detect it? |
| Cadence | Weekly or continuous | Annual to quarterly | Every 1-3 years |
| Driven by | Signature database | Human methodology | Threat intelligence |
| Typical duration | Minutes to hours | 3-15 days | 4-12 weeks |
| Finds logic flaws | No | Yes | Yes |
| Tests your response | No | Rarely | Yes |
What penetration testing costs at each frequency
Cadence conversations stall on price, usually because the quoted number covers only the testing days. Budget the whole cycle and the comparison between annual and quarterly changes shape considerably.
Day rates and what drives them
UK penetration testing engagements are priced in tester-days, and the day rate moves with accreditation, specialism and demand. A short external infrastructure assessment for a small estate is a few days of work; a complex web application with multiple user roles and an API behind it is comfortably two weeks. Scope is what you actually control, and a tightly-defined scope is the single biggest lever on cost.
Cheap quotes usually indicate an automated scan with a report template attached. Ask how many tester-days are included and who holds the certifications, because those two answers explain most price differences.
The costs that never appear in the quote
Remediation engineering time, a retest to prove fixes worked, internal coordination and the developer hours lost to context-switching all land outside the invoice. A useful planning rule is that the true cost of a round is roughly double the tester fee once internal effort is counted.
Annual versus quarterly, honestly compared
Quarterly rounds are not four times the price of one annual round. Scoping is reusable, the provider already knows the estate, and each engagement is smaller. The realistic uplift is closer to double, in exchange for cutting your exposure window from twelve months to three.
The figures below are indicative UK planning ranges for a mid-market estate, not quotations — use them for budget conversations, then get a scoped proposal.
Where the money actually goes in one engagement
Roughly a fifth of a typical engagement is scoping and reporting rather than hands-on testing, which is why splitting one large round into four small ones costs more than the tester-days alone suggest.
Building a penetration testing calendar that survives the year
A cadence written in a policy document and never converted into diary entries does not exist. The organisations that keep their schedule are the ones that treat it like a payroll run: booked in advance, owned by a named person, budgeted before the year starts.
Fix the annual round to a date, not a season
“Q3” becomes October, then December, then next year. Pick a month, book the penetration testing provider twelve weeks ahead, and anchor it to something immovable — the month before your certification audit is ideal, because it gives you time to remediate before the auditor arrives.
Reserve budget for the unscheduled rounds
The event-driven half of your penetration testing schedule needs its own budget line, or it competes with the annual round and loses. A reasonable reserve is one additional scoped engagement per year for a moderate-risk business, released against the trigger list rather than spent by default.
Decide the remediation window before the report lands
Agree in advance how quickly each severity must be fixed, and who signs off exceptions. Without that, findings sit in a backlog until the next round rediscovers them, and you pay twice to learn the same thing. Pair the schedule with a rehearsed response capability — a cyber tabletop exercise is the cheapest way to find out whether your team could act on a critical finding at short notice.
Always book the retest
A finding is not closed because a ticket says so. The retest is a small fraction of the original cost and is the only evidence an auditor, insurer or enterprise customer will actually accept. Build it into the original purchase order so it never becomes a separate approval battle.
Send the findings to people who can actually act
A technical report emailed to one engineer is a filing exercise. Split the output: a severity-ranked ticket list for the people fixing things, and a one-page summary for the person who controls the budget. Penetration testing earns its cost at the point where a finding becomes a funded change, not at the point the PDF arrives.
Give the summary a standing slot in a monthly management meeting for the quarter after each round. Findings that are reviewed in public get fixed; findings that live in an inbox get rediscovered next year at full price.
Rotate providers, keep the scope stable
Changing penetration testing provider every second or third round surfaces different findings, because methodology and instinct vary between teams. Keep the scope definition constant while you do it, or you will not be able to tell whether the new findings are new weaknesses or simply new eyes.
Signs your penetration testing rhythm is wrong
You rarely need a formal review to know the cadence has drifted. The symptoms are recognisable, and each maps to a specific correction rather than a general instruction to spend more.
The same findings keep reappearing
If round three repeats round two, your problem is remediation capacity, not frequency. More frequent penetration testing will simply generate the same list faster. Fix the ownership and the fix-window first.
The scope has not changed in three years
An unchanged scope in a changing estate means you are testing a shrinking fraction of your exposure with each passing year. Re-scope annually from an asset inventory and a cybersecurity risk register, not from last year’s statement of work.
Findings arrive after the release, not before
If reports consistently land once the code is in production, the schedule is bolted to the calendar rather than the delivery cycle. Move to per-release testing for the application, and keep the infrastructure round annual.
Nobody can say when the last test was
An unanswerable question is itself the answer. When the report cannot be found and the date is disputed, the programme is informal, and the first fix is a register of tests, scopes, dates and remediation status — not a bigger budget.
Your customers are testing you instead
Enterprise customers increasingly demand evidence before signing. When their questionnaire drives your schedule, you have outsourced a risk decision to your buyers, and you will always be reacting. Getting ahead of that is also the cheapest way to shorten sales cycles.
Frequently asked questions about penetration testing
Is once a year enough for a small business?
For a genuinely static estate with no custom software and no regulated data, an annual round plus continuous scanning is defensible. Add an event-driven test the moment you publish anything new to the internet.
Does a passing penetration testing report mean we are secure?
It means no significant exploitable weakness was found within that scope, in that window, by that team. It is evidence, not a guarantee, which is exactly why the cadence matters more than any single result.
Should we test after every software release?
Full rounds after every release are unaffordable for most teams. Test major releases that change authentication, data handling or the external surface; cover the rest with automated scanning and code review.
How long does a test take from booking to report?
Allow four to twelve weeks from enquiry to final report for a scoped engagement: two to eight weeks of lead time, three to fifteen days of testing, then a week or two for reporting and debrief. Regulated or threat-led exercises take considerably longer.
Can we use the same provider every year?
Yes, and the continuity helps. Rotate every second or third cycle anyway so that a fresh methodology gets applied to a familiar estate, and keep the scope definition stable so the results stay comparable.
What should we do first if we have never had penetration testing?
Start with an external infrastructure assessment, because that is the surface an opportunistic attacker meets first. Fix what it finds, then widen the scope to internal networks and applications on the next round.
References
NCSC — Penetration Testing Guidance
NCSC — CHECK Penetration Testing Scheme
PCI Security Standards Council — Document Library
NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment
ISO/IEC 27001 — Information Security Management Systems
OWASP Web Security Testing Guide
CREST — Accreditation for Penetration Testing Providers
