Do you need an incident response plan, and what should it include?

Do you actually need an incident response plan?

Yes. If your organisation holds personal information, processes payments, or depends on systems whose failure would disrupt the business, you need a written incident response plan (IRP). The question is no longer whether incidents happen, but whether your team will react well when one does — and that depends on having decided the hard things in advance.

Beyond good practice, a plan is increasingly a baseline expectation. Breach-record-keeping obligations under PIPEDA, health-sector rules like PHIPA, and Quebec's Law 25 all assume you can detect, assess, and document incidents. Frameworks such as SOC 2 and ISO 27001 require a documented and tested incident response process, and enterprise and healthcare buyers routinely ask to see one during vendor security reviews. The absence of a plan is itself a finding.

• You collect, store, or process personal or health information.
• You are pursuing or hold SOC 2, ISO 27001, or a comparable certification.
• You sell to enterprise, government, or healthcare buyers who run vendor security reviews.
• You carry cyber insurance — most policies now require a documented IRP.
• You operate systems whose downtime would materially harm the business or its customers.

What should an incident response plan include?

A complete incident response plan covers six core areas. Each answers a question your team should not be working out for the first time in the middle of an incident.

Keep the plan concise and usable. A 60-page document no one can find at 2 a.m. is worse than a clear two-page playbook with the essentials and the phone numbers.

• Roles and contacts: who leads the response, who decides on notification, and how to reach legal counsel, IT, executives, your cyber insurer, and outside experts — including after hours.
• Severity classification: how you rank incidents (for example, low, medium, high, critical) so the response matches the threat and the right people are pulled in.
• Detection and containment: how incidents are reported and triaged, and the first steps to isolate systems, revoke credentials, and preserve evidence rather than wiping it.
• Notification triggers and deadlines: the legal thresholds and clocks that decide whether and when you must tell regulators and affected individuals.
• Communications: who approves internal updates and external messaging to customers, partners, regulators, and the public, and how those are coordinated with legal.
• Post-incident review and recovery: how you restore systems safely, find the root cause, and update controls, training, and the plan itself afterward.

What breach-notification rules should the plan reference?

Your plan should map the notification rules that apply to your data and the people it affects, because the deadlines can be short and the thresholds are easy to misjudge under pressure. Identifying obligations early is one of the most error-prone parts of a real incident, so do the homework before one happens.

Privacy Horizon's role here is to help you simplify these obligations into a clear decision tree your team can follow, not to leave you parsing statutes during a crisis.

• PIPEDA (Canada, private sector): report breaches posing a 'real risk of significant harm' to the Office of the Privacy Commissioner of Canada, notify affected individuals as soon as feasible, and keep a record of all breaches.
• PHIPA and other provincial health laws: health information custodians have their own breach-notification duties that may apply alongside or instead of PIPEDA.
• Quebec's Law 25: requires notifying the Commission d'acces a l'information and affected individuals of confidentiality incidents presenting a risk of serious injury, and maintaining a register of incidents.
• GDPR (EU/EEA data): notify the supervisory authority within 72 hours of becoming aware where there is a risk to individuals, and notify individuals when the risk is high.
• HIPAA (US protected health information): breach notification obligations apply to covered entities and business associates within defined timeframes.

How is an incident response plan different from a disaster recovery or business continuity plan?

An incident response plan, a disaster recovery (DR) plan, and a business continuity plan (BCP) are related but distinct, and a mature organisation has all three. Confusing them leaves gaps exactly where you can least afford them.

The incident response plan governs how you handle a security or privacy incident — detection, containment, investigation, notification, and lessons learned. The disaster recovery plan covers how you restore IT systems and data after a disruptive event, such as restoring from backups after ransomware. The business continuity plan is broader still, covering how the whole organisation keeps operating — people, premises, and processes — during a major disruption. In practice they hand off to one another: an incident triggers the IRP, and if it takes systems offline, the IRP invokes DR and BCP to recover and keep the business running.

How do you keep an incident response plan effective over time?

A plan only works if it is tested and kept current — an untested plan is a hope, not a capability. Run a tabletop exercise at least annually, walking the team through a realistic scenario (such as ransomware or an exposed customer database) to find gaps in contacts, decision rights, and assumptions before a real attacker does.

Review and update the plan whenever your systems, vendors, regulatory exposure, or team change, and always after a real incident. Capture what worked and what did not, fix the root causes, and feed those lessons back into the plan, your controls, and staff training. This is where ongoing security leadership matters: a virtual CISO can own the plan, run the exercises, and make sure improvements actually land rather than sitting in a document. You can also use our Security Incident Calculator to estimate the potential cost of an incident and help justify the investment in being prepared.