Building an incident response plan and team
In short: An incident response plan sets out who does what, how serious incidents are rated, who can make key decisions and how people communicate when systems may be compromised. A short, tested plan with clear roles beats a long document nobody has read.
Why you need a written plan
During an incident people are stressed, information is incomplete and decisions are urgent. Without a plan, teams argue about who is in charge, cannot find phone numbers and forget to call the insurer or regulator. An incident response plan (IRP) answers those questions in advance. It sits alongside detailed playbooks for common incident types such as ransomware, phishing and lost devices.
Team and roles
A computer security incident response team (CSIRT) may be a permanent group in a large organisation or a virtual team called together when needed. The most important role is the incident commander, who coordinates the response and makes or escalates decisions, but does not do the hands-on technical work. A dedicated scribe keeping a timestamped log is often overlooked and always valuable.
Include people outside IT: legal, privacy (the data protection officer if you have one), HR for insider cases, communications, and a senior executive who can make business decisions such as shutting down a service.
What the plan should contain
- Scope and definitions: what counts as an incident and who the plan covers.
- Roles and authority: named people and deputies, and who can approve isolation, shutdowns, external disclosure and spending.
- Severity levels: criteria, response times and escalation paths for each level.
- Contact list: internal staff, IT suppliers, managed security provider, cyber insurer, legal advisers, police and regulators, with phone numbers that do not depend on company systems.
- Communication: primary and out-of-band channels, update frequency and approval for external messages.
- Playbooks and evidence handling: links to procedures and rules for preserving evidence.
- Review: when the plan is tested and updated.
Severity and communication
Base severity on business impact: how many people or systems are affected, whether personal or sensitive data is involved, legal duties and reputational risk. Keep criteria simple so a tired analyst at 3 a.m. can apply them.
Assume the attacker may be reading your email and chat. Agree an out-of-band channel, such as a separate messaging workspace on personal phones or a conference bridge, and keep a printed or offline copy of the plan and contacts.
| Small organisation | Large organisation |
|---|---|
| Virtual team; one person may hold several roles | Dedicated CSIRT with on-call rota |
| Relies on IT supplier and insurer's response firm | In-house forensics and threat intelligence |
| Two-page plan plus a few playbooks | Full plan, many playbooks, regular exercises |
Tip: agree a retainer with an external incident response firm before you need one. Contracts and approvals take time you will not have during a crisis.
Practice
Why should the incident commander avoid doing hands-on technical work?
What is out-of-band communication and why is it needed?
Give three groups outside IT who belong in an incident contact list.
Key takeaways
- A plan decides roles, authority and contacts before an incident.
- The incident commander coordinates; a scribe keeps the log.
- Severity levels should be simple and based on business impact.
- Use out-of-band communication and keep offline copies of the plan.
- Test and update the plan regularly, for example with tabletop exercises.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.