Some incidents are obvious: the service is down, the building is inaccessible, the account is compromised. The harder event is partial. Messages are delayed. One administrator sees strange activity. A provider says the platform is healthy. Staff can still work through personal accounts. A critical report contains unexplained differences. Nobody wants to declare an incident and create disruption if the problem is temporary. The institution continues until the workaround becomes the breach.
Declaration is an authority decision
Monitoring can generate an alert. Only governance can decide that normal operating assumptions no longer hold. The declaration should activate named powers: freeze changes, preserve evidence, use emergency communications, incur response expense, isolate systems and convene decision-makers. Without a declared state, teams hesitate to use those powers or exercise them inconsistently.
Define observable triggers
Avoid a threshold that depends on proving the root cause. Use conditions visible at the time:
- Loss of reliable control over a privileged identity or recovery route.
- Material inconsistency in critical records or transaction instructions.
- Unavailability exceeding the agreed tolerance for a critical outcome.
- Evidence that protected information reached an unauthorised recipient.
- Provider failure combined with inability to verify its status independently.
- Any workaround that requires bypassing a high-consequence control.
A trigger can activate a limited incident posture while investigation continues.
Value object — The Declaration Card
Place a concise card in the emergency plan:
- Declare: named roles authorised to activate the incident state.
- Triggers: observable conditions, including a discretionary catch-all for credible high consequence.
- Immediate powers: actions permitted without additional approval.
- Mandatory actions: preserve, notify internally, record decisions and establish command.
- Prohibited actions: deleting evidence, using unapproved channels or making external claims without authority.
- Expiry: when the declaration must be reviewed, escalated or closed.
- Record: the facts and authority supporting declaration and closure.
The card should be usable by the person who first sees the failure, not only by counsel or security specialists.
Create levels without creating debate
Incident levels help allocate response, but elaborate scoring can delay action. Use a small number of states: heightened observation, controlled incident and major incident. Allow escalation on one severe dimension. A low-volume event involving control of a principal’s identity may justify major response even if few systems are affected.
Make early declaration reversible
Teams resist declaration because they fear reputational or operational cost. Design the first step as a reversible internal posture. It may pause selected changes, increase evidence collection and activate a verified call tree without public notification. It is easier to stand down a controlled response than to reconstruct evidence after three days of informal workarounds.
Separate declaration from blame
An employee should not believe that declaring an incident accuses a vendor or admits a breach. It states that the institution cannot safely rely on normal assumptions. Use language that protects escalation: “control condition,” “verification failure” or “continuity event” can be more precise than prematurely naming an attack.
Close with proof
The person who declares need not be the person who closes. Closure should require evidence that the affected authority, data and outcome are reliable again, temporary access is removed and workarounds are reconciled. The worst outage is not always the longest. It is the ambiguous failure that never became an incident until consequence made the declaration for you.