The UK Cyber Security and Resilience Bill Just Reached Parliament: What Boards Need to Know Before the 24-Hour Reporting Clock Starts

On 1 September 2026, the Cyber Security and Resilience Bill reached Committee Stage in the House of Lords. If that sentence didn't register as significant, it should have. This is the biggest overhaul of UK cyber regulation since the original NIS Regulations came into force in 2018, and it is going to change how a great many organisations, some of whom have never thought of themselves as "critical infrastructure", have to detect, report and govern cyber incidents.

For CISOs, IT security leaders and compliance teams, this is not a piece of Westminster process to skim past. The Bill widens who is regulated, tightens how fast you have to report an incident, and raises the financial and governance stakes for getting it wrong. Whether your organisation already sits inside the current NIS regime or has always assumed this sort of legislation was somebody else's problem, now is the moment to work out where you stand.

This article sets out what the Bill actually does, who it brings into scope, what the new reporting timelines will demand of your team in practice, and what a sensible organisation should be doing between now and Royal Assent to get ahead of it rather than scrambling once it lands.

The current UK NIS Regulations date back to 2018, transposed from the EU's original NIS Directive. They were written for a world before ransomware-as-a-service, before the SolarWinds and MOVEit supply chain incidents, and before cloud and managed service providers became as central to critical national infrastructure as the operators they support. The government's own assessment, echoed by the National Cyber Security Centre, has been that the current regime has gaps: it under-regulates the supply chain, it doesn't properly capture managed service providers, and its reporting requirements are too slow and too narrow for how modern incidents actually unfold.

Meanwhile, the EU moved on. NIS2 came into force across the bloc with a substantially wider scope, tougher reporting deadlines and much sharper personal liability for management bodies. The Digital Operational Resilience Act (DORA) did something similar for financial services. The UK, no longer bound to mirror EU law but very much still trading with and operating alongside EU-regulated entities, has had a choice: let the gap between UK and EU cyber regulation widen, or catch up on its own terms. The Cyber Security and Resilience Bill is that catch-up.

It was introduced to Parliament in November 2025, reached Lords Committee Stage on 1 September 2026, and is expected to receive Royal Assent by the end of the year. The substantive obligations will follow through secondary legislation, with most experts pointing to full effect from around 2028. That sounds distant, but anyone who has run a compliance programme knows that two years disappears fast once budgets, tooling, headcount and testing schedules are involved, particularly when the destination itself is not fully fixed yet and will keep firming up as the secondary legislation is drafted.

The current NIS Regulations apply to Operators of Essential Services, covering sectors such as energy, transport, health, water and digital infrastructure, and to Relevant Digital Service Providers, covering cloud services, online marketplaces and search engines. The Bill keeps that foundation but builds substantially on top of it.

Three additions matter most. The first is a new statutory category of Relevant Managed Service Providers, created specifically because the government and the NCSC have identified MSP compromise as one of the most efficient ways for an attacker to reach dozens or hundreds of downstream victims through a single breach. If your organisation provides managed IT or managed security services of any meaningful size, you should assume you are being brought inside the regulatory perimeter, not left outside it.

The second is data centres, regulated for the first time as critical national infrastructure in their own right. The thresholds under discussion sit around 1 megawatt of capacity for general facilities and 10 megawatts for enterprise-only sites, which captures a far wider range of operators than the handful of hyperscale names that usually come to mind when people picture "data centre regulation".

The third is the Designated Critical Supplier mechanism, which gives regulators the power to pull a specific supplier into statutory duties based on its relationship with an already-regulated customer, even if that supplier would not otherwise meet any sector threshold. In practice, this means an organisation can find itself in scope not because of what it does, but because of who it supplies. A mid-sized software vendor or specialist consultancy serving an energy operator or an NHS trust could be designated in this way, and it is worth having that conversation with your commercial and legal teams now rather than after a customer's regulator makes the decision for you.

Large electricity load controllers managing 300 megawatts or more of demand are also being added, reflecting how central flexible demand management has become to grid stability as renewable generation scales up.

Put simply, the net has widened in exactly the directions the last few years of incident data would predict: supply chain, managed services, and the physical infrastructure underpinning digital services. If your organisation sits anywhere near energy, transport, health, water, digital infrastructure, managed IT services, or a data centre of meaningful size, this Bill is worth a proper scoping exercise rather than an assumption either way.

This is the part that will land hardest operationally, and it is worth sitting with the detail rather than skimming it.

Under the Bill, regulated organisations will need to notify their sector regulator and the NCSC within 24 hours of becoming aware of a significant incident. That is not 24 hours to investigate and understand what happened; it is 24 hours to notice, triage and formally report that something significant has occurred. A fuller report, with proper detail on cause, impact and remediation, is then due within 72 hours. Where an incident affects customers, there is a separate obligation to notify them directly. And where an incident originates with another organisation, for example a supplier or a managed service provider, there is a cascade reporting duty that requires the affected organisation to report it onward even though the root cause sits elsewhere.

The threshold for what counts as reportable has also broadened. Historically, UK incident reporting under NIS has leaned heavily on service continuity: was availability disrupted? The Bill extends this to cover confidentiality and integrity issues too, meaning a data breach or unauthorised access event can trigger the same 24- and 72-hour clock as an outage, even if the service itself never went down.

For any organisation whose current incident response process relies on a security team quietly working an issue for a few days before anyone outside the department hears about it, this is a genuine operational shift, not a paperwork exercise. Meeting a 24-hour notification deadline requires detection capability good enough to actually notice an incident quickly, an escalation path that reaches the people who can authorise a regulatory notification without needing three layers of sign-off, and a pre-agreed template and process so nobody is drafting a regulator notification from scratch under pressure. Organisations that already run regular incident response tabletop exercises and have tested runbooks will find this manageable. Organisations that don't will find the first live incident under the new regime a very uncomfortable way to discover the gaps.

The financial penalties in the Bill are designed to be taken seriously at board level, not just by the security function. Standard contraventions carry a penalty of the greater of ¬£10 million or 2% of global annual turnover. Serious or repeated contraventions rise to the greater of ¬£17 million or 4% of global annual turnover. On top of that, there are daily penalties of up to ¬£100,000 for continuing non-compliance, and separate penalties of up to ¬£10 million for failing to comply with information notices or for non-disclosure. For a large multinational, the turnover-linked figures dwarf the fixed caps; for a mid-sized organisation, the fixed caps alone are more than enough to reshape a year's budget.

Enforcement will run through sector-specific regulators, with the NCSC receiving notifications in parallel across all sectors, giving it a national-level view that the current fragmented regime doesn't provide. The Bill also expects, in language echoed by both the government's own guidance and independent legal commentary, that leadership teams demonstrate genuine oversight, accountability and informed decision-making around cyber risk, in line with existing corporate governance codes.

It is worth being precise here rather than overstating it: the Bill's current drafting is less prescriptive on personal management liability than NIS2 is in the EU, and it does not import NIS2's size-cap classification system wholesale. But the direction of travel across every comparable jurisdiction, the EU included, points the same way. Boards are being asked to show they understood the cyber risk they were carrying and took reasonable steps to manage it, not simply to point at a security team and hope that satisfies a regulator after the fact. Directors' and officers' liability insurers are already adjusting their questions accordingly, and it would be a mistake to assume the softer UK drafting today means softer expectations in practice once the first few enforcement cases are published.

One of the most common reactions to legislation like this is a quiet assumption that it applies to somebody else. Energy companies, water utilities and hospital trusts know they are regulated. Everyone else tends to assume they sit outside the perimeter. That assumption is exactly what the Bill's expansion is designed to close down.

Consider a specialist software vendor with forty staff, serving a handful of NHS trusts and a couple of energy operators. Under the current regime, that vendor is very unlikely to be directly regulated. Under the Bill, if one of its regulated customers' regulators decides the vendor's failure would materially disrupt an essential service, it can be designated as a Critical Supplier and pulled into the same statutory duties as the operators it serves. The vendor doesn't get a vote in that decision. Equally, a managed IT provider that has always thought of itself as a general business services company, rather than a piece of national infrastructure, may find itself squarely inside the new Relevant Managed Service Provider category simply because of the scale and nature of what it manages for its clients.

This is precisely why a proper scoping exercise matters more than a quick internal assumption. It needs input from whoever holds your major contracts, because the clause that pulls you into scope may well be sitting in a customer agreement you haven't reread in years, not in anything your security team controls directly.

If your organisation operates across the UK and the EU, or serves EU customers from a UK base, you are not looking at one new regime in isolation. You are looking at a UK Bill that shares its 24 and 72-hour reporting rhythm with NIS2, sits alongside DORA's operational resilience requirements for financial services, and continues to interact with existing GDPR breach notification duties, which carry their own separate 72-hour clock for personal data incidents.

The practical advice from compliance specialists working across both regimes is consistent: build your programme to the higher NIS2 standard and map down to UK requirements, rather than building two parallel compliance efforts. The UK regime differs from NIS2 in some specifics, including its dual notification model to both a sector regulator and the NCSC, its Designated Critical Supplier mechanism, and its distinct data centre capacity thresholds, so a straight copy-paste of an EU compliance programme won't fit perfectly. But the underlying capability you need, being able to detect an incident fast, assess it accurately, and report it within a day, is the same capability regardless of which regulator you are reporting to. Organisations that treat this as one unified resilience programme, rather than a stack of separate regulatory checkboxes, will spend less money and end up better protected.

Royal Assent is expected by the end of the year, with full effect following through secondary legislation over the next couple of years. That gap is not a reason to wait. It is the window in which the organisations that get ahead of this will separate themselves from the ones still building a response plan when their first reportable incident happens.

Start with scope. Work out, properly and with input from legal and commercial teams as well as security, whether your organisation falls under the existing Operator of Essential Services or Relevant Digital Service Provider categories, whether you meet the new Managed Service Provider or data centre thresholds, and whether your relationship with any regulated customer could see you designated as a Critical Supplier. Do not assume the answer is no simply because it was no under the old rules.

Test your detection and escalation capability against a 24-hour clock, not a leisurely one. If your organisation has never run a full incident response tabletop exercise, or hasn't run one recently, this is the moment. A realistic exercise will show you exactly where the gaps sit: whether your monitoring would actually catch the kind of incident that matters, whether the right people would be looped in fast enough, and whether anyone actually knows how to draft and submit a regulatory notification under time pressure.

Map your supply chain with the Designated Critical Supplier mechanism in mind. Know which of your suppliers would put you at risk if they were breached, and know whether your own customers might now expect you to meet standards you haven't previously had to demonstrate. Cascade reporting duties mean an incident at a third party can become your regulatory problem, so supplier risk assessment needs to move from an annual tick-box exercise to something closer to continuous monitoring.

Get independent validation of where you actually stand, rather than relying on internal assumptions. A CREST-certified penetration test will show you the real-world attack paths into your environment before a regulator, or an attacker, finds them for you. Threat intelligence and real-time monitoring capability will determine whether you can genuinely meet a 24-hour detection and notification window, rather than discovering during a live incident that your first indication of compromise arrives on day four. And a proper cyber strategy review, mapped against NIS2, DORA and the emerging UK Bill together, will tell you whether your governance and reporting lines would actually satisfy a board that is now expected to show it understood the risk it was carrying.

It is also worth putting this in front of your board before the Bill demands it. A short paper setting out where your organisation currently sits against the new scope criteria, what a 24-hour notification would realistically require of your team today, and what the financial exposure would look like under the new penalty bands tends to focus attention far more effectively than a general briefing on "upcoming regulation". Boards respond to concrete numbers and concrete gaps, not abstract risk. If you have director's and officers' liability cover, it is worth a conversation with your broker now as well; insurers are already starting to ask more detailed questions about incident response testing and reporting capability as this kind of legislation moves through Parliament across multiple jurisdictions, and getting ahead of those questions is far easier than answering them after a claim.

Finally, budget for this properly rather than treating it as a line item to squeeze in later. Detection tooling, regular penetration testing, tabletop exercises and supply chain risk mapping all cost money, but they cost considerably less than a £17 million penalty, a failed regulatory audit, or the reputational damage of a breach that becomes public because a customer was notified before your own board fully understood what had happened.

The Cyber Security and Resilience Bill is not yet law, and its full substantive requirements will only bite once secondary legislation lands, probably around 2028. But the direction is set, the scope is widening in predictable ways, and the 24-hour reporting clock is the headline change that every CISO, IT security leader and compliance officer needs to plan around now, not in two years' time.

Organisations that use this window to test their detection, tighten their escalation paths, map their supply chain exposure and validate their defences properly will meet the new regime from a position of strength. Those that wait for Royal Assent to start thinking about it will be building an incident response capability under the worst possible conditions: during their first reportable incident, against a clock that no longer gives them the luxury of time.

If you want a clear, independent view of where your organisation actually stands against this Bill, and against NIS2 and DORA more broadly, that is exactly the kind of assessment worth having before the clock starts rather than after.