Cyber Incident Reporting Under the Cyber Security and Resilience Bill: A Board Checklist

The Cyber Security and Resilience Bill will give regulated organisations 24 hours to tell their regulator about a significant cyber incident. Twenty four hours sounds generous until you remember how incidents really start: late on a Friday, with partial information, systems behaving oddly and nobody yet sure whether it is an outage, an error or an attacker.

The organisations that meet that deadline calmly will not be the ones with the best lawyers on the day. They will be the ones whose boards agreed, months earlier, who decides, what counts as significant, what gets sent and to whom. This guide turns the Bill's reporting rules into a practical checklist your board can work through now, before hour one ever starts.

Where the Bill Stands Today

The Cyber Security and Resilience (Network and Information Systems) Bill is the biggest change to UK cyber regulation since the NIS Regulations of 2018. It brings managed service providers and data centres into scope, lets regulators designate critical suppliers and introduces a two stage reporting duty for significant incidents.

The House of Lords finished its examination on 2 November 2026 and the Bill has gone back to the Commons to consider the Lords amendments. Commentators expect Royal Assent between late 2026 and spring 2027, with much of the detail, including reporting mechanics, set later through secondary legislation and consultation. We covered the October votes in detail in what the Lords changed and what boards should do now.

That timetable is not a reason to wait. Reporting readiness depends on governance, definitions, contracts and rehearsal, and none of those can be built in a day once the Act is in force. Regulated customers will also start asking their suppliers for evidence well before regulators do.

What the Bill Asks You to Report, and When

As introduced, and as summarised by Hill Dickinson and Mayer Brown, the reporting duty works in two stages:

• An initial notification within 24 hours of becoming aware of a significant incident. It identifies your organisation, the services affected and gives brief details of what happened. Think of it as an alert, not an investigation.
• A fuller report within 72 hours, with what you have learned about the cause, scope and impact.
• Notice to customers who are likely to be adversely affected, as soon as reasonably practicable. Lords amendments strengthened this for data centre operators, digital service providers and managed service providers.

Reports go to your regulator and the National Cyber Security Centre. Some regulators will be the ones you know already, such as Ofgem, Ofcom or the ICO for some digital services. For many managed service providers, it will be the first time they have had a regulator at all.

Notice what starts the clock: becoming aware. That is a question of fact your regulator can test later. If your monitoring raised an alert at 2am that nobody looked at until Monday, expect to be asked why. The clock rewards organisations that can turn a suspicion into a confident judgement within hours, which is a detection and triage problem as much as a legal one.

What Counts as Significant After the Lords Changes

The definition of a reportable incident was one of the most debated points in the Lords. As introduced, it could have captured events capable of having an adverse effect, which peers warned would flood regulators with failed attempts and low level noise. As VinciWorks and ISACA report, the Government accepted the point. The amended definition focuses on incidents that have actually adversely affected the operation or security of network and information systems, and a voluntary route for near misses will be developed instead.

That is good news, but it moves the pressure onto your first few hours. The question you must answer quickly, with evidence, is no longer "could this matter?" but "has it actually affected our systems, and is the effect significant for the service we provide?" Boards should agree the thresholds in advance, service by service, so the incident lead is applying a definition rather than inventing one under pressure.

Signals that usually mean significant

• A regulated service is unavailable or degraded beyond an agreed threshold
• Data has been accessed, altered or stolen, or its integrity cannot be confirmed
• An attacker has gained privileged access to systems that support a regulated service
• Customers or other regulated organisations are affected, or likely to be
• You have had to invoke business continuity or disaster recovery plans

Write your own version of this list, approve it at board level and review it after every incident. The thresholds that matter for a water company are not the ones that matter for a managed service provider.

The Board Checklist: Ready Before Hour One

This is the core of the guide. Each item is something the board can ask for, see evidence of and track. Work through it now and use it to brief your audit or risk committee.

1. One accountable executive, with deputies

Somebody must own the decision to report and the content of what is sent. That should be a named executive with the authority to act at 3am, not a committee. Name deputies too, because incidents do not respect annual leave. The NCSC Board Toolkit is a good starting point for the governance conversation.

2. An agreed definition of significant

Agree the thresholds for each service you provide: duration of outage, number of customers affected, type of data involved and whether privileged systems are compromised. Record the reasoning, because a regulator will ask how you decided.

3. Templates that only need the facts filling in

Draft the 24 hour notification and the 72 hour report now, with approval routes agreed. On the day, nobody should be debating wording or tone. Keep copies offline, along with your regulator, NCSC, ICO and insurer contact details, in case your systems are unavailable.

4. Evidence you can trust within hours

You cannot decide whether systems have actually been affected without logs, alerts and someone who can read them. If you rely on a single in-house engineer or a supplier with no out of hours cover, your 24 hour clock may run out before anyone looks. 24/7 managed detection and response closes that gap for many organisations.

5. Suppliers who can meet your clock

If a managed service provider or cloud host suffers an incident that affects you, you need to know quickly enough to make your own report. Check that contracts require prompt notification, measured in hours rather than days, and that supplier contacts are current.

6. A rehearsed decision

The reporting decision should be practised, not discovered. Build it into a tabletop exercise with the people who would really make the call. Our guide to five tabletop scenarios for leadership teams includes ones that test exactly this.

What a Good 24 Hour Notification Looks Like

The initial notification is short by design. Regulators want to know early that something significant is happening, so they can spot patterns across sectors and offer help. They do not expect a finished investigation. The final format will be set by each regulator, but a well prepared template usually covers six things:

1. Who you are: the legal entity, the regulated service and a contact who can answer questions at any hour.
2. When you became aware: the date and time, and how the incident was detected.
3. What is affected: the services, systems and locations involved, and whether customers or other regulated organisations are affected.
4. What you know so far: a plain description of the incident, clearly separating confirmed facts from working assumptions.
5. What you are doing: containment steps taken, specialists engaged and the next update you expect to give.
6. Other reports made: for example to the ICO, the police or an EU authority, so regulators can coordinate.

Two habits make these notifications far easier. First, write in plain language and avoid speculation about who is behind the attack. Attribution is rarely clear in the first day and you may have to correct it later. Second, keep a copy of exactly what was sent, when and by whom, inside your decision log. The 72 hour report then becomes an update to that record rather than a fresh piece of writing under pressure.

It also helps to think about your audience. The people reading your notification are looking for impact on essential services and signs of a wider campaign. A short, factual note that arrives on time is far more useful to them, and far better for you, than a polished report that arrives late.

Who Does What in the First 72 Hours

Clarity on roles stops the most common failure: everyone assuming someone else has told the regulator. A simple ownership table, agreed in advance, removes that risk.

Keep the group small and the decision log running from the first minute. The log protects the organisation later, because it shows a regulator what you knew, when you knew it and why you acted as you did. It also makes the 72 hour report far quicker to write.

Lining It Up With the Rules You Already Have

The new duty sits alongside, not instead of, the reporting rules you already follow. One incident can trigger several reports to different bodies on different clocks.

The ICO's 72 hour rule for personal data breaches is unchanged. The existing NIS Regulations already require notification without undue delay and within 72 hours. Organisations with EU operations may also face NIS2 or DORA timelines. The practical answer is a single reporting plan that lists every obligation, its trigger and its owner, so the incident lead can work through them in order rather than from memory.

For a wider view of the first day of an incident, including what to preserve and who to call, see our guide to the first 24 hours of a cyber attack.

A 90 Day Plan for Boards

You do not need the final regulations to make real progress. This plan gets the foundations in place and leaves room to adjust once the detail is published.

Penalties are a reason to take this seriously, but not the main one. As introduced, the Bill proposes maximum fines of up to £17 million or 4% of worldwide turnover for the most serious breaches. The bigger cost is usually the one that comes from a slow, confused response: longer outages, angrier customers and a regulator who starts from the view that you were not prepared.

How Cybergen Can Help

We help boards and security teams get ready for the 24 hour clock and respond well when it starts:

• Incident response, with responders who help you contain, investigate and gather the facts your reports need
• Board tabletop exercises that rehearse the reporting decision against realistic scenarios
• 24/7 managed detection and response, so you know within hours whether systems have actually been affected
• Virtual CISO support to own the reporting plan, the definitions and the board reporting

If you would like a second opinion on your reporting readiness, talk to our team.

The Cyber Security and Resilience Bill is still before Parliament and its reporting rules may change. This checklist reflects the position as at 12 November 2026.

Frequently Asked Questions