Consider a hosting provider that had decided, reasonably enough, that the Cyber Security and Resilience Bill was somebody else’s problem, then received a resilience questionnaire from an in-scope water utility client: mitigation architecture by layer, time-to-mitigate definitions, escalation contacts, recent post-attack reports. No statutory duty applied to that provider. The questionnaire did not care.
That is how this regime will actually arrive for most organisations. Not through a letter from a regulator, but through a procurement form from a customer who is in scope and needs to show their own auditor that the availability of their service does not quietly depend on an unmanaged DNS zone and a reseller’s promise.
Where the Cyber Security and Resilience Bill stands and what it changes
The Cyber Security and Resilience (Network and Information Systems) Bill is a Government Bill that amends and widens the Network and Information Systems Regulations 2018, the UK’s post-Brexit inheritance of the original EU NIS Directive. It was introduced in the House of Commons in November 2025 and remains under parliamentary scrutiny at the time of writing; progress can be followed on the UK Parliament Bills site. Much of the operational detail, including sector thresholds and the shape of regulator guidance, will land later in secondary legislation.
Three structural shifts matter if you own uptime rather than policy.
Scope widens. Managed service providers and parts of the digital supply chain are brought inside a perimeter that previously centred on operators of essential services and a narrow set of digital service providers. Regulator powers strengthen, with a more serious penalty regime and more direct information-gathering. And incident reporting stops being a data-breach reflex: the trigger is framed around disruption to the service, with a two-stage process in the Bill as introduced (an initial notification within 24 hours of becoming aware, then a fuller report within 72 hours), plus a duty to inform affected service users in defined circumstances. Confirm the final wording against the Act and your sector regulator’s guidance when it exists.
Waiting for commencement is the obvious mistake. Scope assessment, supplier mapping and evidence collection are slow, political and dependent on third parties answering emails. Teams that start when the regulations bite will spend the implementation window chasing a reseller for a scrubbing contract they cannot produce.
This is not legal advice. Final duties depend on the text as enacted.
Who is likely to be in scope, and the supplier question most firms get wrong
A first-pass scope test on your own entity is quick. Do you operate an essential service in energy, water, transport, health, digital infrastructure or drinking water? Do you provide online marketplaces, search engines or cloud computing services at a size above the existing thresholds? Do you sell managed IT, security operations, hosting, network management or similar services where you have ongoing access to a customer’s network and information systems? If yes to the third question, assume you are in the frame and check the detail later.
The second test is the one teams skip. You may be comfortably out of scope and still be pulled in contractually, because an in-scope customer has a supply chain duty and will discharge it by pushing requirements down to you. Scope creeps through procurement faster than it creeps through the sector list.
Resale chains make this worse. The provider on your invoice may be reselling another company’s transit, filtering and scrubbing capacity, which means the party who can actually change a mitigation policy mid-attack is two contracts away from you and has never heard your company name. Assurance has to be chased to the operating party, not the reseller, and that is an awkward conversation to have for the first time during an incident. Our breakdown of what ISP-level DDoS protection covers and does not cover is a useful reference for working out where the real boundary sits.
Practical step, and it fits on one page: map who terminates your traffic, who operates your authoritative DNS, who runs your edge or proxy, and who is authorised to change a filtering policy at 03:00 without waking you. Names and companies, not product logos.
Why denial-of-service sits at the centre of the Bill’s resilience duties
The NIS framing has always been about continuity of service, not just confidentiality of data. Security of network and information systems means availability, integrity and authenticity as well as secrecy. A distributed denial-of-service (DDoS) attack is the purest availability event there is: no data leaves, nothing is encrypted, and the service is simply gone.
Here is the part that changes internal behaviour. If the reporting trigger hinges on actual or potential significant disruption rather than confirmed loss of data, an attack you absorbed can still be reportable. A 400 Gbps flood that scrubbing handled with no customer impact may be a near miss with obvious potential for significant disruption. A 12 Mbps application-layer flood against a login endpoint that took checkout offline for 40 minutes almost certainly crosses a service-impact threshold, despite looking like noise on a bandwidth graph.
Most DDoS runbooks classify events by traffic volume. Volume is the wrong axis for this duty. Without a written classification step that maps an event onto a regulatory threshold, the notification decision defaults to whichever engineer happens to be on call at 02:40, and that engineer is busy.
Build an incident clock. It starts at detection, not at the post-incident review, and it carries named decision owners for each stage: who declares, who assesses reportability against written criteria, who signs the notification, who informs affected customers. Regulators ask when you knew. The honest answer should not be a reconstruction from Slack scrollback. The NCSC’s guidance on hacktivist DDoS activity and a seven-step response is a reasonable starting template to adapt.
Three surfaces a regulator-ready control set has to cover
“Appropriate and proportionate”is doing enormous work in the legislation, and no regulator will hand you a shopping list. Assessed honestly, denial-of-service resilience lives on three surfaces, and a control set that covers two of them is not covered.
Network and transport
Volumetric and protocol floods: UDP reflection, amplification via exposed services, SYN floods, carpet bombing across a prefix. The questions that matter are upstream capacity, whether filtering happens before your transit saturates, and whether mitigation is always-on or diverted on demand. Capacity marketing is the least informative part of this; our guide to judging scrubbing capacity claims covers why headline Tbps figures tell you very little about your own path.
Application layer
Low-volume HTTP floods, API abuse, credential-stuffing against login pages, expensive search queries repeated 50 times a second. These fail long before your pipe does, because the constraint is database connections and application threads, not bandwidth. Rate-limiting by endpoint, bot management and caching policy belong in the evidence file alongside the network layer.
Authoritative DNS
The layer almost nobody documents. Teams write up the scrubbing contract and the WAF, then leave authoritative DNS sitting with a registrar’s free bundled service that was never tuned, carries no service level agreement (SLA) worth the name and offers no escalation path beyond a web form. Lose authoritative DNS and every other control becomes irrelevant, because the service is unreachable regardless of how healthy the origin is. Anycast footprint, provider diversity, TTL strategy and a tested escalation contact are the minimum for anyone claiming proper DNS DDoS attack protection as part of a resilience posture.
Origin exposure, documented as a risk
When a proxy-based defence fails, attack size is rarely the reason. A leaked origin address is. Consider the retailer with a reverse proxy in front of its website that was hit by a modest application-layer flood aimed straight at the origin IP, pulled from historical DNS records. The edge saw nothing. The origin fell over. The incident log recorded a service outage with no corresponding spike at the proxy, which is a confusing artefact to explain to a regulator six months later.
Origin addresses leak through outbound mail headers, stale A and MX records, certificate transparency logs, old monitoring and status endpoints, and development subdomains nobody retired. A control set presented as appropriate is not credible if anyone on the internet can reach the origin directly. It is an easy audit question to ask and almost impossible to bluff.
Deployment model as a recorded decision
Reverse proxy, BGP-based scrubbing with GRE or cross-connect return, hosting-level filtering: each fits different traffic, different protocols and different tolerance for latency. Choose deliberately and write down why. Most organisations inherited their model from whoever sold them hosting.
Evidencing appropriate and proportionate measures without a sales deck
An evidence file that survives contact with an auditor holds five things: an architecture diagram broken out by surface (network, application, DNS); a written mitigation design rationale; a tested escalation path with names and out-of-hours routes; attack reports from real events with vector breakdowns; and the post-incident actions actually completed, with dates.
Always-on versus on-demand belongs in that rationale. It is a design decision, not a product tier. On-demand is cheaper in standby but adds detection and diversion time before traffic reaches scrubbing, typically minutes rather than seconds once BGP convergence is counted. Always-on removes the delay and adds steady-state cost and some latency in the path. Neither is correct in the abstract. Recording which trade-off you chose, for which services, and why, is stronger evidence of proportionality than any vendor capacity figure you could paste into an annexe.
Then there is the word “managed”. It decides whether a mitigation service is a control or a line item on an invoice. Does the contract include onboarding and rule tuning, or did you get a dashboard? Who is authorised to change policy during an attack without your written sign-off? Does escalation reach a network engineer, or a ticket queue with a four-hour first-response target? If a human on the provider’s side cannot act at 03:00 on their own authority, you have bought monitoring, not management.
Rehearse the reporting decision, not just the packet filtering. Tabletop it: a flood starts at 23:10, mitigation engages, customer-facing latency doubles for 25 minutes. Reportable? Who decides, against what criteria, by when? Regulatory failures in availability incidents are usually notification failures, not mitigation failures.
Building the budget case: downtime cost, penalties and how UK protection is priced
UK managed DDoS pricing is usually structured around clean bandwidth or protected prefixes, with a monthly commitment, an always-on premium or an on-demand standby fee, and then overage and per-event charges that finance teams discover during their first bad month. Ask for the overage rate in writing and ask what triggers an event charge. Our analysis of what UK DDoS protection actually costs sets out the common models in more detail.
Build the case bottom-up from downtime, not from fear of fines. Revenue per trading hour. SLA credits you owe your own customers. Incident response staff hours at loaded cost. Contractual penalties and any regulatory exposure. Compare that annual figure against always-on protection versus standby plus event charges under an on-demand arrangement, and the conversation stops being about threat intelligence slides.
The Bill’s stronger penalty regime is a board-level argument and a weak engineering argument. Boards respond to statutory exposure; engineering teams respond to mean time to recovery and the on-call rota. Present both, separately, to the right audience.
Where should partial budget go first? Authoritative DNS resilience and closing origin exposure, almost always. Both are cheap relative to additional scrubbing capacity, both address failure modes that make every other control moot, and both are the first things a competent assessor will probe. Extra Tbps on a contract you already have buys very little availability per pound by comparison.
Frequently Asked Questions
What is the Cyber Security and Resilience Bill and what does it change?
It is a Government Bill that amends and expands the Network and Information Systems Regulations 2018, introduced in the House of Commons in November 2025. The main changes are wider scope (including managed service providers and parts of the digital supply chain), stronger regulator powers and penalties, and incident reporting duties that cover disruption to services rather than only personal data breaches. Significant detail will follow in secondary legislation and sector regulator guidance.
Who is in scope of the Cyber Security and Resilience Bill?
Operators of essential services and relevant digital service providers already covered by the 2018 Regulations, plus managed service providers newly brought inside the perimeter. Many organisations outside the statutory scope will still face equivalent requirements contractually, because in-scope customers must obtain assurance from their suppliers. Check the final thresholds in the Act and the regulations made under it.
Does a DDoS attack have to be reported under the new regime?
Possibly, including when mitigation worked. Where the trigger is framed around actual or potential significant disruption, an absorbed attack with clear potential to take a service down can still meet the threshold. Write classification criteria into your runbook so the decision is made against a standard rather than by whoever is on call.
What counts as appropriate and proportionate DDoS protection?
No regulator publishes a fixed list, so proportionality is demonstrated through documented reasoning. In practice that means controls across network and transport, application layer and authoritative DNS, a recorded always-on or on-demand decision, verified absence of origin exposure, a tested escalation path, and evidence from real incidents.
When is the Cyber Security and Resilience Bill expected to take effect?
No commencement date is settled while the Bill is still before Parliament, and duties will phase in through secondary legislation after Royal Assent. Treat any specific date you see quoted as an estimate and verify current status on the Parliament Bills page. The preparatory work, scope assessment, supplier mapping and evidence collection, is worth starting regardless.
If supplier assurance is the next thing on your list, the colocation and data centre DDoS checklist covers the questions worth asking before you sign anything.