--- title: "Ransomware Recovery Checklist: 12 Steps After an Attack" date: 2026-02-18T08:40:00+01:00 author: FAST LTA canonical_url: "https://www.fast-lta.de//en/blog/ransomware-recovery-checkliste-12-schritte-nach-dem-angriff" section: "Entries: Articles" --- ### Phase 1: Isolation and Mapping (0 to 4 Hours) [\#](#phase-1-isolation-and-mapping-0-to-4-hours "Phase 1: Isolation and Mapping (0 to 4 Hours)") Goal: Stop the attack and prevent it from spreading. #### Step 1: Appoint Incident Commander and Activate Team (0 to 15 min) [\#](#step-1-appoint-incident-commander-and-activate-team-0-to-15-min "Step 1: Appoint Incident Commander and Activate Team (0 to 15 min)") Who? - Incident Commander: one person with decision-making authority (IT manager, CISO, or CEO) - IT team: all administrators - Management: IT manager, CEO (to be informed; decision-relevant later) - Optional: external forensics firm, cybersecurity consultant, lawyer What happens? - Incident Commander appointed and briefed - Emergency meeting (30 minutes) with IT and management - Roles assigned: who handles IT recovery? Who handles communications? Who manages external partners? - Emergency hotline set up for internal queries Common mistake: waiting too long for external experts. Perform quick internal isolation even without external support. #### Step 2: Stop the Spread: Isolate the Network (15 to 30 min) [\#](#step-2-stop-the-spread-isolate-the-network-15-to-30-min "Step 2: Stop the Spread: Isolate the Network (15 to 30 min)") What? Ransomware attempts to spread across the network. Isolation is critical. How? - Quick decision: is a complete network shutdown necessary, or only specific segments? - Immediately disconnect infected systems from the network (remove the network cable, do not just shut down) - Immediately disconnect all backups from the network and revoke cloud backup credentials - Block VPN access (if the attacker entered via VPN) - Rotate admin credentials (ransomware may have stolen these) - Activate Endpoint Detection and Response (EDR) if not already active Critical: assume that ransomware has stolen admin credentials. Simply logging out is not sufficient. #### Step 3: Identify and Document Infected Systems (30 to 60 min) [\#](#step-3-identify-and-document-infected-systems-30-to-60-min "Step 3: Identify and Document Infected Systems (30 to 60 min)") What? Which systems are affected? Which are still clean? How? - List affected systems (AD, file server, ERP, email, etc.) - Record timestamps: when was the encryption first noticed? (Important for forensics and for reporting deadlines) - Check EDR logs: when was the first suspicious process? - Document isolation status: which systems are offline? Which are still online? - Take screenshots (for forensics and insurance) Practical note: a simple spreadsheet is sufficient: system, status, timestamp, notes. #### Step 4: Check Backup Integrity (60 to 120 min) [\#](#step-4-check-backup-integrity-60-to-120-min "Step 4: Check Backup Integrity (60 to 120 min)") What? Are your backups still usable, or have they also been encrypted? How? - Hardware air gap backups: can you access them? Is the physical isolation still intact? - Cloud backups: can you access them? Were they deleted using stolen credentials? - Identify the last known good backup: a backup that predates the infection - Test backup integrity: can files be read? Critical: if ransomware has destroyed all backups, contact immediately: - Forensics firm - Insurance provider - Lawyer - Competent authority (reporting obligations apply regardless of recovery options) --- ### Phase 2: Recovery Start (4 to 24 Hours) [\#](#phase-2-recovery-start-4-to-24-hours "Phase 2: Recovery Start (4 to 24 Hours)") Goal: Initiate the recovery process, restore the first systems. #### Step 5: Recovery Prioritisation and Restoration Plan (1 to 2 hours) [\#](#step-5-recovery-prioritisation-and-restoration-plan-1-to-2-hours "Step 5: Recovery Prioritisation and Restoration Plan (1 to 2 hours)") What? Which systems do we restore first? How? - Assess criticality: - Critical (immediate): AD (domain), email, ERP, file server (nothing works without these) - Important (6 to 24 hours): VoIP, antivirus server, DNS - Less critical (later): individual workstations, test systems 32. Check dependencies: AD must come before other systems (all others depend on AD) 33. Estimate RTO per system: how long does each restore take? 34. Define recovery order: 35. Domain Controller (1 to 2 hours) 36. Email (2 to 4 hours) 37. ERP (4 to 8 hours) 38. File server (8 to 16 hours) 39. Workstations (days 2 to 3) Practical note: a simple plan is sufficient: ​“Domain Controller recovery starts at 06:00, estimated completion 08:00.” #### Step 6: Prepare the Recovery Environment (1 to 2 hours) [\#](#step-6-prepare-the-recovery-environment-1-to-2-hours "Step 6: Prepare the Recovery Environment (1 to 2 hours)") What? Before restoring, you need a clean place to do it. How? - Network isolation: recovery takes place in a separate VLAN/​subnet (not the production network) - Prepare hardware: recovery hardware (VM, server, storage) available - Obtain backups: connect the air gap storage in a controlled way; restore cloud copies if needed - Gather credentials: recovery credentials from secure offline storage - Make a forensic copy: bit-for-bit copy of an infected system for later analysis Security: ensure that recovered systems are not reachable from the production network until fully validated. #### Step 7: Execute Recovery: Domain Controller (2 to 4 hours) [\#](#step-7-execute-recovery-domain-controller-2-to-4-hours "Step 7: Execute Recovery: Domain Controller (2 to 4 hours)") What? The Domain Controller is the heart. Once it is restored, all other systems can follow. How? - Restore the AD data store from backup - Start domain services: Active Directory, Kerberos, LDAP - Test replication: can other domain controllers replicate? - Test user login: can a test user log in from a test workstation? - Test Group Policy: are GPOs being applied? - Validation: admin accounts present? Passwords reset? If something goes wrong: - Boot into Directory Services Restore Mode and check the AD database - If necessary, use forensics assistance to repair from backup Time estimate: 2 to 4 hours (depends on backup size and hardware speed). --- ### Phase 3: Full Restoration (Days 2 to 7) [\#](#phase-3-full-restoration-days-2-to-7 "Phase 3: Full Restoration (Days 2 to 7)") Goal: Restore all systems step by step; re-establish business continuity. #### Step 8: Execute Recovery: Email and Other Critical Systems (Days 1 to 3) [\#](#step-8-execute-recovery-email-and-other-critical-systems-days-1-to-3 "Step 8: Execute Recovery: Email and Other Critical Systems (Days 1 to 3)") What? After AD, restore email, ERP, and the file server. How? - Email server (Exchange): - Restore the mailbox database from backup - Start email services - Test: users can log in and retrieve emails - Estimated time: 4 to 8 hours 60. ERP system (SAP, Oracle, etc.): 61. Restore the database backup 62. Start the application server 63. Test: users can log in and process transactions 64. Estimated time: 8 to 16 hours (databases are large) 65. File server: 66. Restore NFS/SMB shares from backup 67. Validate permissions 68. Test user access 69. Estimated time: 4 to 12 hours (depends on data volume) Parallel processing: email and ERP can run in parallel if they use separate hardware. #### Step 9: Validation and Security Checks (Days 3 to 4) [\#](#step-9-validation-and-security-checks-days-3-to-4 "Step 9: Validation and Security Checks (Days 3 to 4)") What? Before bringing production systems online, ensure no malware remnants remain. How? - Run a full EDR scan on all systems (may take hours) - Log analysis: when did the attack enter? Via which vector? - Credential resets: reset passwords for all critical accounts - Block VPN/​remote access (if the attacker entered this way) - Check admin access logs: were backdoors installed? - Review firewall rules: were new rules added by the attacker? Common mistake: going online without validation means the attacker can re-infect the systems immediately. #### Step 10: Staged Production Migration (Days 4 to 7) [\#](#step-10-staged-production-migration-days-4-to-7 "Step 10: Staged Production Migration (Days 4 to 7)") What? Move systems from the isolation network back to the production network. How? - Move to production ONLY after validation - One system at a time (not all at once) - Test phase: wait 4 to 8 hours, check for new suspicious activity - Rollback plan: if malware re-emerges, take the system offline immediately - Activate monitoring: all systems under enhanced EDR surveillance - Re-activate backups immediately (clean systems should now be backed up) Example timeline: - Day 4: AD and email online - Day 5: ERP online - Day 6: File server online - Day 7: Workstations online --- ### Phase 4: Post-Incident Review (Afterwards) [\#](#phase-4-post-incident-review-afterwards "Phase 4: Post-Incident Review (Afterwards)") Goal: Forensics, authority notification, lessons learned. #### Step 11: Forensics and Attack Analysis (Parallel, Days 1 to 14) [\#](#step-11-forensics-and-attack-analysis-parallel-days-1-to-14 "Step 11: Forensics and Attack Analysis (Parallel, Days 1 to 14)") What? Who attacked you? How? When? How? - Engage an external forensics firm (should run in parallel with recovery) - Create an attack timeline: - Initial access: phishing? RDP? vulnerability? - Privilege escalation: which exploits? - Lateral movement: how did it spread? - Exfiltration: was data stolen? (Relevant for double extortion and GDPR) - Encryption: when did ransomware activity begin? 89. Identify the attacker: is it a known group? 90. Write a forensics report (for insurance, lawyer, authorities) Note: the forensics report is often required for insurance cost reimbursement. #### Step 12: Meet Reporting Obligations (NIS2 and GDPR Deadlines) [\#](#step-12-meet-reporting-obligations-nis2-and-gdpr-deadlines "Step 12: Meet Reporting Obligations (NIS2 and GDPR Deadlines)") What? Authorities must be informed, on tight deadlines. How? - NIS2 incident reporting (if your organisation is in scope of Directive (EU) 2022⁄2555): - Early warning to the competent national authority or CSIRT within 24 hours of becoming aware of a significant incident - Incident notification within 72 hours - Final report within one month - In Germany, the competent authority is the BSI; other EU member states have their own designated authorities 96. Data protection authority (if personal data is affected): 97. Notify the competent supervisory authority within 72 hours (GDPR Article 33) 98. Inform affected individuals where there is a high risk (GDPR Article 34) 99. Financial sector: DORA (Regulation (EU) 2022⁄2554, applies since 17 January 2025) imposes its own ICT incident reporting régime 100. Notify the insurer: 101. Contact the cyber insurer immediately (policies often tie cover to prompt notification) 102. Submit a claim and attach the forensics report 103. Notify customers (if data has been leaked): 104. Particularly relevant in double-extortion cases 105. Transparency is important for maintaining trust 106. Sector regulators (critical infrastructure and other regulated sectors) may have additional requirements Critical: missing notification deadlines can trigger fines on top of the incident itself. Under NIS2, essential entities face fines of up to EUR 10 million or 2 percent of global annual turnover. --- ### Timeline: A Realistic Recovery Scenario [\#](#timeline-a-realistic-recovery-scenario "Timeline: A Realistic Recovery Scenario") - 06:00: Ransomware detected (files with an unfamiliar extension), T+0 - 06:15: Incident Commander and team activated, T+0.25h - 06:45: Network isolated, infected systems offline, T+0.75h - 08:00: Backup status checked (air gap copy intact), T+2h - 10:00: Recovery plan finalised, T+4h - 14:00: Domain Controller recovery online, T+8h - 15:00: First users can log in with test accounts, T+9h - 18:00: Email recovery online, T+12h - 22:00: ERP database recovery starts, T+16h - Day 2, 06:00: ERP online, T+24h - Day 2, 18:00: File server online, T+36h - Day 3, 18:00: All workstations online, business back to normal, T+60h RTO achieved: 2.5 days (60 hours). With good backups and planning, this is realistic. Without backups, recovery takes weeks, if it succeeds at all. --- ### Frequently Asked Questions [\#](#frequently-asked-questions "Frequently Asked Questions") Should we pay the ransom? This decision should be made by executive management together with the insurer and lawyer. With good backups, payment is usually not necessary. How long does an average recovery take? With good, tested backups: typically 1 to 3 days for core systems. Without usable backups: weeks of rebuilding from scratch, with permanent data loss. Industry reports consistently show that full recovery often stretches over weeks. What if backups were also encrypted? This is the scenario you must prevent. That is why hardware air gap backups exist: offline, not reachable, not encryptable. Should we engage a forensics firm? Highly recommended. They help with attacker attribution, prevention of recurrence, and insurance support. --- ### Further Resources [\#](#further-resources "Further Resources") → Recovery Time Objective: How to Calculate Your RTO Realistically (/en/blog/recovery-time-objective/) → Incident Response for Ransomware: Who Does What? (/en/blog/incident-response-ransomware/) → How Ransomware Destroys Backups: Technical Analysis (/en/blog/wie-ransomware-backups-zerstoert/) → Silent Brick System: Hardware Air Gap for Secure Recovery (/en/produkte/silent-brick-system/) → Request a Demo (/​en/​kontakt/​demo/​) ### Ransomware Ransomware is malware that encrypts data on infected systems and demands a ransom for decryption — with the goal of forcing organizations and public bodies to pay by paralyzing their operations. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/ransomware) ### Air Gap An air gap is the complete physical interruption of all network connections between a backup system and the rest of the IT infrastructure, so that the system has no addressable network interface in its offline state and is therefore unreachable by ransomware and attackers. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/air-gap) ### RTO / RPO RTO (Recovery Time Objective) is the maximum acceptable downtime after an IT failure; RPO (Recovery Point Objective) is the maximum acceptable data loss — both are metrics that must be technically demonstrably met in backup architectures and must not merely be defined as aspirational targets. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/rto-rpo) ### Ransomware Ransomware is malware that encrypts data on infected systems and demands a ransom for decryption — with the goal of forcing organizations and public bodies to pay by paralyzing their operations. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/ransomware) ### Ransomware Ransomware is malware that encrypts data on infected systems and demands a ransom for decryption — with the goal of forcing organizations and public bodies to pay by paralyzing their operations. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/ransomware) ### Air Gap An air gap is the complete physical interruption of all network connections between a backup system and the rest of the IT infrastructure, so that the system has no addressable network interface in its offline state and is therefore unreachable by ransomware and attackers. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/air-gap) ### Disaster Recovery Disaster recovery refers to the structured processes and technical measures that ensure IT systems can be restored within defined timeframes (RTO) with maximum data loss (RPO) after a severe failure — ransomware attack, hardware failure or data center outage. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/disaster-recovery) ### Disaster Recovery Disaster recovery refers to the structured processes and technical measures that ensure IT systems can be restored within defined timeframes (RTO) with maximum data loss (RPO) after a severe failure — ransomware attack, hardware failure or data center outage. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/disaster-recovery) ### Air Gap An air gap is the complete physical interruption of all network connections between a backup system and the rest of the IT infrastructure, so that the system has no addressable network interface in its offline state and is therefore unreachable by ransomware and attackers. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/air-gap) ### Disaster Recovery Disaster recovery refers to the structured processes and technical measures that ensure IT systems can be restored within defined timeframes (RTO) with maximum data loss (RPO) after a severe failure — ransomware attack, hardware failure or data center outage. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/disaster-recovery) ### Disaster Recovery Disaster recovery refers to the structured processes and technical measures that ensure IT systems can be restored within defined timeframes (RTO) with maximum data loss (RPO) after a severe failure — ransomware attack, hardware failure or data center outage. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/disaster-recovery) ### GDPR The GDPR (General Data Protection Regulation, EU 2016/679) is the European regulation for the protection of personal data — particularly relevant for IT infrastructure in Art. 5 (principles), Art. 17 (right to erasure), Art. 28 (processors) and Art. 32 (security of processing). [Mehr erfahren →](https://www.fast-lta.de//en/glossary/gdpr) ### GDPR The GDPR (General Data Protection Regulation, EU 2016/679) is the European regulation for the protection of personal data — particularly relevant for IT infrastructure in Art. 5 (principles), Art. 17 (right to erasure), Art. 28 (processors) and Art. 32 (security of processing). [Mehr erfahren →](https://www.fast-lta.de//en/glossary/gdpr) ### GDPR The GDPR (General Data Protection Regulation, EU 2016/679) is the European regulation for the protection of personal data — particularly relevant for IT infrastructure in Art. 5 (principles), Art. 17 (right to erasure), Art. 28 (processors) and Art. 32 (security of processing). [Mehr erfahren →](https://www.fast-lta.de//en/glossary/gdpr) ### DORA DORA (Digital Operational Resilience Act, EU 2022/2554) is an EU regulation that has applied to all regulated financial market participants since January 2025, setting concrete requirements for ICT risk management, backup systems (Art. 11 and 12), third-party provider management (Art. 28–30) and incident reporting. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/dora) ### Ransomware Ransomware is malware that encrypts data on infected systems and demands a ransom for decryption — with the goal of forcing organizations and public bodies to pay by paralyzing their operations. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/ransomware)