Incident notification workflow: stages and deadlines
An incident notification workflow moves through four stages: internal confirmation, first notice to the counterparty, a preliminary report, and a closing report. The deadline for each stage comes from the notification clause in your specific agreement, not from a public register. Missing the first notice usually creates more exposure than any delay later in the process.
What starts the clock
The clock starts when your team confirms that an event meets the definition of an incident in the contract. Confirmation is an internal decision, made by whoever holds operational authority over the affected system. Suspicion is not confirmation. A ticket in a monitoring tool is not confirmation either, unless the contract says so.
Once confirmed, the first notice becomes due. Its content and timing follow the clause the parties negotiated, so two contracts with the same counterparty can run on different clocks. This is why the workflow itself, not a fixed number of hours, is the reliable reference point.
What changes once notice is sent
Sending the first notice changes three things. It fixes a date the other side can point to later. It starts any contractual cure period that depends on notice being given. It also shifts the burden: after notice, silence from the recipient becomes their problem to explain, not yours.
Before notice is sent, the incident is an operational fact. After notice, it is a contractual event with its own record and its own consequences for renewal, liability caps, and termination rights.
Stages of the workflow
| Stage | What happens | Who acts |
|---|---|---|
| Confirmation | The event is checked against the contract definition of an incident | Operational lead on the affected side |
| First notice | A short notice is sent to the counterparty under the notification clause | Contract owner or legal contact named in the agreement |
| Preliminary report | Scope, affected systems, and immediate mitigation are described | Technical lead, reviewed by legal |
| Closing report | Root cause, remediation, and any contractual consequence are recorded | Contract owner, signed off by both sides where the clause requires it |
Steps to run the workflow
- Confirm the event against the contract definition before any external communication starts.
- Identify the notification clause and the contact named for notices, not the general account contact.
- Send the first notice in the form the clause requires — email is not always enough.
- Keep a dated internal log of every message sent and received during the incident.
- Prepare the preliminary report once scope is reasonably clear, even if remediation is not finished.
- Close the file with a report that states outcome and any change to ongoing obligations.
Who decides and by when
The decision on whether an event qualifies as a notifiable incident sits with the party that controls the affected system, guided by the contract definition. Disputes about qualification are usually resolved through the escalation path named in the agreement, not by unilateral declaration from either side.
If the contract sets tiers of severity, the tier decides who signs the report. A low-severity incident may close with an internal note. A high-severity one usually needs sign-off from whoever holds contractual authority to accept risk on each side.
Common forks
If the incident affects a system covered by a separate outsourcing schedule, the notification runs under that schedule first, and only escalates to the master agreement if the schedule is silent.
If the deliverable involved is a tokenised asset, proof of the underlying token follows a distinct procedure, described in Token in tokenised rights in practice, and should not be folded into the incident report itself.
If the counterparty is a distributor rather than a direct technology vendor, the onboarding file usually already sets the contact for notices — check it before assuming the general contract address applies.
What this page does not resolve
This workflow does not tell you whether a specific event meets your contract's definition of an incident — that depends on wording only your agreement contains. It also does not replace a check on the counterparty itself, which is a separate step, covered in Counterparty report before onboarding a distributor.
Where the dispute concerns whether a document or scan produced during the incident is genuine rather than generated, that question sits outside this workflow and is addressed separately in Document report when a scan looks generated explained.
Verified
This page describes a contractual workflow, not a statutory one, so it carries no external legal citation. Timing information behind our own review cycle is published in Delivery statistics, published automatically overview and the deadline. Last reviewed on the date shown in the page footer.
FAQ
How long does incident notification workflow take in practice?
Length depends on the clause in your contract, not on a fixed industry number. A well-drafted clause separates the first notice, which should be fast, from the closing report, which can reasonably take longer while remediation finishes.
Which documents are needed to start?
You need the contract clause on notification, the internal log confirming the event, and the named contact for notices under that clause. Without the named contact, notice sent to the wrong address may not count as valid.
What happens if the other side does not respond?
Silence after a valid notice usually shifts risk toward the silent party under most notification clauses, but the exact effect depends on wording. Document every attempt to reach the named contact before treating silence as acceptance or as a breach.
Related publications
Notification timing often interacts with renewal terms — see Renewal and price review technology contract for the adjoining workflow.
If your situation does not match a clean incident notice, start with What to do first in this situation in practice.