The Cyber Security and Resilience (Network and Information Systems) Bill was introduced in the House of Commons in November 2025. It has since cleared all Commons stages, entered the Lords on 25 June 2026, completed Second Reading on 14 July 2026, and enters Committee Stage on 1 September 2026.

Royal Assent is expected in late 2026. Substantive effect is not expected until around 2028, delivered through secondary legislation following a government implementation consultation planned for 2026.

That gap — assent in months, effect in years — is what makes this the right moment to look at it. Organisations that wait for the regulations will have roughly a year of notice on obligations that take longer than a year to implement. Organisations that start now are working from a Bill whose framework is settled even if its detail is not.

The Bill is the most significant overhaul of UK cyber regulation since the NIS Regulations 2018, and it moves the UK closer to — though deliberately not identical with — NIS2.

What changes in scope

The existing NIS Regulations cover operators of essential services in energy, transport, health, drinking water and digital infrastructure, and relevant digital service providers (online marketplaces, search engines and cloud computing services).

The Bill extends direct regulation to:

Relevant managed service providers (RMSPs). A new statutory category, distinct from RDSPs. This is the single largest scope expansion. The policy rationale is straightforward and well evidenced: an MSP with privileged access into hundreds of client environments is a concentration point, and MSP compromise has been a repeated route into UK organisations. This site covered same-day exploitation of N-able N-central by Storm-1175 and the CVE-2026-18577 patch bypass and its MSP blast radius earlier this month — precisely the risk the RMSP category exists to address.

Data centres. Regulated for the first time as a category, reflecting their designation as UK critical national infrastructure. The Bill brings operators of data centres within the regime, with the detail of thresholds and applicability to be settled in secondary legislation.

Designated critical suppliers. A mechanism allowing regulators to designate specific suppliers to regulated entities as themselves subject to duties, where the supplier’s failure would have a significant disruptive effect. This is the provision to watch most closely: it means an organisation can be pulled into statutory regulation not by its own sector, but by who its customers are.

Oversight of both RMSPs and RDSPs will sit with the Information Commission — the reconstituted body that the ICO becomes.

Incident reporting

The reporting regime tightens materially against the current NIS position.

The Bill introduces a two-stage reporting duty: an initial notification within 24 hours of becoming aware of a significant incident, followed by a fuller report within 72 hours. Reports go to the relevant regulator and to the NCSC.

The reportability threshold is also broadened beyond the current NIS focus on service continuity, to encompass incidents affecting confidentiality, integrity and availability — which brings data-focused incidents into a regime that previously centred on disruption.

There is a further duty of note: a requirement to notify affected customers where an incident affects them, which for MSPs and data centre operators is a substantial operational commitment given the number of customers a single incident can touch.

The 24-hour front end is the part that requires new capability. UK organisations have built 72-hour reporting muscle around GDPR Article 33. A 24-hour initial notification is a different function: it must run out of hours, it must be triggerable by an on-call engineer’s judgment rather than by a completed assessment, and it must not wait for legal sign-off that takes a working day to obtain.

Penalties

The Bill establishes a two-tier structure:

  • Serious contraventions: up to GBP 17 million or 4% of global annual turnover, whichever is greater
  • Less serious contraventions: up to GBP 10 million or 2% of turnover
  • Continuing non-compliance: daily penalties up to GBP 100,000 per day

The daily penalty provision is the one that changes behaviour. A capped one-off fine can be provisioned for; an accruing daily penalty for continuing non-compliance cannot, and it converts a remediation backlog into a live financial exposure with a running total.

How it differs from NIS2

The Bill is not a NIS2 transposition, and the differences matter for organisations operating on both sides of the Channel.

No size-cap classification. NIS2 uses a size-cap rule creating essential and important entity tiers with different supervisory regimes. The UK Bill retains the existing OES/RDSP architecture and adds categories to it, rather than adopting the two-tier structure.

More delegated to secondary legislation. NIS2 specifies ten minimum risk-management measures in Article 21(2). The UK Bill leans considerably more on regulations and regulator-issued codes of practice, with the substantive duties to be fleshed out later. That is why the 2028 timeline exists, and why the implementation consultation is the document to watch.

Management liability framed differently. NIS2 Article 20 imposes explicit duties on management bodies, including approval of risk-management measures and liability for infringements, plus a training requirement. The UK Bill’s treatment of individual accountability is less prescriptive on its face — though the practical expectation that boards own cyber risk is unchanged, and the Lords stages are one place where amendments on this point may surface.

The critical supplier designation is a UK-specific mechanism without a direct NIS2 analogue, and it gives regulators a targeted tool that the European framework achieves — less precisely — through supply chain security obligations on regulated entities.

For groups in scope of both, the practical answer is to build to NIS2 and map down. NIS2’s specificity makes it the harder standard in most respects, and an organisation meeting Article 21(2) will find the UK secondary legislation largely satisfied. This site’s coverage of the October 2026 NIS2 deadline and management liability sets out that baseline.

What to do in the assent-to-effect window

The temptation is to wait for the regulations. That is a mistake for anything with a long lead time, and most of what matters here has a long lead time.

Determine whether you are an RMSP, and do it early. “Managed service provider” is a commercial description that a great many organisations fit without using the term. If you provide ongoing management, administration, monitoring or support of a customer’s IT infrastructure, systems or networks — with some degree of privileged access or network connectivity into their environment — you should assume you are in scope until the definition in secondary legislation says otherwise. That includes a considerable number of software vendors whose product includes a managed or hosted operations component.

Ask whether you might be designated a critical supplier. If you supply an OES or a large RDSP and your failure would materially disrupt their essential service, designation is plausible. That question is worth putting to your major regulated customers now, because they will be assessing their own supplier dependencies as the Bill progresses.

Build the 24-hour capability. This is the item with the shortest implementation path and the highest failure rate. It requires: a defined trigger for what constitutes awareness; a named on-call decision-maker with authority to file; a pre-drafted initial notification template; out-of-hours legal reachability; and a rehearsed path. Test it with a timed exercise starting at 2am on a Sunday. Organisations that do this find the failure is almost never technical.

Build the customer notification path. For an MSP with hundreds of clients, notifying affected customers under time pressure is a communications and contractual problem as much as a security one. Determine now who holds the customer contact data, what the contractual notification commitments already say, and whether the two are consistent.

Review your contracts in both directions. As a prospective RMSP, your customer contracts should anticipate statutory reporting duties, audit and information-provision obligations to a regulator, and the possibility of regulator engagement. As a customer of MSPs and data centres, your contracts should require notification to you within a window that lets you meet your own obligations.

Engage with the implementation consultation. The government’s 2026 consultation is where thresholds, definitions and the RMSP boundary get decided. For organisations sitting near the edge of a definition, that consultation is materially more valuable to engage with than the Bill’s remaining parliamentary stages.

The pattern worth noting

Three jurisdictions are now converging on the same regulatory instinct within a few months of each other: the EU CRA’s Article 14 reporting duties from 11 September 2026, NIS2’s October 2026 compliance culmination, and the UK Bill’s expected late-2026 assent.

All three pull previously unregulated intermediaries — product manufacturers, managed service providers, data centres, digital supply chain participants — into statutory regimes with 24-hour reporting front ends and turnover-linked penalties.

An organisation that sells technology or technology-enabled services into Europe should plan on the assumption that by 2028 it is a regulated entity in at least one of these regimes, probably more than one, and that the common requirement across all of them is the ability to recognise a significant incident and tell a regulator about it within one day.

That capability is buildable now, and it is the same capability in every jurisdiction. Building it once, before any of the deadlines force it, is the cheapest version of this available.

This article is provided for informational purposes only and does not constitute legal advice.