Building an Incident Response Plan

1. Why you need a plan

When an incident happens, people are stressed, time is short and information is incomplete. A plan means the important decisions are made calmly in advance: who is in charge, who to call, what to do first and how to communicate.

Organisations with a practised plan notice incidents sooner, contain them faster and recover with less damage, to their systems, their reputation and the people they serve. A plan doesn't need to be long. Two or three pages that everyone knows are worth more than a thick binder nobody has read.

2. Before you start

• Get leadership support. The plan needs someone senior to own it and give it authority.
• Involve the right people. Include whoever handles IT, communications, finance, programmes and staff wellbeing. Small organisations may have one person covering several of these.
• Know what you're protecting. List your critical systems, accounts and data, and the people who could be harmed if they were exposed.
• Start from where you are. The Readiness Assessment shows your gaps and produces a simple starter plan you can build on.

3. Define what counts as an incident

Staff need to know what to report. A security incident is anything that threatens the confidentiality, integrity or availability of your information, systems or people: a phishing email someone clicked, a lost phone, a hacked account, a leaked file, a website attack, or harassment of a staff member online.

Agree severity levels so the response matches the risk:

4. Agree roles

Name people, not just job titles, and give every role a deputy. In a small organisation one person may hold several roles.

• Incident lead: takes charge, makes decisions, coordinates the response and keeps the log.
• Deputy lead: steps in if the lead is unavailable or is themselves affected.
• Technical lead: investigates, contains and recovers systems, or manages outside technical support.
• Communications lead: handles messages to staff, partners, affected people and the media.
• Wellbeing lead: supports staff who are targeted or affected, including physical safety.
• Leadership: approves major decisions, such as public statements, legal steps or paying for outside help.

5. Make reporting easy

• Choose one simple reporting channel, such as a secure group chat or a dedicated email address, and a backup in case that channel is compromised.
• Tell everyone, including volunteers and new staff, how and when to report.
• Make reporting blame-free. People who fear blame report late, and late reports cause the most damage.
• Ask for the basics: what happened, when, which device or account, and what they've done so far.
• Thank people for reporting, even false alarms.

6. Write the response steps

Use the five SIIRF steps as the backbone of your plan.

Prepare

• Keep an up-to-date list of devices, accounts and sensitive data, with owners.
• Put basic protections in place: 2-step verification, encryption, updates and offline backups.
• Train staff and practise the plan.

Identify

• Confirm what is happening and how serious it is, using your severity levels.
• Start the incident log: time, what was seen, who reported it.
• Decide who needs to be involved.

Contain

• Protect people first, especially anyone at physical risk.
• Stop the damage spreading: disconnect affected devices, reset passwords from clean devices, restrict access.
• Preserve evidence: don't delete messages, wipe devices or pay ransoms in a rush.

Recover

• Clean or rebuild affected systems, then restore from known-good backups.
• Check accounts and data are secure before returning to normal work.
• Keep affected people informed.

Learn

• Hold a short, blame-free review within two weeks.
• Agree what to change, who will do it and by when.
• Update the plan and share the changes.

7. Plan your communications

• Internal: how and when staff are told, and what they should and shouldn't say.
• Affected people: how you'll inform people whose data or safety is at risk, in a way that doesn't put them in more danger.
• Partners and funders: who tells them, and what they need to know.
• Public and media: who approves statements, and a short holding statement prepared in advance.
• Backup channels: how the team will talk if email, phones or messaging apps are compromised, such as a pre-arranged encrypted group and a phone tree.

8. Build your contact list

Keep a list that works offline, with a printed copy stored safely. Include:

• Incident lead, deputy and response team, with several ways to reach each.
• IT support and any outside digital security experts.
• A lawyer who understands data and digital rights issues.
• Your data protection authority, if the law requires you to report breaches.
• Platform reporting routes for your main accounts.
• Key partners, funders and your bank.

9. Add playbooks for likely incidents

A playbook is a one-page checklist for a specific incident. Start with your three to five most likely incidents, such as phishing, account takeover, lost devices, ransomware and data breaches. For each, write:

• How to recognise it.
• The first actions, in order.
• Who to involve and who to inform.
• How to recover and what to check afterwards.

The Incident Playbooks are a good starting point for your own playbooks.

10. Know your legal duties

• Find out which data protection laws apply to you, including laws in countries where your staff, partners or beneficiaries are.
• Many laws require reporting serious personal data breaches to a regulator within a short deadline, often 72 hours, and sometimes informing affected people.
• Check funder and partner agreements: many require you to report incidents to them.
• Note these duties, deadlines and contacts in the plan so nobody has to look them up mid-incident.

11. Test the plan

A plan that has never been practised will have gaps. Run a tabletop exercise at least once a year: walk through a realistic scenario as a team and talk through what each person would do.

• Keep it short: 60 to 90 minutes.
• Use a realistic scenario for your context.
• Note every question nobody could answer: those are your gaps.

12. Review and improve

• Review the plan after every incident or near-miss, and at least once a year.
• Update it whenever key people, systems or risks change.
• Keep a dated version history so everyone knows they have the latest copy.
• Keep your incident log up to date: patterns in it show where to improve. See The Incident Log.

13. Plan outline checklist

A complete plan usually includes:

1. Purpose and scope.
2. What counts as an incident, and severity levels.
3. Roles, responsibilities and deputies.
4. How to report an incident.
5. Response steps: prepare, identify, contain, recover, learn.
6. Communications plan and backup channels.
7. Contact list.
8. Playbooks for likely incidents.
9. Legal and contractual reporting duties.
10. Testing and review schedule, with version history.