GRC

Peers table 24-hour customer alerts and AI incident reporting

Lords amendments to the Cyber Security and Resilience Bill seek 24-hour customer alerts, 14-day final reports and AI incident reporting.

Scales of justice graphic with the headline Lords push faster incident alerts

Peers have tabled a batch of Report stage amendments to the Cyber Security and Resilience Bill that would put a 24-hour clock on telling customers about incidents and make frontier AI developers report when their models break into regulated systems. None of it is law yet, but the direction of travel matters for anyone building an incident response plan around the new NIS regime.

What happened

The House of Lords published an updated running list of amendments to the Cyber Security and Resilience (Network and Information Systems) Bill on 9 October 2026. It marks 27 amendments as new or altered, and 26 of them stand in the name of Baroness Harding of Winscombe. They sit alongside earlier proposals from Lord Clement-Jones, Baroness Kidron, Baroness Northover, Baroness Morgan of Cotes and Lord Tarassenko.

Report stage in the Lords is scheduled for 26 October 2026, although Parliament warns that future dates can move. Report is the first point at which the whole House can vote on changes, having finished line-by-line scrutiny in Grand Committee on 7 September.

These are tabled amendments from individual peers, not government policy. Many backbench amendments are withdrawn or never moved, so the text could look very different once Report is over.

The detail

Baroness Harding’s amendments fall into three groups.

Customer notification. The Bill already expects operators of essential services (OES), relevant digital service providers (RDSPs) and relevant managed service providers (RMSPs) to warn customers likely to be affected by an incident. Her amendments would tie that warning to the initial notification sent to the regulator and require it “in any event within 24 hours” of becoming aware of the incident. Providers would also have to keep customers updated whenever the incident or its likely impact changes materially, and advise them on steps they can take to protect themselves.

A final report. On top of the existing initial and full notifications, regulated organisations would have to give their regulator a final report within 14 days. It would describe how severe the incident was, its likely root cause or threat type, and the mitigations applied.

AI and near misses. A new clause would oblige any developer of a frontier AI model made available in the UK to notify the affected regulated organisation and its regulator when one of its models gains, or is used to gain, unauthorised access to systems that organisation relies on. The timetable mirrors the operator regime: an initial notice within 24 hours, a fuller one within 72 hours and a final report within 14 days, with copies to the CSIRT and the AI Security Institute. Failing to report would attract the same penalties as an operator of an essential service. A separate clause would let regulated organisations voluntarily report incidents, threats and near misses to the NCSC or their regulator without taking on extra liability. Her explanatory note links this to Article 30 of NIS2.

Other peers’ amendments on the list include:

  • Lord Clement-Jones: “last-resort” powers to order the shutdown of data centres or large-scale AI systems in an AI security emergency, which he first pushed at Committee; a 12-month review of a statutory defence under the Computer Misuse Act 1990 for good-faith security work; narrowing the definition of a managed service so that advisory, software support and help desk work without privileged access falls outside it; and an annual report to Parliament on incident volumes.
  • Lord Tarassenko: a requirement for the AI Security Institute to audit frontier AI products before they are used in regulated systems.
  • Baroness Northover: a free advice and incident response service for SMEs in or supplying the regime, a requirement for the government’s review of the legislation to assess divergence from EU NIS2, and UK Cyber Security Council registration for the people running regulated systems.
  • Baroness Morgan of Cotes: regulation based on risk “irrespective of their size”, so that small but critical providers are not left out.
Timeline of incident reporting deadlines proposed in Lords amendments to the Cyber Security and Resilience Bill

Why it matters for UK organisations

The customer notification change is the one most likely to affect day-to-day operations. MSPs are being brought into scope for the first time. For them and for digital service providers, a hard 24-hour deadline to tell customers is a much tougher test than a general expectation to tell them promptly. Most of the duties will arrive through secondary legislation after Royal Assent, and commentators expect full effect around 2028.

The AI clauses follow concerns, reported in Computer Weekly’s coverage of the Committee debate, about incidents in which AI models went beyond controlled environments during testing. Whether or not they pass, they test whether the NIS regime should cover the companies whose tools can reach into an operator’s network as well as the operators themselves. The government has said it is considering “proportionate containment powers” rather than accepting the kill-switch wording.

Expert view

In my experience, notification deadlines expose weak detection, not weak paperwork. The hard part of a 24-hour customer clock is knowing within those hours that something has happened and roughly what it touched. When we run incident exercises with service providers, the hours vanish while teams work out which customers sit behind a compromised management plane, because the asset and tenancy data is out of date.

The 14-day final report is sensible, but organisations should be honest about how little root-cause certainty they will have by then. A report written with a deadline in mind is more useful when it says plainly what is still unknown.

The frontier AI reporting clause is the most novel idea here, and also the hardest to make work. Developers will often not know that their model touched a particular victim’s network, and the “ought reasonably to be aware” test will be argued over for a long time. The voluntary near-miss route, by contrast, is cheap and overdue.

I would also welcome the MSP definition change from Lord Clement-Jones. Tying the definition to privileged access, rather than to the commercial label on a contract, matches how attackers actually move from supplier to customer.

What to do now

  1. Time your detection-to-customer path. Run a tabletop that starts the clock at first alert and ends when an affected customer receives a usable warning. If it takes more than 24 hours, find the bottleneck.
  2. Fix your customer-to-asset mapping. MSPs and digital providers need to know which tenants depend on which management tools, accounts and remote access paths. This also supports the Cyber Essentials controls on user access and secure configuration.
  3. Draft a final-report template covering severity, impact, likely root cause and mitigations, so the 14-day version is not written from scratch.
  4. Inventory AI agents with network reach. Record which AI tools hold credentials or tokens for production systems, apply least privilege, and log what they do.
  5. Review supplier contracts so that providers must notify you quickly and keep you updated, whatever the final wording of the Act.

Bottom line

Tabled amendments are not obligations, and plenty of these will fall away. But the message from the Lords is consistent: faster and fuller incident communication, customers kept informed, and AI developers within the reporting regime. Organisations that can already detect, scope and tell customers about an incident within a day will be ready whichever version reaches the statute book.

Sources