Skip to content

Business Continuity Plan After a Cyberattack: A Template

Critical processes, RTO and RPO, manual workarounds: a practical business continuity plan template so your small business keeps serving clients after an attack.

By the Cyber Caribou team6 min read

Monday, 6:40 a.m., at a 30-person food distributor in the West Island. Six trucks are supposed to leave at 9. The operations manager opens his laptop and can't reach the order management system. On the server, every file has a new extension, next to a ransom note.

The IT provider is on the way to isolate the network and restore backups, which will take days. Meanwhile, a much simpler question needs an answer: how do we deliver to the grocery stores this morning?

That is what a business continuity plan (BCP) is for. This guide gives you a usable structure, based on guidance from the Canadian Centre for Cyber Security and NIST.

TL;DR

  • A business continuity plan answers one question: how do you keep serving clients while your systems are down? It complements your incident response plan; it doesn't replace it.
  • In its ITSM.10.014 guidance (January 2026), the Canadian Centre for Cyber Security recommends three complementary plans: incident response, business continuity and disaster recovery.
  • The core of a BCP: your critical processes, a recovery time objective (RTO) and a recovery point objective (RPO) for each, and a manual workaround.
  • Keep a paper copy. A plan stored on the encrypted server is useless.

Continuity, incident response, recovery: what's the difference?

A business continuity plan keeps essential activities running during a disruption, an incident response plan contains the attack, and a disaster recovery plan brings you back to normal operations. In its January 2026 publication ITSM.10.014, the Canadian Centre for Cyber Security describes the BCP as a specific plan to recover the services most critical to your operations as quickly as possible.

PlanQuestion it answersExample at the distributor
Incident responseHow do we stop the attack and limit the damage?Isolate the network, call the insurer, preserve evidence
Business continuityHow do we keep serving clients in degraded mode?Take orders by phone, deliver with paper slips
Disaster recoveryHow do we get back to normal, and in what order?Restore order management, then accounting, then the rest

No incident response plan yet? Start with our template for small businesses.

For method, the standard reference is still NIST SP 800-34 Rev. 1 (2010), which sets out seven steps: policy, business impact analysis, preventive controls, recovery strategies, the plan itself, testing and maintenance. A small business doesn't need all the formality, but the order is right.

Step 1: Identify your critical processes

A critical process is an activity whose interruption causes serious harm within hours or days: lost clients, penalties, missed legal deadlines. To find them, get leadership in a room for two hours and ask three questions about each activity:

  1. How long can we stop it before it becomes serious?
  2. What are the consequences: money, clients, obligations, reputation?
  3. Which systems, suppliers and people does it depend on?

That's your business impact analysis. NIST calls the key figure the maximum tolerable downtime, all impacts included. The Cyber Centre adds that only critical services belong in the BCP; everything else can wait. Aim for five to eight processes, not thirty.

Step 2: Set an RTO and an RPO for each process

The recovery time objective (RTO) is the maximum downtime you can tolerate; the recovery point objective (RPO) is the maximum amount of data you can afford to lose, expressed in time. Those are the Cyber Centre's definitions. NIST adds that the RTO must be shorter than the maximum tolerable downtime, because you also need time to catch up on the backlog.

Here's the distributor's table:

Critical processSystemRTORPOManual workaround
Order takingOrder management, email4 h1 hPhone orders on numbered paper forms
Picking and deliveryOrder management, label printer8 h4 hPrinted client and route list, blank delivery slips
Supplier paymentsOnline banking2 daysn/aUrgent payments by phone with the bank, two approvers
PayrollCloud payroll service3 days1 dayRepeat the previous pay run with the payroll provider
InvoicingAccounting software5 days1 dayInvoices issued later from paper delivery slips
Phone and emailVoIP, email4 h1 dayForward calls to cell phones, printed contact list

Then test those targets against reality. If backups run nightly, your real RPO is at least 24 hours. If your last full restore took three days, an 8-hour RTO is wishful thinking. The gap becomes your to-do list, which often starts with tested 3-2-1-1-0 backups.

According to a CDW Canada study published in 2025, small Canadian organizations took an average of 25.7 days to recover from an incident. A BCP won't necessarily shorten that, but it lets you keep delivering and invoicing in the meantime.

Step 3: Plan manual workarounds

A manual workaround is a way to carry out a critical process without the usual system; it only works if it's written down, known to staff and ready to use. The paper form has to exist before the crisis, not be invented at 7 a.m. on a Monday. The most common ones:

  • Printed lists, updated monthly: clients, suppliers, employees, emergency numbers.
  • A standby laptop, kept off the usual network, to read the plan and reach the bank.
  • A backup communication channel: a messaging group on cell phones, or an emergency email address outside your usual environment. If the mailbox is compromised, the attacker reads everything you write in it.
  • Crisis payment rules: no banking change accepted during the incident without a call-back to a known number. Fraudsters love chaos.

And don't plug back in the computers that "look fine" until your IT provider gives the green light.

The BCP template, section by section

A small business BCP fits in five to ten pages; at fifty, nobody will read it during a crisis. Use this list as your template:

  • Activation: who triggers the plan, on what criteria, and who steps in if they're away.
  • Crisis team: three to five people, each with a role (decisions, operations, communications, IT liaison).
  • Emergency contacts: IT provider, your insurer's incident line, bank, legal counsel, key clients and suppliers.
  • Critical processes with their RTO and RPO (the table above).
  • Workarounds and where the materials are: forms, lists, standby laptop.
  • Communications: pre-drafted messages for staff, clients and suppliers, as the Cyber Centre recommends.
  • Recovery order for systems, agreed with your IT provider.
  • Obligations: in Quebec, Law 25 requires an entry in your confidentiality incident register and, if the incident presents a risk of serious injury, notice to the Commission d'accès à l'information and the people affected. Elsewhere in Canada, PIPEDA has its own breach rules. Check these obligations with your legal advisor.
  • Paper copy, up to date and stored off-site, as the Cyber Centre's baseline controls recommend.
  • Date of the last review and of the last exercise.

Test the plan before you need it

A continuity plan that has never been tested is only a hypothesis: test it at least once a year, and after any major change of software or supplier. The Cyber Centre suggests several formats, from seminars to live exercises, with tabletop exercises in between.

For a small business, a tabletop exercise is the best place to start: two hours, a realistic scenario, and the crisis team walking through the plan out loud. Our guide to running a tabletop exercise shows you how. Add a technical test: time the restore of one critical system and compare the result to your RTO.

Every exercise uncovers gaps: an outdated phone number, a form nobody can find, a key person on vacation. Fix them, date the new version, print it.

Our team can help you build this plan and put it to the test through our ongoing security partnership. Prefer to talk it through first? Book a free consultation with one of our experts.

Frequently asked questions

What is the difference between a business continuity plan and a disaster recovery plan?+

A business continuity plan keeps your critical activities running during an outage, often in a degraded mode with manual workarounds. A disaster recovery plan describes how to restore systems and return to normal operations, and in what order. The Canadian Centre for Cyber Security recommends having both, alongside an incident response plan.

How do I set RTO and RPO for a small business?+

For each critical process, ask how long it can stop before serious harm occurs: that is the basis of your RTO, the recovery time objective. Then ask how many hours of data you can afford to lose: that is your RPO. Compare these targets to your actual backups; a nightly backup means an RPO of at least 24 hours.

Does a 20-person company really need a business continuity plan?+

Yes, but it can fit in a few pages: critical processes, tolerable downtime, workarounds, contacts and prepared messages. A small business without in-house IT often depends on a handful of people and applications, which makes a long outage especially costly. The plan lets you make the hard decisions calmly, in advance.

How often should a business continuity plan be tested?+

We recommend at least one exercise a year, plus a new test after any major change such as new business software, a new IT provider or a move. The Canadian Centre for Cyber Security doesn't set a specific frequency but stresses regular testing, such as tabletop exercises. A timed restore test is a good complement.

Sources

  1. 1.Canadian Centre for Cyber Security: Improving cyber security resilience through emergency preparedness planning (ITSM.10.014, January 2026)
  2. 2.Canadian Centre for Cyber Security: Baseline cyber security controls for small and medium organizations
  3. 3.NIST SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems
  4. 4.CDW Canada: IT and cybersecurity trends for small businesses in Canada (2025)
  5. 5.LégisQuébec: Act respecting the protection of personal information in the private sector (P-39.1)