Incident response plan template

1. About this plan

This plan sets out how Acme responds to a security incident, step by step. It is the operational companion to the Acme Incident Response Policy: the policy says what must happen and who owns it; this plan says how responders do it.

Replace every [Fill in] before you adopt the plan, and delete anything that does not match how you actually work. A plan that describes steps nobody performs is worse than a short plan that is followed.

2. Severity levels

Assign every incident one of these levels during triage. The triggers are examples; the response targets are examples too. Set your own targets, make sure they match your Incident Response Policy and any customer contracts, and only commit to times you can actually meet.

3. Roles

For SEV1 and SEV2, name a person for each role at the start of the incident. In a small team one person may hold two roles, but the Incident Commander and the technical lead should be different people when possible.

4. Response phases

4.1 Detect and triage

Goal: Decide quickly whether this is an incident and how serious it is.

1. Anyone who suspects an incident reports it to security@acme.example or [incident channel]. Reporting in good faith is never penalised.
2. The on-call responder acknowledges the report within the target for the suspected severity.
3. Open an incident record with an identifier in the form INC-YYYY-NNN, even if the event turns out not to be an incident.
4. Assign a severity using the table in section 2. When the facts are uncertain, choose the higher level; it can be lowered later with a written reason.
5. For SEV1 and SEV2, name the Incident Commander, open a dedicated channel named after the identifier, and name a scribe and a communications lead.
6. Record the triage decision and the reason in the incident record, including when the outcome is "not an incident".

Done when: Severity assigned, roles named, record open.

4.2 Contain

Goal: Stop the harm from spreading while preserving what you need to understand it.

1. Preserve evidence before changing anything you can avoid changing: snapshot affected volumes, export relevant logs and audit trails, and note each item in the evidence log.
2. Revoke sessions and disable or reset compromised accounts; rotate exposed keys, tokens and secrets.
3. Isolate affected hosts, containers or laptops rather than deleting them; block malicious addresses or domains.
4. Record every containment action in the timeline with the time and who performed it.
5. Check whether customer, personal or confidential data may be involved and tell the Incident Commander as soon as that becomes likely. Acme then starts the notification assessment in section 5.

Done when: Spread stopped and evidence preserved; the commander agrees containment is holding.

4.3 Eradicate

Goal: Remove the cause, not just the symptom.

1. Identify the root cause and every system, account and credential it touched.
2. Remove the attacker's access, malware or faulty change; patch or reconfigure the weakness that let it happen.
3. Rebuild compromised systems from known-good images or infrastructure code rather than cleaning them in place.
4. Confirm with the technical lead that no persistence remains (new accounts, keys, scheduled jobs, OAuth grants).

Done when: Root cause removed and confirmed by the technical lead.

4.4 Recover

Goal: Return to normal service safely and watch for a repeat.

1. Restore data from backups where needed, and verify integrity before returning systems to service.
2. Return systems to production through your change process, using its emergency path if necessary, and record the approval.
3. Increase monitoring on the affected systems for a period you set: [Fill in].
4. Send the final status update and, where required, the customer follow-up.
5. The Incident Commander declares the incident closed and records the closure time.

Done when: Service restored, monitoring in place, incident formally closed.

4.5 Post-incident review

Goal: Turn the incident into documented improvements.

1. Hold a blameless review within [Fill in: number] business days of closure for every SEV1 and SEV2.
2. Cover the timeline, root cause, impact, what went well, what did not, and how long detection, containment and recovery took.
3. Create a corrective action for each gap with an owner and a due date, and track it in your ticketing system to closure.
4. Have the plan owner approve the review and attach it to the incident record.
5. Update this plan, the contact sheet and any runbook the incident showed to be wrong.

Done when: Review approved, actions ticketed with owners and dates.

5. Communication templates

Only the people named in your Incident Response Policy may approve messages to customers, partners, regulators, the press or law enforcement. Everyone else does not confirm, deny or speculate about an incident outside the response team.

Before any external notification: check your customer contracts, data processing agreements, insurance policy and the laws that apply to you for notification duties, recipients and deadlines. These vary by contract, jurisdiction and the type of data involved. This template is not legal advice; involve legal counsel before sending a regulatory or customer notice.

5.1 Internal status update

Send to the incident channel and the executive sponsor at the cadence set for the severity.

• Incident: INC-[YYYY-NNN], [short title], SEV[1-4]
• Status: [Investigating / Contained / Recovering / Resolved]
• Time of this update: [YYYY-MM-DD HH:MM UTC]
• What we know: [Facts confirmed so far, in plain words]
• What we do not know yet: [Open questions]
• Impact: [Systems, customers and data affected, or "none confirmed"]
• Actions since last update: [Fill in]
• Next steps and owners: [Fill in]
• Decisions needed: [Fill in, or "none"]
• Next update: [Time]

5.2 Customer notification draft

A starting draft only. Adapt it to the facts, your contract terms and counsel's advice, and get the approval your policy requires before sending.

• Subject: Security incident affecting your Acme account
• Opening: We are writing to let you know about a security incident at Acme that [affected / may have affected] [your data / your use of the service].
• What happened: On [date], we [detected / were notified of] [plain description]. [What is known about when it started.]
• What information was involved: [Categories of data, or the service affected. Be specific; do not speculate.]
• What we have done: [Containment and remediation steps taken, in plain words.]
• What you can do: [Specific actions, for example rotating an API key or reviewing access logs, or "no action is needed".]
• Contact: Questions can be sent to security@acme.example. We will share further updates by [channel] [by date / as we learn more].
• Sign-off: [Name, title], Acme

5.3 Notification assessment

For every SEV1 and SEV2, record in the incident record who may need to be told (customers, partners, insurer, regulators, individuals), the basis (contract clause or law), the deadline counsel confirms, who approved the message, and when it was sent. Attach a copy of every notice.

6. Contact sheet

Keep this sheet current and reachable when your normal tools are down (for example a printed copy or a copy outside your main workspace). Review it at least each time the plan is reviewed.

7. Evidence log

Log every item of evidence when it is collected, before remediation where possible. Store it in a restricted, access-logged location and do not edit originals.

8. Tabletop exercise checklist

Run a tabletop exercise at least once between plan reviews, and whenever the plan or the team changes significantly. If you had no real incidents in a period, the exercise record is how you show the plan works.

• [ ] Pick a date and a facilitator who will not also play a response role.
• [ ] Choose a realistic scenario for your stack, for example a leaked source control token, ransomware on a laptop, or a compromised administrator account.
• [ ] Invite the people who would really respond: the Incident Commander, technical lead, communications lead, scribe and an executive sponsor.
• [ ] Prepare three or four injects that change the situation partway through (new evidence, a customer asking questions, a key person unreachable).
• [ ] Walk through each phase of this plan out loud: who is told, who decides, which runbook is used, where evidence goes.
• [ ] Test the contact sheet: can every listed contact actually be reached through the listed channel?
• [ ] Draft the internal status update and the customer notification from section 5 as if the scenario were real.
• [ ] Record the attendees, scenario, decisions, gaps found and the time taken for each step.
• [ ] Open a corrective action ticket for each gap, with an owner and a due date.
• [ ] File the exercise record with your incident records and update this plan with what you learned.