How to Prepare for a Ransomware Attack Before It Happens

Ransomware preparation is less about having a checklist for the day of the attack and more about deciding, in advance, how the company will detect intrusion, contain spread, protect recovery systems, preserve evidence, communicate internally, and restore the services the business cannot operate without. The quality of those decisions before an incident largely determines how many options remain once systems start going offline.

TL;DR

A ransomware plan has to assume that attackers may already have valid credentials, administrative access, knowledge of the network, and time to investigate the company’s recovery environment before encryption begins. Preparation therefore needs to cover identity, segmentation, endpoint visibility, patching, privileged access, backups, incident authority, communications, and recovery testing as one connected operating model.

Backups remain essential, but they only become a resilience capability when they are protected from the same administrators and attack paths that control production, and when the business has proved it can restore critical services from them.

The strongest preparation starts with business impact rather than malware. Identify which services must come back first, what systems and identities they depend on, how much data the company can afford to lose, and who has authority to isolate infrastructure when an attack begins.

From there, harden common entry points, reduce standing privilege, protect and test recovery copies, establish an incident-response structure, and rehearse realistic scenarios before the first real crisis. The objective is to make ransomware an incident the organization can contain and recover from rather than an event that forces every important decision to be made under pressure.

Key Takeaways

• Ransomware preparation should begin with recovery priorities and business dependencies, because restoring systems in the wrong order can leave critical services unavailable even when backups exist.
• Attackers increasingly combine encryption with data theft and extortion, so preparation needs to cover confidentiality and evidence preservation as well as system recovery.
• Vulnerabilities in VPNs, firewalls, remote-access services, and other internet-facing infrastructure remain important ransomware entry points.
• Compromised credentials and identity weaknesses can give attackers legitimate-looking access, making strong authentication, privileged-access controls, and identity monitoring central to ransomware defense.
• Backups should include at least one offline, air-gapped, or immutable copy that ransomware operators cannot modify through ordinary production credentials.
• Network and identity segmentation can reduce how quickly an attacker moves from one compromised endpoint into servers, virtualisation platforms, backups, and other critical infrastructure.
• The most useful measure of ransomware readiness is whether the organisation can contain the attack and restore priority business services within an acceptable period, rather than how many security products it owns.

Ransomware Preparation Starts Before the First File Is Encrypted

The most important change in ransomware over the last several years is that encryption is increasingly one stage of a wider intrusion rather than the whole attack. In the ransomware incidents Mandiant investigated during 2025, 77% included suspected data theft, up from 57% the year before.

By the time employees see inaccessible files or ransom notes, the attacker may already have explored the environment, collected credentials, accessed sensitive data, moved between systems, and investigated the infrastructure the company expects to use for recovery.

The initial access paths are also remarkably practical. Mandiant found that exploitation or suspected exploitation of vulnerabilities accounted for roughly one-third of the ransomware incidents it handled in 2025, with VPNs and firewalls among the technologies repeatedly targeted.

Compromised legitimate credentials were used in 21% of intrusions where the initial vector could be identified. That combination explains why ransomware preparation has to begin well before malware deployment. Internet-facing infrastructure, identity systems, remote access, privileged accounts, and endpoint visibility all influence whether the attacker reaches the stage where large-scale encryption is possible.

What happens after entry is equally important. Mandiant observed attackers targeting virtualization infrastructure in approximately 43% of ransomware intrusions during 2025, up from 29% the year before. Virtualization platforms are attractive because control over a relatively small number of hosts can affect large numbers of business systems at once.

Attackers also understand that recovery infrastructure can determine whether the victim has leverage during extortion. Veeam’s 2025 ransomware research found that 89% of organizations in its study had their backup repositories targeted by attackers. A backup strategy that is reachable through the same privileged identities and management paths as production can therefore fail at exactly the point when the business needs it most.

The recovery numbers show why preparation deserves as much attention as prevention. Sophos’ State of Ransomware 2026 research found that 56% of attacks succeeded in encrypting data and put the average recovery cost at USD 1.7 million.

At the same time, there is evidence that stronger resilience work is improving outcomes: Sophos reported that 55% of affected organizations recovered within one week, with 16% recovering in less than a day, and linked that progress in part to increased investment in backup infrastructure.

The important difference is that recovery speed depends on what was prepared beforehand, including clean restore points, working credentials, documented dependencies, available infrastructure, and people who know which systems must return first.

This is a useful way to frame ransomware readiness. The goal is to give the company options when the attack happens. If administrators can contain compromised identities, critical networks are segmented, logs still exist, backups cannot be altered, restore procedures have been tested, and leaders already know who can make high-impact decisions, the organization enters the incident with room to maneuver.

If those questions are being answered for the first time while systems are disappearing from the network, the attacker has already gained an operational advantage.

Start With the Systems the Business Cannot Afford to Lose

Ransomware planning becomes much more practical once the company stops treating every server and application as equally important. During a major incident, recovery capacity is limited.

Infrastructure teams may be rebuilding hosts, identity systems may be unstable, vendors may be involved, and the business may be operating with reduced staff or manual workarounds. The useful question therefore becomes which services have to return first for the organization to function.

That priority should be based on business dependency rather than technical convenience. A customer portal may depend on identity services, a database, DNS, network connectivity, and a payment processor. Payroll may rely on several internal applications and a third-party platform.

Restoring the visible application while one of those underlying dependencies is still unavailable does not restore the business process. This is why ransomware preparation should be connected to a proper business impact analysis and documented service dependencies rather than a list of servers ordered by perceived importance.

Recovery objectives help turn that discussion into something operational. A Recovery Time Objective (RTO) defines how quickly a service needs to be restored, while a Recovery Point Objective (RPO) defines how much recent data the business can afford to lose.

NIST’s contingency-planning guidance uses business impact analysis to connect system recovery requirements with operational priorities. Those targets give technical teams something concrete to design around instead of discovering during an attack that the backup architecture cannot meet what the business assumed was possible.

Business question	What the ransomware plan should establish
Which services must return first?	A ranked list based on business impact
What does each service depend on?	Identity, network, databases, DNS, cloud, vendors, and infrastructure
How long can the service remain unavailable?	Recovery Time Objective
How much recent data can be lost?	Recovery Point Objective
Is there a manual workaround?	Temporary operating procedure if recovery takes longer
Who owns the recovery decision?	Named business and technical owners
How will recovery be validated?	Defined checks before the service is returned to users

Identity infrastructure deserves particular attention because so many other recovery activities depend on it. If Active Directory, cloud identity, DNS, privileged accounts, or authentication services are unavailable or untrusted, administrators may struggle to access the very systems they are supposed to rebuild.

Recovery plans should therefore account for how trusted administrative access will be re-established and how critical systems will authenticate during restoration.

Third-party dependencies need to be mapped as well. A company may have pristine backups of an application and still be unable to operate because a payment gateway, managed service provider, telecom provider, SaaS platform, or software vendor is unavailable or requires credentials that were compromised during the incident.

Important supplier contacts, support arrangements, contractual escalation routes, and recovery dependencies should be documented alongside internal systems.

The value of this work appears when the incident becomes chaotic. Instead of every department insisting that its application should be restored first, the organization already knows which services support revenue, customers, payments, communications, and core operations, and in what order the underlying dependencies need to return.

That recovery sequence becomes the backbone of the ransomware plan because it determines where limited technical effort should go when the company is under the greatest pressure.

Build Backups for an Attacker Who Will Try to Destroy Them

Backups are the centre of most ransomware recovery plans, but simply having them is a weak measure of readiness. Modern ransomware operators understand that the victim’s ability to restore systems determines how much leverage encryption creates, so backup consoles, repositories, snapshots, virtualisation platforms, and administrative credentials increasingly become targets during the intrusion.

The useful assumption is therefore that an attacker with sufficient time inside the environment will eventually look for the recovery infrastructure and try to weaken it before the visible attack begins.

That changes how backups need to be designed. A production administrator who can modify servers, delete cloud workloads, and permanently remove backup copies creates a very large blast radius if that identity is compromised. Recovery infrastructure should have separate administrative controls, and at least one important copy of critical data should be difficult for ordinary production credentials to alter.

The UK’s National Cyber Security Centre recommends keeping backups separate from the systems being protected and ensuring ransomware cannot automatically reach and destroy them, alongside controls that prevent backups being modified or deleted during an attack.

The familiar 3-2-1 principle remains useful as a starting point: maintain multiple copies of important data, use more than one storage type or location, and keep a copy separated from the primary environment. Modern ransomware planning often strengthens that model with immutability, offline copies, logically isolated vaults, or separate cloud accounts so an attacker cannot simply authenticate to the backup platform and erase the recovery history.

AWS, for example, provides Vault Lock controls that can enforce write-once-read-many protection on backup recovery points, preventing protected copies from being deleted before their retention period expires once compliance mode is locked.

Backup design question	Ransomware-ready answer
Can normal production administrators delete every backup?	Separate backup privileges from ordinary production administration
Can ransomware reach backup storage directly?	Isolate repositories and restrict network paths
Can old recovery points be altered or deleted?	Use immutable or locked copies for critical data
Are credentials shared with production systems?	Use separate identities and strong authentication
Is there a copy outside the primary environment?	Maintain offline, isolated, or independently controlled recovery copies
Are backup changes monitored?	Alert on deletion attempts, policy changes, and unusual administrative activity
Do we know whether restoration actually works?	Perform recurring recovery tests against defined RTO and RPO targets

Recovery credentials themselves also need protection. If the same privileged identity manages Active Directory, production infrastructure, virtualisation, and backups, compromising that account can give the attacker nearly everything required to sabotage recovery. Backup administrators should use dedicated identities, strong MFA, tightly restricted access paths, and ideally privileges that are unavailable during ordinary day-to-day administration.

Destructive actions such as disabling backup jobs, shortening retention, or deleting large numbers of recovery points should generate high-priority security alerts because those actions may be an early indication that an attacker is preparing the environment for ransomware deployment.

The other common mistake is testing whether backups are being created rather than whether systems can actually be recovered from them. A successful backup report says little about whether application dependencies were captured, encryption keys are available, databases restore cleanly, credentials still work, or the organisation can rebuild enough infrastructure to use the recovered data.

Recovery exercises should therefore restore representative critical services into an isolated environment and validate the application from the business perspective, not simply confirm that files can be extracted.

The relevant question during ransomware planning is not “Do we have backups?” It is whether clean, protected recovery copies will still be available after an attacker has spent days deliberately trying to remove them, and whether the organisation has already proved that those copies can bring its most important services back within the time the business can tolerate.

Limit How Far an Attacker Can Move After the First Compromise

Ransomware becomes far more damaging when one compromised account or endpoint can reach large parts of the environment. The initial foothold may be a user laptop, a VPN account, or an exposed server, but the attack usually becomes operationally serious when the threat actor begins moving laterally, collecting better credentials, reaching domain controllers, and gaining access to systems that can distribute malware or disable recovery.

Microsoft describes lateral movement as a critical stage in human-operated ransomware attacks because it allows attackers to expand access toward valuable assets and sensitive data.

Identity is central to that movement. Once attackers obtain credentials with broader privileges, they can often move through legitimate administrative protocols rather than deploying obviously malicious tools.

MITRE ATT&CK documents how valid accounts can be abused for persistence, privilege escalation, defence evasion, and lateral movement, while credential dumping can give attackers additional account material from memory, caches, and operating-system stores. That is why ransomware preparation has to include privilege reduction and credential hygiene long before the incident begins.

Network segmentation creates another layer of containment. A user workstation generally does not need unrestricted connectivity to backup infrastructure, hypervisors, domain controllers, database administration interfaces, or every production server.

Microsoft recommends using network segmentation to isolate sensitive systems and limit lateral movement when a breach occurs. The same principle can be applied between user networks, server environments, management infrastructure, development systems, cloud workloads, and recovery systems so that access between them happens through deliberately controlled paths.

Area	Ransomware-resilient approach
User endpoints	Restrict direct administrative access to critical servers
Domain administration	Use separate privileged identities and controlled admin paths
Server networks	Limit east-west traffic to services that genuinely need it
Backup infrastructure	Keep management interfaces and credentials isolated from production
Virtualisation platforms	Restrict access to dedicated administrators and management networks
Remote access	Limit users to the applications and resources required for their role
Cloud administration	Use temporary privilege and tightly scoped roles
Legacy systems	Segment aggressively when modern security controls cannot be added

Domain controllers deserve particular protection because gaining control of the directory can transform a limited compromise into an enterprise-wide incident. Microsoft’s analysis of human-operated attacks found that threat actors successfully breached a domain controller in more than 78% of the attacks it examined.

Once attackers control privileged directory identities, they can potentially distribute software, alter policies, create persistence, and expand access across large portions of a Windows environment. Protecting administrative credentials, reducing where privileged accounts can sign in, and monitoring unusual directory activity therefore has direct ransomware value.

The objective is to make compromise expensive to expand. An attacker may still gain access to one machine or steal one account, but that first success should not automatically provide a route to virtualisation hosts, backup repositories, privileged identity systems, and critical databases.

Segmentation and privilege control buy defenders something extremely valuable during ransomware: time. The more barriers the attacker has to cross, the more opportunities security teams have to detect unusual activity and contain the intrusion before encryption becomes an organisation-wide event.

Harden the Entry Points Attackers Use Before Ransomware Is Deployed

Ransomware prevention works best when it focuses on the access paths attackers repeatedly use rather than trying to predict a specific malware family. Remote-access services, internet-facing appliances, exposed administrative interfaces, weak credentials, phishing, and unpatched vulnerabilities all matter because they can give an attacker the foothold needed to begin the longer intrusion that eventually leads to encryption or extortion.

Internet-facing infrastructure deserves especially aggressive treatment because the exposure is continuous. VPN gateways, firewalls, remote desktop services, web applications, and management interfaces should be inventoried, patched quickly, and reviewed for unnecessary exposure. If a service does not need to be reachable from the internet, removing that exposure is usually more reliable than trying to compensate for it with monitoring alone.

Identity controls should be hardened at the same time. Privileged users, remote-access users, administrators, and employees with access to critical business systems should use phishing-resistant MFA wherever practical, with legacy authentication disabled and suspicious sign-in activity monitored. Stolen credentials remain useful to ransomware operators because they can make attacker activity look legitimate during the early stages of an intrusion.

A practical prevention baseline looks like this:

Entry point	Preparation priority
VPN and remote-access services	Patch quickly, enforce strong MFA, restrict unnecessary exposure
Internet-facing appliances	Track vendor advisories and emergency vulnerabilities
Privileged identities	Use separate accounts, strong MFA, and temporary elevation
Email and phishing	Strengthen filtering, attachment controls, and user reporting
Remote desktop	Restrict or remove direct internet exposure
Unmanaged endpoints	Bring them under EDR, patching, and device-control policies
Third-party access	Limit privileges, monitor sessions, and remove stale accounts
Service accounts	Reduce privilege and eliminate unnecessary long-lived credentials

The important part is speed. A serious vulnerability in an internet-facing appliance cannot always wait for the normal monthly patch cycle, particularly when exploitation is already occurring. The company should have an emergency remediation process that allows high-risk systems to be patched, isolated, or protected with temporary controls quickly without spending hours deciding who is allowed to approve the change.

Third-party access deserves the same scrutiny because vendors, managed service providers, and contractors may have trusted access into systems that internal employees cannot reach directly. Those accounts should follow the same principles as internal privileged access: individual identities, strong authentication, narrow permissions, monitored activity, and removal as soon as the business need ends.

The objective must be to make the common entry routes harder to exploit and easier to detect, so an attacker has less opportunity to establish the persistent, privileged foothold required for a damaging ransomware operation.

Detect the Intrusion Before Ransomware Becomes the First Visible Symptom

One of the most damaging assumptions in ransomware planning is that the attack begins when encryption starts. By that point, the attacker may already have spent hours or days inside the environment collecting credentials, disabling controls, discovering backups, and testing how far privileged access can reach.

The better detection model looks for the behaviours that usually appear earlier in the intrusion, when defenders still have a chance to contain the attacker before the business impact becomes severe.

Endpoint detection and response is central because ransomware operators often leave a trail before deployment. Credential dumping, remote administration tools, suspicious PowerShell activity, unusual service creation, privilege escalation, attempts to disable security software, and movement between systems can all provide earlier warning.

Microsoft has documented how its ransomware detections combine signals across endpoint, identity, email, and cloud activity to identify human-operated attacks before encryption becomes widespread.

Identity telemetry should be watched with the same urgency. A privileged account signing in from an unfamiliar device, multiple failed MFA attempts followed by a successful login, sudden role elevation, or an administrator account being used on systems it does not normally touch can indicate that the attacker is moving toward higher-value access. These signals become more useful when correlated with endpoint and network activity rather than reviewed separately.

A practical ransomware-focused detection baseline should include:

Signal	Why it matters
Credential dumping or LSASS access	May indicate attackers collecting higher-value credentials
New privileged group membership	Can signal escalation toward administrative control
Security tooling disabled or tampered with	Common precursor to broader attacker activity
Remote administration tools appearing unexpectedly	May provide lateral movement or command-and-control capability
Unusual SMB, RDP, or remote service activity	Can reveal movement between systems
Backup policy or retention changes	May indicate preparation to damage recovery capability
Sudden access to virtualisation platforms	High-value target during ransomware intrusions
Large data transfers or archive creation	May indicate exfiltration before encryption
Mass file modification	Potential early sign of encryption activity

The monitoring team also needs the authority to act on high-confidence signals. If an analyst sees a compromised endpoint attempting credential dumping and lateral movement at 2 a.m., opening a ticket for the morning undermines the value of continuous detection.

Pre-approved actions such as isolating endpoints, disabling compromised accounts, blocking known malicious infrastructure, or revoking active sessions can interrupt the attack while the wider incident team is being mobilised.

Detection coverage should be tested periodically rather than assumed. Purple-team exercises, controlled ransomware simulations, and attack-path testing can reveal whether expected alerts actually fire and whether the response team receives enough context to act quickly. A company may have EDR, SIEM, identity monitoring, and network telemetry in place and still discover that the critical signals are not correlated or that the overnight escalation path is too slow.

The objective is to recognise the ransomware intrusion while it still looks like suspicious identity and endpoint behaviour rather than waiting for thousands of encrypted files to provide confirmation. The earlier the company can identify credential theft, privilege escalation, lateral movement, backup tampering, and data staging, the greater the chance of containing the attack before recovery becomes the primary problem.

Predefine Who Can Make High-Impact Decisions During the Attack

Ransomware incidents become harder when technical teams know what should happen but nobody is sure who has authority to approve it. Isolating a laptop is one thing.

Disconnecting a production network segment, disabling a privileged administrator, shutting down a customer-facing service, invoking disaster recovery, or taking a core identity system offline can affect large parts of the business. Those decisions need to be assigned before the incident rather than discovered through a chain of phone calls while the attacker is still moving.

The incident structure should therefore separate technical containment authority from business-impact authority. Security and IT teams can usually be pre-authorised to take low-regret actions such as isolating a compromised endpoint, revoking a suspicious session, blocking a malicious IP address, or disabling an account that is clearly under attacker control.

Actions that could interrupt major operations should escalate to an incident lead who understands the business consequences and can make that decision quickly.

A practical decision matrix can look like this:

Decision	Who should usually own it
Isolate a compromised endpoint	Security / SOC
Revoke stolen sessions	Identity or security team
Disable a confirmed compromised account	Security / identity team
Block malicious infrastructure	Security / network team
Disconnect a production server	Incident lead with system owner
Shut down a business-critical service	Executive or designated crisis owner
Invoke disaster recovery	Incident commander / technology leadership
Contact cyber insurer	Legal, risk, or designated incident coordinator
Engage external forensics	Incident lead / legal
Notify customers or regulators	Legal, privacy, and executive leadership

This is also where legal, communications, insurance, and executive leadership need to be connected to the technical plan. A ransomware event may involve stolen customer information, contractual obligations, regulatory reporting, law enforcement, ransom demands, operational disruption, and public communications at the same time.

The technical team can establish what happened and what is still at risk, but the organisation needs named owners for the decisions that extend beyond containment.

Contact information should exist somewhere that remains available if normal systems are unavailable. If Microsoft 365, Active Directory, VPN access, or corporate phones are disrupted, the company still needs a way to reach incident leaders, external responders, cyber insurers, key vendors, legal counsel, and senior management.

That can mean an offline contact list, separate emergency communication channel, or another method that does not depend entirely on the infrastructure most likely to be affected by the incident.

The most useful outcome is a short chain of command that everyone understands. During ransomware, speed does not come from allowing everybody to act independently. It comes from knowing which actions are already authorised, which decisions need escalation, and exactly who owns them. That clarity prevents the organisation from losing valuable containment time to internal uncertainty while the attack is still unfolding.

Test the Recovery Plan Before Ransomware Tests It for You

A written ransomware plan can look complete and still fail badly under pressure if nobody has tested how the pieces work together. The first real exercise should not happen during a live attack.

Tabletop exercises, technical recovery drills, and controlled simulations give teams a chance to find the practical gaps that documents hide: missing contact details, unclear decision rights, untested backups, unavailable administrators, broken dependencies, or recovery steps that assume systems are still online when they are not.

CISA’s ransomware guidance recommends regularly testing backup procedures and incident-response plans, because recovery depends on much more than the existence of backup data.

The organisation needs to know whether critical systems can be restored cleanly, whether credentials and encryption keys are available, whether dependent services come back in the right order, and whether the business can operate while parts of the environment are still unavailable.

The exercises should cover both technical and executive decisions. A realistic scenario might begin with an administrator account compromise, followed by lateral movement, backup tampering, data exfiltration, and encryption of selected systems.

The security team should have to investigate and contain the activity, while business leaders decide whether to shut down production, invoke disaster recovery, contact insurers, communicate with customers, or bring in external responders. That is much more useful than testing only whether a backup can restore one server.

A good ransomware exercise should answer questions like these:

Exercise question	What it tests
Can we identify the initial compromise quickly?	Detection and investigation
Can we isolate affected systems without losing control of the environment?	Containment authority
Can we reach incident leaders if normal communications fail?	Crisis communications
Are backup administrators and recovery credentials still available?	Recovery access
Can priority services be restored in the correct order?	Dependency mapping
Can we prove restored systems are clean before reconnecting them?	Recovery validation
Do legal, privacy, and communications teams know when they need to engage?	Business-response coordination
Can we continue operating manually for a period?	Business continuity

Technical restore drills should go further than tabletop discussion. A team should actually restore representative workloads into an isolated environment, rebuild dependencies, validate application functionality, and measure the time required.

If the business expects a critical application back within four hours and the first real restore test takes eighteen, that is valuable information because the gap can still be fixed before an attacker creates the same problem under pressure.

The exercise should end with concrete changes rather than a meeting summary. Escalation contacts may need updating, recovery priorities may need reordering, backup permissions may need tightening, and monitoring gaps may need new detections. Repeating the exercise periodically lets the company see whether those weaknesses are improving as infrastructure, staff, and vendors change.

Ransomware readiness becomes credible when the organisation has already practised the uncomfortable parts. The goal is for the real incident to feel like an escalation of a process people recognise rather than a crisis in which every important decision, dependency, and recovery step is being discovered for the first time.

Prepare for Data Theft and Extortion, Not Just Encryption

A ransomware response plan that focuses only on restoring encrypted systems is increasingly incomplete. Many ransomware groups now steal data before they encrypt anything, then use the threat of publication as a second source of leverage.

The UK’s National Cyber Security Centre notes that ransomware attackers may steal data and threaten to leak it as part of the extortion process. That changes the preparation problem considerably because a company can restore every server successfully and still face a serious confidentiality, legal, and customer-trust issue.

The organisation therefore needs to know what evidence it would require to determine whether data actually left the environment. Endpoint telemetry, cloud audit records, firewall logs, proxy data, identity activity, database auditing, and file-access records can all become important when investigators are trying to establish what an attacker reached and whether large datasets were staged or transferred.

The NCSC describes security logging as the foundation for monitoring and incident situational awareness, particularly because those records help responders answer what happened, what was affected, and whether remediation has worked.

That investigation should be planned alongside the recovery process:

Question during the incident	Evidence or preparation needed beforehand
What data could the attacker reach?	Data classification and access mapping
Which accounts were compromised?	Identity and authentication logs
Were sensitive files accessed?	File, storage, and application audit records
Was data transferred externally?	Network, proxy, firewall, and cloud telemetry
Were logs or controls tampered with?	Protected centralised logging
Which customers or jurisdictions may be affected?	Data inventory and ownership records
Can the company substantiate the scope of the breach?	Preserved forensic evidence and incident timeline

Legal and communications teams also need to enter the process earlier than they would in a purely technical outage. Australia’s current cyber-incident guidance recommends that organisations consider their legal reporting obligations and communicate appropriately when incidents involve customer data.

The exact obligations vary by jurisdiction, industry, contractual commitments, and the type of information involved, which is why the incident plan should already identify the people responsible for making those assessments rather than leaving the security team to interpret them during the crisis.

The ransom demand itself should also have a predefined decision path. The FBI does not support paying ransomware demands and warns that payment does not guarantee the organisation will recover its data. Payment can also introduce legal, insurance, sanctions, financial, and negotiation considerations that belong with executive leadership, legal counsel, insurers, and specialist responders rather than an infrastructure team working under pressure.

This is another reason preparation needs to happen before ransomware arrives. The company should already know where sensitive information lives, what evidence would establish whether it was accessed, who decides whether disclosure obligations have been triggered, and who participates if an extortion demand arrives.

Recovery gets the systems running again. A complete ransomware plan also prepares the organisation to understand what happened to its data and manage the consequences with evidence rather than guesswork.

Recovery Should Assume the Environment Is Still Untrusted

One of the easiest mistakes during ransomware recovery is moving too quickly from restoration to reconnection. Getting systems back online is important, but restoring a server from backup does not automatically mean the wider environment is clean.

Compromised identities, persistence mechanisms, malicious remote-access tools, scheduled tasks, cloud tokens, or attacker-created accounts may still exist elsewhere. If those access paths survive, the company can restore successfully and still give the attacker a route back in.

Recovery therefore needs to happen inside a controlled environment. Critical systems should be rebuilt or restored into segmented recovery zones where security teams can validate operating systems, applications, identities, configurations, and dependencies before reconnecting them to normal production traffic.

Microsoft recommends using clean, isolated environments during ransomware recovery so restored workloads are not immediately exposed to the same compromised conditions that existed during the attack.

Identity recovery usually needs to happen early because every other administrative action depends on it. Passwords and privileged credentials associated with compromised systems should be rotated, suspicious sessions revoked, attacker-created accounts removed, and high-value administrative access reviewed before production is re-established.

Service accounts deserve the same attention because ransomware operators may obtain machine credentials that continue working after employee passwords have been changed.

A clean-recovery sequence can look like this:

Recovery step	Why it comes early
Re-establish trusted administrative access	Ensures responders are not using compromised credentials
Rebuild or validate identity infrastructure	Other systems depend on trusted authentication
Revoke sessions, tokens, and compromised credentials	Removes surviving attacker access
Restore core network and security services	Re-establishes visibility and controlled connectivity
Restore critical applications in dependency order	Brings business services back coherently
Validate endpoint and server security controls	Confirms monitoring is active before wider reconnection
Reintroduce users and integrations gradually	Limits the impact if residual compromise is discovered

Security monitoring should remain especially sensitive during this period. New administrative logins, unfamiliar services, unexpected outbound connections, newly created accounts, security-tool tampering, or attempts to reconnect to known attacker infrastructure should receive immediate attention.

A recovery environment is one of the few moments when the organisation has an opportunity to rebuild parts of its infrastructure with a cleaner security baseline, and reconnecting everything at once wastes that advantage.

There is also a temptation to restore exactly what existed before the attack. That can reintroduce the same exposed services, excessive privileges, outdated software, and weak configurations that helped the attacker succeed in the first place.

Where time permits, high-risk weaknesses identified during the investigation should be corrected as part of recovery, particularly around remote access, administrator privileges, identity protection, segmentation, and backup controls.

The end of ransomware encryption is therefore not the end of the incident. Recovery is complete when priority services are operating reliably, the organisation has reasonable confidence that attacker access has been removed, monitoring has been restored, and the environment is no longer dependent on the same weaknesses that enabled the intrusion.

That standard takes longer than simply restoring data, but it dramatically reduces the risk of rebuilding the business directly into a second compromise.

Ransomware Readiness Is Really About Preserving Options

The strongest ransomware preparation is designed around one idea: when an attack happens, the organisation should still have choices.

It should be able to isolate compromised systems without losing control of the entire environment, disable accounts without locking out every administrator, restore priority services from protected backups, investigate what data was accessed, and communicate with staff, customers, insurers, and regulators without relying on systems that may already be compromised.

That is why preparation cannot sit entirely inside the security team. Identity, network architecture, backup design, vulnerability management, business continuity, legal response, communications, vendor escalation, and executive decision-making all shape the outcome.

A technically strong security team can still struggle badly if nobody knows which applications must return first, if backup credentials are compromised, or if every major containment decision needs to climb through an improvised approval chain.

The practical goal is therefore resilience rather than perfect prevention. Strong authentication, segmentation, patching, endpoint protection, and monitoring should reduce the probability and scale of compromise.

Immutable or isolated backups, tested recovery procedures, defined incident authority, and preserved evidence should reduce the damage when prevention fails. Both sides matter because ransomware operators only need one workable route in, while the defender needs enough layers to keep that initial success from turning into a business-wide shutdown.

A company that has mapped its critical services, protected its recovery environment, rehearsed high-impact decisions, and proved that it can restore important systems within realistic timeframes enters a ransomware incident from a much stronger position. The attacker may still create disruption, but the organisation is far less likely to discover its most important weaknesses for the first time while the ransom clock is already running.

FAQs

1. What is the first thing a company should do to prepare for ransomware?

Start by identifying the business services that matter most and mapping what they depend on. That includes applications, identity systems, databases, networks, cloud services, vendors, and the people who administer them. The goal is to understand what would create the most operational damage if it became unavailable and what has to be restored first.

From there, review the controls around those critical services: remote access, MFA, privileged accounts, patching, endpoint protection, segmentation, backups, logging, and recovery procedures. Ransomware preparation becomes much more effective when it is organised around business impact rather than around individual security tools.

2. Are backups enough to recover from ransomware?

Backups are essential, but they are only useful if attackers cannot destroy them and the organisation can actually restore from them. Ransomware operators increasingly target backup repositories, snapshots, virtualisation platforms, and administrative credentials because removing recovery options increases pressure on the victim.

A stronger backup strategy includes isolated or immutable copies, separate backup administration, tightly controlled deletion rights, strong authentication, and recurring restore tests. The company should know how long critical systems take to recover and whether application dependencies, credentials, and configuration are included in that recovery process.

3. What does an immutable backup mean?

An immutable backup is a recovery copy that cannot be changed or deleted during a defined retention period, even by ordinary administrators. This makes it much harder for ransomware operators to erase the backup after gaining control of production systems or privileged credentials.

Immutability should still be combined with access separation and monitoring. If an attacker can change backup policies before new recovery points are created, compromise backup credentials, or control the surrounding infrastructure, other weaknesses can remain. The strongest design uses multiple layers around the recovery environment rather than relying on immutability alone.

4. How often should ransomware recovery be tested?

Critical recovery processes should be tested regularly and whenever major infrastructure or application changes occur. A tabletop exercise might be run several times a year, while technical restore testing can follow a schedule based on system importance and recovery requirements.

The frequency matters less than the quality of the test. Restoring a few files does not prove that a business application can be recovered. Good exercises restore representative workloads, validate dependencies, measure the actual recovery time, test communications and escalation, and confirm that restored systems can be trusted before they return to production.

5. How does network segmentation help against ransomware?

Segmentation limits how easily an attacker can move from one compromised system into other parts of the environment. A user laptop should not automatically have access to backup infrastructure, hypervisors, domain controllers, databases, and every production server.

When network paths and administrative access are restricted, attackers have to cross more security boundaries to expand the intrusion. That creates additional opportunities for detection and containment. Segmentation does not prevent the first compromise, but it can materially reduce the number of systems that one compromised account or endpoint can reach.

6. Why are privileged accounts so important in ransomware defence?

Privileged identities can change configurations, create accounts, disable controls, access critical servers, and interfere with recovery systems. Once ransomware operators obtain administrator or domain-level credentials, the scope of the incident can expand very quickly.

Privileged accounts should therefore use stronger authentication, separate administrative identities, temporary elevation, controlled sign-in paths, and detailed monitoring. Administrators should also avoid using high-privilege accounts for everyday email or web browsing, because that exposes valuable credentials to unnecessary attack surface.

7. Should a company shut systems down as soon as ransomware is detected?

Sometimes rapid isolation is necessary, but the decision should follow a predefined containment plan. Isolating compromised endpoints, disabling stolen accounts, or blocking malicious infrastructure can usually happen quickly. Taking major production systems offline may require additional judgement because it can affect customers, operations, evidence preservation, or recovery.

The important point is to decide authority in advance. Security teams should know which actions they can take immediately and which require an incident leader or business owner. Waiting for ad hoc approvals during active ransomware can give the attacker valuable additional time.

8. What should we do if attackers steal data before encrypting systems?

The incident should be treated as both an operational disruption and a potential data breach. The company needs to determine what information the attackers could access, whether data was actually transferred, which identities were involved, and which customers, employees, or jurisdictions may be affected.

That requires good logging, data classification, identity records, network telemetry, and preserved forensic evidence. Legal, privacy, communications, and executive teams should be involved according to the organisation’s incident plan because notification and reporting obligations depend on the data involved and the applicable laws or contracts.

9. Should a business ever pay a ransomware demand?

Payment is a legal, financial, operational, and risk decision rather than a purely technical one. Paying does not guarantee that systems will be recovered, stolen data will be deleted, or the organisation will not be targeted again. There may also be sanctions, insurance, regulatory, and law-enforcement considerations.

Companies should establish the decision process before an incident occurs, including who would involve legal counsel, insurers, specialist negotiators, and executive leadership. Strong preparation reduces the chance that the organisation reaches a point where payment appears to be its only practical option.

10. What does a ransomware-ready company look like?

A ransomware-ready company knows which services matter most, how attackers could reach them, who can make containment decisions, and how critical systems will be restored. It has strong identity controls, segmented infrastructure, monitored endpoints, protected backups, useful logs, clear escalation, and people who have already practised the response.

Readiness does not mean the organisation cannot be attacked. It means one successful compromise is less likely to turn into uncontrolled business-wide disruption. The company retains trusted recovery options, understands its decision path, and can move from detection to containment and restoration without inventing the process during the incident.