Incident notification workflow: documents to prepare
An incident notification workflow under a technology contract starts the moment either side identifies an event the notification clause covers. Before any message goes out, four documents need to be ready: the incident log, the notice itself, the escalation contact list and the record of prior exchanges with the other party. Missing one of these delays a clock the contract is already running.
What changes once the clock starts
Most technology contracts fix the notification window as a short, defined period counted from discovery, not from confirmation. Once that period opens, three things shift at once. The party that stays silent past the window usually loses the right to argue the delay was reasonable. Service credits and remedy clauses that depend on timely notice become enforceable or unenforceable depending on what was sent and when. Internal sign-off that would normally take days gets compressed into hours, because the contract does not pause for internal approval chains.
This is why the documents below need to exist in a ready state before an incident happens, not after.
Documents to prepare
| Document | Purpose | Who prepares it |
|---|---|---|
| Incident log | Records discovery time, affected systems and first actions taken | Incident owner, as soon as the event is flagged |
| Notice draft | Follows the format the contract requires, if one is specified | Contract manager or in-house counsel |
| Escalation contact list | Names the person and address the notice must reach on both sides | Pulled from the signed contract and its annexes |
| Prior correspondence record | Shows whether the same issue was raised before, and how it was closed | Whoever holds the contract file |
| Acknowledgement receipt | Confirms the other side received the notice and when | Filed once a reply arrives, or its absence is logged |
What to do
- Assign an incident owner immediately. This person logs the discovery time before anything else happens.
- Pull the notification clause and any linked annexes from the signed contract, not from memory.
- Complete the internal incident record: root cause, systems affected, and what data or service the incident touches.
- Draft the notice using the format the contract specifies, or a plain factual format if none is set.
- Send the notice to the contractual notice address and copy the internal legal contact at the same time.
- File the acknowledgement once it arrives, or log its absence with a timestamp if it does not.
Who decides
Decisions inside this workflow sit with whoever the contract names as the notice recipient, usually a contract manager or an escalation contact on each side. If the contract sets an internal escalation path, that path decides whether the incident is severe enough to move up before a reply comes back. Where the contract stays silent on decision-making, the default is whoever signed the notice clause on each side, working to the fixed window the contract states.
If your situation is different
If the counterparty has no formal incident clause in its contract, send the notice anyway and keep proof of delivery. A missing clause does not remove the duty to inform a party whose systems or data are affected.
If the incident involves a subcontractor further down the chain, notify your direct counterparty first. The chain of notice generally follows the chain of contracts, not the chain of systems.
If the notice window lapses with no acknowledgement, escalate through the contact named for disputes in the contract, and keep the original notice and its delivery proof on file.
What this page does not decide
This page sets out the workflow and the documents behind it. It does not decide whether a given incident triggers a reporting duty outside the contract, and it does not replace a review of the specific notice clause in your agreement, which can set a different window or a different recipient. For how this team scopes that kind of review and where the scope ends, see Working with this team and its limits.
Sources and how we checked
Reviewed on 4 November 2025. The steps above reflect how notification clauses are drafted and applied across the technology contracts this practice handles; they are not a substitute for the clause in your own agreement. Where a notice names a party registered abroad, a registry check on that party is a separate step. If the counterparty sits in Belgium, see Counterparty in Belgium and its limits in practice before relying on any address given in the notice. If the notice itself references a Maltese-law document, see Document in Malta explained for what a registry check on that document can confirm.
Related reading
The same document-preparation logic applies at other points in the contract lifecycle. See Renewal and price review: documents to prepare for the equivalent list at the point a contract comes up for renewal.
Some incidents surface a separate problem: a licence has ended but something tied to it, such as a token, is still running. If that applies here, see What to do first in this situation in practice.
FAQ
How long does incident notification workflow take in practice?
The window itself is set by the contract, often measured in hours rather than days. Preparing the five documents above before an incident happens is what makes that window achievable; teams that start from a blank page usually miss it.
Which documents are needed to start?
An incident log with a discovery timestamp, and the escalation contact list from the signed contract. Everything else in the table above can follow within the notice window, but these two need to exist first.
What happens if the other side does not respond?
Log the absence of a reply with a timestamp and escalate through the contact named for disputes in the contract. Silence does not stop the clock the notice already started; it shifts the next step to escalation.