· Yair Knijn
The 24-hour incident clock that started before anyone in the org noticed
Most CISOs carry a quiet assumption into every tabletop: the incident clock starts when the SOC pages someone. The alert fires, the bridge opens, the timer runs from there. It feels reasonable, because it is the first moment your people knew. The regulator does not measure from that moment, and the gap between when something became detectable and when your team noticed is where late filings are born.
That gap is small when one app breaks. It is days wide when a subprocessor three contracts down the chain is breached and the first signal you get is a vendor email written by their lawyers.
The notification windows: DORA's initial report and NIS2's 24-hour early warning
The windows are short and not symmetric. Under DORA, a financial entity classifies an ICT incident within 24 hours of detection, and once it is major, the initial notification to the competent authority is due within 4 hours of that classification. NIS2 runs a separate track for essential and important entities: an early warning within 24 hours of becoming aware, a fuller notification by 72 hours, a final report at one month. Sit under both regimes and you are running two clocks at once, and meeting DORA's tighter one does not free you from filing to a different NIS2 authority.
None of these deadlines reward you for paperwork being ready. They reward you for the clock having started when it was supposed to.
Why the clock runs from detectability, not from your alert
Read the trigger language. DORA's classification window counts from detection. NIS2's early warning counts from when the entity became aware. Awareness is a legal standard, not a log timestamp. A supervisor reconstructing the timeline will ask when the first evidence reached a system you control, not when a human happened to read it.
So the practical question is never "when did we decide to act." It is "what is the earliest moment a reasonable operator, looking at telemetry we already had, should have known." If that evidence sat unread in one product's logs for two days because nobody correlates across the estate, your 24 hours did not start when you say. It started two days earlier, and you have already blown the window.
Detecting a subprocessor breach you do not directly monitor
You do not get a packet capture from your vendor's vendor. What you get are second-order signals, and they are scattered across the very products that do not talk to each other:
- An auth provider's status page degrading, while one app logs a spike in failed token refreshes.
- A payment subprocessor's webhook latency climbing, visible only inside the billing product.
- A support tool quietly emailing that "a limited set of records may have been accessed."
- Anomalous admin access in one Customer Environment that matches a pattern showing up in three others.
Each of those is a shrug in isolation. Correlated, they are the breach, and the correlation is the detection. An estate where each app keeps its own log guarantees nobody sees the pattern until the vendor's lawyers force it, days into a clock that already ran out.
One audit trail that reconstructs the timeline regulators ask for
When the supervisor follows up, the question is brutally specific: what did you know, when did you know it, what could you have known sooner. Answering by exporting from eight products and stitching timestamps by hand is how a filing becomes defensible on paper and indefensible in the room. The reconstruction itself becomes evidence that your detection was structurally late.
The fix is not another alerting dashboard bolted onto the pile. It is one audit trail every product writes to, keyed per customer, so the earliest detectable signal across the estate is a single query, not a forensic project. In Spot Suite that trail lives against the Customer Environment, so the moment a subprocessor's trouble first touched your systems is one timestamp you can defend, not ten you assemble after the window closed. If short-window reporting is on your roadmap, start with how you would prove the detection time, then work outward.