Every regulatory disclosure rule asks the same question. Each calls it something else
Falco Feeds extends the power of Falco by giving open source-focused companies access to expert-written rules that are continuously updated as new threats are discovered.
When I spoke about the EU regulatory landscape for banks and fintechs last year, I noted that the Cyber Resilience Act (CRA) had entered into force but would not legally apply until December 2027. That is still true for most of the CRA, but not for the framework’s reporting obligations.
As of September 11, 2026, manufacturers of products with digital elements sold into the EU market have to report actively exploited vulnerabilities and severe incidents. These organizations are required to send an early warning to the European Union Agency for Cybersecurity (ENISA) and the relevant national Computer Security Incident Response Team (CSIRT) within 24 hours. This must then be followed by a more detailed notification within 72 hours, and a final report within 14 days for a vulnerability or one month for a severe incident. The new rule doesn’t just apply to new products, but to products already on the market as well.
For most regulated organizations, that isn’t a new obligation, just a new disclosure clock added to a pile of existing ones. And if you’re a software vendor selling into highly regulated industries, it’s worse than that: Your notification is the event that also starts your customers' clocks.
Deadlines usually get all the attention because they’re the easiest thing to put on a board slide, but those deadlines are downstream of one key judgement. That judgement is where most organizations actually fail.
But you can't make that judgement clearly and confidently until you make it past the deadlines.
The clocks are multiplying
Here’s a list of some concurrent timelines a global organization may be tracking:
- General Data Protection Regulation (GDPR) Article 33. Regulated entities must notify the supervisory authority without undue delay, no later than 72 hours after becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to individuals’ rights and freedoms. Under Article 34, if the risk to individuals is high, you notify them too.
- Network and Information Security 2 (NIS2) Article 23. Regulated entities must deliver a 24-hour early warning after becoming aware of a significant incident, a fuller notification at 72 hours, and a final report at one month.
- Digital Operational Resilience Act (DORA). Regulated entities must send an initial notification within four hours of classifying an incident as major, and in no case later than 24 hours from becoming aware of it. This should be followed by an intermediate report at 72 hours and a final report at one month.
- Securities and Exchange Commission (SEC) Form 8-K, Item 1.05. Organizations must disclose a material cybersecurity incident within four business days of determining it is material.
- Cyber Incident Reporting for Critical Infrastructure Act (CIRCIA). Cybersecurity and Infrastructure Security Agency (CISA) is expected to finalize CIRCIA in September 2026. Once enacted, it’s expected to mandate regulated entities to report a covered cyber incident within 72 hours of reasonably believing one occurred, and a ransom payment within 24 hours of disbursing it.
- The CRA. As explored above, regulated entities must send an early warning to ENISA and the relevant national CSIRT within 24 hours, follow with a more detailed notification within 72 hours, then submit a final report within 14 days for a vulnerability or one month for a severe incident, as of September 11, 2026.
That’s six regulatory regimes, each with very similar, albeit not quite the same, deadlines, recipients, and forms. A single incident at a multinational financial institution that ships software and has US listings can plausibly trigger four of them at once.
The instinct is to build a matrix of deadlines and hand it to the incident response team. While that’s worth doing, it’s also not the most important step you can take to get ahead of a disclosure.
Reading the clock isn't the hardest part
Look closely at what starts each family of frameworks’ clocks, because they don’t all start with the same triggering “event.”
In the first family — DORA and SEC — the clock starts with a judgment you make. DORA's four hours begin when you classify the incident as major, and the SEC's four business days begin when you determine the incident is material. Notice that neither clock starts at incident discovery itself.
In the second family — GDPR, CIRCIA, NIS2, and CRA — the clock starts ticking with awareness, which sounds more objective than it is. GDPR's 72 hours begins once you have enough information to conclude a breach has likely occurred. CIRCIA's 72 hours begins the moment you reasonably believe an incident has happened. NIS2 gives you 24 hours from the point you become aware of a significant incident. The CRA gives you 24 hours from the point you become aware that a vulnerability in your product is being actively exploited.
In every case, the clock starts when you find out, not when the attack started. Here’s the part I find more interesting:
In the first family, the clock is short but doesn’t start until you have decided whether an incident is material or major. In the second family, the clock starts earlier, but you still can’t file anything until you have decided something similar; the threshold questions determine whether you report at all.
In any case, the work that matters happens before any clock starts, and regulators have closed the obvious loophole. The SEC requires the materiality assessment to be made without unreasonable delay after discovery, so there’s no buying extra time. DORA caps the whole thing at 24 hours from awareness, regardless of when you classify. GDPR asks you to explain yourself if you miss the 72-hour deadline.
You don’t get to stop the clock to think about it longer. You either decide fast or explain why you can’t.
Same judgment, four labels
Strip away the legalese, and all of the regulatory regimes outlined above are asking the same question: “Does this incident cross the line where someone outside my organization needs to know about it?” Each one chose its own word to put in that line.
The SEC calls it material. DORA calls it major. NIS2 calls it significant. The CRA calls it severe, or in the case of a vulnerability, actively exploited. GDPR does not name it at all and instead describes a risk to the rights and freedoms of natural persons, with a higher bar of “high risk” for notifying individuals directly.
That’s four words and a description for what is, ultimately, one judgment.
Security teams already make this exact judgment constantly. They call it prioritization — drawing a line and triaging the things that matter most. The regulatory version is the same act performed with a clock running and legal consequences attached, which is a meaningful difference in stakes but not in kind.
Reframing it this way has practical implications. If you treat disclosure thresholds as an exercise that begins when your legal team gets involved, you will be too slow, because the facts live elsewhere. If you treat them as prioritization with an audience — albeit an audience that can impose fines or even jail time — then you can build for them in advance using muscles your team already has.
DORA checks your math skills
If you want to see why this can’t be improvised, just read DORA's classification rules. Under the regulatory technical standards, an incident is major only if critical services have been affected, and then it must meet at least two of the six remaining criteria.
The criteria include the number of clients or counterparties affected, reputational impact, the duration of the attack and service downtime, the scope of data losses, the geographic spread, and the economic impact. An incident touching more than 10% of the clients using the affected service generally clears that particular threshold. There is even a recurrence rule: Separate incidents that are not individually major count as one major incident if they happen at least twice in six months, share an apparent root cause, and collectively meet the criteria.
Read that again, this time as an operational requirement rather than a legal one: In four hours, you need to know how many clients were affected, for how long, and in which jurisdictions. And you need to know what data was exfiltrated. That is not a judgment you can make just from a configuration snapshot. A snapshot tells you how the environment was set up, but it doesn’t tell you what happened inside, in what order, or to whom.
This is where the compliance conversation often misses the mark. The industry has spent years getting good at proving that controls exist at a specific point in time. Almost every framework rewards that, and it is useful for passing an audit. But not one of the six regimes we’ve discussed asks whether a control existed; they all ask what happened.
Those are different questions, and they require different evidence.
What an accurate fact pattern actually requires
Strip the six regulations down to what they have in common and here’s what you get:
- What was accessed or affected, in enough detail to characterize the data involved.
- When the incident happened, including when it started, which is usually earlier than when you actually identified it.
- Who was affected, by count and often by jurisdiction.
- Whether it was malicious, since NIS2 asks explicitly about unlawful acts and the CRA distinguishes an actively exploited vulnerability from a theoretical one.
- What you did about it, and what remains to be done.
The word to hold on to as you gather evidence is “accurate.” An early filing you have to walk back is not a win. Several of these regulatory bodies have staged reporting precisely because the authorities expect your understanding to improve, but the early warning still has to be defensible and the final report has to reconcile with it.
On the CRA specifically, notice that "actively exploited" is a factual claim about the present. A static scanner can tell you a vulnerability is present in your product, but it cannot tell you that someone is currently using it. That distinction is key for CRA reporting obligations. Determining whether something in your system is being actively exploited requires observing abnormal behavior in production, and that is a fundamentally different kind of evidence than a vulnerability inventory.
Disclosure doesn’t stop at the regulator
Another aspect that gets lost in the deadline matrix is that regulators aren’t your only audience. If you are a vendor, your customers have contractual notification rights as well, and many of them are regulated entities whose own clocks start when you tell them something. That’s the downstream effect of software supply chains and organizational security.
If you handle personal data, GDPR Article 34 requires you to notify individuals directly, and if you’re a public company, you have investors who need to be notified as well. Each of these audiences requires a different level of technical detail, and each one will compare what you told them against what you told the others — and it may all end up in the news.
While that’s ultimately a communications problem, it rests on the same foundation: one fact pattern, told consistently to several audiences over different timelines. Organizations that improvise this process end up with a regulatory filing that does not match the customer email, which can be an even worse problem than being late.
That’s why this conversation should never live and die with the security team. Convening your counsel, product leadership, and third-party risk function in the same room before an incident is the least glamorous, yet highest-value preparation available to you. You can even consider running a tabletop exercise together, because practice makes perfect. In the end, these are the people who will have to sign the filings, and they should help design how the facts get assembled before the heat of the moment ever hits.
So what should you do before the clock starts?
To get ahead of any future regulatory disclosures (and keeping my fingers crossed for you that such a plan remains theoretical even when thoroughly prepared), there are five action items worth executing before next quarter:
- Map the regulations that apply to you, and build for the strictest first: Prioritization is still the most efficient path, and it is the advice I would have given years ago. That has not changed.
- Write down your classification methodology, and test it: DORA requires an internal classification approach and the SEC expects a materiality process. Both are more useful as a rehearsed procedure than as a document. You’re going to hit walls if nobody has run it before.
- Try to actually populate the fields: Take one plausible incident and try to answer what was touched, when, and whose data was involved, using only what you collect today. The gaps you find are your most pressing compliance risks.
- Decide who decides: A four-hour clock does not survive a scheduling conflict. Name the classifier, name the backup, and give them the authority to act without a committee’s approval.
- Rehearse the response and the disclosure: Most tabletop exercises end when the incident is contained. Run tabletop exercises that end when all the appropriate filings are submitted on time.
Each of the six regimes is asking the same question. They just each answer it with a different word: material, major, significant, severe. Your judgement depends on the same evidence: what actually happened, to whom, and when. But at the moment the clocks start, can you make that call with enough confidence to put your name on it?
That confidence must be built long before an incident, and it comes from being able to see what’s actually running in your environment, in real time. Only being able to prove the configuration was correct, or the control existed during your last audit, is a critical gap when you’re four hours into a major incident with a regulator and affected customers waiting on the other end.
