Science & Technology · Cyber Resilience
The 24-Hour Clock Starts Before the Investigation Ends
September 29, 2026
When cyber risk moves faster than certainty, the hardest problem isn’t finding more information. It’s knowing when you have enough to act.
At 9:07 a.m., a company learns that hackers may be exploiting software people are already using. Maybe it helps run a hospital. Maybe it connects a small business to the internet. Maybe it sits inside a device in someone’s home. By 9:15, engineers want more data. Security wants validation. Lawyers want to know whether it must be reported. Leadership wants to know how many customers could be affected. The customers have a simpler question:
Am I safe?
Nobody has the complete answer yet. The clock does not care.
The Cyber Resilience Act’s (CRA) vulnerability and incident reporting obligations began September 11, 2026. It imposes a reporting timeline that begins at awareness, not completion. An early warning must be submitted without undue delay, and in any event within 24 hours of becoming aware of the qualifying event. A separate 72-hour notification also runs from awareness. Internal approval processes do not start or reset these clocks. [1]
This regulation addresses a specific operational reality: technology may already be under attack while the manufacturer is still determining what happened. You may never know the name of the vulnerable product. You may only know the organization that depends on it. Someone does not have to personally buy a piece of software to be affected when it fails. Your information could be at risk because an employer, government agency, university, pension administrator, vendor, or another organization in the chain relied on the software.
MOVEit Transfer is file-transfer software developed by Progress Software. In 2023, the CL0P ransomware group began exploiting a previously unknown vulnerability in the software on May 27. Progress Software publicly disclosed the vulnerability four days later, on May 31. This predates the CRA reporting requirements and is not being presented as a CRA violation. It illustrates the operational problem the CRA now addresses. While organizations were determining scope, affected versions, exposure, remediation, and customer risk, exploitation was already occurring. Customers needed immediate answers: Do I need to install a patch? Change credentials? Disconnect a device? Take a system offline? Is my data exposed? Can my organization safely continue using the product? For businesses and critical infrastructure—hospitals, manufacturers, utilities, transportation providers, government organizations, or small businesses—those questions become operational. The 24-hour requirement is not simply bureaucratic paperwork. Information may need to move quickly because exploitation and customer risk can still be unfolding. [3]
The software vulnerability may belong to the manufacturer. The consequences do not.
Organizations are built to resolve uncertainty before making consequential decisions. The CRA requires consequential decisions while uncertainty still exists. This collision is where compliance can fail.
In high-consequence investigations, the absence of a complete picture does not suspend the requirement to act. The discipline is to separate what is known from what is assessed or inferred. Distinguish investigative questions—Which versions are affected? What is the root cause?—from decision questions that cannot wait: Has awareness occurred? Who owns that determination? What evidence supports the decision?
At Hour 4, an organization may know enough to recognize a potentially reportable event without knowing its complete scope. This isn’t CSI. The lab does not produce the definitive answer before the commercial break. The operational challenge is knowing when incomplete evidence has nevertheless become sufficient evidence for a decision. Waiting for certainty can put an organization in conflict with the “without undue delay” requirement.
ENISA, the European Union Agency for Cybersecurity, operates the CRA’s Single Reporting Platform (SRP) used for required notifications. Assigned Representatives (ARs) are the people authorized to submit notifications on a manufacturer’s behalf. The CRA is difficult not simply because 24 hours is short. It is difficult because the regulatory clock and the investigative clock are running at the same time. ENISA indicates that associated ARs can continue submitting notifications, but drafts remain visible only to the AR who created them. Consider this scenario: It is Hour 19. The person preparing the warning becomes unavailable. Another AR logs in. [2]
The draft is not there.
Does the backup have the evidence, reasoning, authority, and context necessary to reconstruct what the organization knew, what remained uncertain, why the reporting threshold was considered met, what evidence supported that conclusion, what had already been decided, and what still needs to be submitted? Meanwhile, the original 24-hour clock is still running. This is more than a platform limitation. It exposes a continuity-of-operations problem and demonstrates that organizational risk frequently exists between systems, teams, authorities, and handoffs rather than within any single component.
Cyber risk rarely stays inside the company where it begins. Neither does uncertainty. When a manufacturer cannot turn evidence into a decision, uncertainty spreads outward: regulators do not know, customers do not know, downstream organizations do not know, and people may not know whether they need to act. HSG calls this The Intelligence Gap™: the distance between possessing information and converting it into timely, defensible action. AI can accelerate analysis, but human judgment still determines what evidence means, what remains unknown, whether a threshold has been crossed, who has authority, and what happens next.
To manage this, organizations should treat reporting readiness as a continuity exercise rather than a one-time compliance check. Leaders should draft an internal decision-support aid—a one-page record that tracks the signal and timestamp, awareness determination, evidence, confirmed facts, assessments, unknowns, deadlines, decision owner, ARs, evidence location, actions, and reasoning. This record does not replace official notification requirements. An incomplete internal document does not excuse a missed deadline. It serves as a defensible audit trail of the decision-making process during the window when facts are still forming. The important retrospective question is: "Given what you knew at the time, why did you do what you did?"
Mature product-security teams already have coordinated disclosure and incident-response processes. The useful question is whether those processes cover the specific reporting and continuity requirements of the CRA—not whether every organization needs a new governance structure. Existing workflows may suffice if they are tested for handoff and visibility under time pressure.
If the person preparing your first notification became unavailable at Hour 19, could someone else pick up the evidence, understand the reasoning, exercise the authority, and finish the job before Hour 24? If the answer requires a meeting to figure out, you may already have found the gap. HSG’s Decision Defensibility Briefing tests a critical reporting workflow before a real incident tests it for you—examining the evidence, authority, decision points, and handoffs between signal and action.
Request a Decision Defensibility Briefing