- Most organisations restore before confirming the attacker is gone, leading to re-infection within 72 hours
- Two in three organisations with encrypted data restored it from backups, and 48% paid the ransom (Sophos State of Ransomware 2026)
- Ransomware groups target backup infrastructure directly; validate every backup on isolated hardware before using it
- GDPR Article 33 requires notification to your supervisory authority within 72 hours of discovering a personal data breach
- Mandiant M-Trends 2026 puts median attacker dwell time at 14 days, so assume they were inside long before encryption started
Why most recoveries fail
Three failure modes account for most prolonged ransomware incidents.
The first is restoring before eradication. Your team recovers from backup, reconnects to the network, and re-infection occurs within hours. The attacker never left. Scheduled tasks, new administrator accounts, remote access tools, and implanted credentials survive the restore and give the attacker a fresh foothold to redeploy encryption.
The second is paying the ransom and treating that as a recovery plan. Decryptors fail on corrupted files, return partial keys, or do not work on newer encryption variants. In Sophos State of Ransomware 2026, 66% of organisations with encrypted data restored it from backups, and the share that paid fell to 48%, its lowest in three years.
The third failure is quieter: rebuilding to the same state that made the attack possible. If your environment had gaps before the incident, restoring from an untouched backup re-creates them. The next group finds identical conditions.
Step 1: confirm the attacker is gone
Attackers get in well before they encrypt anything. Mandiant M-Trends 2026 puts the global median dwell time at 14 days, up from 11 a year earlier. In 30% of the ransomware cases Mandiant investigated, the attackers used access left over from an earlier compromise. The encryption event marks the end of the attack, not the beginning.
Before restoration begins, your incident response team needs a full picture: every affected system, every compromised credential, every new account created during the intrusion, and every persistence mechanism found and confirmed removed.
What persistence looks like
Ransomware investigations routinely turn up:
- Scheduled tasks that re-execute the loader or callback payload
- New local administrator accounts created during lateral movement
- Remote monitoring and management (RMM) tools left running after initial access
- Web shells implanted on internet-facing servers
- Domain group policy modifications that preserve attacker privileges
- Registry changes disabling endpoint security tools
- OAuth tokens and API keys provisioned for persistent cloud access
Some groups wait 30 to 60 days after initial discovery before re-entering, targeting organisations that restored without completing eradication.
Step 2: validate your backups
Modern ransomware families treat backups as their primary obstacle to payment. Conti, LockBit 3.0, and BlackCat/ALPHV all include modules that enumerate and attempt to encrypt or delete Volume Shadow Copies, backup software databases, and network-accessible backup repositories. If your backup system was reachable from the infected environment during the attack window, treat it as potentially compromised.
The validation process
- Identify the last clean backup date. This is before the attacker's initial access, not before encryption was deployed. Check your logs for the earliest evidence of attacker activity.
- Mount the backup on isolated hardware with no network connectivity to your production environment or domain.
- Run your EDR and updated AV tools against the mounted backup. Look for known ransomware artefacts, backdoors, and loaders.
- Perform a test restore of one critical system on that isolated hardware. Verify it boots, passes EDR scanning, and returns accurate data.
- Only rely on backups that pass all four checks.
Step 3: eradicate before restoring
Do not attempt to clean infected systems. Rebuild them. Verifying that a system is fully clean takes more effort than rebuilding from a known-good image, and you still cannot be certain. Wipe compromised endpoints, servers, and domain controllers and rebuild from a validated baseline or fresh OS install.
Active Directory requires particular attention. If domain controllers were compromised, treat every account with domain admin-equivalent privileges as compromised. Reset all privileged credentials before connecting any restored system to the domain.
Many teams rebuild workstations but retain compromised domain controllers. A clean workstation connecting to a compromised domain is still within the attacker's reach. Full eradication means the domain, not just individual machines.
Step 4: sequence the restoration
Restore in business priority order, not technical convenience. Define your tiers before an incident so the sequencing decision is made from a plan rather than under pressure.
The three-tier approach
Tier 1, core business continuity: payroll, customer-facing services, core ERP, and communications. Target: live within 72 hours of completing eradication.
Tier 2, operational support: secondary line-of-business applications, reporting, analytics, and internal tools. Target: live within the first week.
Tier 3, non-critical: archives, development environments, test systems, and low-usage internal tools. These wait until Tier 2 is confirmed clean and stable.
Each tier requires sign-off from your incident response lead before connecting to the production network.
Define your manual fallback procedures before an incident, not during one. Paper-based or offline workflows for payroll approval, customer order handling, and financial authorisation prevent operational paralysis in the first 48 to 72 hours while Tier 1 systems come back online.
Step 5: meet your regulatory notification obligations
Notification obligations run concurrently with recovery work, not after it. Missing a notification deadline while focused on restoration is a separate regulatory violation from the attack itself.
GDPR: the 72-hour window
GDPR Article 33 requires you to notify your supervisory authority within 72 hours of becoming aware of a personal data breach. In a ransomware attack, that clock starts when your security team establishes personal data was involved, not when encryption was first detected. Ransomware almost always touches personal data because it encrypts indiscriminately across file systems.
The notification needs the nature of the breach, approximate categories and numbers of individuals affected, likely consequences, and measures taken or planned. You do not need a complete investigation first. Notify within 72 hours and update the authority as your picture develops.
NIS2: 24 hours for significant incidents
Under NIS2 Article 23, essential and important entities must submit an early warning to their competent authority within 24 hours of becoming aware of a significant incident. A ransomware attack that disrupts your services qualifies. A full notification follows within 72 hours, and a final report is due within one month.
Engage a data protection lawyer at the start of incident response, not the end. Early legal involvement gives you privilege protection for investigation materials and reduces the risk of notification errors that create a second regulatory exposure.
Step 6: harden as you rebuild
Your previous state had weaknesses the attacker found and exploited. Rebuilding to the same configuration gives the next group identical conditions to work from.
As each system comes back online:
- Enforce MFA on all privileged accounts before connecting them to the network
- Deploy or verify EDR coverage on every endpoint before it joins production
- Review and implement Active Directory tiering: most ransomware moves laterally via over-privileged domain accounts
- Enable centralised audit logging before any system handles live data
- Apply all outstanding patches to the OS and applications before production
Your last system coming back online is not the finish line. Security posture better than pre-attack is.
How long does recovery take?
Plan for weeks before business operations are fully restored. Sophos State of Ransomware 2026, a survey of 2,158 organisations in 17 countries, puts the average recovery time at three weeks. 55% of organisations recovered within a week and 83% within a month, while 3% took longer than three months.
In our experience, the fastest recoveries share three things: a rehearsed incident response plan, backups tested within the previous six months, and a segmented network that limited how far the attacker could move.
How Cyvra helps
Cyvra supports ransomware recovery from initial scoping and forensics through post-incident hardening. We work alongside your internal teams or take the lead where capacity is limited.
- Incident scope and forensics: identify every affected system, compromised credential, and persistence mechanism before restoration begins
- Backup validation: independent assessment of backup integrity on isolated infrastructure before your team relies on it
- Clean room rebuild: restore critical systems from validated images in an isolated environment before returning them to production
- Regulatory notification: draft and submit GDPR and NIS2 notifications within required timelines
- Post-incident hardening: AD tiering, MFA rollout, EDR deployment, logging architecture, and network segmentation
- Tabletop exercises: rehearse your response before you need it, so decisions are made from a plan rather than under pressure
Contact our cybersecurity practice or read about our compliance and incident response services.