What is an incident response plan?
An incident response plan is a written, approved document. It tells your team exactly what to do when a cyber attack or other security incident happens. It says who is in charge and how incidents are rated. It lists who must be told and by when. It also sets the first technical steps for the attacks you are most likely to face. A good plan is short enough to use under pressure. It is also specific enough that nobody has to invent the process at 2 a.m.
Most incident response plans follow the lifecycle in NIST Special Publication 800-61. NIST is the US standards agency, and SP 800-61 is its guide to handling computer security incidents.
The NIST incident response lifecycle
NIST SP 800-61 Revision 2 describes four phases that form a loop. Lessons from one incident feed preparation for the next.
- Preparation. Build the team, plan, contact lists and tools before anything goes wrong. That means central logging, endpoint detection, tested backups and access to outside help.
- Detection and analysis. Spot the signs of an incident, such as an alert, a staff report or a call from a partner. Confirm it is real, work out its scope and severity, and start writing things down.
- Containment, eradication and recovery. Cut off affected computers, disable accounts and block known signs of the attacker. Remove the attacker and their tools. Restore from known-good sources and watch for reinfection.
- Post-incident activity. Hold a lessons-learned review and fix the root cause. Update the plan and playbooks. Keep evidence for as long as legal or regulatory needs require.
Roles on the incident response team
Smaller companies will give several roles to one person. That is fine, as long as every role has a named owner and a deputy.
| Role | What they do | Typical owner |
|---|---|---|
| Incident commander | Runs the response, sets priorities, makes decisions and owns the timeline | Head of security, CTO or IT lead |
| Technical lead | Directs investigation, containment and recovery work | Senior engineer, SOC lead or IR provider |
| Communications lead | Drafts all messages and keeps one version of the truth | Marketing or comms, with legal review |
| Legal and privacy | Decides on regulatory and contractual notifications and protects legal privilege | General counsel, outside counsel or DPO |
| Executive sponsor | Approves big decisions, such as taking production offline or engaging outside help | CEO or COO |
| Scribe | Keeps a timestamped log of actions and decisions | Anyone not doing hands-on work |
Also list outside contacts. Start with your incident response or SOC provider. A SOC is a team that watches your systems for attacks 24/7. Add your cyber insurer, since many policies expect you to call their hotline first. Add outside lawyers and your cloud and hosting providers. Include law enforcement too, such as the FBI's Internet Crime Complaint Center (IC3) in the US.
Incident response plan template: the sections to include
Copy this structure. Keep the core plan short. Put technical steps in separate playbooks, which are step-by-step checklists.
- Purpose and scope. Which systems, cloud accounts, SaaS tools and third parties the plan covers, and what counts as an incident.
- Team and contacts. Names, deputies and phone numbers. Add an out-of-band channel, a separate way to talk in case email or chat is hacked.
- Severity levels. A simple scale that decides who gets woken up and how fast (see the table below).
- Detection and reporting. How staff report a suspected incident, where alerts go, and the first questions to answer.
- Communication plan. Who speaks to staff, customers, regulators and media, and who approves each message.
- Playbooks. Step-by-step checklists for your most likely incidents. At minimum, cover ransomware, business email compromise and data breach.
- Evidence handling. How logs, disk images and notes are collected, stored and protected.
- Legal and regulatory notification. Which laws, contracts and regulators apply to you, and their deadlines.
- Recovery. Who decides a system is clean enough to go back into use. Link this to your disaster recovery plan.
- Testing and maintenance. The tabletop exercise schedule, the plan owner and the next review date.
For section 3, a four-level scale works for most companies. Adjust the examples to your business.
| Severity | Examples | Expected response |
|---|---|---|
| SEV 1: Critical | Ransomware spreading, confirmed theft of customer data, production down because of an attack | Executives alerted immediately, round-the-clock work until contained |
| SEV 2: High | Compromised admin account, malware on a server, email compromise with money at risk | Response team engaged within the hour |
| SEV 3: Medium | One infected laptop, a contained phishing compromise of a standard user | Handled the same business day |
| SEV 4: Low | Blocked phishing campaign, policy violation, suspicious but unconfirmed activity | Logged and reviewed in normal working hours |
Playbooks for ransomware, BEC and data breach
Playbooks make the plan practical. Each should fit on a page or two. Here are the core steps for three common cyber attacks. Ransomware locks your files and demands payment. Business email compromise (BEC) is when a criminal takes over or fakes a work email account, often to steal money. A data breach is when private data is exposed or stolen.
Ransomware
- Isolate affected computers, ideally with your EDR tool's containment feature. EDR is software on each computer that spots and stops attacks. Do not switch machines off, because memory can hold evidence.
- Disable compromised accounts and reset privileged (admin) credentials, including service accounts.
- Confirm your backups are intact and kept apart from the affected systems before you rely on them.
- Find out how the attacker got in and check for data theft. Many ransomware groups steal data before they lock it, then threaten to leak it (double extortion).
- Involve the executive sponsor, legal and your insurer before any talk of payment. In the US, check OFAC sanctions guidance first, because paying a sanctioned group can be illegal.
Business email compromise (BEC)
- Reset the mailbox password and sign out all active sessions and tokens. Confirm that multi-factor authentication (MFA) is enforced. MFA is a second login step, such as a code on your phone.
- Look for ways the attacker kept access: inbox forwarding rules, new MFA methods, OAuth app consents and mailbox delegates.
- If money was sent, call your bank right away to ask for a recall. Report it to IC3 if you are in the US.
- Warn customers and suppliers who may get fake invoices from the hacked account.
Data breach
- Stop the exposure: close the public storage bucket, cancel the leaked key and block the attacker.
- Work out what data, whose data and how many records were affected. Use logs, not guesses.
- Bring in legal early to decide on notification duties.
Evidence handling and regulatory notification
Evidence matters to insurers, lawyers and regulators. Write a few simple rules into the plan:
- Keep a timestamped incident log from the first minute: who did what, when and why.
- Export and save logs early, because many systems overwrite them after a set period.
- Store evidence in a locked-down location and record who accessed it (chain of custody).
Then list the notification deadlines that apply to you. Many laws set short deadlines for reporting a breach, so know yours in advance. Common ones include:
| Rule | Who to notify | Deadline |
|---|---|---|
| GDPR and UK GDPR | Supervisory authority, such as the ICO in the UK | Without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach |
| GDPR and UK GDPR | Affected individuals | Without undue delay, when the breach is likely to result in a high risk to them |
| NIS2 (EU entities in scope) | National CSIRT or competent authority | Early warning within 24 hours, notification within 72 hours, final report within one month |
| SEC rules (US public companies) | Investors, through Form 8-K | Within four business days of determining that an incident is material |
| HIPAA (US health data) | Individuals, HHS and in some cases the media | Without unreasonable delay and no later than 60 days after discovery |
| US state breach laws | Residents and sometimes the state attorney general | Varies by state |
| Customer contracts and DPAs | Your customers | Set by each contract; check them now |
Test the plan with tabletop exercises
A plan nobody has practiced tends to fail the first time it is used. A tabletop exercise is a guided discussion. The team walks through a realistic scenario step by step. For example: "the finance director's mailbox has been forwarding invoices outside the company for two weeks".
- Run at least one tabletop a year, and after big changes such as an acquisition or new leadership.
- Include executives and legal, not only IT.
- Add surprises: the incident commander is on a flight, the backup server is also encrypted, a journalist calls.
- Record every gap and give each one an owner and a due date.
CISA, the US Cybersecurity and Infrastructure Security Agency, publishes free tabletop exercise packages you can adapt.
How NextGarrison helps
NextGarrison helps companies write and test incident response plans, and runs tabletop exercises. We also provide hands-on incident response when something goes wrong. Building your plan for SOC 2, a security report many business customers ask for? Read what SOC 2 compliance involves. Pair the plan with a disaster recovery plan. If you are dealing with an active incident right now, use our emergency contact page.
Need a hand with this?
Talk to a senior consultant. We reply within one business day with clear next steps and a scoped quote.
Written by
NextGarrison Security TeamPenetration testers, SOC analysts and compliance consultants
Our consultants test applications and networks, run 24/7 security monitoring and prepare companies for SOC 2, ISO 27001 and PCI DSS assessments. We write about what we see in real engagements, in plain English.