Ransomware Readiness in 2026: A NIST CSF 2.0 Action Plan for Small and Mid-Sized Businesses

Ransomware is no longer just an IT problem. A serious attack can stop sales, payroll, customer support, production, billing, and access to core business records. Attackers may also steal data before encrypting systems, then use the threat of public exposure as extra pressure.

For small and mid-sized businesses, the hardest part is deciding what to do first. Security teams may have a long list of products and controls, while business leaders need a practical plan that reduces risk without creating a large enterprise program overnight.

In June 2026, NIST published IR 8374 Revision 1, a ransomware risk management profile aligned with Cybersecurity Framework 2.0. The profile organizes ransomware readiness across governance, identification, protection, detection, response, and recovery. CISA’s StopRansomware guidance also emphasizes strong authentication, offline or protected backups, incident response planning, and recovery testing.

This guide turns those principles into a practical business action plan.

Start With the Business Impact, Not the Malware

You do not need to predict the exact ransomware family that may attack you. You need to understand which business processes cannot stop.

List your critical services

Examples include:

• Customer ordering
• Payment processing
• Payroll
• Email and collaboration
• Customer support
• Production systems
• Inventory
• Accounting
• Identity and login systems
• Cloud administration
• Backups

For each service, record how long the business can operate without it. A two-hour outage and a five-day outage require very different recovery plans.

Use NIST CSF 2.0 as a Simple Structure

NIST CSF 2.0 is useful because it helps teams avoid focusing only on prevention. Strong ransomware readiness includes six areas: Govern, Identify, Protect, Detect, Respond, and Recover.

You do not need to become a framework expert. Use each function as a question.

• Govern: Who owns ransomware risk and which rules apply?
• Identify: What systems, data, users, and suppliers matter most?
• Protect: What makes initial access and lateral movement harder?
• Detect: How will we notice suspicious activity quickly?
• Respond: Who acts when an incident starts?
• Recover: How do we restore safe operations?

This structure prevents a common mistake: buying security tools without a response and recovery plan.

Govern: Assign Clear Ownership

Ransomware readiness fails when everyone assumes someone else owns it.

Name an executive owner

A business leader should own the risk at a high level. This person does not need to configure firewalls. They do need to approve priorities, budgets, downtime targets, communication rules, and major response decisions.

Name technical owners

Assign owners for identity, endpoints, backups, cloud systems, network controls, incident response, legal coordination, and communications.

Document decision authority

During an attack, teams should know who can isolate systems, shut down access, contact law enforcement, notify customers, engage legal counsel, call the cyber insurance provider, and approve emergency spending.

Do not wait for an incident to debate authority.

Identify: Know What You Must Protect

You cannot recover systems you do not know exist.

Build a basic asset inventory

List servers, laptops, cloud accounts, SaaS platforms, network devices, domain names, critical applications, backup systems, and key service providers.

For each asset, record:

• Owner
• Business purpose
• Location
• Operating system or platform
• Criticality
• Backup status
• Administrator
• End-of-life status

Find unsupported systems

Old systems can become easy entry points. If a device or application no longer receives security updates, replace it or isolate it. Document a deadline instead of leaving it as a permanent exception.

Identify Your Most Dangerous Accounts

Attackers often target identity before they target servers.

Create a list of privileged accounts. Include domain administrators, cloud administrators, backup administrators, email administrators, security administrators, finance users, and anyone who can deploy code or change production systems.

Separate admin accounts from everyday accounts

Administrators should not browse the web, read everyday email, and manage critical systems with the same powerful identity.

Use a standard account for daily work and a separate privileged account for administrative tasks.

Protect: Move Toward Phishing-Resistant MFA

Compromised credentials remain a major path into business systems. MFA makes stolen passwords less useful, but not every MFA method provides equal protection.

CISA recommends phishing-resistant MFA, especially for email, remote access, and critical systems. FIDO-based passkeys and hardware security keys can prevent common credential-phishing attacks because authentication is tied to the legitimate service.

Prioritize these systems

• Email
• VPN and remote access
• Cloud administration
• Backup consoles
• Password managers
• Finance systems
• Domain and DNS accounts
• Security tools

If you cannot move every user immediately, protect administrators and high-risk users first.

Protect Backups From the Same Attack

A backup is not useful if ransomware can encrypt or delete it.

CISA recommends offline, encrypted backups and regular testing. Modern cloud platforms may also offer immutable or write-protected storage options.

Use the 3-2-1 idea as a starting point

Keep multiple copies of important data, use more than one storage type or failure domain, and keep at least one copy isolated from normal production access.

The exact design can vary. The important point is independence.

Separate backup administrator credentials

Do not let a compromised domain administrator automatically gain full control of every backup. Use separate credentials, strong MFA, restricted network access, and alerts for destructive backup actions.

Protect backup configuration too

Keep copies of backup policies, infrastructure templates, encryption key procedures, and recovery instructions. A backup file alone may not be enough if no one remembers how to rebuild the system around it.

Test Restores, Not Just Backup Jobs

A green “backup successful” message does not prove that you can recover.

Every quarter, restore a sample of critical systems and data. Measure how long it takes. Confirm that applications start, permissions work, and data is usable.

Run a full recovery exercise for at least one critical service

Choose a business system such as payroll, customer orders, or accounting. Pretend the production environment is unavailable. Rebuild it from the approved recovery process.

Document missing passwords, dependencies, license files, network rules, certificates, vendor contacts, and manual steps. Fix the gaps before a real emergency.

Protect Endpoints With Basic Hygiene

Endpoint detection and response can help, but it works best with good baseline controls.

Use these practical steps

• Keep operating systems and browsers updated.
• Remove local administrator rights where they are not needed.
• Use endpoint protection or EDR.
• Block or control risky script execution.
• Disable unused services.
• Use application control on sensitive systems where practical.
• Encrypt laptops.
• Manage devices centrally.

Do not leave remote management tools open to the internet without strong access controls.

Reduce Lateral Movement

Ransomware becomes much more damaging when an attacker moves from one compromised system to many others.

Segment important networks. Restrict administrative protocols. Limit who can access servers. Separate production from user devices. Restrict management interfaces to approved networks or zero-trust access systems.

Do not use one shared administrator password

Unique privileged credentials reduce the chance that one stolen secret unlocks the whole environment.

Use a privileged access management approach if the size of the business justifies it. Smaller teams can still use separate admin identities, strong password management, and limited group membership.

Patch Based on Risk

Not every patch has the same urgency.

Prioritize internet-facing systems, identity services, remote access tools, security appliances, browsers, email servers, and vulnerabilities known to be actively exploited.

Create patch deadlines

For example, critical actively exploited vulnerabilities may require action within days. High-risk internet-facing issues may need a one-week target. Lower-risk internal updates can follow the normal maintenance cycle.

Make exceptions visible. If a system cannot be patched, add a compensating control and a replacement plan.

Detect: Centralize the Logs That Matter

You do not need every log on day one. Start with sources that help identify ransomware behavior.

• Identity provider sign-ins
• Email security events
• Endpoint alerts
• VPN and remote access
• Cloud administrator activity
• Backup changes
• Firewall and network alerts
• Critical server logs

Alert on dangerous changes

Examples include a new global administrator, MFA disabled, backup retention changed, many files renamed quickly, security tools stopped, mass account lockouts, suspicious remote management activity, or unusual login locations.

Detect Unusual Backup Activity

Attackers often try to weaken recovery before launching encryption.

Alert when someone deletes backups, changes retention, disables replication, removes immutability, rotates keys unexpectedly, changes backup administrator roles, or disables scheduled jobs.

Treat backup changes as security events, not only infrastructure events.

Respond: Create a One-Page Ransomware Playbook

A long incident response manual is useful, but the first hour needs a short checklist.

Your first-hour plan should answer

• Who declares the incident?
• Who leads technical response?
• How do we communicate if email is unavailable?
• Which systems can be isolated immediately?
• Who contacts legal counsel and the cyber insurer?
• Who preserves evidence?
• Who contacts key vendors?
• Who handles customer and public communication?

Print the emergency contact list or store an offline copy. Do not keep the only response plan inside the systems that may be encrypted.

Do Not Rush to Wipe Systems

Fast action matters, but careless action can destroy evidence.

Isolate affected systems when needed. Preserve logs and forensic data. Record what you changed and when. Work with qualified incident responders if the impact is serious.

The response team needs to understand the initial access path and attacker activity before declaring the environment clean.

Plan Communications Before the Crisis

Ransomware incidents create pressure from employees, customers, vendors, regulators, media, and attackers.

Prepare message templates

Create draft messages for employees, customers, suppliers, and leadership. Do not fill them with promises. Keep them factual and adaptable.

Assign one communications owner. Technical teams should not publish unreviewed details during an active incident.

Recover: Rebuild From a Known-Good State

Recovery is more than restoring files. You must trust the environment again.

Reset compromised credentials. Rebuild affected systems from approved images where possible. Patch the initial access weakness. Restore data from known-good backups. Monitor the rebuilt environment closely.

Prioritize by business service

Restore the services that support critical business outcomes first. That may mean identity and DNS before a business application, or network connectivity before a database.

Your recovery plan should list technical dependencies in order.

Use Recovery Time and Recovery Point Targets

Two simple numbers make backup discussions more practical.

Recovery Time Objective (RTO) is how quickly a service should return.

Recovery Point Objective (RPO) is how much recent data the business can afford to lose.

A payroll system might need an RTO of one day and an RPO of a few hours. A real-time order platform may require much tighter targets.

Set targets with business owners, not only IT.

Review Third-Party and MSP Access

Managed service providers, software vendors, accountants, support contractors, and remote maintenance partners can have powerful access.

List third-party accounts. Require strong MFA. Remove old accounts. Restrict access times and systems. Ask vendors about their incident notification process.

Do not give every vendor permanent administrator access

Use temporary or just-in-time access when possible. Review active vendor permissions every quarter.

Practice With a Tabletop Exercise

A tabletop exercise is a low-cost way to find gaps.

Gather leadership, IT, security, legal, communications, and operations. Present a scenario: Monday at 8:15 a.m., employees cannot access shared files, several servers display ransom notes, and the main backup console shows deleted jobs.

Ask what each person would do in the first 15 minutes, first hour, first day, and first three days.

Record unanswered questions

You may discover that no one has the insurer’s emergency number, legal notification rules are unclear, backup credentials are stored in the same domain, or there is no alternate communication channel.

Those discoveries are the value of the exercise.

A Practical 90-Day Ransomware Readiness Plan

Days 1–15: Find the biggest risks

Inventory critical systems. Identify privileged accounts. Confirm backup coverage. Find internet-facing services. Check whether MFA is enforced on email, remote access, cloud, and backup systems.

Days 16–30: Protect identity and backups

Move administrators toward phishing-resistant MFA. Separate backup credentials. Add offline or immutable backup copies. Test a restore.

Days 31–45: Improve endpoints and patching

Update critical systems. Remove local admin rights where possible. Deploy or tune endpoint protection. Review remote access tools.

Days 46–60: Improve detection

Centralize key logs. Add alerts for privileged changes, backup deletion, suspicious sign-ins, and security-tool shutdowns.

Days 61–75: Build the response plan

Create a one-page ransomware playbook, emergency contact list, alternate communications channel, and legal/insurance escalation process.

Days 76–90: Exercise recovery

Run a tabletop exercise and one technical restore exercise. Fix the gaps. Report the remaining top risks to leadership.

Ten Questions Leadership Should Ask Every Quarter

1. Which critical systems are not covered by tested backups?
2. Can a normal administrator delete our protected backups?
3. Which privileged accounts still use weak MFA?
4. Which critical systems are unsupported or unpatched?
5. How quickly would we notice a compromised administrator?
6. When did we last test a full restore?
7. Who leads a ransomware incident?
8. How would we communicate if email failed?
9. Which third parties have administrator access?
10. What are the top three ransomware risks we have not fixed?

Common Ransomware Readiness Mistakes

Assuming backups equal recovery. Only tested restores prove recovery.

Using the same identity for production and backups. Separate failure domains.

Buying tools before fixing identity. Stolen privileged accounts can bypass many controls.

Ignoring third-party access. External accounts can become an entry path.

Keeping the response plan only online. Store an offline copy.

Skipping exercises. A plan that has never been tested is only a theory.

Final Ransomware Readiness Checklist

• Critical business services identified
• Asset inventory maintained
• Privileged accounts separated
• Phishing-resistant MFA prioritized
• Internet-facing systems patched quickly
• Endpoint protection deployed
• Network movement restricted
• Offline or immutable backups maintained
• Backup administrators separated
• Restores tested on a schedule
• Key identity and security logs centralized
• Ransomware response playbook documented
• Emergency contacts available offline
• Recovery order documented
• Third-party access reviewed
• Tabletop exercises completed

Conclusion

Ransomware readiness does not require a perfect security program. It requires a business to make the most important failures harder and recovery more reliable.

Use the NIST CSF 2.0 ransomware profile as a structure. Govern the risk. Know your critical systems. Protect identity and backups. Detect dangerous changes. Practice response. Prove that recovery works.

If your organization can protect administrator accounts, keep independent backups, detect major changes, isolate affected systems, communicate under pressure, and restore critical services from a known-good state, you are far better prepared than a business that only buys more security software.

Start with the 90-day plan. Measure progress. Repeat the exercises. Ransomware resilience is not a one-time project. It is an operating capability.

Official Resources

Use NIST IR 8374 Revision 1: Ransomware Risk Management and the CISA StopRansomware Guide as primary references. Review the latest versions when updating your plan because threat patterns and recommended controls continue to evolve.