Writing an incident response plan that works for a small organization

The Canadian Centre for Cyber Security puts 'develop an incident response plan' first in its baseline cyber security controls for small and medium organizations. NIST SP 800-61 Rev. 3, published in April 2025, goes further and treats incident response as part of everyday cyber risk management, aligned to the functions of the NIST Cybersecurity Framework 2.0, rather than a separate emergency binder. Both point to the same thing: the plan exists so people do not have to invent the process in the middle of an attack.

A good small-organization plan fits on a handful of pages and answers six questions:

• Who is in charge, and who can they call at 2 a.m.?
• Who can authorize spending, shut systems down, and speak to clients or media?
• How will we communicate if email and Teams are down or compromised?
• What do we do first for the incidents we are most likely to face?
• How do we preserve evidence and decide whether we must notify anyone?
• How do we know the plan still works?

Roles matter more than names, because people go on holiday. Assign a primary and a backup for each, and write down what each role can decide without asking.

The plan's contact list must work when your systems do not. Store it on paper and on personal phones, and include your insurer's claims line and policy number, counsel, your bank's fraud department, your IT provider's after-hours number, and an incident responder. Agree an alternate channel in advance, such as a group call number or a messaging group set up on personal devices, so you are not coordinating through a mailbox the attacker can read. Our printable incident contact sheet and call-tree guide cover this in detail.

Do not try to cover every possible attack. Attach one-page playbooks for the three or four scenarios most likely for your organization. For most Canadian small businesses that means:

• Business email compromise and payment fraud
• Ransomware or widespread encryption
• Lost or stolen laptop or phone
• Data sent to the wrong person, or a vendor reporting a breach that involves your data

1. 01

   Start a timeline

   Who noticed what, when. Photograph screens. Record every action taken.

2. 02

   Preserve before you clean

   Isolate devices rather than powering them off; do not wipe or reimage until key systems are imaged; export or hold cloud logs before they age out.

3. 03

   Call the insurer early

   Many policies require prompt notice and approval of vendors.

4. 04

   Assess notification with counsel

   Under PIPEDA, a breach creating a real risk of significant harm must be reported to the Privacy Commissioner and affected individuals notified as soon as feasible. Quebec, Alberta and Ontario health custodians have their own rules.

5. 05

   Keep the breach record

   PIPEDA requires a record of every breach of security safeguards to be kept for 24 months, reported or not.

An untested plan is a guess. Run a tabletop exercise at least once a year: walk the team through a realistic scenario, such as a finance mailbox hijacked on a Friday afternoon, and note every point where someone did not know what to do or who to call. Update the plan after every exercise, every real incident, and every change of IT provider, insurer, bank or key staff. ISO/IEC 27035, the international standard on incident management, builds the same cycle of planning, response and lessons learned into its approach.

If you want help, we run tabletop exercises and review plans against your actual systems and contracts.