Incident response plan

Status: operative document. Version 1.0, 2026-09-18. Owner: Yannick M. Richard. Review cycle: annual, or on material change. Companion to the change management statement, the risk register and the statement of applicability (controls A.5.24–A.5.27). Not a certification document.

1. Why this document exists, and the honest constraint

Controls A.5.24 to A.5.27 require incident management planning, a response process, and a post-incident review. Most organisations satisfy this with an on-call rota, an escalation matrix, and a paging platform.

This service has one operator. There is no rota, no second responder and no separation of duties, because there is no second person. Writing an escalation matrix here would be theatre — it would describe a handover that cannot happen. That constraint is recorded as an accepted risk in the risk register rather than disguised with a document that implies otherwise.

What genuinely exists, and what this plan is actually built on:

• Detection is automated and continuous. Alerts are evaluated on a 30-second interval against the fleet’s metrics and logs, with rules that cover service death, disk exhaustion, CPU and memory pressure, resolver availability, and network error rates.
• Notification is a real transport that is exercised, not a described one — alerts deliver over authenticated SMTP to an address the operator reads.
• Response actions are declarative and reversible. Because the fleet is defined in a Git repository, most responses are a reviewed commit, and a bad change is reverted automatically by a health gate without human intervention.

The single-operator constraint is the plan’s most serious weakness, and it is named here deliberately. If the operator is unreachable, no escalation path exists. This is a structural property of a one-person service; it is disclosed rather than papered over.

2. Severity levels

Severity determines how fast the response happens and whether the incident is published. It is assigned at detection and may be raised at any point.

Severity	Definition	Response target	Published?
S1 — Critical	Customer traffic is affected, or a customer-data or key-material exposure is suspected. VPN tunnels down, resolver dead serving clients, secrets leaked, fleet host lost.	Immediate; drop all other work	Yes — in the monthly review record
S2 — Major	A production service is impaired but customers are not affected, or a control asserted in the audit has regressed. Monitoring down, backup failure, deploy gate failing closed.	Same day	Yes
S3 — Minor	Degraded but functional, or a near-miss with no customer impact. Disk trending to full, elevated error rate, a stale-but-not-expired credential.	Next working session	Summarised
S4 — Observation	Not an incident. A finding from a self-check or a scan that needs a decision.	Tracked, no deadline	No

The line that matters: any suspected exposure of key material or customer identity is S1 regardless of apparent blast radius. Under-classifying a suspected leak to avoid the S1 process is the failure mode this rule exists to prevent.

3. The response process

3.1 Detect

Automated: an alert fires, or a deploy gate fails closed, or the daily signed audit reports all_ok: false.

Manual: the operator notices something. Manual detection is recorded as an incident like any other — an incident found by a human is evidence that the automated detection has a gap, and the gap is the finding.

3.2 Triage and declare

Within the response target for the severity, the operator:

1. Assigns a severity from the table above.
2. Writes the incident down immediately, before fixing it — a timestamped # Incident: <short title> entry. The record is opened at declaration, not reconstructed afterwards. A record written after the fact is a story, not evidence.
3. States what is known and what is suspected, separately. The distinction is preserved in the record; collapsing them destroys the audit value.

3.3 Contain

Stop the harm before diagnosing the cause, where that is possible:

• Suspected key or credential exposure → rotate first, understand second. Rotation is cheap and already rehearsed; an un-rotated suspected leak is an unbounded exposure.
• Customer-affecting outage → restore service first, diagnose after. The declarative config makes the fastest path usually “revert the last change”, which the health gate may already have done.
• Fleet host lost → follow the disaster recovery runbook path; the escrowed age identities exist precisely so a rebuilt host can decrypt its own backups.

3.4 Eradicate and recover

Fix the cause with a reviewed commit. The response is itself a change, and it follows the change path — no imperative fix is left in place, even under pressure, even at S1. An incident response that bypasses change management creates an undocumented state, which is how a second incident starts.

Where an emergency on-host action is genuinely necessary, it is taken, and then immediately reconciled into the repository so the declared state and the running state match again. An unreconciled emergency fix is treated as an open incident until it is reconciled.

3.5 Verify

Recovery is not complete when the symptom stops. It is complete when:

• the service is confirmed healthy by the same checks that would have caught the original problem,
• the daily signed audit reports all_ok: true again, and
• the fix is on main and deployed, not sitting on a branch.

4. Post-incident review

Every S1 and S2 incident gets a written review within seven days. S3 is reviewed at the next monthly cycle and summarised.

The review answers, in this order:

1. What actually happened — the timeline, from the record opened at declaration, not from memory.
2. What the impact was — customers affected, data affected, duration.
3. Why it was possible — the condition that allowed it. Not “human error”; human error is a symptom, and the useful question is what made the error possible and undetected.
4. Why it was not caught sooner — the detection gap, if any.
5. What changed — the commits, the new check, the amended document.
6. What remains open — carried forward explicitly, with the residual risk accepted or the work scheduled.

A review that finds nothing to change is treated as incomplete and sent back. Every incident had a cause; if the review identifies no action, it did not find the cause. This rule exists because “no action needed” reviews are the most common way an incident process becomes decorative.

5. Publication

S1 and S2 incidents appear in the dated internal review record with: severity, dates, a description, the root cause, and the change made. Personal data is not included, and neither is exploit detail that would create risk — but the fact of the incident, its severity and its resolution are published.

The reasoning is the same as everywhere else in this audit: a claim that nothing ever goes wrong is not credible, and a record that admits incidents is worth more than one that has none.

6. What this plan does not have, stated plainly

• No on-call rota and no escalation matrix — one operator. Disclosed, not solved.
• No automated paging or escalation. Notification is email to the operator. If the operator is offline, nothing escalates. A self-hosted paging platform was evaluated and rejected: every credible open-source option either requires a database and telephony stack that would add more failure surface than it removes, or has been discontinued upstream. Email was already working and exercised; the tooling was not the gap.
• No recovery-time guarantee for human response — only for automated rollback, which is immediate and independent of any human.
• No independent post-incident review. The operator reviews their own incidents. Recorded as an accepted risk.

The gaps above are the reason this document says aligned with ISO/IEC 27001:2022 and not certified. Two of the four are structural to being a one-person service.