Incident Management Standards

Incident management standards — the process, whatever the cause

Criteria verified as of August 2026. Re-verify on the web before committing to anything (§8).

1. Scope and triggers

Applies to the end-to-end management process of an incident, regardless of its cause: detection and declaration criteria, severity classification, activation of command roles, internal and external communication, mitigation decisions under uncertainty, escalation, closure, blameless postmortem and the learning chain that turns incidents into changes. It covers equally the reliability incident, the security one, the data quality one, the one caused by a vendor outage and the one that is not technical (a personal data breach, the failure of a critical third party, operational fraud).

Triggers: "declare an incident", "severity", "SEV1/SEV2", "P1/P2", "incident commander", "IC", "comms lead", "scribe", "incident channel", "status page", "war room", "stakeholder update", "spokesperson", "mitigate", "rollback", "command handover", "IC handoff", "incident closure", "postmortem", "follow-up actions", "MTTR", "time to declare", "major incident", "problem management", "tabletop", "game day", "vendor outage".

Governing principle: an incident is managed with an explicit command structure, not with the sum of good intentions. The dominant failure of organisations is not technical: it is that nobody declared, nobody was coordinating and nobody was talking to whoever they had to talk to. Corollary: declaring is cheap, not declaring is expensive. A SEV2 opened and downgraded after 10 minutes costs one notification; an hour without coordination costs the entire incident.

Not applicable:

• sre-practice-standards (critical boundary, arbitration in §3): service reliability as a discipline — SLI/SLO, error budget and its policy, burn rate alerts, design and sizing of the on-call rota, PRR, toil, capacity planning, DORA. Its treatment of incident command and postmortems is the summary applied to a reliability incident; the canonical version of the process is this skill. If the two diverge, this one wins.
• incident-response-forensics-standards: the technical response and the investigation of a security incident — containment without destroying evidence, memory and disk acquisition, chain of custody, analysis, eradication and recovery, ransomware/identity playbooks. A security incident uses both: this one governs it (who commands, who speaks, how it is decided), that one investigates it (what happened, how they got in, what they touched, what is preserved).
• observability-standards: the telemetry with which it is detected and diagnosed, and its retention.
• grc-compliance-standards: the regulatory framework, audit evidence and formal risk acceptance; here, only the trigger of the duty to notify and its operational coordination.
• vulnerability-management-standards: the CVE before it is exploited (triage, SLA, VEX).
• appsec-standards: threat modelling and vulnerability classes in your own code.
• identity-access-management-standards: break-glass, session and token revocation.
• onprem-standards, kubernetes-standards, networking-standards, cicd-standards, data-platform-standards, aws-standards/azure-standards/gcp-standards, homelab-standards: the concrete mitigation on each platform.
• bcdr-standards (the boundary is scale — when the incident stops being recoverable within the service and activates the continuity plan, it stops being managed as an incident and becomes DR: the IC hands over command to the crisis director and the change of regime is declared explicitly), detection-engineering-standards (the detection that triggers the declaration), privacy-engineering-standards (a personal data breach, risk assessment for the data subjects and communication to those affected), offensive-security-standards (deconfliction: an authorised exercise must not consume the incident process, and a real finding during the exercise does activate it), secrets-management-standards, backup-recovery-standards, tech-leadership-standards (the blameless postmortem as a process — format, deadlines, actions with an owner — belongs here; defending it when management asks for someone to blame is a leadership obligation and is theirs. A blameless culture is not sustained by a document: it is sustained by someone who absorbs that pressure), itsm-itil-standards (a boundary with real overlap that must be arbitrated: the live technical incident belongs here — severity declaration, command, coordination, communication during the outage and blameless postmortem; the service process wrapping it is theirs: ticket logging and categorisation, catalogue, the contractual SLA and its credit regime, hierarchical escalation and the customer relationship. Problem management — eliminating the cause once service is restored, with its known error database — is theirs; here it ends when the service is restored and the postmortem has actions with owners. And the distinction neither of the two should erase: a contractual SLA is not an SLO, which belongs to sre-practice-standards).

2. Default decisions

Verify the status of the frameworks and references on the web before committing to them in a real project (§8).

3. The lifecycle as an engineering process

Boundary arbitration (read this before routing)

• "How much can this service fail, what measures it and who is on call?" → sre-practice-standards.
• "Who is in command right now, what is communicated and how is it decided?" → this skill.
• "What did the attacker do, what did they touch and what is preserved?" → incident-response-forensics-standards.
• Accepted and declared duplication: severities, the IC role and postmortems appear in all three. The source of truth for the process is this one; the others apply it to their domain.

3.1 Detection and declaration

• Declaration is an explicit and timestamped act, not a state of mind. It is recorded who declares, when, with what severity and why.
• Anyone can declare, including support, an internal customer or an on-call intern. Requiring approval to declare is the most effective mechanism for turning a SEV3 into a SEV1.
• Automatic thresholds that declare on their own (or at least propose): error budget burn above the paging threshold, an indication of compromise confirmed by detection, data loss or corruption, a critical vendor outage, a suspected personal data leak.
• The regulatory clock starts at "awareness" of the incident, not at the diagnosis (§6): recording the detection time precisely is an operational obligation, not a detail.

3.2 Classification: severity with observable criteria

Severity is decided in ≤ 60 seconds with a table that a tired human at 03:00 reads without interpreting. It is set by impact × urgency, with impact expressed in user language:

Hard rules of classification:

• Each level defines a response, not prestige: who gets woken up, communication cadence, whether a postmortem is mandatory, whether a status page is needed.
• Every indication of compromise, exfiltration or exposed personal data enters as SEV1 or SEV2 by default, and only comes down after assessment — never the other way round.
• Severity is reviewed continuously and can go up or down; the change is announced in the channel with a reason. What is not done is negotiating it down because of its consequences.
• An incident that triggers a regulatory notification cannot be lower than SEV2.

3.3 Roles: who commands and who speaks

• Incident Commander: decides, prioritises, delegates, maintains the state and cuts off discussions. They do not debug, do not type, do not investigate. Their value is coordination bandwidth, not knowledge of the system — which is why the best expert is usually the worst IC: as soon as they get into the problem, there is no IC any more. If the IC has their hands on the keyboard, there is no IC.
• Operations lead: the only person authorised to execute changes on production during the incident, or to delegate them by name. It prevents three people mitigating simultaneously and treading on each other.
• Communications lead: internal (management, support, sales, legal) and external (status page, customers). Translates into user language and shields the Ops lead from interruptions.
• Scribe: a live timeline with timestamps — facts, hypotheses, decisions and who took them. Reconstructing the timeline after the fact is 90% of the cost of the postmortem and 100% of its errors.
• Experts (SMEs): they come in, contribute, leave. The channel is not a spectator gallery; the IC has explicit authority to eject whoever is not contributing, including any executive.
• Escalation by time, not by heroics: if in N minutes there is no mitigation or hypothesis, it is escalated. The thresholds are written down, not implicit.
• Command handover in long incidents: maximum shifts (2-4 h per IC), an explicit handover announced in the channel ("IC moves from A to B at 04:12"), with a state briefing: what is known, what has been ruled out, what is in flight, what has been communicated and to whom, which decisions are pending. A 12-hour incident with a single IC ends in bad decisions through exhaustion.

3.4 Communication

• A single channel, with a predictable name (#inc-YYYYMMDD-<slug>), persistent and exportable. Coordinating by DM is forbidden: context in private is context lost.
• An update template (always the same structure, so it can be skim-read): [SEV<n>] <service> — <impact in user language> · Status: investigating|identified|mitigating|monitoring|resolved · Current action: <what> · Next update: <time>.
• A fixed cadence even when there is no news. "No news, still working" is information: it stops five people coming in to ask and breaking the response.
• Language: describe impact, not architecture. Neither panic nor euphemism: "intermittent problems" is forbidden when the service is down, and speculating about the cause before you have it is forbidden. Never promise a resolution time you do not control; promise the time of the next update, which you do control.
• A status page for external impact, with written criteria for when it is published (not "when somebody remembers"). The first message goes out before the cause is known. The absence of a status page during an outage does not hide it: it turns it into a trust incident as well as a technical one.
• In a security incident: external communication is coordinated with legal/DPO before publishing, and technical detail is omitted (§5 and the sister skill). Furthermore, if the attacker is suspected of having access to the corporate channel, coordination moves to an out-of-band channel.

3.5 Deciding under uncertainty

• Mitigate before understanding. The user does not get paid in explanations. Levers in order: rollback, disable a feature flag, drain traffic, degrade functionality, scale capacity, failover.
• The exception that must be said out loud: when compromise is suspected, destructive mitigation (reinstall, recreate, power off) destroys the evidence and with it the ability to know whether the attacker is still inside. In that case it is coordinated with incident-response-forensics-standards: preserve first (memory and disk), isolate instead of destroying, and the IC leaves a record of the decision and who took it. A service restored on top of a still-compromised system is an incident that reopens worse.
• Rollback is the default option in the face of any correlated recent change. Fix forward requires explicit justification from the IC and a time limit after which it is rolled back anyway.
• Timeboxing hypotheses: every investigation line has assigned time; once exhausted, it is reported and another route is taken. Without this, three people chase the same hunch for an hour.
• When to stop: the incident is declared mitigated when the user impact ceases and is verified with telemetry, not when "it looks like it's fine". It moves into monitoring for a defined window before closing.

3.6 Closure and learning

• Closure with: mitigation and resolution times (which are different), quantified impact (users, requests, time, money if possible), the cause classified according to the taxonomy, open actions, the regulatory obligations triggered and their status.
• A blameless postmortem within ≤ 5 working days. Minimum content: impact, timeline, contributing factors (in the plural — never the singular root cause), what worked, what did not, why detection took as long as it did, and actions. The right question is "what made this action seem reasonable at the time?", not "who got it wrong?".
• Blameless is not impunity: an honest error in a system that allowed it is dealt with in the postmortem; deliberate or negligent conduct is dealt with through another channel and is not diluted here.
• Actions: a named owner (a person, not a team), a date, and in the same backlog as the product. Each action is classified by effectiveness: eliminate the failure class > automate > detect earlier > document > "be careful" (that last one is not an action, it is a wish — it is not accepted).
• Review of execution, not of prose: a monthly review of the status of open actions. The process metric is the percentage of actions closed on time; if it is low, the postmortem is theatre and you must either stop writing them or start executing them.
• Problem management (ITIL 4): incidents sharing contributing factors are aggregated into a problem with its own owner and engineering budget. Three identical incidents are not three incidents: they are one unresolved one.
• A quarterly trend review: distribution by cause taxonomy, by service and by time of day; recurrences; incidents detected by the customer before the telemetry (a metric of detection quality, fed back to observability-standards and detection-engineering-standards).

4. Process quality (the gates)

The process is audited, not the people. Gates, in order of increasing cost:

1. Was it declared, and in time? The difference between the first signal (alert, ticket, tweet) and the declaration. If the pattern is "it was declared when the customer already knew", the problem is in the declaration threshold or in the fear of declaring, not in the on-call team.
2. Was there a named and announced IC? An incident with no identifiable IC in the channel is a process failure even if the technical outcome was good.
3. Was the communication cadence respected? Countable over the channel: gaps > 2× the cadence are a finding.
4. Is there a live written timeline? A postmortem reconstructed from memory 3 days later is fiction with timestamps.
5. Does the postmortem have actions with a named owner and a date, and were they closed? See §3.6.
6. Did the assigned severity survive later review? Both chronic over-sizing (everything is SEV1 → nothing is) and systematic under-sizing are bugs in the table.
7. Exercises: a quarterly tabletop (around a table, no systems: decisions, roles and communication — including a security scenario and a vendor outage one) and a game day with real injection. Every exercise produces findings with owners; an exercise that cannot fail is a demonstration.
8. A test of the regulatory notification chain: simulate an incident with personal data and time how long the organisation takes to have the minimum information to notify. If it takes longer than the deadline, the deadline will not be met on the real day (§6).

5. Process security

• The incident tooling is a first-tier target: paging, chat, status page and runbook documentation. Whoever controls them controls the response. MFA, its own access control and a tested alternative route in case the chat provider is precisely what is down.
• An out-of-band plan: contact list, voice bridge and alternative channel, accessible without the corporate SSO and tested (a phone list living in the wiki that is down does not exist). Coordinate with identity-access-management-standards for break-glass.
• Compartmentalisation in security incidents: the general management channel may be compromised and the investigation may need stealth. The IC decides what is said in the broad channel and what in the restricted IR channel; the decision is documented.
• Communication without leaks: the status page describes impact, not architecture or versions; public postmortems are sanitised of PII, internal paths and exploitable detail.
• Personal data in the channel: pasting dumps with PII into the incident channel is forbidden. Reference identifiers; the channel is archived and replicated in more places than you think.
• The duty to notify: it is decided by legal/DPO with the information incident management provides, and it is not postponed until the full diagnosis is available — you notify with what is known and expand later (§6). This is not legal advice: the legal criteria are set by legal/DPO.

6. Operability: metrics, deadlines and load

Metrics that are useful

• Time to declare (first signal → declaration): it measures the process, it is actionable and almost nobody measures it. The most underrated metric of the domain.
• Time to mitigate (declaration → impact ceasing): it is what the user notices.
• Percentage of postmortem actions closed on time: it measures whether learning exists.
• Incidents detected by the customer before the telemetry: it measures detection.
• Recurrence by cause taxonomy: it measures whether the failure class or the symptom is being attacked.
• Incident load per person and per shift: it measures the sustainability of the process.

MTTR pitfalls (do not use it blindly)

• It is a mean over a long-tailed distribution: one 20 h incident and nine of 5 min give an "MTTR of 2 h" that describes none of them. Use median and p90 segmented by severity, or the full distribution.
• It is easy to game: by closing early, by not declaring the small ones, or by reclassifying downwards.
• It mixes distinct phases (detect, declare, diagnose, mitigate, resolve): aggregated, it hides exactly the bottleneck you are looking for.
• Never as an individual, team or bonus target: the number gets optimised, not the service.

Regulatory deadlines (verify every figure in §8 — do not quote them from memory)

Data verified in August 2026; the legal criteria belong to legal/DPO, not to engineering.

The single source for the deadlines: grc-compliance-standards. The same regimes appear in three skills (here, incident-response-forensics-standards and that one). If they diverge, grc-compliance-standards wins and the other two are corrected in the same change. What is irreducibly from here is not the figure, it is the operational criterion: the clock runs from awareness, not from the diagnosis, and whoever decides to notify is not whoever is mitigating.

• GDPR art. 33: notification to the supervisory authority (AEPD in Spain) without undue delay and at most within 72 h from awareness of the breach, unless it is unlikely to entail a risk to rights and freedoms; communication to the data subjects if the risk is high (art. 34). The processor notifies the controller without undue delay. Phased notification is admissible (partial within the deadline, expanded later). Document every breach, whether notified or not.
• NIS2: an early warning within 24 h, notification within 72 h, final report within 1 month from awareness of the significant incident; an interim report if the authority asks for one. In Spain, the reference CSIRT is INCIBE-CERT (private sector), CCN-CERT (public sector) and ESPDEF-CERT (defence). The Spanish transposition (Ley de Coordinación y Gobernanza de la Ciberseguridad) had still not been published in the BOE as of August 2026 — verify its status before asserting anything.
• DORA (financial entities): initial notification of a major incident within 4 h of the classification as major and in any case ≤ 24 h from detection, an interim report ≤ 72 h and a final report ≤ 1 month from the last interim one. The RTS templates have applied since March 2025.
• ENS (RD 311/2022): notification to CCN-CERT via LUCIA, with staggered deadlines by impact according to guide CCN-STIC 817. The specific deadlines per level come from secondary guides: cross-check them against the text in force before using them (§8).
• Concurrency: the same incident can trigger GDPR + NIS2 + DORA + ENS + a customer contract simultaneously, with different clocks starting at different moments. It is managed with a single obligations matrix per incident type, prepared in advance, not improvised at 03:00.

Sustainable on-call (a process lens)

Sizing, compensation and alert hygiene live in sre-practice-standards. From the incident process:

• Incident load is a process metric, not an individual one: if one person has taken three SEV1s in a month, the problem is the system.
• Alert fatigue = undeclared incidents. It is the most common way for the process to fail silently.
• After a night-time SEV1 there is compensated rest; an exhausted IC takes expensive decisions.
• Nobody is IC and Ops at the same time in SEV1-SEV2. If there are not enough people to separate the roles, the incident is already telling you the real size of your response capacity.

Incidents that are not technical

• Vendor / SaaS outage: it is still your incident in front of your user. Identical roles; the Ops lead manages the workaround and the contractual escalation with the vendor (have the support channel and the contract number beforehand, not during). Document the impact for the third-party risk review (grc-compliance-standards).
• A personal data breach: activate legal/DPO at declaration, not at closure; the 72 h clock runs in parallel with the mitigation. The risk assessment for the data subjects and the communication to those affected are not decided by engineering.
• A data failure / an incorrect calculation published: the impact is reputational and sometimes regulatory, and mitigation includes correcting backwards what was already issued. Coordinate with data-platform-standards.
• A crisis that exceeds the service (site loss, prolonged unavailability): a formal handover to the continuity plan; see bcdr-standards.

7. Sustainability and prohibitions

• Cadence: the severity table and the regulatory obligations matrix reviewed at least annually and after any incident where they caused doubt; communication templates reviewed after every SEV1; the cause taxonomy reviewed at the close of each quarter.
• The process is adopted incrementally: start with severities + IC + a single channel + postmortems. A 40-page process nobody reads produces zero well-managed incidents.
• What is not used during an incident gets deleted. Incident documentation is measured by its use at 03:00, not by its completeness.
• Real training: nobody is IC without having shadowed another IC and having been through a tabletop. The role is trained, not assigned by seniority.

FORBIDDEN

• ❌ Not declaring "so as not to make noise", or waiting to be sure before declaring.
• ❌ Requiring hierarchical approval to declare an incident.
• ❌ Negotiating the severity down because of its consequences (politics, SLA, customer, monthly report).
• ❌ Lowering the severity of a possible compromise or a possible breach before the assessment.
• ❌ An incident without a named IC, or an IC who debugs, types or investigates.
• ❌ IC and Ops lead in the same person in SEV1-SEV2.
• ❌ Coordinating by DM, by parallel threads or across three channels; an incident with no live written timeline.
• ❌ An indefinite IC shift in a long incident, or a command handover not announced in the channel.
• ❌ Hunting for the root cause while the user is affected, with a rollback available.
• ❌ Mitigating by destroying evidence (reinstall, recreate, power off) when compromise is suspected, without coordinating with incident-response-forensics-standards.
• ❌ External silence during a visible outage, or "intermittent problems" when it is down.
• ❌ Promising a resolution time; speculating publicly about the cause; multiple voices speaking outwards.
• ❌ Exploitable technical detail or PII on a status page, in a public postmortem or in the incident channel.
• ❌ A postmortem with culprits, with "human error" as its conclusion, or with the root cause in the singular.
• ❌ A postmortem without actions with a named owner and a date, or actions in a separate list nobody prioritises or reviews.
• ❌ Actions of the "be more careful", "train the team" or "review better" type as the sole remedy.
• ❌ Closing the incident without verifying the mitigation with telemetry.
• ❌ Using MTTR (or the incident count) as an individual, team or bonus target.
• ❌ Delaying the regulatory notification until the full diagnosis is available.
• ❌ Improvising the map of legal obligations during the incident.
• ❌ Tabletops and game days announced as a demonstration; if it cannot fail, it is not an exercise.
• ❌ Turning the process into ITSM bureaucracy: CAB, forms and approvals inside the incident.

8. Mandatory web verification

Before committing to any figure, deadline or reference, search for it — do not remember it. Legal deadlines are where inventing costs the most:

1. GDPR art. 33-34 and the AEPD's guidance on breach notification: the deadline, the electronic office channel and the risk criteria. Verified Aug-2026: 72 h from awareness, phased notification admissible.
2. NIS2 (Directive 2022/2555) and its Spanish transposition: 24 h / 72 h / 1 month confirmed as of Aug-2026; pending: the Ley de Coordinación y Gobernanza de la Ciberseguridad had still not been published in the BOE — confirm its status, the exact recipient and whether the NIS2 revision proposed by the Commission (January 2026, with reporting of ransom details in ransomware) is already in force.
3. DORA: 4 h / 24 h / 72 h / 1 month and the reporting RTS (Regulation 2025/301 and its annexes). There are sources describing a four-milestone model instead of three: cross-check.
4. ENS (RD 311/2022) and guide CCN-STIC 817: deadlines by impact level (24 h / 72 h / 5 days circulate in secondary guides). Not verified against the primary source — confirm it before using it.
5. ITIL: ITIL 4 remains operative; PeopleCert announced ITIL v5 in February 2026 with publications still pending. Verify the status before quoting normative ITSM guidance.
6. Incident command references: response.pagerduty.com (roles, IC training) and Google's incident management guide (sre.google, IMAG, chapter 9 of the SRE Workbook). Check whether they have changed before quoting them as canon.
7. Stance on ransom payment: verified Aug-2026 — the United Kingdom is advancing a ban for the public sector and CNI plus a duty to notify before paying; the EU and Spain do not prohibit paying and regulate through transparency and sanctions/AML. It changes fast: verify it, and the decision to pay is not technical (see incident-response-forensics-standards).
8. Management tools (paging, status page, incident bots) you are going to recommend: status, licence and any recent security incident at the vendor.

Declared gap: the ENS deadlines by impact level (§6) and the exact detail of DORA's milestone model have not been cross-checked against the primary source in this review. Do not use them without verifying them.

If the web contradicts this document, the web wins — flag the discrepancy.