Three regimes, routinely confused
UK financial services carries several testing obligations of different shapes, and which apply to you depends on what you are and what your supervisor has said.
CBEST
Firms and financial market infrastructures core to UK financial stability, selected by their supervisor
A threat intelligence-led assessment run under Bank of England oversight, established in 2014 and used within the supervisory strategies of the PRA, the Financial Market Infrastructure Directorate and the FCA. Threat intelligence about real adversaries drives a red team against important business services, deliberately less constrained than routine testing.
This is not a DDoS test and a DDoS test does not satisfy it. A CBEST engagement is a targeted intrusion exercise; availability under hostile load is a different question with different methods. If a vendor offers you CBEST-compliant DDoS testing, they are describing something that does not exist.
STAR-FS
A wider set of firms, within the PRA and FCA supervisory toolkit
Simulated targeted attack and response assessments for financial services. The same intelligence-led philosophy applied more broadly than CBEST, assessing the cyber resilience of important business services.
Same answer. Intelligence-led attack simulation, not availability testing. Useful to know the distinction exists, because firms told they are in scope for STAR-FS sometimes assume it covers everything.
Operational resilience (FCA and PRA)
Broadly, across UK financial services
Identify the business services whose disruption would cause intolerable harm, set an impact tolerance for each, map the people, processes and technology beneath them, and test against severe but plausible scenarios until you can show, rather than argue, that you remain within tolerance.
This is where DDoS testing actually belongs, and where most firms have a real gap. A volumetric or application-layer attack on an internet-facing service is a textbook severe but plausible scenario, and it is one of the few that can be exercised rather than tabletopped.
Impact tolerance is measured in time. So is a DDoS test.
An impact tolerance is a duration: the longest a service can be disrupted before the harm becomes intolerable. Firms state those durations to their supervisors, and then face the harder question of how they know.
Most scenario testing produces findings that have to be argued into a time estimate. A workshop concludes that a failure would be serious, and somebody converts that into a number. A DDoS test does not need the conversion step. It produces the measurement directly: how long before the attack was detected, how long before mitigation engaged, what got through while it did, and how long the service took to return to normal once the traffic stopped.
Those are the same units as the tolerance. That is an unusually direct piece of evidence, and it is available for one of the few disruption scenarios that can be exercised safely against a real environment rather than imagined.
It also tends to surface the uncomfortable finding. A tolerance of two hours is a reasonable-sounding statement until a test shows mitigation taking longer than that to engage on the path that actually matters. Better to learn it from an exercise you scheduled. More on the mechanics in testing without disrupting production and measuring resilience.
Common questions
Is DDoS testing part of CBEST?
No. CBEST is a threat intelligence-led assessment: intelligence on real adversaries drives a red team against your important business services, under Bank of England oversight. It is an intrusion exercise. A DDoS test measures whether a service stays available when traffic turns hostile, which is a different question answered with different methods. The two are complementary and neither substitutes for the other.
So where does DDoS testing fit the UK regime?
In the operational resilience framework. You are required to set an impact tolerance for each important business service and to test against severe but plausible scenarios. For any service delivered over the internet, a denial-of-service attack is among the most plausible disruption scenarios there is, and unlike most scenarios it can be genuinely exercised against the real environment rather than discussed in a workshop.
Why does that matter more than it sounds?
Because impact tolerance is expressed in time: the maximum tolerable duration of disruption to a service before harm becomes intolerable. A DDoS test result is expressed in the same units. Time to detect, time for mitigation to engage, time to recover once the attack stops. Very few exercises produce a number you can set directly against a tolerance you have already stated to your supervisor. Most produce findings that then have to be argued into a time estimate.
Our supervisor has not told us we are in scope for CBEST. Does that mean we are fine?
It means CBEST specifically does not apply, which is a narrower statement than it sounds. The operational resilience requirements apply broadly regardless, and they are the ones that ask whether you can evidence staying within tolerance. Firms sometimes read not being selected for CBEST as an absence of testing obligations, and that is the wrong inference.
We already do penetration testing. Is that enough?
It covers a different failure mode. Penetration testing looks for a way in. Denial of service assumes no way in is needed and asks whether the service survives being reachable. A firm can pass every penetration test it commissions and still be unable to state, with evidence, how long its payment service stays up under a sustained flood. That gap is exactly what an impact tolerance is meant to close.
How does this relate to DORA?
They are separate instruments with a similar shape. DORA is EU law and its Article 26 threat-led penetration testing is the closest analogue to CBEST, while its Articles 24 and 25 resilience testing is the closest analogue to the UK operational resilience regime. A group operating in both will find the testing work overlaps heavily even where the legal obligations do not, which is worth exploiting rather than duplicating.
Evidence in the units your tolerance is written in
We are an independent testing company, tied to no mitigation vendor. Our method is simultaneous multi-vector testing that adapts in real time to your defences rather than replaying a script, which is Patent-Pending, and the report is built to be handed to an engineer as a work list and to a supervisor as evidence.
This page describes our reading of the UK framework as at August 2026 and is not legal advice. Whether CBEST or STAR-FS applies to your firm is a matter for your supervisor, and your impact tolerances are yours to set.