Incident response plan template

This plan sets out how [Organization] prepares for, detects, responds to and recovers from cybersecurity incidents. Its aims are to limit harm to our customers, staff and operations, to restore normal service quickly and safely, to protect evidence, and to meet our legal duties, including the duty under the Data Protection Act, 2020 (the "Act") to report certain breaches to the Information Commissioner within 72 hours.

This plan applies to:

• all information systems, networks, devices, cloud services and data that [Organization] owns, manages or uses, including systems run for us by IT providers and other third parties;
• all employees, contractors, interns and volunteers, who must report suspected incidents as set out in section 7;
• all of our locations: [list offices, branches and sites].

Physical emergencies such as fire, hurricanes and flooding are covered by our [business continuity or disaster recovery plan]. Where a physical event and a cyber incident happen together, the Incident Lead coordinates with the person responsible for that plan.

The incident response team is made up of the roles below. Contact details for each person and their deputy are in Appendix A. If a role holder is unavailable, their deputy acts with the same authority.

The Incident Lead assigns a severity level during triage and reviews it as more is learned. If in doubt, choose the higher level. Any incident that may involve personal data is treated as at least Severity 2 until the Data Protection Officer decides otherwise.

Preparation is what makes the rest of this plan work. [Plan owner] makes sure that:

• every role in section 4 has a named person and a deputy, and they know what is expected of them;
• the emergency contact sheet (Appendix A) is complete, checked every [6] months, and printed and stored off site;
• we keep an up-to-date list of our key systems, the data each one holds, who supports it and how to restore it;
• we know where personal data is held and which systems hold sensitive personal data;
• backups of key systems are taken [daily], at least one copy is kept offline or cannot be altered, and restores are tested [every quarter];
• logging is turned on for firewalls, servers, email and cloud services, and logs are kept for at least [90 days];
• multi-factor authentication is turned on for email, remote access, cloud services and administrator accounts;
• our IT provider contract says what help they give during an incident, including after hours;
• we know what our cyber insurance policy covers, how to notify the insurer and whether we must use its approved providers;
• staff are trained to recognize and report incidents, and know the reporting channels in section 7;
• we have a way to communicate if email is down or compromised, such as a phone tree or a separate messaging group [describe];
• the plan has been tested with a tabletop exercise in the last [12] months (section 19).

Incidents are detected by staff, customers, security tools, our IT provider, banks or outside parties. Anyone who suspects an incident must report it straight away to [IT help desk or Incident Lead, with phone number and email]. Outside working hours, call [after-hours number]. If you think your email account is compromised, report by phone, not email.

Report anything like this:

• a ransom note, files that will not open or have strange new names;
• a click on a suspicious link or attachment, or entering your password on a suspicious page;
• emails sent from your account that you did not send, or new forwarding rules you did not create;
• a request to change a supplier's or employee's bank details, or an unusual request for payment;
• a lost or stolen laptop, phone, USB drive or paper files;
• personal data sent to the wrong person or posted in the wrong place;
• unexpected pop-ups, programs, account lockouts, or a computer that suddenly runs very slowly;
• a customer or supplier telling you they received a strange message from us.

When you report, do not:

• switch off an affected computer, unless told to. Disconnect it from the network instead (unplug the network cable and turn off Wi-Fi);
• delete suspicious emails or files, run your own clean-up tools, or try to investigate yourself;
• contact the attacker, reply to a ransom note or pay anything;
• discuss the incident on social media, with the media or with anyone outside the response team.

You will not be penalized for reporting an honest mistake promptly. Reporting quickly is the single biggest thing you can do to limit the harm.

The person who receives the report contacts the Incident Lead. Within [1 hour] of a report, the Incident Lead, with the Technical Lead, works through the following:

• Open an incident record and give it a reference number [format, e.g. IR-2026-001]. Start the incident log (Appendix C).
• Get the facts from the person who reported it, using the incident report form (Appendix B).
• Confirm whether this is a real incident or a false alarm. If it is a false alarm, record it and close it.
• Work out what is affected: which systems, accounts, devices, locations and data.
• Decide whether the incident is still happening or spreading.
• Decide whether personal data may be involved. If it may be, tell the Data Protection Officer straight away and record the date and time we became aware. The 72-hour deadline for reporting to the Information Commissioner runs from this point (section 13).
• Assign a severity level (section 5) and escalate as that level requires.
• Decide whether outside help is needed now: IT provider, insurer, bank, or incident response specialists.
• Decide how the team will communicate. If email or the network may be compromised, use [phone or separate messaging group].

The goal of containment is to stop the damage from spreading while keeping evidence. The Technical Lead decides the steps; the Management Sponsor approves anything that will disrupt operations, such as taking a key system offline. The table gives first steps for common incidents.

Record every containment action in the incident log, with the time and who did it.

Once the incident is contained, the Technical Lead removes its cause. This normally includes:

• identifying how the attacker got in, such as a phishing email, a weak or reused password, an unpatched system or an exposed remote access service;
• removing malware, unauthorized accounts, remote access tools, forwarding rules and scheduled tasks the attacker created;
• rebuilding affected systems from clean, known-good sources where there is any doubt that cleaning is enough;
• resetting passwords for affected accounts, administrator accounts and service accounts, and revoking access tokens and keys that may be exposed;
• fixing the weakness that was exploited, such as applying patches, closing exposed services or tightening firewall rules;
• checking other systems for the same weakness or signs of the same attacker.

Recovery returns systems to normal operation safely. The Technical Lead and the owner of each business system agree the order in which systems are restored, starting with [the systems most critical to operations, e.g. payments, customer service, payroll].

• Confirm the backups to be used were taken before the incident began and are free of malware.
• Restore systems and data, and check them with the people who use them before returning them to service.
• Bring systems back in stages, watching for signs that the attacker is still present.
• Monitor affected systems and accounts closely for at least [30] days after recovery.
• Tell staff and, where appropriate, customers when services are back to normal.
• Record what data, if any, could not be recovered.
• The Incident Lead confirms the incident is resolved, and the Management Sponsor signs off closure for Severity 1 and 2 incidents.

In Jamaica, recovery may coincide with power outages or storm damage. Make sure the systems you restore first have reliable power and connectivity, and follow our [business continuity plan] where it applies.

Within [10] working days of closing a Severity 1 or 2 incident, the Incident Lead holds a review meeting with the response team and the people affected. Severity 3 incidents are reviewed [monthly as a group]. The review is about improving, not blaming.

• Use the post-incident review form in Appendix E.
• Agree what happened, the root cause, how it was detected and how long each phase took.
• Identify what worked well and what did not, including any part of this plan that was unclear or not followed.
• Agree actions, each with an owner and a due date, and track them to completion.
• Update this plan, the contact sheet and staff training as needed.
• Report the findings and the action plan to [management or the board].

Under the Act, a data controller must report to the Information Commissioner any security breach that affects or may affect personal data, and any contravention of the data protection standards, within 72 hours of becoming aware of it. The Data Protection Officer is responsible for making this report on behalf of [Organization].

• The 72 hours start when we become aware of the breach, not when the investigation ends. Weekends and public holidays count. The Data Protection Officer records the date and time we became aware in the incident log.
• Do not wait until all the facts are known. The Information Commissioner's online breach report form allows a report to be made in phases: an initial report, follow-up reports and a final report.
• Report through the "Report a Data Breach" form on the Office of the Information Commissioner's official website. The OIC has warned the public about a fraudulent website imitating it, so check that you are on the official site before entering any information.
• Affected people must be notified as required by the regulations. The Data Protection Officer decides, with the Management Sponsor, who must be told, what they are told and how.
• If a service provider that processes personal data for us has a breach, we may still need to report it. Our contracts with these providers should require them to tell us promptly.
• We keep a record of every personal data breach, including those we decide not to report, with the facts, the risk assessment and the reasons for our decision.

In general terms, the report to the Information Commissioner describes:

• who we are, and the contact details of our Data Protection Officer and of any service provider involved;
• what happened, when it happened and when we became aware of it, how it was detected and its likely cause;
• the types of personal data affected, and the approximate number and categories of people affected;
• the likely consequences for the people affected;
• what we have done and plan to do to deal with the breach and reduce the harm, including whether we have reported it to the police;
• whether and how we have notified the people affected.

Our [data breach response checklist] sets out the detailed steps. Breaching the Act's standards or failing to make a required report is an offense, and penalties can be significant, so take legal advice where the position is unclear.

All communication about an incident is coordinated by the Communications Lead and approved by [the Management Sponsor] before it is sent. Messages must be accurate, consistent and free of speculation. Never say that no data was affected until that has been confirmed.

Holding statement template: "[Organization] is aware of an IT incident affecting [some of our systems]. We acted quickly to contain it and are investigating with [specialist support]. [Services that remain available.] We will share updates at [channel]. Customers with questions can contact [contact details]."

Keep a copy of every message sent, with the date, time and audience, in the incident log.

Evidence may be needed to understand the incident, to support an insurance claim, to report to the authorities and in any legal action. The Technical Lead is responsible for preserving it.

• Do not switch off affected devices unless the Technical Lead says so. Disconnecting them from the network keeps information in memory that may be lost on shutdown.
• Do not run clean-up tools, reinstall systems or delete files before evidence is captured, unless that is needed to stop serious harm. Record it if it happens.
• Export logs from firewalls, servers, email and cloud services as soon as possible. Many services keep logs only for a limited time.
• Photograph ransom notes and error messages. Save suspicious emails as attachments so the full message details are kept, rather than forwarding them.
• Record each item of evidence: what it is, where it came from, who collected it, when, and where it is stored.
• Record every handover of an item of evidence from one person to another (the chain of custody).
• Store evidence securely, with access limited to [named roles]. Work on copies, not originals.
• If legal action or an insurance claim is likely, have forensic copies made by qualified specialists.
• Note the time zone and whether device clocks were accurate, so timelines can be matched.

The Incident Lead, with the Data Protection Officer and the Management Sponsor, decides which authorities to report to. Record each report, its reference number and the date and time it was made.

If we hold personal data about people in other countries, other countries' laws may also apply. Take legal advice.

• Do not reply to, negotiate with or pay attackers without a decision from the Management Sponsor, taken with advice from our legal adviser and insurer.
• Paying does not guarantee that data will be restored or deleted, and may encourage further attacks.
• Report the demand to the police and to JaCIRT.
• Keep the ransom note and any messages from the attackers as evidence.

A tabletop exercise is a guided discussion in which the response team works through a realistic incident scenario, step by step, using this plan. It finds gaps in the plan, contact details and decision-making before a real incident does. Nothing is switched off and no live systems are touched.

• Run an exercise within [3] months of adopting this plan, then at least [once a year], and after any major change to our systems, people or this plan.
• Include everyone named in section 4, their deputies, and where possible our IT provider.
• Allow [2 to 3] hours. A facilitator presents the scenario in stages ("injects"), and the team decides what to do at each stage.
• Record the gaps found and agree actions with owners and due dates, as in a post-incident review.

Scenarios to choose from:

• ransomware found on a Friday evening before a public holiday, with the IT provider's main contact unreachable;
• a supplier "changes" its bank details by email and a large payment has already been sent;
• a laptop holding customer records is stolen from a staff member's car;
• a spreadsheet of customer details is emailed to the wrong recipient;
• a cyberattack during a hurricane-related power and internet outage;
• our IT provider tells us its own systems have been breached.

Questions the exercise should answer: Who is in charge? How do we talk if email is down? When did the 72-hour clock start, and who is drafting the report to the Information Commissioner? Who calls the bank and the insurer? What do we tell staff and customers, and when? Can we restore from backup, and how long would it take?

• All staff are told how to recognize and report incidents when they join and in [annual] security awareness training.
• Members of the response team are briefed on this plan when they take on a role and take part in the tabletop exercise.
• Lessons from incidents and exercises are shared with staff, without naming individuals.

[Plan owner] reviews this plan every [12] months, after every Severity 1 or 2 incident, after each tabletop exercise, and when our systems, providers, staff or the law change. The emergency contact sheet is checked every [6] months. Changes are approved by [Management Sponsor] and recorded in the document control table.