Start With the Purpose
A response plan exists so that people can make reasonable decisions quickly while stressed. It is not a compliance trophy. A forty-page document that nobody has read fails that purpose, while a short plan that people have practiced with often succeeds.
Aim for something a person could skim in a few minutes during an incident, with deeper detail kept in separate reference pages. If the plan cannot be found at 3 a.m. because it lives on the file server that just went down, it needs a copy somewhere else, including a printed or offline version.
The Core Sections
Purpose and scope
State briefly what the plan covers (security incidents affecting systems, accounts and data) and what it does not (for example, general outages handled through ordinary service management). Say which parts of the business and which systems are in scope. Keep this to a paragraph or two.
Definitions and severity levels
People need a shared answer to “how bad is this?” A simple scale of three or four levels is usually enough, with each level described in terms of impact: how many people or systems are affected, whether sensitive data may be exposed, whether business operations are stopped. Each level should say who must be told and how quickly.
This works much like ticket prioritization in a help desk, where impact and urgency together decide the response. Reusing familiar ideas helps staff adopt it.
Roles and responsibilities
Name roles first, then people. Typical roles include:
- Incident lead: owns the response and decides when to escalate. Often a senior IT person or security lead.
- Technical responders: investigate, contain and recover systems.
- Communications owner: drafts messages to staff, customers and others, and approves what is released.
- Management sponsor: can authorize disruptive decisions, such as taking a major service offline.
- Legal, privacy and HR contacts: consulted when personal data, employee conduct or legal duties are involved.
- Record keeper: maintains the timeline.
Each role needs a named primary and a backup, since people are on leave or unreachable. One person may fill several roles in a small team, and that is fine as long as it is explicit.
Contact list
Include names, roles, phone numbers and alternate ways to reach people, along with relevant external contacts such as your internet provider, key suppliers, an insurer if you have one, and outside specialists if you have an arrangement. Review this list on a schedule, because stale phone numbers are one of the most common failures. Store it where it can be reached when your main systems are unavailable.
Detection and reporting
Explain how staff report something suspicious: one phone number or address, available at all hours if possible, with a clear promise that reporting is welcome even when the person made a mistake. Describe the main alert sources the team watches and who looks at them. Your logging and monitoring arrangements belong here, at least in summary.
Response procedures
This is the practical center of the plan. Rather than writing one giant procedure, create short checklists for the most likely scenarios, such as:
- a phished or compromised account
- malware on a workstation
- a lost or stolen device
- ransomware on a server
- an exposed credential, such as a password pasted into a public place
Each checklist covers initial triage, containment steps, evidence to preserve, who to notify, and criteria for recovery. Keep wording plain and steps in order.
Communication rules
Decide in advance who may speak to staff, customers, the press and regulators, and who may not. Include a rule for what channel to use if normal email or chat may be compromised. Avoid speculation in messages, and record what was said and when.
Legal and privacy duties
If personal data may be involved, various privacy regulations may require notifying authorities or affected people within a set period. The rules depend on location and circumstances, so the plan should say who to consult early rather than trying to summarize the law. Records kept during the response can matter later.
Recovery and return to service
Describe how a system is declared clean and returned to use, who approves it, and what extra monitoring follows. Link this to your backups and any disaster recovery plan, so that the two documents agree about priorities and who decides.
Review and learning
Finish with a requirement to hold a post-incident review after significant incidents and to update the plan afterward.
Who Owns the Plan Itself
One named person should own the document: keeping it current, running practice sessions and collecting changes. Senior management should approve it so that the decision-making authority it describes is real. Without ownership, plans drift out of date as people change roles and systems are replaced.
Making It Usable
- Keep the main document short, with appendices for contacts and checklists.
- Use plain language, not jargon that only specialists understand.
- Test it. A tabletop exercise, in which the team talks through a made-up scenario, reveals missing contacts and unclear roles at very low cost. Once or twice a year is a common rhythm.
- Update after every real incident and after major system or staffing changes.
- Make sure people know it exists, and where.
A plan does not prevent incidents, and no plan anticipates everything. Its value is that, when something unexpected happens, people are working from a shared starting point rather than improvising from scratch.