Incident Response Plan Template: Mapped to PCI DSS 12.10 and ISO 27001

An incident response plan is a written, tested procedure that tells your team what to do the moment a security incident is suspected: who leads, how serious it is, how to contain it, who must be told and by when, and how to recover and learn from it. The template below is a copy-ready cyber incident response plan for UK organisations, with each section mapped to PCI DSS v4.0.1 Requirement 12.10 and ISO/IEC 27001:2022 Annex A controls 5.24 to 5.28. Copy it from this page or download the incident response plan template as an editable Word document, with contact tables, an incident log and a testing record ready to fill in.

Sovereign Secure does not provide live incident response or retainers. If you are dealing with an incident now, follow your insurer’s and acquirer’s instructions and the NCSC’s incident management guidance.

What is an incident response plan?

An incident response plan (IRP) is the documented procedure an organisation follows to detect, contain, investigate and recover from a cyber security incident, and to notify the right people on time. It names who leads, sets severity levels and escalation routes, and links to playbooks for specific attacks. It is the core document of security incident management.

It is easy to confuse with the documents around it:

What should an incident response plan include?

At minimum: scope, roles, reporting, classification, response steps, evidence, notification, recovery, lessons learned and testing. The table shows what each section must cover to satisfy PCI DSS and ISO 27001.

PCI DSS also requires a procedure for stored card numbers (PAN) found where they should not be (12.10.7). That requirement, 12.10.4.1 and the payment page tamper-detection alerts in 12.10.5 were future-dated and have been mandatory since 31 March 2025. Our PCI DSS guide to Requirement 12 puts these in context.

What are the incident response plan steps?

Most plans follow six steps of incident response:

1. Preparation: the plan, contacts, tools, logging and training in place before anything happens.
2. Detection and analysis: confirm an incident, record a timeline and set severity.
3. Containment: stop the spread, for example by isolating systems and disabling accounts.
4. Eradication: remove the cause, close the entry point and reset credentials.
5. Recovery: restore from known-good backups, monitor closely and return to service.
6. Lessons learned: find the root cause and improve controls and the plan.

The older NIST SP 800-61 Revision 2 model grouped steps 3 to 5 into one phase. Six steps are easier to assign to named owners.

The incident response plan template

Copy the sections below into your own document, or use the Word version, and replace the bracketed text. Keep the core plan short enough to use under pressure, and put detailed playbooks in appendices.

1. Purpose and scope

This plan sets out how [Organisation] detects, responds to and recovers from information security incidents affecting [systems, sites, services and data in scope, including the cardholder data environment if applicable]. It applies to all staff, contractors and [named suppliers]. Owner: [role]. Approved by: [director]. Last tested: [date]. Next review: [date, no more than 12 months away].

An event is anything observed that may affect security. An incident is an event that threatens the confidentiality, integrity or availability of information or systems. A personal data breach is a security breach leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data; the ICO deadline runs from when you become aware of one.

2. Roles and contacts

List external contacts too: IT or managed service provider, cloud and hosting providers, insurer, legal adviser, acquirer, payment service provider and forensic provider.

3. How to report a suspected incident

Anyone who notices something suspicious reports it immediately to [service desk, phone and email, 24/7], saying what they saw, when and on which system. Do not investigate, switch off or delete anything. Alerts from intrusion detection, file integrity monitoring, payment page tamper detection and wireless scanning go to [team] for triage.

4. Severity levels

Set response and update targets for each level that you can actually staff.

5. Response procedure

• Analyse: open the incident log, record every action with a time, set severity, and decide early whether personal data or card data is involved, because both start external deadlines.
• Contain: isolate affected systems from the network rather than switching them off, disable compromised accounts and block known indicators.
• Eradicate: remove malware and persistence, close the entry point, reset credentials and patch.
• Recover: restore from known-good backups, check integrity, monitor closely and return to service with the incident lead’s sign-off.

Appendices: playbooks for ransomware, business email compromise, card data compromise, lost devices, insider misuse and supplier compromise.

6. Evidence handling

Preserve logs, disk and memory images where possible, and record who collected what, when and how (chain of custody). Take forensic advice before running tools on affected systems.

7. Notification and communication

Use an out-of-band channel if email or chat may be compromised. The data protection lead decides on ICO and individual notification; the incident lead notifies the acquirer, insurer and regulators using the deadlines below. One approved spokesperson handles external questions.

8. Continuity and backups

Refer to [business continuity plan] and [backup restore procedure], and record recovery priorities for critical services.

9. Post-incident review

Within [number] days of closure: root cause, what worked, what did not, and actions with owners and dates. Update this plan, risk register and controls.

10. Testing, training and review

Test this plan at least every 12 months and after significant change. Train everyone with a role, at the frequency set in [targeted risk analysis or training plan]. Keep records of tests, training and changes.

Incident response plan example: a ransomware attack

This worked example shows how the template’s sections are used in order when a member of staff finds encrypted files on a Monday morning. The timings show the sequence, not targets to copy; set your own in section 4.

Turning this into a playbook for each likely attack, and rehearsing it in a cyber tabletop exercise, is how a plan becomes something a team can follow under pressure. For prevention steps, see how to prevent ransomware.

What extra steps apply to a card data breach?

If card data may be compromised, preserve evidence and tell your acquirer straight away. Specifically:

1. Do not switch off or rebuild affected systems; disconnect them from the network instead.
2. Preserve logs from payment systems, firewalls and payment pages.
3. Notify your acquirer immediately. The deadline comes from your merchant agreement and card brand rules, not PCI DSS, which requires your plan to cover notifying payment brands and acquirers and to include their incident procedures.
4. Expect a forensic investigation. The acquirer or card brand may require a PCI Forensic Investigator (PFI), a separate PCI SSC programme.
5. Run the 12.10.7 procedure if card numbers turn up outside the cardholder data environment, such as in logs, email or spreadsheets: retrieve, securely delete or migrate them, check for sensitive authentication data, find how they got there and fix the gap.

Card brand fines and costs are usually passed on by the acquirer; see PCI non-compliance fees. The standard itself is in the PCI SSC document library.

Who must you notify after a cyber incident in the UK, and how fast?

It depends on the data and your sector. These are the main deadlines to build into section 7.

The ICO’s report a breach page explains how to notify.

How often should an incident response plan be tested?

At least once every 12 months for PCI DSS (Requirement 12.10.2), covering every element of 12.10.1, and after significant changes. ISO 27001 sets no fixed frequency, but auditors expect evidence that the plan is prepared, communicated and improved.

The NCSC’s free Exercise in a Box is a good starting point for small teams. For boards, the government’s Cyber Governance Code of Practice asks directors to make sure the response plan is exercised at least once a year.

Test the incident response plan alongside your continuity plans: incident response contains and investigates the attack, while continuity plans keep critical services running and recover them. Our business continuity plan template covers the second half, and if customers or regulators want certified continuity arrangements, ISO 22301 business continuity is the standard to look at.

Why Sovereign Secure

• PCI SSC-approved QSA company: we assess Requirement 12.10 in PCI DSS assessments, so we know the evidence assessors ask for.
• ISO 27001 certified: our ISO 27001 consultancy includes incident response plan review and development as part of building your ISMS.
• Testing that exercises your detection: red team assessments and penetration testing show whether attacks are noticed and escalated.
• Clear about our role: we help you prepare and test; we do not provide live incident response or retainers.
• UK company since 2012, headquartered in Accrington, Lancashire, with offices in Los Angeles, Singapore, Dubai and Dhaka.

Get your plan reviewed

Send us your current plan, or this template once completed, and tell us which standards you work to. We will explain how a review fits within ISO 27001 or PCI DSS work and give you a fixed quote. Contact us or call +44 161 523 5276.