Validating Microsoft 365 recovery after ransomware: A practical guide

Why standard Microsoft 365 recovery mechanisms are insufficient for ransomware protection

Many companies rely on built-in Microsoft 365 features like Retention Policies, Recycle Bin, and Versioning, believing them to be adequate protection against data loss, especially from ransomware. However, these mechanisms have significant limitations in the context of a targeted ransomware attack.

Microsoft 365 Retention Policies are useful for compliance but are not designed for comprehensive backup. Files can be automatically deleted after a set period, and some data might not fall under retention rules at all. In a ransomware attack where files are encrypted, these policies may not help, as encrypted files can be synchronized back into Microsoft 365, rendering saved versions useless. Attackers, with valid credentials, can manipulate retention policies to permanently delete data, as described in CISA's guidance on protecting against ransomware [1].

SharePoint and OneDrive Recycle Bins retain deleted files for 93 days, and versioning stores at least 500 file versions by default. However, if ransomware creates a new encrypted copy of a file and deletes the old one, or encrypts the file in place, versions can also be encrypted, or recovery from them can be complex and time-consuming. Additionally, recovery using eDiscovery, designed for compliance, is cumbersome for operational recovery.

In essence, Microsoft adheres to a Shared Responsibility Model, where Microsoft is responsible for platform availability, and the user is responsible for protecting their data within that platform.

Critical Microsoft 365 data: What needs protection and testing

Effective protection begins with understanding which data is critical to the business. It's impossible to provide uniform protection for every document, so organizations must classify data to prioritize their mission-critical and sensitive information. Data classification is the process of identifying, categorizing, and protecting content according to its sensitivity level or impact. This helps achieve and maintain regulatory compliance (e.g., HIPAA, CCPA, and GDPR), effectively implement data privacy and confidentiality, and reduce data management costs.

In Microsoft 365, critical data can reside in Exchange Online (email, calendars), SharePoint Online (documents, sites, intranet), OneDrive for Business (individual user files), and Teams (chats, files, meeting recordings). Examples of critical data include customer information, financial records, employee data, intellectual property, and confidential project documents. Microsoft Purview helps discover, classify, and label sensitive information within the environment, applying consistent protection policies.

To determine data criticality and corresponding RTO (Recovery Time Objective) and RPO (Recovery Point Objective), one must ask: what happens if this information is unavailable? What would be the financial and reputational losses? Are there regulatory requirements? For most organizations, Microsoft 365 data should be considered Tier 2 with an RTO of less than four hours and an RPO of one to four hours. For regulated industries, Exchange Online and SharePoint often require an RTO of less than 10 minutes and an RPO of less than one hour, as outlined in industry guidelines for business continuity planning [2].

Architectural requirements for SaaS backup for effective ransomware recovery

For a SaaS Microsoft 365 backup solution to be effective against ransomware, it must meet several key architectural requirements:

Immutable copies: Backups must be protected from modification, encryption, or deletion, even if attackers gain administrator credentials. This is achieved using WORM (Write Once, Read Many) technologies or locked storage, ensuring a "clean" copy of data for recovery.
Isolation from the production environment: Backups should be stored physically or logically isolated from the primary Microsoft 365 environment. This creates an "air gap" that prevents ransomware from spreading from the production system to the backups. This can be achieved by storing data in cloud object storage with versioning enabled.
Granular recovery: The solution must allow for the recovery of individual files, emails, SharePoint objects, OneDrive, or Teams items, not just entire sites or mailboxes. This significantly speeds up the recovery process and minimizes business downtime by allowing only damaged elements to be restored.
Adherence to the 3-2-1-1-0 principle: This extended backup principle suggests having three copies of data, on two different media, one of which is off-site, one copy is offline or immutable, and zero errors during recovery verification [3]. This ensures maximum resilience against various failure scenarios, including ransomware.

Expert position
Kateryna Levchuk
Digital Workplace Expert
Key expert focus: validate the recovery scenario for critical Microsoft 365 data after an incident, not only the existence of a SaaS backup.
Expert profile →

Microsoft 365 backup solutions, such as those offered by Rubrik and Veeam, are designed with these requirements in mind, providing data immutability, a logical air gap, and granular recovery.

Operational mechanism: Developing and testing a critical data recovery plan from SaaS backup

Having a robust SaaS Microsoft 365 backup solution is only part of the equation. Crucial for successful ransomware recovery is a well-developed and regularly tested recovery plan. Without such a plan, even the best backups can prove useless or recovery may take an unacceptably long time.

Stages of developing and testing a recovery plan:

Define RTO and RPO for critical data: Based on data classification, establish clear RTO (maximum allowable downtime) and RPO (maximum allowable data loss) targets for each type of critical data. This will prioritize recovery efforts. For example, critical systems may require continuous data protection or hourly increments, as recommended in industry standards [4].
Develop a detailed recovery plan: Document step-by-step procedures for recovering each type of critical data from the SaaS backup. The plan should include: who is responsible for recovery, what tools to use, sequence of actions, contact information, and escalation procedures.
Regular recovery testing: Testing should be conducted regularly (at least quarterly) to ensure the plan works and data can be restored within established RTO/RPO. This may include restoring individual files, mailboxes, or even entire sites to a test environment. It is important to verify backups before launching a company-wide strategy.
Document and analyze results: All testing results, identified issues, and changes made to the plan must be thoroughly documented. This allows for continuous improvement of the recovery process.
Update the plan: The recovery plan must be reviewed and updated annually or after significant changes in the Microsoft 365 infrastructure, changes in data criticality, or the emergence of new threats.
Staff training: The IT infrastructure team must have a clear understanding of the recovery process from SaaS backup, including practical skills in using the solution.

CISA (Cybersecurity and Infrastructure Security Agency) recommends testing ransomware recovery plans to ensure their effectiveness. Recovering data from backup is critical to minimizing the impact of an attack.

Checklist for validating Microsoft 365 recovery after ransomware

This checklist will help CIOs, CTOs, and CISOs assess their readiness for Microsoft 365 recovery after a ransomware attack:

Are critical Microsoft 365 data defined and classified?
Does the SaaS backup solution have immutable copy functionality?
Does the SaaS backup ensure isolation of backups from the M365 production environment?
Does the SaaS backup support granular recovery (individual files, emails, objects)?
Is a detailed plan for recovering critical M365 data from SaaS backup developed?
Are RTO and RPO defined for each type of critical M365 data?
Is regular (at least quarterly) testing of critical data recovery from SaaS backup conducted?
Are recovery testing results and identified issues documented?
Is the recovery plan reviewed and updated annually or after significant changes in the M365 infrastructure?
Does the IT infrastructure team have a clear understanding of the recovery process from SaaS backup?

Effective ransomware recovery is not just about having backups, but a proven ability to quickly and fully restore critical data. Investments in Microsoft 365 SaaS backup only pay off when these solutions are integrated into a comprehensive, tested cyber resilience plan.