The 24-Hour Cyber Clock Has Started: Can You Prove What You Knew, When You Knew It — and What You Did?

Cyber regulation is beginning to measure organisations in hours rather than audit cycles. That creates a challenge that incident response plans alone cannot solve: can you assemble defensible evidence quickly enough to explain what happened, what you knew, what controls were affected and why you made the decisions you did?

For years, cyber security assurance has largely operated on a periodic model. Organisations define controls, write policies and procedures, collect evidence, perform assessments and respond to audit findings. The process is familiar and, in many cases, effective. It works particularly well when assurance is intended to demonstrate that a control environment existed at a particular point in time and where the organisation has days or weeks to gather supporting material, speak to subject-matter experts and assemble an evidence pack.

That model becomes much harder to sustain when regulation starts measuring response in hours rather than weeks. On 11 September 2026, reporting obligations under the EU Cyber Resilience Act became applicable to manufacturers of products with digital elements. Manufacturers must now report certain actively exploited vulnerabilities and severe security incidents, with an early warning potentially required within 24 hours of becoming aware of the issue and a fuller notification following within 72 hours. In the UK, the Cyber Security and Resilience Bill is moving in a similar direction, proposing a two-stage reporting model for regulated organisations with an initial notification within 24 hours and a fuller report within 72 hours.

These are different regimes covering different organisations and circumstances, but the direction of travel is clear. Cyber security is shifting from periodic demonstration towards operational accountability, and that changes what effective assurance needs to look like.

The difficult question is not whether you have an incident response plan

Most established organisations already have one. They will have incident management procedures, escalation paths, security monitoring, vulnerability management processes, communications plans and defined responsibilities. Those documents matter, but they do not in themselves answer the questions that arise when a potentially serious incident is discovered at 14:37 on a Tuesday afternoon.

Within minutes, the organisation may need to understand what happened, when it first became aware of the event, which systems and services are affected, which vulnerabilities may be involved and whether the incident is still developing. It may need to determine which security controls should have prevented, detected or limited the event, whether those controls were actually operating as expected and what evidence supports that conclusion. It may also need to understand whether customers or suppliers are affected, which regulatory obligations apply and whether the available information is sufficient to justify a decision to report.

The critical question is therefore not simply whether the organisation possesses evidence. It is whether it can produce and interpret that evidence quickly enough to support a defensible decision while the clock is running.

Twenty-four hours is not very long

A 24-hour reporting requirement sounds manageable until we consider where the information needed to understand an incident actually resides. Some of it may be in a SIEM, some in an endpoint management platform, some in vulnerability scanners, identity systems, cloud security tooling or asset inventories. Other relevant information may sit in ticketing systems, supplier contracts, architecture documents, risk registers or policies. A significant proportion may also exist only in the experience and knowledge of individual people.

The organisation may therefore possess everything it needs, but that does not mean it can assemble it efficiently. Traditional assurance often relies on evidence being collected after somebody asks for it. An auditor asks how privileged access is controlled, somebody finds the policy, another person exports a configuration, someone else produces an access review and a technical team explains what the output means. Over time, an evidence pack is constructed and a conclusion is reached.

That model works when the organisation has several weeks. It becomes much less effective when the relevant question must be answered in hours. Evidence that exists but cannot be located, understood and related to the issue quickly enough has limited operational value.

From evidence repositories to evidence relationships

The solution is not simply to collect more evidence. Many organisations already have enormous quantities of it. The harder challenge is understanding the relationships between different forms of evidence and the controls, assets and obligations they support.

Consider a compromised endpoint. Knowing its operating system version is useful, as is knowing that endpoint protection was installed and that a policy required a particular security configuration. However, the important assurance questions go further. Was that endpoint actually within the intended scope of the control? What configuration should have been applied? Was the configuration present on that specific device at the relevant time? When was it last verified? Was an exception recorded? Had vulnerability management identified a weakness, and if so, had remediation been assigned and completed?

This is no longer a document-management problem. It is a relationship problem. Effective assurance depends on maintaining traceable connections between assets, risks, controls, obligations, implementation, evidence, assessments and decisions. When something goes wrong, those relationships become critical because they allow the organisation to understand not only what information exists, but what that information actually proves.

Without those connections, an investigation can quickly become an exercise in organisational archaeology. With them, the organisation has the beginnings of a defensible record of its security posture before, during and after an event.

What did you know, and when did you know it?

This may become one of the most important assurance questions of the next few years because cyber incidents rarely arrive fully formed. At 14:37, an alert may indicate suspicious activity. Thirty minutes later, analysts may believe an endpoint has been compromised. A few hours after that, evidence may suggest lateral movement, and by the following morning the organisation may understand that a customer-facing service is potentially affected.

The interpretation of the event changes as new evidence becomes available. That makes provenance important. Organisations should be able to reconstruct not only the final conclusion but the state of knowledge that existed when significant decisions were made. They should know what evidence was available, where it originated, when it was collected, whether it was current, who reviewed it, what conclusion was reached and what information was still missing.

This matters because hindsight changes the apparent quality of a decision. Something that appears obvious three weeks after an incident may have been far from obvious during the first six hours. A defensible assurance process therefore needs to preserve not simply what the organisation eventually discovered, but what it reasonably understood at a particular point in time and why it acted on that understanding.

Control existence is not control effectiveness

Time-sensitive incident reporting also exposes another long-standing weakness in traditional compliance activity: the difference between demonstrating that a control exists and proving that it worked.

A security standard may require multi-factor authentication, the identity platform may support it and a policy may mandate its use. An audit six months earlier may even have confirmed that MFA was configured correctly. None of that proves that MFA was actually enforced for the account involved in a specific incident. Likewise, a vulnerability management process may require critical vulnerabilities to be remediated within 14 days, but the important questions are whether the affected asset was visible to the scanner, whether the vulnerability was detected, whether a remediation ticket was generated, whether responsibility was assigned and whether the issue was resolved.

Control design tells us what should happen. Evidence tells us what did happen. Assurance is the process of determining whether that evidence is sufficient to support the conclusion that the control was effective. That is a far more demanding standard than simply proving that a policy or process exists, but it is also far more useful when an organisation is trying to understand the significance of a real incident.

The answer is not another dashboard

The cyber security industry has become very good at producing dashboards. They display vulnerabilities, compliance percentages, alerts, assets, incidents, configuration status and risk scores, but they are usually views into individual systems. An incident does not respect those boundaries.

Understanding a significant cyber event may require information from ten different technical platforms, several policies, multiple teams and perhaps a supplier. What organisations increasingly need is not another dashboard but an assurance layer capable of bringing those sources together and interpreting them in context. Such a capability must understand which evidence is relevant to which obligation, whether that evidence is current, whether it conflicts with other information and whether it demonstrates design, implementation or actual operation.

It must also be capable of identifying gaps. If the organisation cannot prove that a control was operating, that uncertainty should be visible rather than silently replaced with an assumption. The objective is not to create the appearance of certainty but to make the strength of the evidence, and the limits of the organisation's knowledge, explicit.

AI can help — but it cannot become the evidence

Artificial intelligence has an important role to play because the volume of security evidence has already exceeded what most assurance teams can continuously review manually. AI can classify documents, extract relevant information, identify relationships, compare evidence against control requirements, highlight inconsistencies and reduce the amount of material a human assessor has to read.

The danger comes when the AI-generated conclusion begins to replace the evidence rather than helping people understand it. If an AI system concludes that a control is effective, the organisation should still be able to explain why. It should be possible to identify which evidence supports the conclusion, where that evidence originated, how current it is, whether contradictory evidence exists, how confident the organisation should be and what information remains missing.

The objective should therefore not be automated compliance. It should be AI-assisted, evidence-led assurance in which the human decision-maker remains accountable. Speed without traceability simply produces conclusions faster; speed combined with traceability can produce defensible assurance.

From point-in-time assurance to decision-ready assurance

The 24-hour reporting clock highlights a weakness that has existed for much longer than these particular regulatory requirements. Most organisations still perform assurance retrospectively. Evidence is collected because an audit is approaching, controls are examined because an assessment has begun and documentation is refreshed because somebody has requested it.

The underlying security systems may operate continuously, but the assurance process frequently does not. That separation is becoming increasingly difficult to sustain. Organisations do not necessarily need continuous auditing, but they do need continuous assurance readiness: the ability to understand their current security posture without reconstructing it from scratch every time somebody asks a difficult question.

That means maintaining the relationships between requirements, controls and evidence as the environment changes. It means knowing where evidence comes from, when it was last validated, what control it supports and whether the organisation's confidence in that control has changed. It also means identifying gaps before an incident, audit or regulatory deadline exposes them.

The goal is not to have an auditor permanently looking over everybody's shoulder. It is to make the organisation decision-ready, so that when a board member, regulator, customer or incident commander asks an important question, a defensible answer can be produced while that answer still matters.

The real test of assurance happens when the clock is running

Cyber security frameworks, policies, audits and certifications remain important, but none of them individually answer the question an organisation may suddenly face during a developing incident: what is actually happening, which controls are working, what evidence supports that view and how certain are we?

Increasingly time-sensitive cyber reporting requirements make that distinction harder to ignore. For manufacturers covered by the Cyber Resilience Act, part of that future arrived on 11 September 2026. In the UK, the Cyber Security and Resilience Bill points in a similar direction, although its proposed measures remain subject to the parliamentary process and subsequent implementation.

The organisations best prepared for this environment will not necessarily be those with the largest collections of policies, screenshots, reports and audit artefacts. They will be those that can rapidly establish what they know, explain why they believe it, identify what they do not know and preserve the evidence behind the decisions they make.

Because when the cyber clock starts, having evidence is no longer enough. The real measure of assurance is whether you can turn that evidence into a defensible decision before the clock runs out.