Ransomware recovery is an operating decision
A ransomware plan is often reduced to one question: “Do we have backups?” The more useful question is: “Can we restore the business in the right order when systems, credentials, communications, and documentation may all be affected?”
Microsoft’s ransomware guidance warns that attackers may target backups, recovery systems, and the documentation needed to restore operations. Recent Microsoft reporting on cloud-based ransomware also describes attackers attempting to delete storage, snapshots, recovery containers, and other cloud resources. These are confirmed threat techniques in reported cases; they are not proof that every cloud tenant has been attacked in this way.
Define the recovery order
Create a recovery-priority list that reflects how the office operates. A typical sequence might include:
- Safety, facilities, and alternate communication.
- Identity administration and administrator access.
- Internet, phones, and network connectivity.
- Core line-of-business applications.
- Financial, payroll, and payment systems.
- Customer, patient, or client records.
- Shared files and collaboration platforms.
- Nonessential systems and convenience services.
The correct order differs by business. A medical office, law firm, manufacturer, and property-management company will not have the same priorities.
For each system, record the owner, vendor, dependencies, restoration method, acceptable downtime, and acceptable data loss. Ask whether the system can be restored without the original administrator account.
Protect backups from ordinary administrator access
Backups should not be reachable through the same credentials and network paths used by everyday workstations. Use separate administrative identities, MFA, role-based access, and alerts for deletion or configuration changes. Consider immutable or otherwise protected storage where appropriate.
A backup that can be deleted by a compromised office administrator is not necessarily useless, but it is exposed to the same event it is supposed to help the business survive. The design should account for malicious deletion, accidental deletion, provider outage, and regional disruption.
Test restoration, not just backup jobs
A successful backup job demonstrates that data was copied. It does not demonstrate that the data is complete, usable, or restorable within the business’s acceptable timeframe.
Run several types of tests:
- Restore a representative file and verify it opens.
- Restore a mailbox or collaboration item.
- Restore a critical application or database to a safe test environment.
- Confirm that permissions and dependencies return correctly.
- Measure the time required and document obstacles.
- Conduct a “zero functionality” discussion in which all normal systems are assumed unavailable.
Retain the result, including failures. A failed test is useful if it leads to a corrective action.
Plan for compromised credentials
Ransomware response may require rebuilding identity systems, not simply restoring files. Keep a list of emergency contacts, recovery administrators, backup-console access, vendor escalation procedures, and trusted devices. Store this information securely outside the primary environment.
During an incident, do not rush to reconnect restored systems. A restoration performed before the attacker is removed can reintroduce malicious access. Qualified responders should help determine containment, evidence preservation, credential resets, and safe restoration order.
Keep the business moving
Business continuity is the ability to continue priority work while technology is impaired. Identify manual processes for scheduling, customer communication, payment approval, document intake, and urgent service delivery. Decide which records must be recreated later and who owns that reconciliation.
Prepare alternate communications. Microsoft recommends planning for the possibility that normal email and collaboration tools may be unavailable. Keep phone numbers, emergency contacts, customer notification templates, and key procedures in an offline or independently accessible location.
Ransom decisions require more than technology
The FTC states that paying a ransom does not guarantee recovery. It also recommends reporting attacks, investigating how access occurred, securing operations, and considering notification obligations. Decisions about payment, sanctions, legal exposure, and notification require qualified legal and incident-response advice.
A quarterly recovery routine
Each quarter, review backup coverage, privileged access, retention, immutability, monitoring, and restoration results. At least annually, run a cross-functional tabletop exercise with management, IT, operations, finance, legal, and communications.
The confirmed lesson from current guidance is that recovery must be designed before the incident. The uncertain part is the exact technical path because each office uses different applications, vendors, and data. Document those dependencies now, while the normal environment is available.
Sources
Microsoft backup and ransomware planning: https://learn.microsoft.com/en-us/azure/security/fundamentals/backup-plan-to-protect-against-ransomware
Microsoft cloud-based ransomware research: https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/
Microsoft Backup and Recovery benchmark: https://learn.microsoft.com/en-us/security/benchmark/azure/mcsb-v2-backup-recovery
FTC breach response guidance: https://www.ftc.gov/business-guidance/resources/data-breach-response-guide-business