Template · Cyber Security

Security Incident Response Template

A fill-in incident record and response plan — severity, the timeline as it happens, containment decisions, evidence preservation, notification deadlines, and the blameless review that follows.

Markdown. No sign-up, no email.

Fill this in during the incident, not afterwards. A timeline reconstructed from memory a week later is missing exactly the details that matter — who knew what, when, and what was tried first.

Print a copy of the empty version. The incident where you need it may be the incident where the wiki is unavailable.

Incident ID: _______ Opened: ____ (date/time + timezone) Incident lead: _______________ Deputy: _______________ Communications owner: _______________ Scribe: _______________

🔴 Name the lead in the first five minutes. An incident with three people acting and nobody deciding takes longer and does more damage than one person working alone.

1. Severity#

LevelMeaningThis one
SEV1Confirmed data exposure, or a critical system unavailable
SEV2Credible compromise, contained; degraded service
SEV3Suspicious activity, no confirmed impact

Chosen: ____ Why: _______________ Re-assessed at: _______ New level: ____

Severity can go up. Say so explicitly when it does, and re-notify.

2. What we know — updated as we learn#

TimeWhat was observedSourceWho

First detection: _______________ (how did we find out — monitoring, a customer, a third party?) Earliest evidence of activity: _______________

The gap between those two lines is your real detection time. It is worth measuring even when it is embarrassing, because it is the number that drives what you fix afterwards.

3. Scope#

Systems involved
Accounts involved
Data potentially accessed
Personal data involvedyes / no / unknown
Records affected (estimate + basis)
Third parties or customers affected
Still ongoingyes / no / unknown

Record "unknown" where it is unknown. A confident wrong number in the first hour becomes the number everyone repeats.

4. Containment decisions#

TimeAction takenWho approvedTrade-off accepted

Evidence preserved before containment? yes / no — what: _______________

🔴 Containment can destroy the evidence needed to understand the incident: rebuilding a host wipes what was on it, and rotating a credential can hide how it was used. Snapshot first where you can. If speed requires destroying evidence, that is a legitimate choice — record who made it and why.

5. Notification#

PartyRequired byDeadlineNotified atBy whom
Internal leadership
Data protection / privacy lead
Regulator
Affected customers
Insurer
Law enforcement

Regulatory deadlines run from awareness, not from resolution. Check your obligations before you need them and write the actual deadline in this table — under GDPR, for example, personal data breaches are notifiable to the supervisory authority within 72 hours of becoming aware, with narrow exceptions. Confirm the specific regimes that apply to you with counsel; this template is not legal advice.

6. Recovery#

Credentials rotated
Sessions and tokens invalidated
Systems rebuilt vs cleaned
Patches applied
How we confirmed the actor no longer has access
Monitoring added for recurrence

Declared resolved at: _______ By: _______________

7. Blameless review — within one week#

Timeline (detection → containment → resolution, with the delays visible): _______________

What worked: _______________

What made it harder: _______________

Root cause — a condition, not a person: _______________

ActionOwnerDueType
prevent / detect / respond

Aim for at least one action in each of the three types. A review that produces only prevention items assumes the next incident will be the same as this one, and it will not be.

What we would tell another team in our position: _______________

Sign-off#

NameDate
Incident lead
Security owner
Executive sponsor

Back to Cyber Security