The 24-Hour Clock: Building an Incident Reporting Process That Survives a Real Breach

A serious cyber incident does not wait for your incident manager to return from holiday. It does not arrive during office hours, with a complete forensic timeline and a clear statement of impact.

It may begin at 02:17 with a suspicious administrator login, a disabled EDR agent or a ransomware operator moving laterally across your network. By the time someone confirms what is happening, the reporting clock may already be running.

For UK organisations, this is becoming a board-level readiness issue. The proposed Cyber Security and Resilience Bill would introduce a light-touch initial notification within 24 hours, followed by a fuller report within 72 hours for relevant regulated entities. The Bill is scheduled for Lords Report Stage on 26 October 2026, but it is not yet operative law and its final scope, thresholds and commencement arrangements may change.

The practical message is straightforward: you should be able to produce an accurate initial notification quickly, even while containment and investigation are still under way.

The 24-hour and 72-hour reporting model

The proposed model is designed to separate early warning from detailed investigation.

Stage	Timing	Purpose	Information required
Initial notification	Within 24 hours of becoming aware an incident is taking place	Alert the regulator and NCSC quickly so support and sector-wide intelligence can begin	Organisation name, affected service and brief incident details
Fuller report	After 72 hours	Provide a clearer assessment of cause, status and impact	Timing, nature, ongoing status, actual or likely impact, affected services and other useful information

The proposed Bill would apply to operators of essential services and relevant managed and digital service providers. It also broadens the focus towards harmful attacks such as ransomware and pre-positioning activity that may have significant UK impact, even if disruption has not yet occurred.

That matters because waiting for visible outage is increasingly unsafe. An attacker who has obtained privileged access, disabled security controls or positioned malware across critical systems may already represent a reportable risk.

What applies today?

The existing Network and Information Systems Regulations 2018 require an operator of an essential service to notify its competent authority of an incident with a significant impact on the continuity of that service. The notification must be made without undue delay and no later than 72 hours after the operator becomes aware of the incident.

The NIS Regulations are not the same as the proposed 24-hour/72-hour model.

The NIS Regulations 2018 remain relevant for in-scope organisations, including parts of the healthcare, energy, transport, water and digital infrastructure sectors. The correct competent authority depends on your sector and jurisdiction.

You can also report serious incidents to the National Cyber Security Centre (NCSC). However, an NCSC report does not automatically satisfy a regulatory reporting obligation. The NCSC is not your regulator, and its voluntary reporting service is separate from statutory notifications.

Why 24 hours is brutally short

Twenty-four hours sounds manageable until you remove the assumptions.

You may spend the first six hours trying to confirm whether an alert is a false positive. Another several hours may disappear while your team identifies affected systems, reaches the on-call decision-maker and works out whether the incident is still active.

In a ransomware event, the operational sequence may include:

• isolating endpoints and network segments;
• disabling compromised accounts;
• preserving evidence before rebuilding systems;
• checking backups and recovery options;
• determining whether data has been exfiltrated;
• contacting cyber insurers and legal advisers;
• briefing executives and trustees;
• identifying affected suppliers or customers; and
• deciding whether the incident meets a reporting threshold.

Detection time alone can consume the entire window.

This is why an incident reporting process cannot begin when the breach is confirmed. It must begin with the foundations that make fast assessment possible: reliable visibility, clear authority, usable records and 24/7 escalation.

Decide significance before the incident

The worst time to debate the meaning of “significant” is at 2am while systems are being encrypted.

Your organisation should pre-agree the factors that trigger escalation and reporting consideration. These should reflect both regulatory language and business impact, including:

• the number of users, staff, patients, customers or public services affected;
• the duration and likely duration of disruption;
• the geographical area affected;
• whether essential or critical services are unavailable;
• compromise of confidentiality, integrity, authenticity or availability;
• the sensitivity of affected data;
• the likelihood of onward impact through suppliers or managed services;
• whether the attacker retains privileged access; and
• potential economic, societal, safety or operational consequences.

The proposed Bill specifically points towards disruption, duration, affected users, geographical scope and compromise of data. Your internal threshold should be at least as clear.

Who decides and who signs off?

Define this in writing. A practical model might be:

1. SOC or IT operations identifies and records the event.
2. Incident lead classifies severity and activates the response plan.
3. CISO, Head of Information Security or IT Director recommends whether the event is potentially significant.
4. Legal and compliance assess regulatory, contractual and data protection obligations.
5. Executive sponsor or delegated director approves external communications where required.
6. Named reporting officer submits the notification and records the submission time.

Do not create a process that requires a single executive to be available before anyone can act. Appoint deputies, maintain current contact details and define what the incident lead is authorised to do without further approval.

The key principle is pre-authorised action. A reporting decision can be revisited as facts develop. A missed deadline cannot be undone.

Evidence you need before a breach

A regulator, insurer, board or forensic investigator will want to understand what happened, what you knew and when you knew it. That requires more than a collection of emails after the event.

Maintain the following before an incident occurs:

1. An accurate asset and service inventory

Record your critical applications, servers, endpoints, cloud services, identities, network devices, suppliers and business owners. Include dependencies.

You cannot assess impact quickly if you do not know which services rely on a compromised system.

2. A controlled incident log

Use a central, access-controlled log with time-stamped entries for:

• alerts received;
• actions taken;
• systems isolated;
• people contacted;
• decisions made;
• evidence collected;
• assumptions and unknowns; and
• reporting deadlines.

Ensure the log remains available if your primary collaboration platform is compromised.

3. Decision and escalation records

Record who made each material decision, when it was made, what information was available and why the decision was reasonable at that point.

This is not bureaucracy. It demonstrates disciplined control under pressure.

4. A communication trail

Keep a record of communications with your SOC, IT team, executives, legal advisers, insurer, suppliers, regulators and the NCSC. Use an out-of-band channel if your normal email or identity platform may be compromised.

5. A forensic timeline

Capture the earliest known suspicious activity, initial access, privilege escalation, lateral movement, data access, containment and recovery actions. Preserve relevant logs and avoid overwriting evidence through rushed remediation.

Your ransomware protection and recovery planning should explicitly address evidence preservation, not only backup restoration.

Build the workflow around five operational steps

Step 1: Detect and triage

Define which alerts require immediate human review. Prioritise indicators such as:

• ransomware behaviour or mass file changes;
• privileged account compromise;
• widespread EDR disablement;
• suspicious cloud administrator activity;
• unusual data transfers;
• exploitation of an internet-facing vulnerability; and
• signs of attacker persistence or pre-positioning.

Step 2: Activate the right people

Maintain a 24/7 call tree with primary and deputy contacts. Include IT, security, legal, compliance, communications, senior management, cyber insurance and key suppliers.

Test every number. A contact list that has not been tested is an assumption, not a control.

Step 3: Stabilise and assess

Contain the threat while gathering enough information to answer:

• What service is affected?
• Is the incident ongoing?
• What systems and data may be involved?
• What is the actual or likely operational impact?
• Could another organisation or supplier be affected?
• Does the incident meet your internal significance threshold?

Step 4: Notify using pre-drafted templates

Prepare separate templates for:

• initial regulator notification;
• fuller 72-hour report;
• NCSC notification;
• ICO assessment where personal data may be involved;
• cyber insurer notification;
• customer or supplier communications; and
• internal executive updates.

The initial notification should be short and factual. It is an early warning, not a finished forensic report. State clearly what is known, what is unknown and when the next update will be provided.

Step 5: Continue reporting and improve

A notification is not the end of the process. Maintain the incident log, update the regulator as required, preserve evidence and complete a structured post-incident review.

Document not only technical failures but also detection delay, decision delay and communication delay.

Test it with a tabletop exercise

Most organisations have an incident response plan. Far fewer have tested whether it works at night, with incomplete information and competing priorities.

Run a tabletop exercise at least annually. Higher-risk organisations should consider a six-monthly cadence, with technical simulations between executive exercises.

Test scenarios such as:

• ransomware affecting a critical service;
• a compromised Microsoft 365 administrator;
• a supplier breach affecting your systems;
• data exfiltration without immediate disruption; and
• an attacker pre-positioned across operational technology.

Require participants to produce the 24-hour notification and outline the 72-hour report. Measure:

• time to detect;
• time to escalate;
• time to identify the incident lead;
• time to reach a significance decision;
• time to produce a draft notification; and
• time to approve and submit it.

How a Managed SOC removes detection lag

A 24-hour reporting capability depends on knowing that an incident is taking place. That is where a Managed SOC or Managed Prevention and Response service can materially change the outcome.

A properly operated service provides:

• 24/7 threat detection across endpoints, networks, cloud and identity;
• alert triage and enrichment by security analysts;
• threat hunting for attacker activity that automated tools miss;
• pre-agreed containment actions;
• escalation to your named incident contacts;
• investigation support and an evidence trail; and
• regular reporting against detection and response performance.

This does not remove your accountability. It removes the assumption that your internal team will notice a serious attack at the right moment.

AOS Technologiies provides managed cybersecurity services for UK organisations, including continuous monitoring, endpoint protection, vulnerability management, incident response and compliance support. The objective is not to send you more alerts. It is to help you identify and act on the threats that matter.

Align reporting readiness with wider compliance

A tested incident process supports more than the incoming Bill.

It provides evidence for Cyber Essentials and Cyber Essentials Plus, particularly around secure configuration, malware protection, access control and incident management. It supports the continual improvement and documented operational controls expected under ISO 27001.

For financial services organisations, it also aligns with DORA-style expectations around ICT incident classification, escalation, reporting, resilience testing and management accountability. Public sector bodies, healthcare providers and critical suppliers face similar expectations through sector regulators, procurement requirements and customer assurance questionnaires.

Compliance is not achieved by owning a policy document. It is demonstrated when your team can execute under pressure.

Your pre-incident readiness checklist

Before your next serious incident, confirm that you have:

• A current asset, service and supplier inventory
• Named incident leads, deputies and 24/7 contact details
• Agreed significance and escalation criteria
• Regulator and NCSC reporting routes documented
• Pre-drafted 24-hour and 72-hour notification templates
• A secure incident log and out-of-band communications channel
• Legal, forensic, communications and insurer support arranged
• Centralised, retained and time-synchronised logs
• Evidence preservation procedures
• A tested ransomware response and recovery plan
• A completed tabletop exercise within the last 12 months

Build the clock before it starts

Every day without a tested incident reporting process is another day of avoidable risk.

Do not wait for the Cyber Security and Resilience Bill to become law. Build the capability now. Detect earlier. Decide faster. Report accurately. Preserve trust.

Book a free 30-minute cybersecurity review with AOS Technologiies to assess your monitoring, escalation and reporting readiness.

Know your exposure. Test your process. Defend your organisation.

Regulatory sources

• Cyber Security and Resilience Bill: Incident reporting factsheet
• Cyber Security and Resilience Bill parliamentary stages
• NCSC incident management guidance
• Network and Information Systems Regulations 2018