Microsoft 365 Backup and SaaS Backup
Why Microsoft 365, Entra ID, Jira, Confluence, Okta & Co. need their own recovery strategy
Microsoft 365 is running, Google Workspace and Salesforce are accessible, and yet business-critical data can still be lost: through accidental mass deletion, a compromised administrator account, or ransomware that enters the cloud via synchronized folders. Emails, documents, project information, knowledge bases, identities, permissions, and contracts now reside on platforms like Microsoft 365, Microsoft Entra ID, Jira, Confluence, Okta, or DocuSign. The provider ensures the availability of the service, while the company itself is responsible for data recovery. With Microsoft 365 Backup, Microsoft is currently expanding its native data backup capabilities. This article shows what a SaaS backup solution must be able to do, where the limits of built-in tools lie, and what questions management, CIOs, and CISOs should be addressing.
In summary: SaaS shifts the operation of an application to the cloud, but not automatically the responsibility for your own data, identities, and configurations. A robust cyber resilience strategy must therefore define which SaaS data needs to be protected, which recovery points are required, and how recovery will be performed after deletion, misconfiguration, or a cyber incident.
Table of Contents
The cloud is available. But is your data recoverable?
For management, CIOs, and CISOs, this raises a different question than with traditional infrastructure: It's not just the availability of the SaaS service that matters. The crucial factor is whether business-critical data and configurations can be restored to a defined, trustworthy state after a data loss or security incident.
What is SaaS backup?
SaaS backup, such as a Microsoft 365 backup, is the process of backing up data and, depending on the application and solution, supported configuration and identity objects from cloud-based software services so that they can be restored after deletion, misconfiguration, or other data loss events. As a cloud backup, the backup is ideally located in an environment separate from the source platform.
It is important to distinguish between high availability and disaster recovery. Microsoft explicitly points out for Microsoft 365 that a disaster recovery copy preserves the current state of content , while a backup allows the restoration of previous states.
Microsoft 365 Backup: What's changing right now
Microsoft is currently rolling out the Full Workload Backup feature for Microsoft 365 Backup . This allows administrators to protect an entire workload, such as SharePoint, OneDrive, or Exchange, with a single policy; new data is automatically included. General availability began in mid-September, and completion is planned for mid-October 2026.
How the risk landscape is changing is illustrated by a case from late September. Zenity Labs, under the name SalesBleed, disclosed vulnerabilities in Salesforce Agentforce that allowed CRM data to be exfiltrated without the victim's knowledge or consent. Salesforce patched the vulnerabilities in August. The case remains relevant as an example of a structural risk: AI agents and integrations access SaaS data with extensive privileges, and this is not limited to a single product.
Shared responsibility: Platform is not the same as data
SaaS providers operate according to the shared responsibility model. The provider is responsible for the infrastructure, availability, and redundancy of its data centers. The customer is responsible for data, identities, permissions, and configurations.
In practice, this means that if a Microsoft data center fails, geo-redundant copies take over. However, if an administrator deletes a SharePoint site or a script overwrites thousands of Salesforce records, the platform considers this an intentional change. It is reliably replicated to all copies. Redundancy protects against platform failure, while backups protect against errors and attacks within the platform. Microsoft explicitly states this division of responsibilities in its shared responsibility documentation : Data, accounts, and identities remain the customer's responsibility in every cloud environment.
This doesn't mean that SaaS providers don't offer protection or recovery capabilities. Microsoft, for example, offers Microsoft 365 Backup for Exchange, SharePoint, and OneDrive. Therefore, a thorough evaluation is crucial: Do the native features of the respective platform meet your specific requirements for retention, recovery, independence, and regeneration?
Shared Responsibility in SaaS: Who is responsible for what?
| Area | Responsible |
|---|---|
| Data centers, hardware, network | SaaS providers |
| Application availability | SaaS providers |
| Geo-redundancy in case of platform failure | SaaS providers |
| Data and content | Customer |
| Identities and permissions | Customer |
| Configurations and policies | Customer |
| Recovery after deletion, error, or attack | Customer |
Why SaaS backup is a cyber resilience issue
Cybersecurity aims to prevent attacks or detect them early. Cyber resilience complements this perspective by adding the ability to continue working after an incident and to restore critical data and systems. Backup serves as a recovery control mechanism, but only if the necessary data is actually backed up and recoverable.
- Protection against accidental or malicious deletion: An independent data set can create an additional recovery option.
- Recovery after misconfigurations: Especially with identity platforms, configurations and policies can be business-critical.
- Historical restoration points: They allow a return to a previous state, provided the solution used and the workload support this.
- Separation of production and backup: A vendor-independent backup platform can store data outside of the respective SaaS production environment.
Which SaaS applications should be included in the backup strategy?
The selection should be based on the criticality of the business processes and the recovery capabilities actually available. Typical areas include:
| Area | examples | Recovery objects to be checked |
|---|---|---|
| Collaboration | Microsoft 365, Google Workspace | Email, files, sites, user content |
| CRM | Salesforce | Data records, attachments, metadata |
| Identity & Access | Microsoft Entra ID, Okta | Users, groups, roles, policies, and other supported configurations |
| Project & Knowledge | Jira, Confluence | Projects, issues, attachments, pages, spaces, and other supported objects |
| Contracts | DocuSign | Documents and other data supported by the backup solution |
| Other SaaS services | e.g. other CRM and DevOps platforms | Workload-specific check |
Backing up Microsoft 365 (formerly Office 365): Where native functions end
Wastebaskets and storage guidelines
By default, deleted items in Exchange Online remain recoverable for 14 days , while SharePoint and OneDrive retain deleted items for up to 93 days . Retention policies and litigation hold further prevent data from being permanently deleted.
These mechanisms are built for compliance and eDiscovery. They allow you to find and export data. However, they cannot be used to revert a mailbox, a Teams environment, or a SharePoint site, including its structure and permissions, to a specific point in time.
The native Microsoft 365 backup
Microsoft 365 Backup partially closes this gap because it enables point-in-time restores even for large amounts of data. However, the service only backs up Exchange Online, OneDrive, and SharePoint Online . It does not cover a complete restore of Teams environments, Entra-ID objects, or Conditional Access policies.
The lack of independence is a more serious issue. According to Microsoft, backups are immutable unless a backup administrator explicitly deletes them during offboarding. However, they never leave the Microsoft 365 trust boundary and are managed through the same administrative level. Therefore, a compromised account with backup administrator privileges, a tenant suspension, or a provider outage can affect both production data and backups simultaneously.
Companies should therefore not make a blanket statement that Microsoft does not offer backups: Backup policies can be configured for OneDrive, SharePoint, and Exchange . The real management question is: What workloads, recovery periods, and restoration requirements apply within the company, and is the chosen native or third-party solution sufficient for these needs?
Other platforms: Google Workspace, Salesforce, Entra ID, Jira, Okta and DocuSign
Google Workspace and Salesforce
Google Workspace follows the same principle, but with different timeframes. Deleted Gmail messages and Drive files remain in the trash for 30 days, after which administrators can restore them for another 25 days via the admin console. After that, they are no longer available to Google either. The tools can recover deleted data, but they have limited effectiveness against overwritten or encrypted content. More information can be found in the article on backing up Google Workspace.
The situation is similar with Salesforce and Atlassian: they offer recycle bins, export functions, and sometimes paid backup options, but no automatically created independent copy. With Salesforce, in addition to the data records themselves, metadata—objects, fields, workflows, and permissions—must also be backed up. Without the appropriate structure, restored data records are practically unusable.
Entra ID Backup: Include identities and configurations in the recovery process
Microsoft Entra ID isn't just about files. Specialized backup solutions protect users, groups, administrative units, roles, enterprise apps, app registrations, and conditional access policies , among other things . The specific scope can depend on the edition, licensing, and API support. This makes identity recovery an integral part of business continuity planning.
Jira and Confluence Backup: Keeping projects and knowledge recoverable
Jira and Confluence store project statuses, tickets, and internal knowledge. Both platforms offer automated backups and granular recovery of supported data such as projects, issues, pages, spaces, files, and attachments, stored immutably outside the production environment. The specific objects to be backed up should be reviewed in the current coverage documentation before implementation.
Okta Backup: Treat identity configurations as critical operational data
Okta offers automated, immutable backups and the recovery of compromised configurations. Therefore, for companies whose access to business-critical applications depends on Okta, the recoverability of the identity system should also be included in their resilience planning.
DocuSign: Include contract data in the recovery analysis
DocuSign also offers automated backup and recovery . Companies should assess which contract and signature data is critical to their legal and operational processes and how it can be restored after data loss.
Typical loss scenarios
User error and bulk changes are among the most common causes. A faulty import, a misconfigured retention policy, or a faulty script can alter large amounts of data in minutes. Often, this only becomes apparent after the recycle bin retention period has expired.
Ransomware indirectly affects cloud data via synchronization. If malware encrypts local files on a device using a OneDrive or Google Drive client, the encrypted versions end up in the cloud.
Compromised administrator accounts are the most serious scenario. Anyone with global admin rights can delete mailboxes and sites, remove policies, and interfere with native backups.
Offboarding regularly leads to unnoticed data loss. After a Microsoft license is revoked, the mailbox and OneDrive of a departing employee are deleted after certain periods. With Google Workspace, Drive files from a deleted account can only be recovered within 20 days.
Integrations and AI agents are a growing source of risk. They operate with extensive permissions and increasingly process content from untrusted sources. An agent that is allowed to read data is often also allowed to modify it. Backups offer no protection against data leaks, and they are often the only fallback against manipulated or deleted data.
Impact on Recovery and Compliance
Many companies have defined recovery goals for their data center, but not for SaaS services, even though communication, sales, and document management depend on them. There's also a technical factor: SaaS platforms limit, via their interfaces, how much data can be written per unit of time. A mass recovery of several terabytes therefore takes significantly longer than datasheets would suggest.
From a regulatory perspective, the situation is clear. Article 32 of the GDPR requires that personal data be made available again quickly after an incident. The NIS2 Directive explicitly names backup management and recovery as mandatory measures. Both apply regardless of where the data is located.
Expert opinion: The underestimated gap
In practice, SaaS data backup rarely fails due to a lack of technology, but rather due to two assumptions. First, native backup is considered a complete solution. It's a sensible first line of defense for rapid recovery. However, as the only copy, it remains tied to the same provider, the same administrators, and the same trust boundary. The 3-2-1-1-0 rule explicitly requires a copy outside this shared boundary.
The second issue: The backup concept ends with Microsoft 365. CRM, ticketing, project management, and knowledge bases often run on additional SaaS services that departments have implemented themselves and which are not included in any backup strategy. The gap usually only becomes apparent when data is missing.
What characteristics should a multi-SaaS backup strategy examine?
A decision should not be based solely on the number of supported applications. For C-level executives and IT management, the following criteria are particularly relevant:
- Independence: Are backup data stored separately from the respective SaaS production environment?
- Immutability: Are backed-up data protected against subsequent modification or deletion?
- Recovery granularity: Which individual objects can be searched and restored?
- Workload coverage: Which applications and which data objects within these applications are actually supported?
- Identity Recovery: Can relevant identity and configuration objects be backed up in addition to user data?
- Data residency and governance: Where is the data located, how is access controlled, and what evidence is available?
- Retention and recovery periods: Do storage and available recovery points meet internal requirements?
- Business: How are backup jobs monitored, errors detected, and restore processes tested?
With each additional SaaS application, the number of recovery processes increases. A shared multi-SaaS platform can consolidate multiple supported workloads into a single management environment, thereby simplifying administration, visibility, and standardized recovery processes. However, the specific benefits depend on the actual workload coverage and the company's requirements. Because features vary depending on the workload, the current product and coverage documentation should be part of every selection decision.
Setting up SaaS backup correctly: six steps
1. Record inventory
Inventory all SaaS applications in use, including those implemented in specialist departments, and identify business-critical data.
2. Define recovery goals
Define RTO and RPO for SaaS workloads in the same way as for on-premises systems.
3. Create an independent copy
Maintain at least one backup outside the source platform, with its own management, MFA, and immutable storage. Native functions remain a sensible first line of defense.
4. Secure completely
In addition to mailboxes and files, also include teams, groups, shared storage in Google Drive, configurations and, in the case of Salesforce, metadata, as well as identity and configuration objects from Entra ID and Okta, project data from Jira and Confluence, and contract data from DocuSign.
5. Choose storage location and operator consciously
Backups in European data centers simplify GDPR documentation. However, for protection against foreign disclosure requests, such as under the US CLOUD Act, it is not only the server location that matters, but also whether the operator is subject to such a legal system (more on this in the article on European data sovereignty ).
6. Test recovery
Regularly practice single and bulk restores (see Recovery Testing and Restoration Test ) and document the actual duration. Also, link offboarding processes to a prior backup.
Seven questions that management, CIO and CISO should answer
- Which SaaS applications are business-critical for our core processes?
- What data, identities, and configurations reside exclusively or primarily on these platforms?
- What native backup, retention, and restore features does each SaaS provider actually offer today?
- What recovery times and retention periods does our company require?
- Do we need a backup copy separate from the SaaS production system?
- Can we selectively restore individual objects or only larger datasets?
- Is the restore process documented and regularly reviewed?
Conclusion: Backup is a prerequisite. Recoverability is the goal.
While the expansion of Microsoft 365 Backup improves the built-in tools, the fundamental principle remains the same: the company itself is still responsible for the recoverability of SaaS data. Cloud services reduce the effort required to operate in-house infrastructure, but they don't eliminate the need to define recovery requirements for business-critical data. Especially with SaaS, it should be clearly documented which data and configurations are protected, how long recovery points are available, and how a restore is performed in an emergency.
A robust SaaS backup is independent of the source platform, covers all critical data types, and is regularly tested. For C-level executives, SaaS backup is therefore not an isolated backup issue, but rather part of business continuity and cyber resilience: Can the company restore its critical SaaS data and access structures to a defined state after data loss, misconfiguration, or a cyber incident?
Consider SaaS recovery as part of overall cyber resilience
Cristie Data supports companies with backup, recovery, and cyber resilience concepts for on-premises, hybrid, and cloud-based environments. The first step focuses not on a specific product, but on the recovery requirements: Which SaaS workloads are critical, what recovery options are needed, and what security gaps exist? With Cristie Data's multi-SaaS backup solution , Microsoft 365, Google Workspace, Salesforce, and other SaaS applications can be backed up in European data centers, regardless of the source platform. Have your SaaS workloads and recovery requirements systematically assessed.
FAQ: Microsoft 365 Backup and SaaS Data Backup
DOES MICROSOFT 365 EVEN NEED TO BE BACKED UP?
Yes. Microsoft is responsible for the availability of the platform, but not for the recoverability of customer data after user error, attacks, or deletion. Microsoft itself clarifies in its shared responsibility documentation that data and identities always remain the customer's responsibility.
IS OFFICE 365 BACKUP THE SAME AS MICROSOFT 365 BACKUP?
Yes, this refers to backing up the same services as Exchange Online, SharePoint, OneDrive, and Teams. Office 365 is the former name; Microsoft now markets most packages as Microsoft 365. Note: "Microsoft 365 Backup" is also the name of the native Microsoft service.
IS THE NATIVE MICROSOFT 365 BACKUP SUFFICIENT?
It's a useful first layer for Exchange Online, OneDrive, and SharePoint. Because it resides within the same provider environment and management layer, it doesn't replace a standalone copy. It doesn't cover other data types or SaaS services.
WHAT IS THE DIFFERENCE BETWEEN A RETENTION POLICY AND A BACKUP?
A retention policy prevents data from being permanently deleted and serves to ensure compliance. A backup allows the restoration of data, structures, and permissions to a specific point in time.
WHAT IS THE DIFFERENCE BETWEEN BACKUP AND DISTASTER RECOVERY?
A disaster recovery copy preserves the current state of data to bridge the gap caused by a data center outage, for example. A backup, on the other hand, allows the restoration of previous states, such as before deletion, misconfiguration, or encryption. Microsoft explicitly describes this distinction for Microsoft 365.
WHAT IS A CLOUD-TO-CLOUD BACKUP?
A backup method where data from a SaaS application is saved directly to a separate cloud environment, bypassing the on-premises data center. Crucially, the target environment and its management are separate from the source platform.
WHAT DATA NEEDS TO BE BACKED UP AT SALESFORCE?
In addition to data records and attachments, metadata such as object definitions, fields, workflows, and permissions are also lost. Without metadata, a complete recovery is virtually impossible.
DO I ALSO NEED TO BACK UP GOOGLE WORKSPACE?
Yes. Deleted Gmail and Drive data is permanently lost after 30 days in the trash and another 25 days via the admin console, even for Google. An independent backup also protects against attacks, user error, and account loss. Learn more in the article on backing up Google Workspace.
DOES A SaaS Backup Protect Against Data Theft?
No. A backup restores lost or manipulated data, but it doesn't prevent its leakage. That's what access control, permissions management, and monitoring are for.
DO I ALSO NEED TO BACK UP ENTRA ID OR OKTA?
Yes, if access to business-critical applications depends on them. Deleted or manipulated users, roles, and access policies can cripple operations just as much as lost files. An independent backup makes it possible to selectively restore individual configurations to a previous state.
Note: AI-powered tools were used to assist in the creation of this article. Research, editorial review, and content responsibility lie with the editors of Cristie Data.
