Incident Response Plan Template

10

sections the document needs

4

wordings people reliably get wrong

6

things an auditor asks to see

1-2 days

to write it yourself

A plan someone can follow at 2am is short, specific and rehearsed, and ten sections do the job. Each entry below is a brief rather than the wording itself, because the answers have to be yours. Four of the ten carry an example clause, because they are the four that go wrong most often.

1. 1

   Purpose and scope

   What it must contain

   One paragraph fixing the boundary: who the plan binds, which information it covers, and which systems sit inside it. Write the boundary you actually have.

   What the auditor checks

   Scope is how they decide whether a given event should have followed this plan. A vague boundary turns every incident you handled informally into a process failure you cannot argue your way out of.

2. 2

   What counts as an incident

   What it must contain

   A one-line definition, then a short set of examples drawn from your own systems so nobody has to interpret the definition under pressure.

   What the auditor checks

   They describe an event and ask whether it counts. If your people would answer differently from your document, detection is not working no matter what the tooling says.

3. 3

   Roles and responsibilities

   What it must contain

   Who leads an incident, who does the containment work, who is allowed to speak publicly, and who can authorize a decision that costs money. Job titles, each with a deputy.

   What the auditor checks

   They check the roles map to real people who know they hold them. In a small business one person may hold two - say so, rather than inventing a team that does not exist.

   [Role] is the communications lead, the only person authorized to speak to customers, regulators or media.

   It names a role rather than a department, and the word only carries the clause: it is what stops a well-meaning engineer answering a journalist mid-incident.

4. 4

   Severity and response times

   What it must contain

   A small number of levels defined by impact rather than cause, each carrying its own clocks, plus a line saying who sets severity and who may change it.

   What the auditor checks

   These are the numbers your own incident records get held against, so they have to be times you can genuinely staff at 3am on a Sunday.

5. 5

   Reporting

   What it must contain

   Where a report goes, what happens out of hours, and what an employee must not do to an affected device before the lead arrives.

   What the auditor checks

   Under-reporting is invisible until they interview staff. They ask a non-technical employee where they would report a suspicious email and compare the answer with what you wrote.

   Report immediately to [channel], and to [after-hours number] outside hours. Nobody is penalized for reporting something harmless.

   One destination instead of a chain of command, and amnesty in writing - which is what turns a twelve-hour delay into a ten-minute one.

6. 6

   Response phases

   What it must contain

   The standard handling sequence, written as instructions rather than theory. Use the canonical names and order, set out further down this page.

   What the auditor checks

   They trace one real incident through the phases in order. A cleared symptom with the exposed credential still valid is the classic finding: recovery was done, eradication was not.

7. 7

   Evidence and chain of custody

   What it must contain

   What gets captured before anything is changed, and the record of who held each item and when.

   What the auditor checks

   Less an ISO question than an insurance and legal one, but it surfaces the moment an incident touched personal data: they ask how you established what was actually accessed.

8. 8

   Notification and communications

   What it must contain

   The deadlines that legally bind you, an owner for each, and the test that starts each clock. Contracts usually run shorter than the law, so name who checks them.

   What the auditor checks

   They compare the date you became aware with the date you notified. A plan with no clock in it cannot evidence that the clock was met.

   Where [trigger test] is met, [Organization] notifies [regulator] and the affected individuals within [deadline], counted from the moment we become aware.

   The order is what makes it work: the test that starts the clock, then the deadline, then who gets told. Write one of these per regime that actually binds you, and delete the rest - a plan listing laws you are not subject to reads as copied.

9. 9

   Post-incident review

   What it must contain

   Which incidents earn a written review and how fast, what the review must record, and where its actions go afterward.

   What the auditor checks

   This is the improvement loop, and it is the section they push hardest on. They want an action from the last review that is closed, dated and traceable to something that changed.

   Every severity 1 and 2 incident gets a written review within 10 business days, and every action carries an owner and a due date.

   It is testable: two dates and a list an auditor can open. Compare it with the version most plans carry, which promises that a review will be held - a sentence nobody can ever fail and nobody can ever verify.

10. 10

    Testing and maintenance

    What it must contain

    How often the plan is exercised, what forces an extra test, and the document control block that dates and owns it.

    What the auditor checks

    The first thing they look at and the easiest to fail. A plan last approved two years ago by somebody who has left is a finding before anyone reads the content.

Setting the severity scale

Severity is the first decision in any incident: it sets who gets woken up and how fast the clock runs. Keep it to four levels, define each by impact rather than cause, and write the response times beside them. The grid below is the shape, not a calibration to copy - severity 1 shows what a tight clock reads like, and the rest are yours to set at times your own roster can genuinely meet at 3am.

1. Severity 1 (critical)

   The business is visibly affected, or data is confirmed to have moved.

   Acknowledge within 15 minutes, at any hour. Contain the same hour.

2. Severity 2 (high)

   One account, endpoint or user is compromised, and it is contained there.

   Acknowledge inside the business hour.

3. Severity 3 (medium)

   Something looks wrong, but no compromise is confirmed.

   Acknowledge the same business day.

4. Severity 4 (low)

   Handled correctly by the person who found it.

   Acknowledge the next business day.

Two rules keep a scale honest, and both belong in the text: anyone may raise an incident at any severity, and only the incident lead may lower one. Re-classify upward the moment the facts change.

The six response phases

Section six is the spine of the response itself. Use the canonical names and this order, one line of instruction each - an auditor tracing a real incident expects to find all six, and a renamed sequence just makes the tracing harder. What each phase is really for:

1. 01

   Preparation

   Everything you need has to work before you need it. A plan nobody rehearses is a document, not a capability.

2. 02

   Identification

   Confirm it is real, record it, and put one named person in charge of it.

3. 03

   Containment

   Stop the spread first. Containment beats investigation, every time.

4. 04

   Eradication

   Remove the cause, not the symptom. This is the phase most often skipped under pressure.

5. 05

   Recovery

   Restore from something you trust, then watch it before you call it closed.

6. 06

   Lessons learned

   The phase thin plans drop and every auditor asks about. No written review, no improvement loop.

Confirming the document exists, is approved and covers the right ground takes about two minutes. The rest of the session is a conversation about what your organization did the last time something went wrong. These are the questions, close to verbatim, and what a good answer looks like.

? Show me the incidents you handled in the last twelve months.

Satisfies A register with the date and time each was raised, its severity, who led it, what was done and when it closed - low-severity ones included.

Fails An empty register reads as a detection failure, not a quiet year.

? Who decided this one was a severity 2?

Satisfies A person's name against the decision, and criteria in the plan that match how they were applied in practice.

Fails Severity set by whoever happened to pick up the phone is the common answer and the wrong one.

? You promised acknowledgment within 15 minutes. Did you make it?

Satisfies Timestamps from a system you already use - the ticket, the alert, the chat channel - held against your own targets. Missing a target you set is a far smaller problem than having no way to tell either way.

? What changed because of the last serious incident?

Satisfies A written review with a root cause, actions carrying owners and due dates, and at least one of them closed and traceable to a real change: a configuration, a new control, a new version of this plan.

? Who is on call this week, and what happens if they do not answer?

Satisfies A current roster, a named deputy for every role, and a contact list verified within the period the plan promises.

Fails A number belonging to someone who left in March is one of the easiest findings an auditor will ever write.

? When did you last test this, and what broke?

Satisfies Dated notes from a tabletop exercise listing who attended, what did not work on the day, and what you changed afterward.

Fails An exercise where nothing went wrong is usually an exercise that was not really run.

One pattern runs through all six: they are checking your records against your own commitments, not against an external standard of good behavior. That is why the numbers you write into the plan matter more than how ambitious they sound.

Almost every weak incident response plan fails in one of the same six ways. Read your draft against this list before anyone else does - each one takes a minute to check and most take an afternoon to fix.

• ! Departments instead of people

  "The IT team will contain the incident" describes nobody at 2am. Name the incident lead by job title, name a deputy, and make sure both of them know they hold the role.

• ! Response times you cannot staff

  Copying a 15-minute acknowledgment into a plan with no on-call roster writes the finding for the auditor: they hold your timestamps against your own promise. Set clocks you can meet today, then tighten them once you can.

• ! No usable definition of an incident

  Without concrete examples, staff escalate a slow laptop and stay quiet about a password typed into a fake login page. Five examples from your own systems beat a paragraph of theory.

• ! A plan you cannot reach during the incident

  The plan is in the wiki behind the single sign-on that was just disabled, and the contact list is in a mailbox nobody can open. Keep an offline copy, with printed phone numbers, where the response actually happens.

• ! Reflex reimaging

  The laptop is wiped within the hour and rebuilt by lunchtime. Months later an insurer or a regulator asks what was taken, and the honest answer is that you cannot say. Isolate, capture, then rebuild.

• ! Reviews that change nothing

  The review happens, actions get listed, nobody owns them and the plan version never moves. A run of reviews with no closed actions reads as a process that exists but does not work.

The cover at the top of this page and the body page below are one plan, built to the structure in the guide and run through PolicyMint's own export path with an example company's branding applied. Generated for your business, it arrives with the severity scale tuned to your systems and customers, the incident lead and the single communications lead named as real roles, acknowledgment and containment clocks you can meet, and the notification deadlines that bind you - every section verified and cited to A.5.24, A.5.25 and A.5.26.

Everything above is what you need to write this plan without us. If you would rather not spend the day or two, here is the same one document the other way round.

Scroll the table sideways to compare both routes.