Incident notification workflow: what the decision maker looks at
The person who signs off on an incident notification is not checking whether something went wrong. That part is usually settled already. They are checking three things: whether the clock has started, whether the wording locks the counterparty into a position, and whether the file supports what the notice claims. Everything below follows from those three checks.
What starts the notification clock
In most technology and outsourcing contracts the clock starts on discovery, not on the incident itself. A vendor that finds a problem on Monday and confirms it internally on Wednesday is usually judged from Wednesday, provided the delay is documented. A vendor that suspects a problem on Monday and waits for certainty is judged from Monday, because suspicion already meets most contractual thresholds for a notifiable event.
This is the point most teams get wrong. They wait for a root cause before telling anyone. The workflow does not require a root cause. It requires a description of what is known, what is unknown, and what is being done to close the gap.
What changes once notification is sent
Sending the notice is a point of no return in practice, even where the contract does not say so directly. Once the counterparty has a written account of the incident, later statements are read against it. A second message that narrows the scope reads as a correction. A second message that widens the scope reads as an admission that the first one was incomplete. Both cost credibility with the person who decides remedies.
The same tension shows up outside technology contracts. A comparable pattern appears where a disputed record is later withdrawn rather than corrected — see Crypto services the referenced work is removed and its entry is examined for what the removal itself communicates.
Because of this, the workflow treats drafting as the slow step and sending as the fast one. A notice drafted in an hour and revised twice before release is stronger than one sent within minutes and corrected in public afterwards.
What to do
- Fix the discovery timestamp in writing before any internal discussion starts.
- Assign one owner for the notice; do not let two teams draft in parallel.
- List what is confirmed and what is still under investigation, separately.
- Route the draft through whoever holds contractual sign-off, not just legal review.
- Send on the schedule the contract sets, even if the investigation is incomplete.
- Log the send time and the recipient with the same precision as the discovery timestamp.
Who decides and how long it takes
The decision maker is whoever the contract names for notices — usually a designated contact, not a department. Where no contact is named, the workflow defaults to the signatory of the master agreement. Timing depends on the contract tier and the incident category, summarised below.
| Stage | Typical trigger | Who acts |
|---|---|---|
| Discovery | Internal detection or third-party report | Operations or security team |
| Internal confirmation | Facts are documented, not necessarily resolved | Named incident owner |
| Notice drafted | Confirmation logged | Legal or contract manager |
| Notice sent | Contractual deadline reached | Signatory or named contact |
| Counterparty response | Notice received | Counterparty's designated contact |
Deadlines run from discovery, not from resolution. A team that treats the deadline as a target to finish the investigation by, rather than a target to notify by, is working against the workflow rather than through it.
If the situation differs
If the contract names no fixed deadline, notice is expected within a reasonable time after confirmation — silence for more than a few working days is difficult to defend later. If the incident touches a subcontractor's system rather than yours, notify your own counterparty first and let them manage the chain; do not notify the subcontractor's client directly. If two contracts cover the same platform with different notice periods, the shorter period controls your internal deadline, because missing it under either agreement creates exposure under both.
What this page does not cover
This page describes the sequence of steps and who acts at each one. It does not set out what a specific contract requires, because notice periods, thresholds and recipients vary by agreement and are not summarised here in the abstract. It also does not address whether a given incident meets a separate statutory reporting threshold outside the contract itself — that question depends on the specific regulator and sector and sits outside this workflow description.
Where the underlying question is not the workflow but what a counterparty's own record shows, a narrower check answers it more precisely than a general description can — see Counterparty in Latvia and its limits in detail for how that check is scoped and where it stops.
Where the question is what a specific document can establish rather than how the notice process runs, the answer sits in a different type of file — see Document in Finland and the evidence it can and cannot support.
Verified
This description reflects contractual notification practice observed across technology and outsourcing agreements as at the date of publication. It does not cite statutory provisions, because notice obligations of this kind are set by the individual contract rather than by a single national or EU rule that applies uniformly. Anyone reviewing how our reports are compiled, rather than how contract workflows run, can read The people behind the reports explained.
Related
A comparable decision structure applies at renewal — see Renewal and price review: what the decision maker looks at, and what changes once a renewal notice is sent instead of an incident notice.
Next step
If the incident touches personal data collected from minors, the notification workflow above does not resolve the separate handling question — see When children's data appears in the product in detail for what to do first.
If the incident was triggered by a change in an automated feature rather than a conventional fault, the cost profile differs from the one described here — see When an AI feature changes the data flow explained in a dedicated review.
If the notice cannot be supported because your own processing records are incomplete, that gap has its own consequences — see When records of processing are incomplete explained for what an incomplete file costs at this stage.
FAQ
How long does incident notification workflow take in practice?
From discovery to a sent notice, most teams take between one and five working days. The variation comes from internal sign-off, not from drafting time. Contracts with a named notice period compress this; contracts without one tend to drift.
Which documents are needed to start?
A discovery log with a timestamp, a short factual summary separating confirmed items from open questions, and the relevant contract clause on notice. Nothing else is required to send a first notice; supporting evidence can follow.
What happens if the other side does not respond?
Absence of a response does not stop the clock on your side. Document the send, note the absence of acknowledgement, and proceed as if the notice was received unless the contract specifies a confirmation step.