Cyber Security and Resilience Bill: What Connected Estates Need to Evidence

The next phase of cyber resilience will be judged less by what organisations say about their connected estates, and more by what they can prove when a regulator, customer or incident investigation asks for evidence.

A note on the current Bill status. The Cyber Security and Resilience Bill is not yet law. It was introduced to Parliament on 12 November 2025 and, as of 24 June 2026, has completed its Commons stages and is in the House of Lords. If passed, implementation is expected to be phased, with much of the operational detail set out in secondary legislation and codes of practice. The direction of travel, though, is clear enough for connected-estate operators to consider the implications and start building plans[1].

The Bill would modernise the NIS Regulations 2018, the UK’s primary cross-sector cyber security regime, which currently covers essential services in transport, energy, drinking water, health and digital infrastructure, along with some digital services[2].

From an operator’s perspective, four changes stand out operationally, and each one turns into a question about what you can begin to demonstrate:

• It widens scope: The Bill would bring additional organisations into the regime, including relevant managed service providers, certain data centres and large load controllers. In this context, large load controllers are organisations that manage significant electrical load to and from smart energy appliances such as batteries and EV chargers. The question this raises is whether you, your individual services, or the organisations you supply are now in or near scope[3].
• It puts supply chains in the frame: Regulators would be able to designate critical suppliers where their disruption could significantly affect essential, digital or managed services. In some cases, even small or micro-enterprise digital or managed service providers could be designated where the statutory tests are met. The question is whether you can account for the suppliers your service depends on, including connectivity[4].
• It tightens incident reporting: The Bill is expected to introduce a two-stage model, with an initial notification within 24 hours of becoming aware of a significant incident and a fuller report within 72 hours, alongside streamlined reporting to regulators and the National Cyber Security Centre. For data centres and relevant digital or managed service providers, the Bill also points to new customer-notification requirements where cyber breaches are likely to have affected customers. The fuller report would be based on what is known at that point, not a requirement to have completed the entire investigation. The question is whether, in the first hours of an incident, you can produce a clear account of what happened, which services or customers may have been affected, and how the affected services were supported[5].
• It strengthens enforcement: The Bill would strengthen regulators’ powers and reform the penalty regime, simplifying the penalty bands and introducing new maximum penalties intended to reflect the seriousness and cost of non-compliance. The question is whether your records would stand up to scrutiny rather than your reassurances[6].

The first 72 hours

The clearest way to understand the Bill is to picture the moment it is designed for:

A significant incident is detected. The reporting clock starts. Within 24 hours, you need to notify. Within 72, you need to explain. At that point, the organisation is not asked whether it believed its estate was resilient. It is asked to show how services were monitored, how the fault was identified, which customers or services may have been affected, how connectivity held or recovered, and what was done.

This is where automated connectivity resilience matters most. A failover that keeps a service running while one network is unavailable, and the monitoring record that captures it, are the kind of evidence the reporting window calls for.

In practice, resilience that cannot be proved in that window may as well not have happened, because the people reviewing the incident only see what you can show them.

For connected estates, this evidence often starts at the connectivity layer. If a device, site or service loses its primary connection, the question is not only whether it recovered, but whether the organisation can show when the disruption occurred, how failover worked, which services were affected, and what records were available during the reporting window.  

This is a gap connected-estate operators should be looking to close now, before a regulator, a customer or an incident makes it urgent.

A Connected Estate Evidence Stack

To help IT and infrastructure leaders close that gap, this example of a Connected Estate Evidence Stack, breaks the estate into four layers, each framed as a question you should be able to answer.

Legal assessment is a separate exercise, but operationally there are things that you should be able to answer before an incident, not during one.

The fourth layer is where product regulation enters the estate. The Product Security and Telecommunications Infrastructure Act (PSTI) has applied since 29 April 2024 and places obligations across the supply chain for in-scope consumer connectable products, including requirements around unique passwords, vulnerability reporting and transparency over security update periods. Some product categories are excepted or covered by separate regimes, including EV charge points, medical devices, smart meter products, and certain computer categories such as desktop and laptop computers and non-cellular tablets. For an operator, the practical step is to know which devices are in scope and to hold the supplier evidence the stack calls for[7].

In practice, that evidence is the everyday kind: a connected-device inventory, a supplier register, support-period records, PSTI statements of compliance where relevant, connectivity failover logs, monitoring alerts, incident tickets, support SLAs and escalation records.

Connectivity is where resilience becomes visible, and where its absence usually shows first. It keeps connected devices working, it is often the layer through which an incident is first detected, and it is part of the supply chain a regulated operator now has to account for. None of that means connectivity satisfies the Bill or makes a product PSTI compliant, and no connectivity service should be presented as such. What managed connectivity can do is help produce the evidence those expectations rely on.

Within CSL’s managed critical connectivity model and service range, the patented rSIM is one of the key technologies that helps make resilience visible, measurable and provable. It holds two independent mobile operator profiles, each on its own core network, an arrangement CSL refers to as DualCore. The failover logic sits on the SIM itself, so if the primary network drops, rSIM switches to the second profile on its own, without waiting on the device or on a management platform that may itself be unreachable during an outage. Connectivity is restored and the service keeps running. (Both profiles are themselves multi-network, so switching cores adds to the radio diversity each already has).

Around rSIM sit complementary layers: managed IoT SIMs and private APN routing for visibility and control over how each device connects; round-the-clock monitoring and support that turns availability and response into something you can show rather than assert; and cellular and satellite options for remote or hard-to-reach sites. Each of these is also a source of the records an operator will increasingly be asked to produce, including a clear account of when connectivity failed over and how a service was kept running.

Connectivity does not create compliance. It helps prove resilience.

If your estate also operates in, or sells products into, the EU, two EU regimes sit alongside the UK ones, and it helps to understand how they align. The closest organisational comparison is the EU’s NIS2 Directive, which applies to in-scope entities and services[8]. The product-side comparison is the EU Cyber Resilience Act (CRA), which applies to products with digital elements placed on the EU market. In other words, the CRA is closer to PSTI in concept than to the Cyber Security and Resilience Bill, although the two product regimes are not identical.

Which of these applies is a question of jurisdiction. The UK regimes apply to UK services and products; the EU regimes apply where you operate in the EU (NIS2) or place products on the EU market (CRA), and the CRA can reach manufacturers based outside the EU through an EU importer or an authorised representative.

The direction of travel is similar on both sides: the CRA is already in force and phasing in, with vulnerability and incident reporting from 11 September 2026 and main obligations applying from 11 December 2027. Its reporting model also uses a 24-hour early warning and a 72-hour full notification, submitted through the CRA Single Reporting Platform and addressed to the relevant CSIRT, with information made available to ENISA except in exceptional circumstances.

The practical takeaway is that the evidence behind the stack, the inventories, failover and monitoring records and support periods, increasingly serves more than one regime. As with PSTI, none of it makes a product CRA compliant; this is a high-level map, and the position should always be confirmed for your specific products and services through the appropriate legal advice[9].

The Cyber Security and Resilience Bill is not yet law, but its direction of travel is clear, and the organisations that prepare early will find the eventual detail far less disruptive. The work is not only legal; it is operational: knowing your scope, your suppliers, your connectivity resilience and your product baseline, and being able to evidence each.

If you are unsure what your connected estate could evidence today, a Critical Connectivity Readiness Review that works through your scope, your supplier assurance, your network resilience, and the records you would need to produce is a good place to start.

CSL can help you understand your estate, where the resilience gaps are, and what needs strengthening before a regulator, customer or incident investigation asks those questions.

Is the Cyber Security and Resilience Bill law yet?

No. It is a Bill, introduced on 12 November 2025 and currently progressing through Parliament, where it has completed its Commons stages and reached the House of Lords. If passed, implementation is expected to be phased, with much of the detail set out in secondary legislation and codes of practice.

Who would the Bill affect?

It is built around operators of essential services and digital infrastructure, and it would bring more organisations into scope, including relevant managed service providers, certain data centres and large load controllers that meet the relevant criteria or thresholds. Through its supply-chain provisions, suppliers to regulated operators may also be affected, particularly where disruption to that supplier could significantly affect an essential, digital or managed service.

How does it relate to PSTI, NIS2 and the EU Cyber Resilience Act?

PSTI is a separate UK product security regime for in-scope consumer connectable products. The Bill updates the UK’s NIS Regulations at organisational level. NIS2 is the closest EU organisational comparison, while the EU Cyber Resilience Act is a product-side regime for products with digital elements placed on the EU market. UK and EU obligations should be assessed separately.

Does resilient connectivity make my organisation compliant?

No. Connectivity can support resilience, monitoring and evidence, but it does not replace the duties the Bill would place on regulated organisations, or product-level compliance under PSTI.

What evidence should connected-estate operators collect now?

Operators should be able to produce a connected-device inventory, supplier register, connectivity architecture records, failover logs, monitoring alerts, incident tickets, support SLAs, escalation records and product-security evidence where relevant. The aim is not to prove compliance through connectivity alone, but to show how the estate is monitored, supported and kept operational when disruption occurs.

• UK Parliament, Cyber Security and Resilience (Network and Information Systems) Bill (stages and current status): https://bills.parliament.uk/bills/4035
• GOV.UK, Cyber Security and Resilience Bill factsheets (summary, scope, incident reporting, critical suppliers and enforcement): https://www.gov.uk/government/publications/cyber-security-and-resilience-network-and-information-systems-bill-factsheets
• GOV.UK, Regulations: consumer connectable product security (PSTI requirements and exceptions): https://www.gov.uk/guidance/regulations-consumer-connectable-product-security
• European Commission, Cyber Resilience Act (overview): https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
• European Commission, CRA reporting obligations: https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
• Further Reading: The EU Cyber Resilience Act for IoT https://www.csl-group.com/blogs/eu-cyber-resilience-act-for-iot-why-resilient-connectivity-matters/

[1] Bill stage and introduction date: UK Parliament, Cyber Security and Resilience (Network and Information Systems) Bill, HL Bill 32 (as brought from the Commons). The Commons stages are complete and the Bill is now in the House of Lords. Source: https://bills.parliament.uk/bills/4035. The 12 November 2025 introduction date is given on the DSIT factsheets page.

[2] Basis and scope: HL Bill 32, long title and clause 2. The Act amends the Network and Information Systems Regulations 2018 (defined in clause 1 as S.I. 2018/506). The sectors listed here (transport, energy, drinking water, health, digital infrastructure and some digital services) are the existing NIS 2018 coverage, not a change introduced by the Bill.

[3] HL Bill 32, clause 2(2)(a), which extends the regime to data centres, load control and managed services. Data centres: clause 4, with thresholds in the new Schedule 2 paragraph 11 (a rated IT load of 1 MW, or 10 MW for in-house ‘enterprise’ data centres). Large load controllers: clause 6, with a 300 MW threshold; the relevant appliances are electric vehicles, charge points, electrical heating appliances, battery energy storage systems and virtual power plants. Managed service providers: clauses 9 and 10, with ‘managed service’ defined in the new regulation 1(3B).

[4] HL Bill 32, clause 12, inserting new regulations 14H to 14L. The designation tests are in regulation 14H(1) and (2), including that the disruption is likely to have a significant impact on the economy or the day-to-day functioning of the UK. Small and micro enterprise digital and managed service providers can be designated as critical suppliers even though they sit outside the MSP and digital-provider regimes. Source: DSIT factsheet, ‘Designating critical suppliers’, https://www.gov.uk/government/publications/cyber-security-and-resilience-network-and-information-systems-bill-factsheets/designating-critical-suppliers.

[5] HL Bill 32, clause 15, replacing regulation 11. An initial notification is due within 24 hours, and a full notification within 72 hours, of first becoming aware of a significant incident (new regulation 11(6)). The full notification covers the listed information ‘so far as known’ (regulation 11(2)(b)), and a copy goes to the CSIRT, the function the NCSC performs, at the same time as the competent authority (regulation 11(8)). The Bill also introduces a duty on data centres, and on relevant digital and managed service providers, to identify and notify customers likely to have been adversely affected by an incident. Source: DSIT factsheet, ‘Incident reporting’, https://www.gov.uk/government/publications/cyber-security-and-resilience-network-and-information-systems-bill-factsheets/incident-reporting.

[6] HL Bill 32, clauses 21 and 22 and Schedule 1. The penalty structure moves from three bands to a simplified two-band model, with new maxima of up to £17 million or 4% of worldwide turnover for the higher band, and up to £10 million or 2% of turnover for the standard band. Source: DSIT factsheet, ‘Enforcement’, https://www.gov.uk/government/publications/cyber-security-and-resilience-network-and-information-systems-bill-factsheets/enforcement.

[7] PSTI is a separate regime and is not part of this Bill. It comprises the Product Security and Telecommunications Infrastructure Act 2022 and the PSTI (Security Requirements for Relevant Connectable Products) Regulations 2023, in force since 29 April 2024. Excepted categories include EV charge points, medical devices, smart meter products, and desktop computers, laptop computers and tablet computers without cellular capability, subject to the children’s-product caveat in the guidance. Source: GOV.UK, ‘Regulations: consumer connectable product security’, https://www.gov.uk/guidance/regulations-consumer-connectable-product-security.

[8] NIS2 is the EU’s organisational cyber security regime, the Network and Information Security Directive (Directive (EU) 2022/2555). It is the EU counterpart to the UK NIS framework that this Bill updates, and UK and EU obligations should be assessed separately.

[9] The EU Cyber Resilience Act (Regulation (EU) 2024/2847) entered into force on 10 December 2024. Its reporting obligations apply from 11 September 2026 and its main obligations from 11 December 2027. Manufacturers submit a 24-hour early warning and a 72-hour full notification once through the CRA single reporting platform, addressed to the CSIRT of their main establishment, with the information made available to ENISA except in exceptional circumstances; a final report follows (within 14 days of a fix for an actively exploited vulnerability, or within a month for a severe incident). Source: European Commission, ‘Cyber Resilience Act’, https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act, and ‘CRA reporting obligations’, https://digital-strategy.ec.europa.eu/en/policies/cra-reporting.

This article is for general information and is not legal advice. The measures in the Cyber Security and Resilience Bill, and the scope and obligations under PSTI and the EU regimes referred to, depend on the specific organisation, product and circumstances, and the Bill may change as it passes through Parliament. Organisations should take their own legal and regulatory advice and confirm the current position against official UK and EU sources.