Tuesday, 09:14. An email from a supplier's security team: "We are investigating a security incident affecting a subset of customer environments. We will share further details as they become available." At 09:36 your CEO forwards it back to you with four words: "Are we exposed?"
This post is the calm walk-through of what happens next — the two clocks that may have just started, what NIS2 actually requires at each rung of its reporting ladder, and why the hardest part of the next 72 hours is usually not the regulator. It's reconstructing what the supplier does for you.
Two clocks, and only one of them is theirs
The supplier's clock is contractual. If your contract contains the notification clause NIS2 expects — an obligation to tell you, without undue delay, about incidents that present a risk to your systems — then that 09:14 email was them discharging it. If the contract doesn't contain that clause, you got the email out of courtesy, and some suppliers extend that courtesy only after the press does.
Your clock is regulatory, and it's the one that matters now. Under NIS2 Article 23, if this supplier incident turns into a significant incident for you — one causing severe operational disruption or financial loss, or considerable damage to others — you owe your own national CSIRT or competent authority a sequence of notifications:
- An early warning within 24 hours of becoming aware of the significant incident
- An incident notification within 72 hours of becoming aware
- A final report no later than one month after that notification — plus intermediate updates if the authority asks for them
Note the trigger, because it is the most commonly misstated fact in this whole area: the clock starts when you become aware of the significant incident — not when the incident happened, and not when the supplier first noticed it on their side. That 09:14 email may be the moment your awareness begins. Which means the first real decision of the morning is an assessment question: is this significant for us at all?
Hour zero: "are we exposed?" is a records question
Before any forensics, you need four answers, and none of them live at the supplier: What does this supplier actually do for us? Which of our services and systems does their service touch? What data do they hold or process? And what did we know about their security posture at the last review?
In most mid-market companies, here is how that goes. You open the supplier register spreadsheet. You search SharePoint for the last assessment, your inbox for the contract, a different folder for the evidence files. The register says "reviewed in April" — but the reasoning behind the review lives in the notes of a colleague who left in autumn. Half a day per supplier, and at the end you're still not certain you found the latest version of anything. At hour zero, you are not doing incident response. You are doing archaeology.
There is also a second-order question that surfaces about an hour in, once the news settles: if the breached party is a vendor your suppliers rely on — a cloud platform, a remote-access tool, a managed IT provider — then which of our other suppliers depend on the same vendor?
That question is answerable in minutes only if someone captured supplier-disclosed sub-processor lists at review time. If nobody did, it becomes a fresh round of emails to every critical supplier — in the middle of the worst morning to be sending them.
The 24-hour early warning
If your assessment says this is, or is likely to become, significant for you, the early warning goes out within 24 hours of that awareness. It is deliberately lightweight: whether the incident is suspected to be caused by unlawful or malicious activity, and whether it could have cross-border impact. That's the substance.
The design intent matters: an early warning is allowed to be incomplete. You are not expected to have root cause, scope, or attribution at hour 24 — you are expected to have raised your hand. Waiting for certainty you won't have until Thursday is the classic way to miss the deadline.
Two things should already be decided long before any incident: who in your organisation judges whether an incident is "significant," and who sends the notification. The worst time to design that escalation path is hour 22.
Hours 24 to 72: the incident notification
The 72-hour notification is the fuller picture: an initial assessment of the incident, its severity and impact, and indicators of compromise where available. Between the early warning and this notification, your working hours go into three things — scoping exposure with the supplier's answers as they arrive, containing whatever access or data flow connects their environment to yours, and writing down every decision as you take it.
That last one is not bureaucratic reflex. Six months from now, an auditor or authority may ask the only question that's hard to answer retroactively: what did you know, when did you know it, and what did you decide? A decision log written at hour 30 is evidence. A decision log written at month six is an essay.
One month out: the final report
The final report closes the ladder: a detailed description of the incident, the type of threat and likely root cause, the mitigation you applied, and any cross-border impact. If the incident is still ongoing at the one-month mark, the ladder accommodates that — a progress report then, and the final report once the incident is actually handled.
By this point the quality of your month-one report is almost entirely determined by the quality of your hour-zero records. Teams that could reconstruct the supplier relationship in minutes write the report from their notes. Teams that couldn't, reconstruct twice — once for themselves in the first week, once more for the regulator in week four.
What preparation actually looks like
Every part of this gets decided before the 09:14 email or during it. The before list is short:
- One reconstructible record per critical supplier — services in scope, data touched, current evidence, review history, contract clauses — retrievable in minutes by someone who isn't the person who built it
- Sub-processor lists captured at each review cycle, so "who else depends on this vendor?" is a lookup, not a mailshot
- The notification clause in critical supplier contracts, so the email arrives by obligation rather than courtesy
- A named owner for the significance call, and a pre-drafted early warning template with the destination address already confirmed
- A decision log that starts at hour zero — a shared document is enough, as long as entries carry a name and a timestamp
Where a tool fits — and where it doesn't
Honest scope note: Vittnor — Supply Chain Assurance for the mid-market — does not file your Article 23 notifications, and it does not do forensics. What it does is hold the record that hour zero depends on — one record per supplier, with current evidence, review history, contract clauses, and supplier-disclosed sub-processor dependencies, linked, dated, and exportable. The CEO gets the answer the same morning. The auditor gets the same answer six months later, unchanged.
If you want to know how your current setup would hold up on that Tuesday morning, the readiness check gives you a directional read in twenty questions — free, article-anchored, no sales call attached.