The 72-Hour Reporting Obligation

What the UK Cyber Security and Resilience Bill’s Incident Reporting Window Means for OT Organisations

The UK Cyber Security and Resilience Bill, as currently drafted, introduces a two-stage incident reporting obligation. An early warning must be issued within 24 hours of becoming aware of a significant incident. A fuller report with enough substance to be credible must follow within 72 hours. Reports go to both your sector regulator and the NCSC simultaneously.

For IT environments, 72 hours is tight but workable. Most IT teams already maintain the kind of documented, current knowledge of their systems that a credible report requires. For OT environments, the same window is a fundamentally different challenge, and understanding why reveals something important about the state of OT risk management in most organisations today.

Why a credible report is harder to write than it sounds

A credible incident report isn’t just a timeline of when a problem was detected and what was shut down. A regulator asking for substance will want to know which systems were affected and what those systems do operationally. They’ll want to know what data or process capability those systems hold, what the likely attack path was, and what the scope of exposure is or was. They’ll want enough to assess the severity and whether the response taken was proportionate.

Writing that report requires pre-existing knowledge. You can’t reconstruct it under pressure in the hours after an incident, from systems you may not be able to access and records you may not have maintained. The information that goes into a credible 72-hour report has to exist before the clock starts. And in many OT environments, it doesn’t exist.

The OT knowledge gap

IT teams tend to have this by default. Configuration management databases, asset registers, network diagrams, and patch records are standard practice in IT operations.

OT environments generally can’t say the same. OT estates are usually built over decades, equipment is added without formal documentation, and network diagrams were accurate at commissioning and haven’t been touched since. The engineer who knows what everything does and how it connects is often a person, not a record. When that person is unavailable, or when the incident itself disrupts normal operations, that knowledge doesn’t transfer easily into a written report with a three-day deadline.

The result is that most organisations faced with a significant incident would be writing their 72-hour report from a standing start. They’d be trying to establish what’s on the network, what was affected, and what it does, at exactly the moment when systems may be offline, staff are managing the incident, and time is running out.

What the 72-hour window tests

The reporting obligation is, in practice, a test of pre-incident visibility. It doesn’t test how well an organisation responds to an attack. It tests whether an organisation knew its own environment well enough, before anything went wrong, to describe what happened accurately once it did.