Building a simple incident response plan

An incident response plan does not need to be long. A clear one page plan that people actually know is far more useful than a fifty page document nobody has read. Here is what it should contain.

1. How to report

One simple, well known way to report a suspected incident: a dedicated email address, a chat channel or a phone number, available outside office hours. Make it easy and blame free; you want reports early, even uncertain ones.

2. Roles

• Incident lead: coordinates the response, makes or escalates decisions and keeps the timeline. Not necessarily the most senior or most technical person.
• Technical responders: investigate and act on systems.
• Communications lead: handles internal updates, customers and media when needed.
• Decision makers: who can approve shutting down a service, engaging outside help or notifying regulators.
• Scribe: records actions and times. In small teams, the incident lead does this.

Name people and deputies for each role.

3. Contacts

A list kept somewhere available even if your main systems are down, for example printed or in a separate secure location:

• Internal: IT, security, management, legal, HR, communications.
• External: cloud and software vendors' support, your internet provider, an incident response firm, your cyber insurance provider if you have one, and relevant authorities.

4. Severity levels

A short scale helps decide how urgently to act and who to involve:

• Low: limited impact, handled by the normal team during working hours.
• Medium: one system or account affected, or sensitive data possibly involved; start the incident process.
• High: multiple systems, confirmed data exposure or significant business disruption; involve leadership and consider outside help.
• Critical: widespread outage, ransomware or major data breach; all hands, executive involvement.

5. First steps checklist

• Do not panic and do not destroy evidence.
• Record what you saw and when.
• Report through the agreed channel.
• Do not contact the suspected attacker or alert them.
• Follow the relevant playbook if one exists.

6. Where things are

Locations of backups, log sources, network diagrams, asset inventories and administrative break glass accounts.

Keep it alive

Review the plan every six months and after every significant incident. Out of date phone numbers are one of the most common failures discovered during real incidents.