---
title: "Incident management policy template"
canonical: https://www.grcmana.io/vault/templates/incident-management-policy
published: 2023-12-11
updated: 2026-10-17
author: "Harry West"
framework: "ISO 27001"
type: "Policy"
---

# Incident management policy template

## Key takeaways

An incident management policy is the document in which leadership commits to managing security incidents: what counts as one, who owns the process and who decides on notification. ISO 27001 control A.5.24 requires defined, communicated incident roles, and A.6.8 requires a way for staff to report. This Word template suits UK firms of 25 to 250 staff.

- **Required by** — ISO 27001:2022 control A.5.24, with A.6.8 for staff reporting
- **Approved by** — Top management, together with the incident response plan's severity tiers
- **Review cycle** — At least annually, and after a major incident or significant change
- **Format** — Word, about 7 pages, with a staff reporting notice and a policy management checklist

Someone in finance forwards a suspicious invoice email to IT on Monday, three days after clicking the link in it. Nobody told them that reporting it was their job, or that Friday mattered. An incident management policy settles that before it happens: leadership commits to managing incidents, names who owns the process and makes reporting every employee's duty. This template gives a UK firm of 25 to 250 staff a ready-to-edit incident management policy in Word, written to ISO 27001 control A.5.24.

## What's in the template

One Word document, about seven pages, version 1.0. It has four parts.

1. **The incident management policy.** Three pages, laid out the way an ISO 27001 auditor reads it: purpose and scope, the definitions your plan also uses, leadership's commitments, roles and responsibilities, the staff duty to report, who decides on severity and notification, learning from incidents, and how the policy is approved and reviewed.
2. **A one-page staff reporting notice.** What to report, how and how fast, in plain English for your intranet or induction pack. It points to the reporting channel your incident response plan sets.
3. **A getting-started guide and next steps.** Which sections to edit first, what to leave as written, and how the policy hands the detail to your incident response plan.
4. **A policy management checklist.** Approval, acknowledgement, awareness training and review dates: the records an auditor asks to see alongside the policy.

Every placeholder is in square brackets. You replace the names, roles and reporting channel, confirm each commitment is true, and the policy is ready for management approval.

The policy is the "what" and the "who". The step-by-step "how" lives in its companion, the [incident response plan template](https://www.grcmana.io/vault/templates/incident-response-plan).

## What is an incident management policy?

An incident management policy is the short document in which leadership commits to managing information security incidents. It says what counts as an incident, who owns the process, what every member of staff must do when they spot something, who makes the big decisions and how the firm learns afterwards. It sets the rules. It doesn't hold the playbook.

Auditors ask for it because ISO 27001 expects incident management roles and responsibilities to be defined and communicated, and expects staff to have a way to report what they see. Customers ask for it because their due-diligence questionnaires want to know that someone is accountable, and that your people will speak up.

A policy that tells staff to report, without telling them how, is a poster.

### Policy or plan: which document holds what?

Most firms need both, and the line between them is simple. The policy holds the commitments and decides who decides. The plan holds the steps. Detail that changes often, such as phone numbers and severity criteria, stays in the plan, so updating it doesn't need a board meeting.

| Topic | Incident management policy | Incident response plan |
| --- | --- | --- |
| What counts as an incident | Defines event, incident, personal data breach and major incident | Uses the same definitions, word for word |
| Ownership | Names the policy owner, the incident lead role and the notification decision-maker | Names the people, their deputies and out-of-hours contacts |
| Reporting | Makes reporting a duty for all staff and contractors, with no blame for reports made in good faith | Sets the single reporting channel and what a report should include |
| Severity | Management approves the severity tiers and says who may declare a major incident | Holds the P1 to P4 tiers, their criteria and response targets |
| Notification | Names who decides on regulatory and client notification, and requires every personal data breach to be recorded | Holds the notification map and the clocks |
| Learning | Requires a review of every P1 and P2 incident and reports trends to management review | Holds the post-incident review form and the incident log |

### Which standards and regulators expect one

ISO 27001 sets the controls the policy answers to. UK law, your regulators and your contracts decide which notification duties it has to assign. Which rows apply depends on the data you hold, whether you are authorised by the FCA and who your clients are.

| Standard or regulator | What it asks for |
| --- | --- |
| ISO 27001:2022, control A.5.24 | Plan and prepare for managing incidents by defining, establishing and communicating incident management processes, roles and responsibilities. The policy is where the roles and responsibilities are set and communicated. |
| ISO 27001:2022, control A.6.8 | Give staff a way to report observed or suspected information security events through appropriate channels, in a timely manner. |
| ISO 27001:2022, controls A.5.25 to A.5.27 | Assess events and decide which are incidents, respond in line with documented procedures, and use what you learn to strengthen your controls. The policy requires these; the plan carries them out. |
| UK GDPR, Articles 33 and 34 | Report a personal data breach to the ICO without undue delay and, where feasible, within 72 hours of becoming aware of it, unless it is unlikely to result in a risk to people. Tell the people affected without undue delay when the risk to them is high. Document every breach, whether you report it or not. The policy names who makes that call. |
| FCA (authorised firms) | SUP 15.3 requires a firm to notify the FCA immediately of matters with a serious regulatory impact, and its guidance includes any significant failure in systems or controls. |
| DORA (EU financial entities, and their ICT suppliers by contract) | An ICT-related incident management process, with roles and responsibilities, and reporting of major ICT-related incidents to the competent authority. |
| Customer due diligence | Security questionnaires commonly ask for the policy, who owns incident management, and how quickly you would tell the customer about an incident affecting them. |

For the depth on each control, see the guides to [A.5.24 incident management planning](https://www.grcmana.io/vault/iso-27001/annex-a-5-24-information-security-incident-management-planning-and-preparation) and [A.6.8 event reporting](https://www.grcmana.io/vault/iso-27001/annex-a-6-8-information-security-event-reporting). The response itself is covered under [A.5.25 assessing events](https://www.grcmana.io/vault/iso-27001/annex-a-5-25-assessment-and-decision-on-information-security-events), [A.5.26 responding to incidents](https://www.grcmana.io/vault/iso-27001/annex-a-5-26-response-to-information-security-incidents) and [A.5.27 learning from incidents](https://www.grcmana.io/vault/iso-27001/annex-a-5-27-learning-from-information-security-incidents).

## How to create your incident management policy with this template

With the groundwork in place, this takes about half a day plus one management meeting. Without it, the policy will promise a process nobody runs, so check the groundwork first.

### Before you start

The policy commits the firm to things that have to exist on the day. Check you have:

- **An information security policy and an ISMS scope.** The incident policy sits beneath your top-level policy and should use the same scope and owner. No top-level policy yet? Start with the [information security policy template](https://www.grcmana.io/vault/templates/information-security-policy).
- **Someone to lead incidents, and a deputy.** The policy names the role; a real person has to hold it. At 25 staff that is usually a director. No obvious candidate? The [A.5.2 guide](https://www.grcmana.io/vault/iso-27001/annex-a-5-2-information-security-roles-and-responsibilities) covers assigning security roles.
- **A reporting channel that works.** A shared mailbox, a Teams channel or a phone number that someone monitors, including out of hours if you operate then. Set it up before the policy makes it mandatory.
- **Your notification footprint.** Know whether you hold personal data as a controller or a processor, whether you are FCA-authorised, whether DORA reaches you through your clients, and what your client contracts promise. Not sure of an answer? Write down what you know, mark the gaps, and close them before you name the notification decision-makers in step 4. The [A.5.31 guide](https://www.grcmana.io/vault/iso-27001/annex-a-5-31-legal-statutory-regulatory-and-contractual-requirements) covers keeping that register.

If none of these exist yet, the job is bigger than one policy. That's the point where most firms bring in help.

**1. Name the owner, the approver and the decision-makers** *(about 15 minutes)*

- **Do this:** put names against the policy owner, the approver, the incident lead role and its deputy, and the person who decides whether a breach is reported to a regulator, often a DPO or data protection lead.
- **The template:** lays these roles out with a one-line responsibility each, so you're filling in names, not designing a governance model.
- **Watch for:** a notification decision-maker with no deputy. The ICO clock keeps running while they're on holiday.

**2. Define what counts as an incident** *(30 to 45 minutes)*

Next, set the scope and the four definitions: event, incident, personal data breach and major incident. The template provides all four, matched word for word to the incident response plan, so staff, responders and auditors use the same terms. Your job is to add the everyday examples that make them real for your firm: a laptop left on a train, an email sent to the wrong client, a supplier telling you they've been breached.

> **Where most firms get stuck:** defining an incident as a cyber attack. Staff then don't report the misdirected email, the lost phone or the shared password, and those everyday incidents are exactly what an auditor expects to find in your log. Write the definitions around what actually happens at your firm.

**3. Write the duty to report** *(about 30 minutes)*

- **Do this:** state that every member of staff, every contractor and, through their contracts, your key suppliers must report observed or suspected events straight away, through the channel the plan sets, and must not investigate on their own.
- **The template:** includes the duty, a no-blame statement for reports made in good faith, and the one-page staff notice that turns both into plain English.
- **Watch for:** "report it to your line manager". It adds a step, and the manager may be on leave. Point staff straight to the channel the response team monitors.

> **Where most firms get stuck:** a duty to report that punishes the person who reports. If the last person who admitted clicking a phishing link was singled out, the next one stays quiet. Say in the policy that good-faith reports never lead to disciplinary action, and make sure managers behave that way.

**4. Decide who decides** *(about 30 minutes, then the management meeting)*

Then settle the decisions that can't wait for a meeting. Who approves the severity tiers in the plan? Who may declare a major incident and hand it over to business continuity? Who decides whether a breach goes to the ICO, the FCA or a client, and who speaks to the press? The template sets these out as authorities, not steps, and leaves the detail to the plan.

Write them so the incident lead can act at 2am within the approved tiers, without asking permission. The [A.5.29 guide](https://www.grcmana.io/vault/iso-27001/annex-a-5-29-information-security-during-disruption) covers the hand-over to continuity, and the [A.5.5 guide](https://www.grcmana.io/vault/iso-27001/annex-a-5-5-contact-with-authorities) covers keeping contact with regulators and law enforcement.

An incident lead who needs permission to act is a messenger.

**5. Approve, communicate and set the review** *(one management meeting, then 1 to 2 hours)*

- **Do this:** take the policy to top management for approval, together with the plan's severity tiers. Publish it, ask everyone in scope to acknowledge it, and add the reporting duty to induction and annual awareness training. Set the next review date no more than a year out, with an extra review after any major incident.
- **The template:** includes the staff notice and a policy management checklist for the approval, acknowledgement, awareness and review records.
- **Watch for:** acknowledgement with no awareness behind it. An auditor may ask a member of staff how they would report an incident. The records that answer that are covered in [How to use it so it holds up at audit](#how-to-use-it-so-it-holds-up-at-audit).

### Do it yourself, or have us do it with you

|  | Do it yourself with the template | Do it with GRCMANA |
| --- | --- | --- |
| What you end up with | An approved incident management policy | This policy and the incident response plan, consistent with each other, with roles and severity tiers fitted to your firm, a reporting channel set up and tested, and staff briefed on how to report |
| Your time | Half a day plus one management meeting, if the groundwork is in place. Considerably more if it isn't | Agreed with you at the start, based on the groundwork you already have |
| Best if | You already have an incident lead and a working reporting channel, and someone on your team is comfortable making the calls above | Compliance landed on you alongside your day job, nobody has run an incident before, the audit date is fixed, or a client is asking who would tell them about a breach |

Prefer the second column? [Talk to us about incident readiness](https://www.grcmana.io/contact).

## What does a good incident management policy look like?

Most incident management policies pass a quick read. Fewer hold up when the auditor asks a member of staff how they would report something. Here is the difference.

### Weak and strong, side by side

| Clause | Weak | Strong | Why the strong one passes |
| --- | --- | --- | --- |
| Definition | "An incident is any cyber attack against the company." | "An information security incident is one or more events that compromise, or are likely to compromise, the confidentiality, integrity or availability of information. Examples include a lost device, an email sent to the wrong recipient and a supplier breach affecting our data." | Staff can recognise the everyday incidents, not just the dramatic ones. |
| Duty to report | "Staff should let their manager know about incidents." | "All staff, contractors and \[suppliers\] must report any observed or suspected event immediately to \[channel\]. Reports made in good faith never lead to disciplinary action." | It is a duty, the channel is direct, and it removes the reason people stay quiet. |
| Ownership | "IT is responsible for incidents." | "The \[COO\] owns this policy. The incident lead role is held by \[name\], with \[deputy\], and leads the response under the incident response plan." | Named roles can be sampled. A department can't. |
| Notification | "We will comply with all notification requirements." | "The \[DPO\] decides whether a personal data breach is reportable to the ICO and records the reasoning either way. The \[CEO\] approves any notice to clients or other regulators." | It names who decides. "Comply" names nobody. |
| Learning | "We will learn from incidents." | "Every P1 and P2 incident is reviewed, and its actions are tracked to closure. Incident trends and open actions are reported to each management review." | A.5.27 expects lessons to improve controls. A line into management review shows that they do. |

### What an auditor checks in the first five minutes

Before reading the detail, most auditors check that:

1. **It's current.** It has a version, an approval date and a review date that hasn't passed.
2. **The right person approved it.** The approver is top management, and there's a record of the approval.
3. **The terms match the plan.** The policy, the plan and the incident log use the same definitions and severity tiers.
4. **Reporting is a real duty.** It applies to everyone in scope, and the channel it names exists and is monitored.
5. **The roles are filled.** The incident lead and the notification decision-maker are named people who still work at the firm.
6. **It's genuinely yours.** It has your organisation's name and specifics throughout, with no leftover template text.

If all six hold, the auditor moves on to the plan and the incident log. If one fails, they tend to test staff awareness harder.

### What good looks like at 25 staff and at 250

| Feature | Around 25 staff | Around 250 staff |
| --- | --- | --- |
| Length | Two pages | Three pages; the detail sits in the plan |
| Approver | The CEO or managing director | The board or executive committee |
| Policy owner | A director who holds it alongside their main role | A named security or compliance lead |
| Incident lead | The founder, the COO or a fractional CISO, with a named deputy | A security lead, with a duty manager out of hours |
| Notification decision | The managing director, with outside data protection advice | A DPO or data protection lead, with legal counsel on call |
| Reporting channel | A shared mailbox or Teams channel, plus one phone number | A service desk route, plus a monitored out-of-hours line |

The common mistake at 25 staff is a policy that names a security team the firm doesn't have. The common mistake at 250 is a policy nobody outside IT has read, so incidents surface through gossip rather than the channel.

## How to use it so it holds up at audit

The policy is only half the evidence. An auditor tests whether people follow it, and these are the records they usually ask for:

- **The approval record:** who in top management approved this version and the plan's severity tiers, and when.
- **Acknowledgement:** evidence that staff in scope have read it, from an HR system, an e-signature or a training platform.
- **Awareness records:** induction and annual training that covers how to report, with completion dates.
- **Reports in the incident log:** entries raised by people outside IT, which show that the duty to report works.
- **Management review input:** incident trends and open actions taken to the [management review](https://www.grcmana.io/vault/iso-27001/clause-9-3-management-review), with the decisions that followed.
- **The review history:** the date of the last review, what changed, and the next review date.

**The most common reasons this policy fails audit:**

- It was never formally approved, or the approver isn't top management.
- Staff can't say how they would report an incident.
- The named incident lead or notification decision-maker has left.
- Its definitions don't match the plan or the log, so nobody can tell what was an incident.
- It promises a review of every serious incident, and no reviews exist.
- It was copied from a template and still carries the template's wording or another organisation's name.

If staff don't know how to report, the policy doesn't operate, however well it reads.

## Incident management policy questions

### What should an incident management policy include?

Its purpose and scope, definitions of event, incident and personal data breach, leadership's commitments, and who owns the process. It should also set the duty for all staff to report, say who decides on severity and on notifying regulators or clients, require lessons to be captured, and state how it is approved and reviewed.

### What is the difference between an incident management policy and an incident response plan?

The policy sets commitments, ownership and the duty to report, and is approved by top management. The plan is the step-by-step playbook the response team follows: contacts, severity criteria, response phases and notification clocks. Keeping them separate lets you update the plan without re-approving the policy.

### Who is responsible for incident management?

Top management is accountable. The policy owner keeps the policy current, the incident lead runs the response under the plan, and a named decision-maker handles regulatory notification. Every member of staff is responsible for reporting what they see, straight away.

### Do employees have to report security incidents?

Under a well-written policy, yes. Reporting observed or suspected events is a duty for all staff and contractors, and ISO 27001 expects a channel for it. Reports made in good faith should never be punished, or people stop making them.

### How often should an incident management policy be reviewed?

At least once a year, and again after a major incident or a significant change such as a new incident lead or a new regulator. Keep a record of each review, even when nothing changes.

## Get the template

Start from a policy that already sets the commitments, roles and reporting duty an auditor expects, and uses the same terms as the incident response plan. Download the Word template, put your names in, and take it to your next management meeting alongside the plan.

*This template is a starting point to adapt to your organisation, not legal advice.*