Prepare before an attack, respond during one, and recover after.
We've published new ransomware recovery guidance for Azure SQL Database and Azure SQL Managed Instance on Microsoft Learn. The new guidance provides an end-to-end recovery framework, from preparing before an attack through containing an active compromise, restoring trusted data, validating recovery, and hardening the environment afterward.
When an attacker reaches your database, the decisions your team makes early on shape what you can recover. The guide helps you plan those decisions before an incident starts.
Why this guide matters
An attack on your database can take more than one form: an attacker might encrypt, destroy, delete, or steal your data. You don't need to receive a ransom demand to use the guide. Use it whenever an attacker has reached your data, whether or not anyone asks you for money. It focuses on attacks that come through identities, networks, applications, and configurations you control, not on compromise of the Azure platform itself.
Some of the most important decisions in an incident are also hard to undo:
- Contain attacker access before you restore. If the attacker's way in is still open, a restored database can be compromised again.
- Choose a clean restore point. The guide helps you choose a point from before the damage and verify the restored data before production traffic returns.
- Act before backups expire. Automated backups expire when their retention period ends, so the guide shows you how to preserve them early in an incident.
- Preserve evidence before cleanup. Deleting a compromised resource doesn't hide the attack, but it can destroy the evidence you need to investigate it.
The guide shows when to make each of these decisions, so your team isn't facing them for the first time during an attack.
What the guide covers
The guide introduces a seven-step ransomware recovery framework for Azure SQL DB and Azure SQL MI: Protect, Detect, Contain, Assess, Restore, Validate, and Harden.
| Step | What it helps you do |
|---|---|
| Protect | Before any attack, prepare your environment to reduce attack risk and support recovery. |
| Detect | Recognize signs of a suspected or confirmed compromise. |
| Contain | Stop ongoing attacker activity and limit further damage or spread. |
| Assess | Determine the incident's scope, timeline, and impact to guide recovery decisions. |
| Restore | Recover affected data or access in a trusted environment after attacker access is contained. |
| Validate | Confirm that recovered data and systems are trustworthy before production traffic returns. |
| Harden | Address the gaps the incident exposed to strengthen future protection and recovery. |
You'll also find:
- A protection checklist with controls sorted by what they do: reduce the chance an attack succeeds, help you detect one, or help you recover.
- Guidance on determining how far an attack reached, from a single database to your entire tenant, and what that means for recovery.
- A comparison of restore options, including point-in-time restore, long-term retention backups, cross-region recovery, and recovering deleted resources.
Recovery starts before the attack
Your recovery options are largely set before an attack begins. Turning on backup retention, long-term retention, or audit logging after a compromise doesn't bring back backups that have already expired or logs that were never captured. That's why the guide starts with protection.
Configuration is only part of it. A backup you've never restored is a hypothesis, not a recovery plan. The guide also covers the process work that's easy to overlook:
- Rank your databases by business importance, so responders know what to recover first.
- Agree in advance on who decides when to restore and how your team escalates to Azure Support.
- Test restores, not just backup settings, and time them.
- Rehearse the full response at least once a year.
Preparation doesn't remove the risk of an attack, but it shapes whether your recovery is fast, partial, or not possible at all.
Next Steps
Don't wait for an incident to test your recovery plan. Review the new guidance, walk through the protection checklist, test your restore procedures, and share the recovery plan with your database and incident-response teams.
Overview: Recover Azure SQL Database and Azure SQL Managed Instance from a ransomware attack
Microsoft