How SMBs Can Create a Ransomware Response Plan
Create a ransomware response plan with clear authority, out-of-band contacts, evidence handling, continuity decisions, legal review, and recovery order.
To review ransomware response roles, authority, evidence, and recovery dependencies, contact Quantm Technologies for a scoped conversation.
Response-plan essentials
- A usable plan names primary and alternate roles, trusted communication routes, and decision authority
- The plan must address the "to pay or not to pay" question BEFORE an attack occurs
- Include contact information for legal counsel, cyber insurance, law enforcement, and your MSSP
- Test the plan on a risk-based cadence and after material changes; retest identified gaps until the expected condition is demonstrated.
What the response plan must decide
An active ransomware incident can remove access to email, files, identity systems, customer records, and normal communication channels at the same time. A response plan records authority and contact routes before those systems become unavailable. It also gives responders a place to record what is confirmed, what remains uncertain, and which decisions require counsel, the insurer, or business leadership.
A response plan cannot predict every incident. It should pre-authorize safe actions, identify decisions that still require approval, and show how the team will work when facts are incomplete.
Response roles and records
Phase 1: Preparation (Before the Attack). The preparation phase is everything you do before an attack occurs. This includes identifying your critical systems and data (what must be restored first), documenting your network architecture and asset inventory, establishing relationships with incident response partners (MSSP, legal counsel, cyber insurance carrier, law enforcement), defining roles and responsibilities for every team member during an incident, creating communication templates for employees, customers, vendors, and media, and making the ransom payment decision in advance with executive leadership and legal counsel.
Phase 2: Detection and analysis. When suspicious activity is reported, responders determine what evidence is available, which identities and systems may be involved, whether data access is suspected, and which containment choices are safe. An MDR provider may support this work when the relevant telemetry is connected and the event falls within the contracted scope. The plan should use the provider's documented escalation route and service terms instead of assuming a response time.
Phase 3: Containment. Containment is the race to stop the ransomware from spreading further. Immediate actions include isolating affected systems from the network, disabling compromised user accounts, blocking command-and-control traffic at the firewall, shutting down network shares to prevent further encryption, and preserving forensic evidence (do not wipe affected systems). The goal is to draw a perimeter around the infection and prevent it from reaching systems that are not yet compromised.
Phase 4: Eradication and Recovery. Once the attack is contained, the recovery process begins. This includes identifying and removing all attacker access points (backdoors, compromised accounts), rebuilding affected systems from clean images, restoring data from verified clean backups, verifying the integrity of restored systems before reconnecting them, and implementing additional security controls to prevent recurrence. Recovery should follow a priority order: restore critical business systems first, then secondary systems, then non-essential systems.
Phase 5: Post-Incident Review. After recovery, conduct a thorough post-incident review to document what happened, what worked, what failed, and what needs to change. Update your response plan, security controls, and employee training based on lessons learned. Report to regulatory authorities if required. Notify affected customers and stakeholders. And file your cyber insurance claim with complete documentation.
Testing your plan. A plan that exists only on paper has not demonstrated that contacts, authority, communication, containment, or recovery will work. Set exercises according to critical services, change, and risk. Use different entry paths and business impacts over time, involve the decision-makers named in the plan, and retest failed conditions.
Frequently Asked Questions
Should our ransomware response plan include paying the ransom?
Your plan should address the payment question explicitly, but the default position should be not to pay. The FBI and CISA advise against payment because it funds criminal activity and does not guarantee recovery. However, your plan should define decision criteria that consider business impact, backup availability, data sensitivity, legal obligations, and insurance coverage, so the decision is informed rather than panicked.
Who should be on the incident response team?
At minimum: IT leadership (technical response coordination), executive leadership (business decisions and resource authorization), legal counsel (regulatory obligations and liability), communications lead (internal and external messaging), HR representative (employee-related issues), and your MSSP or external incident response partner. Each role should have a backup person designated.
How often should we test our ransomware response plan?
Choose a test cadence from service criticality, recovery objectives, change frequency, supplier dependencies, and prior results. Tabletop, notification, containment, workaround, and restore tests establish different things. Review the plan after relevant changes or incidents and retain evidence from each test.
Build a response plan people can use under pressure
A decision-ready plan tells responders when to declare an incident, what they may isolate, where they record evidence, and who contacts counsel, the insurer, suppliers, and leadership. It also establishes continuity and restoration authority. The plan should be short enough to use from an alternate workspace when normal email and files are unavailable.
Establish ownership and evidence
The plan should name primary and alternate leaders for technical response, operations, legal and privacy advice, insurance, communications, and executive decisions. Record the contact route, authority, and information each role requires. Store an approved copy outside the identity and file systems that may be unavailable.
Set the assessment boundary before testing. At minimum, include decision authority, alternates, out-of-band contacts, and restoration order. Dependencies deserve the same attention as the main application. A service may be technically restored yet remain unusable because identity, DNS, network access, encryption keys, or a third-party connection is unavailable.
Measure the result without inventing precision
During an exercise, measure the time to declare the incident, reach alternates, establish trusted communications, and make the first authorized containment and continuity decisions. Note where the team waited for a person, fact, or approval that the plan did not address.
Source and next step
- Canadian Centre for Cyber Security ransomware playbook
- Canadian Centre for Cyber Security, Ransomware threat outlook 2025 to 2027
- PIPEDA section 10.1
- NIST ransomware guidance for small businesses
Write decisions into the response plan
A response plan should tell people who can declare an incident, isolate systems, preserve evidence, contact the insurer, involve counsel, approve communications and authorize recovery spending. Contact lists and technical steps matter, but the plan fails if decision authority remains unclear when the normal systems or leaders are unavailable.
Use a scenario involving unavailable files, a compromised identity and an unverified data-theft claim as the working example. Ask the business incident lead to map out-of-band communication, technical response, legal advice, insurance, operations and executive authority, then follow the example through normal operation, disruption and recovery. The review should reveal where access, evidence or authority changes hands.
| Point in the scenario | Required evidence | Decision risk |
|---|---|---|
| Declare | Trigger, incident owner and severity record | Teams wait for certainty while activity continues |
| Contain | Approved isolation and identity actions | Technical staff lack authority or preserve no record |
| Continue operations | Critical service order and alternate procedures | Recovery priorities reflect servers rather than business needs |
| Communicate | Counsel, insurer, staff, customer and supplier routes | Messages are issued before facts and duties are assessed |
Finish by asking the team to convene primary and alternate contacts, make the initial containment decision and record the evidence used. Preserve the result and assign each gap to the person who can change the system or procedure. The next exercise should confirm that the gap was corrected rather than introducing a new scoring scheme.
Readers can continue with the continuity plan for disrupted services, the Canadian small-business ransomware guide, and a scenario for testing the plan. Each destination answers a different operational question and supports the hub-and-spoke structure.
Put a usable ransomware response plan into operation
Build the first plan around one critical service and the contacts, authority, and dependencies it needs during disruption. Complete these steps before adding detail:
- Assign incident roles and alternates. Name the owner, scope and expected result before changing a control.
- Write containment and continuity authority. Record exceptions and dependencies instead of treating partial coverage as complete.
- Exercise evidence, communication and restoration decisions. Preserve the evidence and assign follow-up work with a retest date.
Evidence to retain
- Out-of-band contact list should show the current scope rather than a planned future state.
- Approved isolation actions should identify the person or system that produced the record.
- Critical-service recovery order should include the date, limitation and unresolved exception.
- Decision and communication log should connect the technical result to the affected business service.
Evidence for response-planning ages. Review it after a major platform, supplier, identity, policy or staffing change. If the environment no longer matches the tested scope, mark the prior result as historical and schedule a new check.
Review questions
- Who declares the incident?
- What can IT isolate immediately?
- How is evidence preserved?
- When are counsel and insurer contacted?
- Who authorizes return to service?
Update the plan with confirmed names and authority, then assign missing decisions to leadership, IT, operations, counsel, or the insurer contact. Exercise the corrected condition. The complete ransomware protection guide supplies the preventive and recovery context that does not belong in the incident procedure.
Download the response-plan decision template
Download the ransomware response-plan template as CSV. The template covers incident declaration, identity and endpoint containment, continuity, counsel and insurer contact, and return to service.
Complete the primary and alternate owner, trusted contact route, pre-authorized action, approval requirement, evidence record, and last test date for each decision. Store the approved plan outside the systems it depends on. The template is an operating aid and does not replace legal advice, insurance instructions, technical playbooks, or a service-specific recovery procedure.