24-Hour Incident Reporting Guide

Meeting the New Cyber Incident Notification Requirements

A practical guide to preparing for faster incident reporting under the Cyber Security and Resilience Bill

Published: January 2026

Author: Dead Simple Computing Ltd

Version: 1.0

Contents

• Executive Summary
• What's Changing
• Who Must Report
• What Must Be Reported
• Who You Report To
• The 24-Hour Timeline
• Preparing Your Organisation
• Incident Classification
• Notification Templates
• The Incident Reporting Process
• Customer Notification
• Common Mistakes to Avoid
• Incident Reporting Checklist
• How DSC Can Help

1. Executive Summary

The Cyber Security and Resilience Bill introduces a 24-hour initial incident notification requirement, replacing the current 72-hour timeline under NIS Regulations. This significantly accelerates how quickly organisations must report cyber incidents.

Key changes:

• Initial notification within 24 hours (down from 72 hours)
• Report to NCSC and sector regulator (dual notification)
• Expanded trigger: incidents "capable of having" significant impact
• Customer notification required for those adversely affected
• Higher penalties for non-compliance

What you need:

• 24/7 detection capability
• Pre-defined incident classification criteria
• Prepared notification templates
• Designated reporting contacts
• Tested notification procedures
• Customer communication process

The challenge:

24 hours is not much time. You can't draft notifications from scratch, debate what to report, or search for contact details during an incident. Preparation is essential.

2. What's Changing

Current Requirements (NIS Regulations 2018)

New Requirements (Cyber Security and Resilience Bill)

Why the Change

The Government's rationale:

• Earlier visibility - NCSC can provide earlier support and identify wider threats
• Faster response - Coordinated response across sectors
• Trend identification - Detect campaigns targeting multiple organisations
• Alignment with NIS2 - EU directive has similar requirements
• Lessons from incidents - Delayed reporting hampered response to major incidents

Expanded Trigger

The change from "significant impact" to "capable of having significant impact" is important.

Previously: You only reported if the incident actually caused significant impact.

Now: You must report if the incident could have caused significant impact, even if:

• You contained it before major impact
• The actual impact was limited by your response
• It was a near-miss

This means more incidents will require reporting.

3. Who Must Report

Currently In Scope (NIS Regulations)

Operators of Essential Services (OES):

• Energy (electricity, oil, gas)
• Transport (air, rail, maritime, road)
• Health
• Drinking water supply and distribution
• Digital infrastructure

Relevant Digital Service Providers (RDSPs):

• Online marketplaces
• Search engines
• Cloud computing services

Newly In Scope (Under the Bill)

Managed Service Providers (MSPs):

If you provide managed IT or security services to other organisations, you will likely be in scope for incident reporting.

Data Centres:

Large data centre operators above capacity thresholds.

Designated Critical Suppliers:

Suppliers designated as critical by regulators.

Supply Chain Implications

Even if not directly in scope, you may need to report incidents to customers:

• Contractual notification obligations
• Customer incident response requirements
• Flow-down from regulated customers
• Maintaining trust and relationships

4. What Must Be Reported

Reportable Incidents

Incidents that must be reported:

• Incidents that have had a significant impact on the continuity of the essential service or digital service

• Incidents capable of having a significant impact, even if contained

• Near-misses where significant impact was narrowly avoided

Determining "Significant Impact"

Factors to consider:

Service impact:

• Duration of disruption
• Geographic spread
• Number of users/customers affected
• Criticality of affected functions

Data impact:

• Volume of data affected
• Sensitivity of data
• Potential harm to individuals

Financial impact:

• Direct financial losses
• Costs of response and recovery
• Potential regulatory penalties

Reputational impact:

• Public awareness
• Customer confidence
• Sector-wide implications

Examples

Likely reportable:

• Ransomware affecting operational systems
• Data breach exposing customer information
• Compromise of privileged credentials with system access
• Supply chain attack affecting your services
• Extended service outage from cyber cause

Possibly reportable (assess impact):

• Contained malware infection
• Phishing attack with limited credential compromise
• Attempted intrusion detected and blocked
• Brief service disruption quickly resolved

Unlikely reportable:

• Blocked phishing email
• Routine malware detected and cleaned
• Failed authentication attempts
• Vulnerability discovered but not exploited

When In Doubt

If uncertain whether an incident is reportable:

• Err on the side of reporting
• Make an initial notification indicating uncertainty
• Provide updates as you learn more
• Document your reasoning

Under-reporting carries regulatory risk. Over-reporting demonstrates diligence.

5. Who You Report To

Dual Notification Required

Under the Bill, you must notify both:

• Your sectoral regulator (competent authority)
• The National Cyber Security Centre (NCSC)

Sectoral Regulators

Note: Contact details may change. Verify current contacts with your regulator.

NCSC

NCSC Incident Reporting:

• Web: ncsc.gov.uk/report
• Phone: Available for significant incidents

The NCSC provides:

• Technical guidance
• Threat intelligence
• Support for significant incidents
• Coordination with other affected organisations

Notification Sequence

Within 24 hours:

• Notify sectoral regulator
• Notify NCSC

These can be done in parallel. Don't wait to complete one before starting the other.

Recording Your Notifications

Document:

• Time of notification
• Method (email, portal, phone)
• Who you notified
• What information you provided
• Any reference numbers received
• Follow-up actions agreed

6. The 24-Hour Timeline

When the Clock Starts

The 24-hour period begins when you become aware of an incident that is or may be reportable.

"Become aware" typically means:

• Detection by security tools with human review
• Report from staff or third party
• Notification from customer or partner
• Discovery during investigation

The clock does not start:

• When investigation is complete
• When you're certain of the impact
• When you've contained the incident
• When you're ready to report

What 24 Hours Looks Like

Hour 0: Incident detected/reported

Hours 0-4: Initial triage

• Is this a potential security incident?
• Initial assessment of scope and impact
• Is this potentially reportable?

Hours 4-8: Assessment

• What systems/data are affected?
• What is the potential impact?
• Confirm reportability

Hours 8-16: Notification preparation

• Gather information for notification
• Complete notification template
• Identify any immediate support needs

Hours 16-24: Notification

• Submit notification to regulator
• Submit notification to NCSC
• Document notification details

This is tight. There's no time for:

• Extensive investigation first
• Multiple approval cycles
• Drafting from scratch
• Searching for contact details

What You Know at 24 Hours

Your initial notification will be incomplete. That's expected.

You may know:

• That an incident occurred
• Approximate timing
• Initial scope assessment
• Immediate containment actions
• Basic nature of the incident

You probably won't know:

• Full scope and impact
• Root cause
• Complete data affected
• Attribution
• Full timeline

That's OK. The initial notification is to alert authorities quickly. Detailed information comes in follow-up reports.

7. Preparing Your Organisation

Detection Capability

You can't report what you don't detect.

Ensure you have:

• Security monitoring on critical systems
• Log collection and alerting
• Endpoint detection capability
• Email security with alerting
• Network monitoring

Consider:

• 24/7 monitoring capability (internal or MDR service)
• After-hours detection and escalation
• Weekend and holiday coverage

Pre-Defined Criteria

Don't debate reportability during an incident.

Define in advance:

• What incident types are automatically reportable
• Thresholds that trigger reporting
• Decision tree for borderline cases
• Who makes the reporting decision

Designated Personnel

Identify now:

Incident Response Lead

• Makes decisions during incidents
• Authority to approve notifications
• Available 24/7 or clear backup

Notification Owner

• Responsible for preparing and submitting notifications
• Knows the reporting process
• Has access to templates and contacts

Executive Sponsor

• Senior leader informed of reportable incidents
• Available for escalation
• Authority for customer communication

Legal/Compliance

• Available for guidance on notification
• Review of customer notifications
• Regulatory relationship management

Contact Information

Maintain and regularly verify:

Regulators:

• Sector regulator contact details
• NCSC reporting contacts
• Any portal login credentials

Internal:

• Incident response team contacts
• Executive escalation contacts
• Legal/compliance contacts
• Communications/PR contacts

External:

• Cyber insurance claims line
• Legal counsel
• Incident response retainer (if applicable)
• Key customer security contacts

Documentation and Templates

Prepare in advance:

• Incident classification criteria
• Notification decision flowchart
• Initial notification templates
• Follow-up report templates
• Customer notification templates
• Internal escalation procedures

8. Incident Classification

Classification Framework

Create a framework that maps incident types to reporting requirements.

Example classification:

Automatic Reporting Triggers

Define scenarios that automatically require notification:

Always report:

• Ransomware affecting operational systems
• Confirmed data breach with personal data
• Compromise of privileged accounts with evidence of access
• Attack affecting service delivery
• Supply chain compromise affecting your systems

Assess and likely report:

• Malware on multiple systems
• Unauthorised access detected
• Significant phishing success
• Third-party breach affecting your data

Decision Support

For borderline cases, consider:

• Could this have caused significant impact?
• If you hadn't detected it quickly?
• If your response had been slower?
• If the attacker had progressed further?

• Would a similar incident at a peer organisation concern you?
• If you heard about this through media?
• If a regulator asked about it?

• Is there any doubt?
• When uncertain, report
• You can provide updates if impact is less than expected

9. Notification Templates

Initial Notification Template

Prepare a template that can be completed quickly:

CYBER SECURITY INCIDENT NOTIFICATION

Initial Report - [24-Hour Notification]



ORGANISATION DETAILS

Organisation name: [Name]

Sector: [Sector]

Contact name: [Name]

Contact phone: [Number]

Contact email: [Email]

Reference (if updating): [Reference]



INCIDENT SUMMARY

Date/time detected: [DD/MM/YYYY HH:MM]

Date/time occurred (if known): [DD/MM/YYYY HH:MM]

Brief description: [2-3 sentences describing what happened]



INCIDENT TYPE

[ ] Ransomware

[ ] Data breach

[ ] Unauthorised access

[ ] Denial of service

[ ] Malware infection

[ ] Supply chain compromise

[ ] Other: [Describe]



IMPACT ASSESSMENT (Initial)

Services affected: [List services]

Systems affected: [List systems/count]

Data potentially affected: [Description]

Current service status: [Operational/Degraded/Offline]

Estimated users/customers affected: [Number/Unknown]



ACTIONS TAKEN

Containment: [Brief description]

Investigation status: [Brief description]

Recovery actions: [Brief description]



SUPPORT REQUIRED

[ ] None at this time

[ ] Technical guidance requested

[ ] Coordination with other organisations

[ ] Other: [Specify]



ADDITIONAL INFORMATION

[Any other relevant information]



FOLLOW-UP

Expected time of next update: [Timeframe]

Expected time of detailed report: [Timeframe]

Follow-Up Report Template

For the detailed report (typically within 72 hours):

CYBER SECURITY INCIDENT NOTIFICATION

Detailed Report



REFERENCE

Initial notification reference: [Reference]

Initial notification date: [Date]



INCIDENT TIMELINE

First compromise (estimated): [Date/Time]

Incident detected: [Date/Time]

Containment started: [Date/Time]

Containment completed: [Date/Time]

Recovery started: [Date/Time]

Recovery completed: [Date/Time or ongoing]



DETAILED DESCRIPTION

[Comprehensive description of the incident]



ROOT CAUSE (If known)

[Description of how the incident occurred]



FULL IMPACT ASSESSMENT

Systems affected: [Detailed list]

Data affected: [Detailed description]

Service impact: [Detailed description]

Duration of impact: [Timeframe]

Users/customers affected: [Number]

Financial impact (estimated): [Amount/Unknown]



RESPONSE ACTIONS

[Detailed description of response]



REMEDIATION ACTIONS

Completed: [List]

In progress: [List]

Planned: [List]



LESSONS LEARNED

[Initial lessons identified]



ONGOING ACTIONS

[Actions still in progress]



ATTACHMENTS

[List any attachments - IoCs, timeline, etc.]

10. The Incident Reporting Process

Process Overview

INCIDENT DETECTED

        ↓

INITIAL TRIAGE (Is this a security incident?)

        ↓

CLASSIFICATION (What severity? Potentially reportable?)

        ↓

INCIDENT RESPONSE (Contain, investigate, recover)

        ↓ (In parallel)

NOTIFICATION DECISION (Within first hours)

        ↓

PREPARE NOTIFICATION (Using template)

        ↓

SUBMIT NOTIFICATION (Regulator + NCSC)

        ↓

DOCUMENT NOTIFICATION (Time, method, content)

        ↓

CONTINUE RESPONSE

        ↓

FOLLOW-UP REPORTING (As required)

        ↓

CUSTOMER NOTIFICATION (If applicable)

        ↓

CLOSE AND LESSONS LEARNED

Key Decision Points

Decision 1: Is this a security incident?

• Made by: First responder / SOC
• Timeframe: Within 1 hour of detection
• If yes: Escalate to incident response

Decision 2: Is this potentially reportable?

• Made by: Incident Response Lead
• Timeframe: Within 4 hours
• If yes: Begin notification preparation
• If uncertain: Treat as reportable

Decision 3: Final reporting decision

• Made by: Incident Response Lead (or designated authority)
• Timeframe: Within 12 hours
• Document reasoning either way

Decision 4: Customer notification required?

• Made by: Incident Response Lead + Legal
• Timeframe: As soon as customer impact is understood
• Consider: Contractual requirements, impact on customers

Parallel Tracks

Incident response and notification happen in parallel:

Track 1: Response

• Containment
• Investigation
• Eradication
• Recovery

Track 2: Notification

• Assess reportability
• Prepare notification
• Submit notification
• Follow-up reporting

Don't let notification delay response, or response delay notification.

11. Customer Notification

When Customer Notification Is Required

Under the Bill:

Organisations must notify customers "likely to be adversely affected" by an incident "as soon as reasonably practicable."

Contractual requirements:

Many contracts require incident notification regardless of regulatory requirements. Check your contracts for:

• Notification triggers
• Notification timeframes (often 24-48 hours)
• Required content
• Notification method

Customer Notification Content

What to include:

• What happened (high-level)
• When it happened
• What data/services were affected
• What you're doing about it
• What customers should do (if anything)
• How to get more information
• Contact for questions

What not to include:

• Speculation about attribution
• Detailed technical information
• Information that could help attackers
• Unverified claims about impact

Customer Notification Template

SECURITY INCIDENT NOTIFICATION



Dear [Customer],



We are writing to inform you of a cyber security incident 

that may affect [your data / our services to you].



WHAT HAPPENED

On [date], we detected [brief description of incident].



WHAT INFORMATION WAS INVOLVED

[Description of data/services affected]



WHAT WE ARE DOING

We immediately [containment actions]. We are working with 

[cyber security experts / authorities] to investigate and 

resolve this incident. [Brief description of ongoing actions]



WHAT YOU CAN DO

[Any recommended actions for the customer]



CONTACT INFORMATION

If you have questions, please contact:

[Name, email, phone]



We take the security of your [data/services] seriously and 

apologise for any concern this may cause. We will provide 

updates as more information becomes available.



[Signature]

Coordinating Customer Notification

Considerations:

• Timing: Balance speed with accuracy
• Consistency: Ensure consistent message across customers
• Method: Email, phone, portal - per contract requirements
• Documentation: Record all notifications sent
• Follow-up: Plan for customer questions and updates

12. Common Mistakes to Avoid

Before an Incident

Mistake: No preparation

• No templates ready
• No contact details documented
• No classification criteria defined
• Result: Scrambling during incident, missed deadline

Mistake: No detection capability

• Limited or no monitoring
• No 24/7 coverage
• Alerts not reviewed promptly
• Result: Incidents discovered late, clock already running

Mistake: Unclear responsibilities

• No one designated for notification
• Unclear approval authority
• No backup personnel
• Result: Delays, confusion, missed notifications

During an Incident

Mistake: Waiting for complete information

• Want full picture before reporting
• Investigation delays notification
• Result: Missed 24-hour deadline

Mistake: Underestimating impact

• "It's probably nothing"
• Assume containment means no need to report
• Result: Under-reporting, regulatory issues later

Mistake: Over-complicated approval

• Multiple approval layers
• People unavailable
• Result: Delays, missed deadlines

Mistake: Forgetting dual notification

• Report to regulator only
• Or NCSC only
• Result: Incomplete compliance

After an Incident

Mistake: No follow-up

• Initial notification only
• No detailed report submitted
• Result: Regulatory concern, incomplete record

Mistake: No documentation

• Notification times not recorded
• Content not preserved
• Decisions not documented
• Result: Can't demonstrate compliance if questioned

Mistake: Not learning

• No review of notification process
• Same issues next time
• Result: Repeated failures

13. Incident Reporting Checklist

Preparation (Do Now)

Detection

• ☐ Security monitoring on critical systems
• ☐ 24/7 detection capability (or plan for it)
• ☐ Clear escalation from detection to response

People

• ☐ Incident Response Lead designated
• ☐ Notification Owner designated
• ☐ Executive Sponsor identified
• ☐ Backup personnel identified
• ☐ Contact details documented and current

Process

• ☐ Incident classification criteria defined
• ☐ Reporting decision flowchart created
• ☐ Notification templates prepared
• ☐ Process documented and communicated
• ☐ Process tested/exercised

Contacts

• ☐ Sector regulator contact verified
• ☐ NCSC reporting method confirmed
• ☐ Internal escalation contacts current
• ☐ Customer security contacts documented
• ☐ Legal/insurance contacts documented

During Incident

Initial (0-4 hours)

• ☐ Incident classified
• ☐ Potential reportability assessed
• ☐ Incident Response Lead engaged
• ☐ Initial containment underway

Assessment (4-12 hours)

• ☐ Scope assessed
• ☐ Impact assessed
• ☐ Reporting decision made and documented
• ☐ Notification preparation started (if reportable)

Notification (12-24 hours)

• ☐ Notification template completed
• ☐ Notification reviewed (if time allows)
• ☐ Notification submitted to regulator
• ☐ Notification submitted to NCSC
• ☐ Submission times documented
• ☐ Reference numbers recorded

Ongoing

• ☐ Follow-up report prepared
• ☐ Follow-up report submitted
• ☐ Customer notification assessed
• ☐ Customer notification sent (if required)
• ☐ All notifications documented

Post-Incident

• ☐ Notification process reviewed
• ☐ Lessons learned documented
• ☐ Process improvements identified
• ☐ Templates updated if needed
• ☐ Contact details verified

14. How DSC Can Help

Dead Simple Computing helps organisations prepare for and meet incident reporting requirements.

Detection and Monitoring

MDR (Managed Detection & Response)

• 24/7 threat monitoring
• Human-led response
• Incident detection at any hour
• Initial triage and escalation

SIEM

• UK-based log management
• Security event correlation
• Alerting and reporting
• Evidence preservation

Incident Response Support

Incident Response Planning

• Develop incident response plans
• Create notification procedures
• Design classification criteria
• Prepare templates

Tabletop Exercises

• Test notification processes
• Practice decision-making
• Identify gaps
• Build muscle memory

Compliance Support

vCISO Services

• Regulatory relationship support
• Notification oversight
• Compliance management
• Board reporting on incidents

Contact us:

• Web: deadsimplecomputing.co.uk
• Email: [email protected]
• Phone: 0118 359 2220

Resources

NCSC:

• Incident reporting: ncsc.gov.uk/report
• Incident response guidance: ncsc.gov.uk

Sector regulators:

• Contact your sector regulator for specific guidance

Cyber Security and Resilience Bill:

• Parliament website for latest Bill status

About This Guide

This guide was prepared by Dead Simple Computing Ltd in January 2026 to help organisations prepare for the 24-hour incident reporting requirements under the Cyber Security and Resilience Bill.

Specific requirements may vary as the Bill progresses through Parliament and implementing regulations are published. Organisations should monitor developments and seek appropriate advice.

© 2026 Dead Simple Computing Ltd. All rights reserved.