Ransomware Response Plan: 5 Steps Before Attackers Strike

It’s 2:47 AM on a Saturday when your phone buzzes on the nightstand. The message is from your IT director: “File servers are encrypted. Seeing a ransom note. Call me.”

Your stomach drops. You’ve read the headlines about ransomware attacks—school districts, hospitals, manufacturing plants, law firms. You always assumed it wouldn’t happen to your organization. Now you’re staring at a screen full of encrypted files, a demand for cryptocurrency, and a decision tree that will determine whether your business survives the next 72 hours.

Here’s the uncomfortable truth: by the time you’re in that moment, your options are already limited. The quality of your response depends entirely on what you did before the attack happened. A ransomware response plan isn’t something you write during a crisis. It’s something you build in the calm, quiet weeks when nothing is on fire—and then you hope you never need to use it.

The problem is that most organizations don’t have a real plan. They have a vague sense that they should back up their data. Maybe they have an incident response document that was written three years ago and never updated. Maybe they’ve talked about doing a tabletop exercise but never got around to it. Meanwhile, ransomware groups are running sophisticated operations with dedicated teams, affiliate programs, and customer service departments for handling negotiations.

This article walks through five essential steps you can take right now—before attackers strike—to build a ransomware response plan that actually works. Not theoretical. Not academic. Practical steps you can start implementing this week.

—

Why Most Ransomware Response Plans Fail Before They’re Ever Tested

Let’s start with an uncomfortable observation: the majority of ransomware response plans I’ve seen over the years share the same fatal flaw. They exist as documents, not as capabilities.

A document says “we will isolate affected systems.” A capability means someone on your team knows exactly which systems to isolate, has the credentials to do it, and has practiced the process under pressure. A document says “we will notify stakeholders within 24 hours.” A capability means you have a pre-written communication template, a current contact list, and someone designated to hit send.

The gap between documentation and capability is where ransomware attacks turn into business-ending events.

According to research from cybersecurity firms tracking ransomware trends, the average downtime after a ransomware attack is now measured in weeks, not days. For small and mid-sized businesses, that kind of disruption is often fatal. Studies consistently show that a significant percentage of SMBs that experience a major cyberattack close within a year.

But here’s what doesn’t get talked about enough: the organizations that recover quickly aren’t necessarily the ones with the biggest security budgets. They’re the ones that made deliberate decisions about preparation. They invested in the right places. They practiced. They built muscle memory.

And that’s what the five steps below are designed to help you do.

—

Step 1: Build a Real Asset Inventory (Not the Spreadsheet You Made Three Years Ago)

You can’t protect what you don’t know you have. This sounds obvious, but it’s remarkable how many organizations have no accurate picture of their own IT environment.

I’m not talking about a spreadsheet someone created during onboarding and never updated. I’m talking about a living, breathing inventory that includes:

• Every endpoint — laptops, desktops, servers, mobile devices
• Every application — including shadow IT that departments spun up without telling anyone
• Every data repository — where your sensitive information actually lives
• Every network connection — including that VPN tunnel the vendor set up and forgot to document
• Every user account — especially the privileged ones and the service accounts nobody monitors

Why does this matter for ransomware response? Because when you’re in the middle of an attack, you need to answer questions fast. Which systems are affected? What data is at risk? What can we safely disconnect without breaking critical business functions?

Without an accurate inventory, you’re flying blind. You’ll either isolate too much and cripple your own operations, or isolate too little and let the attackers spread further.

The Practical Side of Asset Discovery

If your inventory is outdated or incomplete, start with automated discovery tools. Network scanning, endpoint detection platforms, and cloud security posture management tools can help you build a current picture. But don’t just rely on tools—talk to your department heads. Ask them what software they’re using, what cloud services they’ve signed up for, what contractors have access to what.

I’ve seen organizations discover entire forgotten servers during this process. One manufacturing client found a legacy system running Windows Server 2003 that was still connected to their network and processing orders. It had been “decommissioned” in a project plan, but nobody actually turned it off.

That kind of discovery is uncomfortable in the moment. It’s much worse when you find it because it’s the entry point for a ransomware attack.

Key takeaway: Your asset inventory needs to be accurate enough that you can quickly determine blast radius during an incident. If you can’t answer “what’s affected” within an hour, your inventory isn’t good enough.

For organizations that need help building this foundational visibility, managed service providers like IP Services offer IT asset management as part of their core offerings. Sometimes the fastest path to a real inventory is partnering with a team that does this work every day.

—

Step 2: Implement Immutable, Tested Backups (and Actually Test Them)

Backups are the last line of defense against ransomware. They’re also the thing most organizations get wrong.

The problem isn’t that companies don’t back up their data. Most do. The problem is that the backups are often:

• Accessible from the main network — meaning ransomware can encrypt them too
• Not regularly tested — meaning nobody knows if they actually work until it’s too late
• Incomplete — missing critical systems or data that was added after the backup policy was written
• Too slow to restore — meaning recovery takes weeks instead of days

Modern ransomware groups specifically target backups. They know that organizations with good backups are less likely to pay. So they spend time during the initial intrusion identifying and destroying backup systems before triggering encryption on the main network.

The 3-2-1-1 Rule (and Why It Matters)

You’ve probably heard of the 3-2-1 backup rule: three copies of data, on two different media types, with one copy offsite. That’s a good start, but it’s not enough anymore.

The updated guidance adds another “1”: one copy that is immutable or air-gapped. This means the backup cannot be modified or deleted, even by someone with administrative credentials. Immutable backups are typically stored in a format that prevents changes for a defined retention period—often using object storage with write-once-read-many (WORM) capabilities.

Additionally, at least one copy should be offline or in a separate environment with completely different credentials. If your production environment gets compromised, the attacker shouldn’t be able to reach your backup infrastructure.

The Testing Question

Here’s the thing about backups that “should work”: they often don’t.

I’ve talked to IT teams that discovered—during an actual recovery scenario—that their backup software hadn’t successfully completed a full backup in months. The jobs were scheduled, the logs looked normal, but somewhere along the way, the backups stopped being usable.

You need to test your backups. Not just verify that backup jobs completed, but actually restore data and confirm it works. This should happen:

• Monthly at minimum for critical systems
• Quarterly for full recovery scenarios — can you actually restore your entire environment?
• After any major infrastructure change — new servers, new applications, new data sources

The test isn’t “did the backup job run?” The test is “can we restore this data and use it?”

Recovery Time Objectives vs. Recovery Point Objectives

Two terms you need to understand:

Recovery Point Objective (RPO) — How much data can you afford to lose? If your RPO is four hours, you need backups every four hours. If it’s 15 minutes, you need continuous replication.

Recovery Time Objective (RTO) — How long can you operate without this system? If your email server goes down and your RTO is two hours, you need a recovery process that can restore email within two hours.

For ransomware response planning, these numbers matter because they determine your backup strategy. A system with a 24-hour RPO and a one-week RTO can be backed up differently than a system with a 15-minute RPO and a one-hour RTO.

Document these objectives. Get business stakeholders to agree on them. Then build your backup and recovery strategy to meet them.

Managed backup and disaster recovery services can help here. IP Services, for example, includes managed backup and disaster recovery as part of their service portfolio, with a focus on ensuring business continuity for mission-critical operations. For organizations without deep in-house expertise, that kind of partnership can mean the difference between a minor disruption and a major outage.

—

Step 3: Develop a Communication and Decision-Making Framework

When ransomware hits, chaos is the default state. People panic. Information is incomplete. Everyone wants answers immediately.

The organizations that handle this well have something the panicked ones don’t: a pre-defined framework for communication and decision-making.

Who’s in Charge?

During a ransomware incident, someone needs to be making decisions. This person needs to:

• Understand the business impact of various response options
• Have the authority to make tough calls (like shutting down systems)
• Be available immediately, even at 3 AM

This is typically the incident response manager or crisis coordinator. In smaller organizations, it might be the IT director or even the CEO. In larger organizations, it might be a dedicated security leader.

The key is that this role is defined before the incident, not assigned in the middle of one.

The Decision Tree

Ransomware response involves a series of decisions, many of which need to be made quickly and under pressure. Having a pre-defined decision tree helps:

Immediate decisions (first hour):

• Do we isolate affected systems? Which ones?
• Do we shut down the entire network or just segments?
• Do we engage external incident response help?
• Do we contact law enforcement?

Short-term decisions (first 24 hours):

• Do we pay the ransom? (Hint: usually no, but it’s a business decision)
• How do we communicate with employees?
• What do we tell customers and partners?
• Do we need to notify regulators?

Medium-term decisions (first week):

• What’s our recovery priority order?
• How do we restore operations while rebuilding security?
• What’s our public communication strategy?

Having these decisions mapped out in advance means you’re not inventing your response in real-time while attackers are actively encrypting your data.

Communication Templates

Pre-written communication templates are worth their weight in gold during an incident. You’ll need templates for:

• Internal communications — to employees, explaining what’s happening and what they should do
• Customer communications — explaining service disruptions and expected timelines
• Partner/vendor communications — alerting them to potential risks
• Regulatory notifications — if you’re in a regulated industry
• Media statements — if the incident becomes public

These templates should be drafted, reviewed by legal, and ready to customize. When you’re in the middle of a crisis, you don’t want to be starting from a blank page.

The Contact List That Actually Works

Your incident response contact list needs to include:

• Internal team members (with personal phone numbers, not just work email)
• External incident response firms
• Legal counsel (with cyber expertise)
• Cyber insurance provider
• Law enforcement contacts
• Key vendors and partners
• PR/communications support

And here’s the critical part: this list needs to be accessible outside your normal systems. If your email is down and your intranet is encrypted, a contact list stored there is useless. Keep printed copies. Store it in a secure location that doesn’t depend on the systems that might be compromised.

—

Step 4: Implement Detection and Response Capabilities

Prevention is ideal, but detection is essential. Assume that despite your best efforts, attackers might get in. The question is: how quickly will you know?

The difference between a minor incident and a major breach often comes down to detection speed. Ransomware attackers typically spend days or weeks inside a network before triggering encryption. They need time to:

• Escalate privileges
• Move laterally to other systems
• Identify and compromise backups
• Stage data for exfiltration
• Deploy ransomware to multiple systems simultaneously

Every hour you detect them earlier is an hour they don’t have to cause damage.

What Detection Actually Looks Like

Effective detection involves multiple layers:

Endpoint Detection and Response (EDR) — Software on individual devices that monitors for suspicious behavior. Modern EDR tools can detect ransomware encryption patterns and automatically isolate affected systems.

Network Detection and Response (NDR) — Monitoring network traffic for signs of command-and-control communication, data exfiltration, or lateral movement.

Security Information and Event Management (SIEM) — Centralized log collection and analysis that can correlate events across multiple systems to identify attack patterns.

Managed Detection and Response (MDR) — A service where a security team monitors your environment 24/7 and responds to threats. This is particularly valuable for organizations that don’t have in-house security operations capabilities.

The challenge is that these tools generate a lot of alerts. Without proper tuning and someone to investigate them, you end up with alert fatigue—where real threats get lost in the noise.

The 24/7 Problem

Ransomware attacks often happen at night or on weekends. Attackers know that’s when security teams are thin or absent. If your detection capability only operates during business hours, you’re giving attackers a significant advantage.

This is where managed security services become valuable. A managed SOC (Security Operations Center) provides round-the-clock monitoring and response. When an alert fires at 3 AM, someone is there to investigate and act.

IP Services offers fully-managed cybersecurity solutions including managed SOC and managed detection and response capabilities. For organizations that can’t staff a 24/7 security team internally, this kind of service can close a critical gap.

Response Playbooks

Detection is only useful if it triggers effective response. Pre-built playbooks should define:

• What happens when ransomware is detected?
• Who gets notified?
• What automated actions occur (if any)?
• What manual steps need to happen?

Playbooks should be specific enough to guide action but flexible enough to adapt to different scenarios. And they should be practiced—more on that in the next section.

—

Step 5: Practice, Practice, Practice (Tabletop Exercises and Simulations)

You can have the best-written response plan in the world. If your team has never practiced executing it, you don’t have a capability. You have a document.

Tabletop exercises are the antidote to paper plans. These are structured discussions where your team walks through a hypothetical scenario and makes decisions in real-time. The goal isn’t to test technical skills—it’s to test decision-making, communication, and coordination.

How to Run a Tabletop Exercise

Choose a realistic scenario. “Ransomware encrypts your file servers and a ransom note appears” is a good start. Add complications: “The attackers also exfiltrated customer data” or “Your backup system is also encrypted.”

Gather the right people. This should include:

• IT/security leadership
• Business unit representatives
• Legal counsel
• Communications/PR
• Executive leadership

Walk through the timeline. Start with detection. What happens next? Who’s notified? What decisions are made? Move hour by hour through the first 24-48 hours.

Document gaps. Every exercise reveals things that aren’t clear, aren’t documented, or aren’t practiced. Write them down. Fix them.

Repeat regularly. Annual exercises aren’t enough. Aim for at least twice a year, with different scenarios each time.

Beyond Tabletop: Technical Simulations

Tabletop exercises test decision-making. Technical simulations test execution. These might include:

• Backup restoration drills — Can you actually restore critical systems from backup? How long does it take?
• Isolation exercises — Can you quickly isolate a compromised system without breaking everything else?
• Communication tests — Can you actually reach everyone on your contact list?

These simulations are uncomfortable. They reveal weaknesses. But finding weaknesses in a controlled exercise is infinitely better than finding them during an actual attack.

Learning from Others

One of the most valuable exercises is studying real-world incidents. When a major ransomware attack makes the news, read the post-mortems and incident reports. What went wrong? What went right? What would you have done differently?

The lessons from other organizations’ experiences can inform your own planning. You don’t have to make every mistake yourself.

—

Putting It All Together: A Practical Timeline

If you’re starting from scratch, the idea of building a complete ransomware response plan can feel overwhelming. Here’s a practical timeline to work through the five steps:

Month 1: Foundation

• Begin asset inventory process
• Assess current backup capabilities
• Identify key stakeholders for incident response

Month 2: Backup and Detection

• Implement or upgrade backup solutions with immutable storage
• Evaluate detection capabilities (EDR, SIEM, MDR)
• Draft initial communication templates

Month 3: Documentation

• Finalize incident response plan document
• Create decision trees and escalation procedures
• Build contact lists (internal and external)

Month 4: Testing

• Run first tabletop exercise
• Test backup restoration
• Identify and address gaps

Months 5-6: Refinement

• Implement improvements identified in testing
• Establish regular exercise schedule
• Train staff on response procedures

Ongoing:

• Regular tabletop exercises (quarterly or semi-annually)
• Backup testing (monthly)
• Plan updates (annually or after major changes)

This timeline is aggressive for most organizations, and that’s intentional. The threat isn’t waiting for you to get around to it.

—

Common Mistakes That Undermine Ransomware Response

Even organizations that invest in planning sometimes make mistakes that undermine their efforts. Here are the most common ones:

Mistake #1: Treating It as an IT Problem Only

Ransomware is a business problem. The decisions made during an incident—whether to pay, how to communicate, which systems to prioritize—are business decisions. If your response plan is owned entirely by IT, you’re missing critical perspectives.

Mistake #2: Planning Without Practicing

I’ve emphasized this already, but it bears repeating. A plan that’s never been tested is a plan that will fail. Practice is what turns planning into capability.

Mistake #3: Ignoring the Human Element

Ransomware attacks often start with human error—a phishing email clicked, a weak password compromised, a social engineering call that gave attackers access. Your response plan should address the human element, including training, communication, and support for affected employees.

Mistake #4: Forgetting About Third Parties

Your organization doesn’t exist in isolation. You have vendors, partners, customers, and service providers. Your response plan needs to account for how you’ll communicate with and coordinate with these parties.

Mistake #5: Assuming You’ll Never Pay

Many organizations say they’ll never pay a ransom. That’s a reasonable position. But the decision to pay is complex, involving factors like the value of encrypted data, the availability of backups, and the potential for data recovery. Your plan should address the payment decision as a business choice, not a moral one.

Mistake #6: Neglecting Cyber Insurance

Cyber insurance can be a critical resource during a ransomware incident—covering incident response costs, legal fees, and even ransom payments in some cases. But insurance policies have requirements, and claims can be denied if you haven’t followed policy terms. Review your coverage and understand what’s required.

—

FREQUENTLY ASKED QUESTIONS

How long does it take to recover from a ransomware attack?

Recovery timelines vary widely based on the scope of the attack, the quality of your backups, and your response capabilities. Organizations with well-tested backup and recovery procedures might restore operations within days. Those without often take weeks or months. The average downtime for organizations that pay the ransom is still measured in weeks, as decryption tools are often slow and unreliable.

Should we pay the ransom if we’re attacked?

This is a business decision, not just a technical one. Law enforcement generally advises against paying, as it funds criminal operations and doesn’t guarantee data recovery. Additionally, paying doesn’t always result in restored data—some attackers take the money and disappear. However, for organizations facing existential threats (like a hospital that can’t provide patient care), payment might be the least-bad option. Your response plan should address the decision framework, even if you hope never to use it.

How often should we test our ransomware response plan?

At minimum, conduct a tabletop exercise annually. Better: twice a year. Best: quarterly, with different scenarios each time. In addition to discussions, test technical recovery capabilities monthly for critical systems. The goal is to build muscle memory so your team can execute under pressure.

What’s the difference between a business continuity plan and a ransomware response plan?

A business continuity plan (BCP) addresses how you’ll maintain operations during any disruption—natural disasters, power outages, pandemics, etc. A ransomware response plan is a specific type of incident response plan focused on cyberattacks. Your BCP should incorporate your ransomware response plan, but they’re not the same thing.

Do we need cyber insurance?

Cyber insurance can be valuable, covering costs associated with incident response, legal fees, regulatory notifications, and potentially ransom payments. However, it’s not a substitute for good security practices. Insurers increasingly require specific security controls as a condition of coverage, and claims can be denied if you haven’t met policy requirements. Review your options carefully and understand the terms.

What should we do first if we suspect ransomware?

If you suspect a ransomware attack in progress, the priority is containment. Isolate affected systems from the network to prevent spread. Don’t power off systems (this can destroy forensic evidence). Contact your incident response team or external provider immediately. Preserve evidence. Don’t communicate about the incident through potentially compromised channels.

How do we know if our backups are actually good?

The only way to know is to test them. Regular restoration tests—where you actually recover data and verify it’s usable—are essential. Test critical systems first, and periodically test full environment recovery. Document how long restoration takes so you can set realistic RTOs.

—

The Bottom Line: Preparation Is Not Optional

Ransomware attacks are not a matter of if for most organizations. They’re a matter of when. The attackers are sophisticated, well-funded, and persistent. They only need to succeed once.

The five steps outlined here—asset inventory, immutable backups, communication frameworks, detection capabilities, and regular practice—form the foundation of an effective ransomware response plan. None of them are exotic or expensive beyond reach. They’re the basics, done well.

But here’s the thing: knowing what to do and actually doing it are different things. Most organizations understand they should have these capabilities. Many don’t have them because the work is hard, the priorities compete, and it’s easy to defer until “next quarter.”

The organizations that survive ransomware attacks are the ones that made preparation a priority before it was urgent. They built the capabilities when nothing was on fire. They practiced when the stakes were low.

You can do the same.

Where to Start Today:

• Assess your current state. Do you have an accurate asset inventory? Tested backups? A written response plan? If you’re not sure, that’s your answer.

• Identify your biggest gaps. Of the five steps, which ones are you weakest on? Start there.

• Get help if you need it. Building these capabilities internally requires expertise and time that many organizations don’t have. Partnering with a managed security provider can accelerate your progress significantly.

—

IP Services has been helping organizations build resilient IT operations since 2001. Their approach combines managed cybersecurity, IT consulting, and hands-on support to help businesses prepare for, respond to, and recover from security incidents. If you’re not sure where to start with your ransomware response planning, their team can help you assess your current state and build a roadmap forward.

You can reach IP Services at 866-226-5974 for sales inquiries or 541-226-5974 for technical support. They also offer resources including their IT expert blog, case studies, webinars, and their MSP Buyer’s Guide for organizations evaluating managed service providers.

The conversation you have today about ransomware preparation might be the most valuable one your organization has this year. Don’t wait until 2:47 AM on a Saturday to wish you’d had it sooner.