A ransomware crew posts a victim listing on a Friday night. The victim is not you. It is the outsourced payroll provider that holds records for three of your operational sites, and the listing sits on a leak site all weekend, screenshotted and reshared in Telegram channels, until somebody in your team sees a news alert on Tuesday morning. Under the reporting model proposed alongside the Cyber Security and Resilience Bill, your initial notification window closed on Saturday.

That is the gap this article is about. Plenty of good legal commentary explains what the Bill says. Far less of it explains what a security team has to change in practice, and almost all of the new duties quietly assume you already know what you own on the internet, who owns each asset internally, and which suppliers touch your essential service. Most organisations do not have that picture. That is what breaks a 24-hour clock.

Where the Bill has got to, and what it changes operationally

The Cyber Security and Resilience (Network and Information Systems) Bill was introduced to Parliament in November 2025. It amends rather than replaces the Network and Information Systems Regulations 2018, so the existing framework of operators of essential services, relevant digital service providers and sector regulators stays recognisable. Parliamentary stages move, so confirm the current position on the Parliament bills tracker before you quote a timeline to your board. This section is accurate as at early 2026.

Four changes matter for how you run security day to day.

• Wider scope. Managed service providers are brought into regulation, and suppliers can be designated as critical to an essential service.
• Tighter, broader incident reporting. A two-stage clock, and a trigger that captures potential disruption rather than only realised disruption.
• Stronger regulator powers. Information notices, more active oversight, and cost recovery so regulators can fund supervision through fees.
• Powers of direction. The Secretary of State would be able to direct regulated entities where national security requires it.

What the Bill is not: it is not a UK transposition of NIS2, and it does not fold personal data breach reporting into one pipeline. If an incident involves personal data, the UK GDPR duty to notify the ICO within 72 hours runs alongside the NIS reporting duty, not instead of it. Plan for parallel notifications with different recipients, different thresholds and different content.

The standard the Bill keeps is outcome-based: security measures that are appropriate and proportionate to the risk. No prescribed control list, deliberately. The practical consequence is that a regulator asking questions after an incident will want to see the reasoning, the evidence behind it and the dates. The NCSC's Cyber Assessment Framework remains the most useful reference point for what good looks like under that wording.

Are you in scope? Work it out before a regulator does

The established categories still apply: operators of essential services in energy, transport, water, health and digital infrastructure, plus relevant digital service providers such as online marketplaces, search engines and cloud computing services regulated by the ICO.

The expansion is where new organisations get caught. Managed service providers, the firms with privileged, ongoing access into client networks, move from being somebody else's third-party risk to being directly regulated. Separately, the Bill provides for designating specific suppliers as critical where their failure would materially disrupt an essential service. You do not opt into that designation, and you may not see it coming.

Data centres have been on this trajectory since the government designated them as Critical National Infrastructure in September 2024. Treat colocation, hosting and interconnect providers as in-scope infrastructure in your planning, whether or not you own the racks.

Then there is the indirect route, which is how most mid-market UK firms will actually feel this legislation. You may never be regulated. Your regulated customer will still flow duties down to you through contract, and their procurement and legal teams are not waiting for Royal Assent to start doing it.

The 24-hour clock is an asset ownership problem before it is a legal one

The government's policy statement set out a two-stage model: an initial notification within 24 hours of becoming aware of a significant incident, and a fuller report within 72 hours, with duties to inform affected customers where an incident could adversely affect them. Confirm the final wording once the Bill completes its passage, because detail here can shift in committee.

Teams that miss the 24-hour mark rarely miss it on drafting. They miss it because the first twelve hours go on working out who owns the affected system. Was that subdomain decommissioned? Which business unit paid for that SaaS tenant? Is the staging box still reachable from the internet? An inventory built by declaration, people telling you what they think they run, falls apart under that pressure. An inventory built by external asset discovery, where the platform finds what is actually reachable from the outside, holds up.

The widened trigger deserves more attention than it is getting. Incidents with the potential for significant disruption pull near-misses and third-party events into the reporting frame. A batch of staff stealer logs surfacing in a leaked credential dump, or your brand named in a ransomware channel, can constitute potential disruption well before anything visibly breaks. Threat intelligence stops being a nice-to-have and becomes a compliance input. If nobody is watching those sources, your clock starts when a journalist calls.

To hit 24 hours, four things need to exist before the incident, not during it:

1. Asset ownership mapping, with a named internal owner per internet-facing asset and service.
2. A named decision-maker per essential service who can authorise a notification out of hours.
3. A pre-agreed severity threshold, written down, so the "is this reportable?"debate is short.
4. A drafted notification template with the fields your regulator will want, so you are filling in blanks rather than composing prose at 2am.

Evidencing appropriate and proportionate measures across your external footprint

Start with what is discovered, not what is declared. Take a familiar pattern: a 400-person organisation is confident it runs around 60 internet-facing hosts. Discovery surfaces legacy campaign microsites from a rebrand, an abandoned staging environment still serving default credentials, and two departmental SaaS tenants bought on a marketing card that IT never approved. None of that appears in a CMDB last touched during a cloud migration. All of it is in scope of an attacker's reconnaissance, and all of it is your responsibility to secure.

On vulnerabilities, regulators will judge quality, not volume. A five-figure open-findings count proves nothing except that you bought scanners. Run dual scanning across infrastructure and web applications, deduplicate the overlap, auto-resolve what has genuinely been fixed, and report a real median time to remediate by severity. That is a defensible number. A raw backlog is not.

DNS and domain hygiene is where paperwork-based security fails fastest. Expired records, dangling CNAMEs pointing at deprovisioned cloud resources, and lookalike domains registered against your brand are all attacker infrastructure in waiting. Build the takedown process now: evidence collection with timestamps and screenshots, registrar and hosting abuse contacts, and a log of what you submitted and when.

Identity exposure sits alongside it. Leaked credentials and infostealer logs affecting staff, and particularly administrators, are the most common route into an essential service that never touches a firewall rule. Classify internal versus external identities so you are monitoring the right people, and treat an administrator appearing in a stealer log as an incident, not a ticket. Our guide to triaging leaked credentials found on the dark web covers that workflow in detail.

Executive exposure belongs in the same conversation. Targeted compromise of a named finance director or operations lead is a realistic route into a regulated service, which makes VIP monitoring a resilience control rather than a courtesy to the leadership team.

Supply chain duties: what you will be asked, and what you must ask

An annual questionnaire and a PDF of an ISO 27001 certificate will not satisfy a duty framed around the ongoing security of supply. Accreditation tracking and continuous monitoring answer different questions. The certificate tells you a supplier passed an audit on a given date against a defined scope. Monitoring tells you their remote access appliance is unpatched and exposed this week. You need both, and you need each vendor mapped to the specific service they touch.

In practice that means a supplier register that records what the vendor does, which essential service it supports, its accreditation status and expiry, and a threat score updated from live sources: breach disclosures, ransomware leak site listings, and chatter in criminal channels that names the vendor. The Glasgow City Council incident is a useful case study in how a supplier compromise becomes your operational problem within hours.

Regulated customers are already pushing notification windows down the chain that are shorter than the statutory ones, because they need your report in time to make their own. Contractual notification windows shorter than the statutory 24 hours are increasingly appearing in new agreements. If you are an MSP, assume you will be asked to hand a client, within 24 hours of an incident, a defensible pack: what was affected, whether client data or client environments were touched, indicators of compromise, containment actions taken, and a named contact who can answer follow-up questions. Build that pack now. Reverse-engineering it mid-incident does not go well, and it is worth discussing how partner and MSP reporting should be structured before a client asks.

A readiness checklist for the next two quarters

Quarter one, establish the facts. Confirm your scope position in writing, including the indirect route through regulated customers, and have someone senior sign it. Run external discovery across domains, subdomains, IP ranges, cloud services and APIs, and reconcile what comes back against your asset register. Assign an owner to every asset. Baseline your current exposure: open findings by severity, credential exposure, domain risks, supplier threat scores.

Quarter two, prove it works. Set and document severity thresholds. Run a tabletop exercise against a 24-hour notification, ideally one that starts at a supplier rather than in your own network, and time it honestly. Tighten the supplier register and get the notification clauses into contracts at renewal. Close the highest-exposure findings and record what you accepted, why, and who approved it.

Make the clock achievable by removing manual handoffs. Findings routed into Jira, Slack, Microsoft Teams, your SIEM or your ticketing system create timestamped evidence of detection to action, which is precisely the audit trail a regulator asks for. Continuous monitoring of live assets keeps that trail current as the estate changes.

Three mistakes recur. Treating this as a policy exercise and writing documents nobody operates. Trusting a CMDB that has not been reconciled since a migration. And counting certificates instead of monitoring behaviour.

Reporting it upwards: what boards and regulators want to see

Boards do not need vulnerability totals. They need trend over time, what changed this week, and open risk expressed by service, so a director can see that the payments platform carries three unresolved high-severity issues while the marketing estate carries forty low-severity ones. That framing survives contact with a regulator too.

Keep the evidence trail dated and durable: point-in-time reports, decision rationale for accepted risks, and proof of remediation timelines rather than assertions. Add people and VIP exposure as a standing item alongside asset and supplier reporting, because credential and executive risk moves faster than infrastructure risk.

Practically, run three output formats: live dashboards for the security team, exported PDFs filed for audit, and scheduled email summaries for the board. The Bill's outcome-based standard rewards organisations that can show sustained, evidenced attention to their external attack surface. It offers very little to those who can only show a policy library.

Frequently Asked Questions

What is the Cyber Security and Resilience Bill and who does it apply to?

It is UK legislation introduced to Parliament in November 2025 that amends the NIS Regulations 2018 rather than replacing them. It applies to operators of essential services in sectors such as energy, transport, water, health and digital infrastructure, to relevant digital service providers, and, under the expansion, to managed service providers and suppliers designated as critical to an essential service. Many unregulated firms will encounter it indirectly through contracts with regulated customers.

When is the Cyber Security and Resilience Bill expected to become law?

The Bill was still progressing through Parliament at the time of writing in early 2026, and no commencement date should be treated as fixed until it receives Royal Assent and implementing regulations follow. Check the Parliament bills tracker for the current stage before planning around a date. Sensible practice is to prepare against the proposed duties now rather than wait for the timetable to settle.

Are managed service providers in scope of the new cyber resilience rules?

Bringing managed service providers into regulation is one of the central changes the Bill proposes, on the basis that MSPs hold privileged, persistent access to client environments. If you provide managed IT, security or cloud services, plan for direct duties around security measures and incident reporting. Clients are likely to demand evidence of readiness well before the legal duty commences.

How quickly will incidents need to be reported under the Bill?

The government's proposed model is an initial notification within 24 hours of becoming aware of a significant incident and a fuller report within 72 hours, with duties to inform affected customers where they could be adversely affected. The trigger extends to incidents with the potential for significant disruption, not only those that have already caused it. Confirm the final requirements once the Bill completes its passage.

Does the Bill replace UK GDPR breach reporting to the ICO?

No. Personal data breach reporting under the UK GDPR continues to run separately, with its own 72-hour duty to the ICO. An incident affecting both an essential service and personal data will generate parallel obligations with different recipients and thresholds, so build both paths into your incident plan and rehearse them together. If you want help mapping your external exposure before those clocks start, get in touch with the DarkInvader team.