Ransomware isn't just an IT issue. It's a business continuity challenge that involves IT systems. When attackers combine data theft with operational disruption, your incident response plan must address questions beyond the security team's scope: How do we maintain customer trust? Which business processes can we sustain manually? Who communicates with regulators?
This playbook guides you in building an integrated ransomware resilience program in four weeks. You're not just fortifying endpoints; you're preparing your organization to function during an attack.
What You Need Before Starting
Authority and Access:
- Executive sponsor with budget authority (you'll need sign-off on business continuity plan changes)
- Access to business continuity coordinators across critical functions
- Ability to schedule 90-minute tabletop exercises with department heads
- Read access to current cyber insurance policy and underwriting questionnaire
Technical Baseline:
- Inventory of all systems that handle customer data or generate revenue
- Current backup architecture documentation
- Identity management system with audit logging enabled
- Existing incident response plan (even if outdated)
Team Involvement:
- At least one business continuity planner
- Legal counsel familiar with Breach Notification Requirements
- Communications lead who reports to C-suite
- Finance contact who understands Contingent Business Interruption Coverage triggers
If you don't have an incident response plan, start there first. This playbook assumes you have basic technical controls and need to integrate them into operational resilience.
Week One: Map Business Dependencies
Day 1-2: Identify Critical Business Processes
Meet with each department head and ask: "If this system goes down for 72 hours, what stops working?" Document the business impact, not just the technology. Revenue processing matters more than the server name.
Create a simple spreadsheet:
- Column A: Business process (e.g., "customer order fulfillment")
- Column B: Supporting systems
- Column C: Maximum tolerable downtime before revenue impact
- Column D: Manual workaround available? (yes/no)
- Column E: Customer-facing? (yes/no)
Day 3-4: Map Third-Party Dependencies
List every vendor with access to your environment or data. For each, document:
- What data they can access
- Authentication method (SSO, API keys, direct database access)
- Their incident notification SLA (check your contract)
- Whether they're in scope for your Cyber Maturity Assessment
If a vendor can't tell you their incident notification timeline, note it as a gap.
Day 5: Validate Backup Coverage
Don't just check that backups run. Verify they cover the systems identified in days 1-2. For each critical business process, confirm:
- Backup frequency matches your maximum tolerable downtime
- At least one backup generation is stored offline or air-gapped
- Backup includes configuration data, not just application files
- Restoration procedure is documented with specific commands
If you're using cloud-native backup, ensure it's in a separate tenancy from production. Attackers who compromise your primary environment often find backups in the same account.
Week Two: Build Response Integration
Day 6-8: Update Incident Response Plan with Business Continuity Triggers
Your incident response plan probably covers containment and eradication. Add a section called "Business Continuity Decision Points" with specific triggers:
- If [system X] is encrypted, activate manual process Y within 4 hours
- If customer data is exfiltrated, legal initiates Breach Notification Requirement review within 2 hours
- If attacker threatens publication, communications lead drafts customer notification immediately
Assign a name to each trigger, not just a role.
Day 9-10: Define Communication Protocols
Ransomware creates pressure from multiple directions. Document who communicates with:
- Customers (if service is disrupted)
- Regulators (if Nonpublic Information is involved)
- Cyber insurance carrier (First Notice of Loss requirements)
- Board members
- Employees
Write template messages now. Your Breach Coach can review these templates in advance.
Week Three: Test and Validate
Day 11-13: Conduct Tabletop Exercise
Schedule a 90-minute session with department heads, legal, communications, and IT. Use this scenario:
"It's Tuesday at 6 AM. Your monitoring tools detect unusual authentication activity from a cloud service account. By 8 AM, file servers in three locations are encrypted. Attackers left a note claiming they exfiltrated customer payment data. Your backups are intact but restoration will take 18-24 hours. Walk me through the first four hours."
Let the conversation expose gaps. Common findings:
- No one knows who has authority to approve ransom payment discussions
- Communications team doesn't have pre-approved messaging
- Business continuity coordinators don't know which systems are encrypted
- Legal isn't sure which state Breach Notification Requirements apply
Document every gap. You'll address them in week four.
Day 14-15: Validate Backup Restoration
Restore a critical system from backup to a test environment. Time it. Document every step. If the procedure says "restore database from backup," that's not specific enough. The actual command sequence matters.
Common issues you'll find:
- Credentials for backup system aren't documented
- Restoration requires software that isn't installed on recovery systems
- Configuration files aren't included in backup
- Database dependencies aren't documented
Fix these now.
Week Four: Operationalize and Document
Day 16-18: Close Gaps from Tabletop Exercise
For each gap identified in week three, assign an owner and deadline. Typical fixes:
- Add decision authority matrix to incident response plan (who can approve what, at what cost threshold)
- Pre-stage communication templates in a shared drive accessible during an outage
- Create a simple one-page "system status" template that IT can update every 2 hours during an incident
- Schedule a 30-minute legal briefing on Breach Notification Requirements for the incident response team
Day 19-20: Update Vendor Risk Assessments
For third parties identified in week one, add these questions to your next vendor review:
- What's your incident notification timeline? (get a specific SLA)
- Do you maintain offline backups?
- Have you tested restoration in the last 90 days?
- If your environment is compromised, what data of ours is at risk?
If a vendor can't answer these questions, escalate. Your cyber insurance underwriter will ask about third-party risk management during renewal.
Day 21: Document and Communicate
Create a single-page reference guide for executives:
- Critical systems and maximum tolerable downtime
- Business continuity triggers and who activates them
- Communication protocol (who speaks to whom)
- Recovery time expectations based on your restoration tests
Share this with your board. Ransomware resilience isn't about preventing every attack. It's about maintaining business operations when prevention fails.
Validation: How to Verify It Works
Run a surprise drill quarterly. At 9 AM on a random Tuesday, send your incident response team this message: "Assume all file servers in location X are encrypted. Activate business continuity procedures." Don't warn them in advance.
Measure:
- Time to activate manual workarounds
- Time to notify stakeholders per your communication protocol
- Whether backup restoration follows documented procedure
- Whether executives know their roles without prompting
If any of these fail, your plan needs work.
Maintenance: Ongoing Tasks
Monthly:
- Review vendor access logs for unusual authentication patterns
- Verify offline backup generation completed successfully
- Update business process dependency map when new systems deploy
Quarterly:
- Conduct unannounced business continuity drill
- Review and update communication templates
- Validate backup restoration (pick a different system each time)
Annually:
- Full tabletop exercise with executive participation
- Review cyber insurance policy for coverage changes
- Update vendor risk assessments
Ransomware groups now combine encryption with data theft, extortion, and reputational pressure. Your resilience strategy needs to match that complexity. This isn't just a four-week project. It's a foundation for a program that evolves as your business and threats change.
