SaaS providers keep their platforms running, but recovering your data after deletion, corruption or a malicious admin is still your job. Microsoft's shared responsibility model states that for all cloud deployment types the customer owns its data and identities, and native recycle bins, retention policies and short admin restore windows were not built to bring back a whole tenant on a known date. This guide helps buyers evaluate purpose-built SaaS backup for Microsoft 365, Google Workspace and Salesforce. It is vendor-neutral and written for security, IT and resilience teams running a selection or a renewal.
Key takeaways
- Retention is not backup. Microsoft Purview retention keeps copies in places such as the Preservation Hold library and Recoverable Items to prevent permanent deletion, but it does not give you point-in-time restore of a site or mailbox.
- Native windows are short and coarse. A Google Workspace admin can restore Drive files only within 25 days after a user empties the trash, and only by date range, not file by file.
- The backup app is a powerful non-human identity. It usually holds tenant-wide read and write permissions through an app registration or connected app, so its credentials need the same protection as an admin account.
- Restore speed decides the outcome. Test bulk restores against your recovery time objective, not just single-file restores in a demo.
- Isolation matters as much as copies. Ask where the copy lives, who can delete it and whether it survives the loss of your tenant or your vendor account.
Define requirements
Start from the incidents you need to recover from, not from a feature list. Typical scenarios are a user or script deleting data, a ransomware-encrypted OneDrive sync, a malicious or compromised admin purging mailboxes, a bad Salesforce data load or deployment that overwrites records and metadata, and an attacker with a stolen integration token wiping or altering CRM data.
- Scope: list every workload. For Microsoft 365 that is Exchange Online, OneDrive, SharePoint and Teams; for Google Workspace, Gmail, Drive and shared drives, Calendar and Contacts; for Salesforce, data, metadata, files and attachments across production and sandboxes.
- Recovery point objective (RPO): how much change you can lose. Salesforce's own Backup and Recover offers automated daily backups plus on-demand runs, and continuous capture only as an add-on, so decide whether daily is enough for high-change objects.
- Recovery time objective (RTO): how fast you need 1, 100 and 1,000 users or sites back. Ask for measured figures at your data volume.
- Retention: align with legal and records requirements. Long retention in a backup is not a substitute for eDiscovery holds, and the two should be designed together.
- Data residency and sovereignty: where copies are stored, and whether the vendor or a sub-processor can read them.
- Identity and access: how the tool authenticates to each SaaS platform and how your operators authenticate to the tool.
See the Business Continuity and Disaster Recovery Guide for setting RPO and RTO by business service.
Capability areas
| Platform | Native recovery you already have | Gap a SaaS backup tool should close |
|---|---|---|
| Microsoft 365 | Recycle bins, Recoverable Items, Purview retention policies and labels; Microsoft 365 Backup as a separately enabled service for Exchange, OneDrive and SharePoint | Teams and other workloads outside native backup scope, copies outside the Microsoft trust boundary if required, cross-tenant restore, unified reporting |
| Google Workspace | User trash, admin Drive restore within 25 days of trash being emptied (20 days after account deletion), Google Vault holds and export | Item-level restore, restore beyond 25 days, restoring Vault-held data back into Drive (Vault exports but does not restore) |
| Salesforce | Recycle Bin, data export, Salesforce Backup and Recover as a separately priced product | Metadata and data restored together with relationships intact, comparison of snapshots, sandbox seeding, coverage of connected platforms |
- Granular and bulk restore: single item, folder, mailbox, site, object or record set, plus whole-tenant or whole-org restore, in place or to an alternate location.
- Point-in-time selection: choose a restore point from before an incident started, and compare snapshots to see what changed. Salesforce calls this Data Compare in its own product.
- Relationship-aware restore for CRM: parent-child records, lookups and metadata must be restored in the right order without overwriting valid data added since.
- Immutable, isolated storage: the backup copy should be append-only or locked for a set period, and stored in a separate security boundary from the tenant it protects. Microsoft describes its own Microsoft 365 Backup copies as immutable and append-only, but they stay inside the Microsoft 365 trust boundary, which is a design choice to evaluate against your threat model.
- Anomaly detection: alerts on mass deletion, mass encryption or unusual change rates, which also help pick a clean restore point.
- Least-privilege connector: the narrowest API permissions the platform allows, separate apps per workload where possible, and certificate or federated credentials instead of long-lived client secrets.
See the Backup Security and Immutable Backup Guide for immutability and isolation patterns.
Evaluation criteria
| Criterion | What good looks like | How to verify |
|---|---|---|
| Coverage | All workloads in scope, including Teams chats and channels, shared drives, Salesforce metadata and files | Coverage matrix per workload, with documented API limitations |
| RPO | Backup frequency that meets your target per workload, with throttling behaviour disclosed | Backup job history during the proof of concept |
| RTO | Measured bulk restore rates at your volume | Timed restore of a large mailbox set, site collection or object set |
| Immutability and isolation | Copies cannot be deleted or shortened by a tenant admin or by a single vendor console user | Attempt deletion with a test admin; read the contractual retention terms |
| Connector identity | Least privilege, certificate or federated credential, IP or Conditional Access restriction, documented rotation | Inspect the app registration or connected app in your tenant |
| Operator access | SSO, phishing-resistant MFA, role separation for restore and delete, approval for destructive actions | Review roles and test a second-person approval |
| Encryption and keys | Encryption at rest with an option for customer-managed keys where required | Key management documentation and audit evidence |
| Audit and export | Logs of every backup, restore, export and policy change, streamable to your SIEM | Pull logs during the proof of concept |
| Exit | Bulk export of backup data in a usable format if you leave | Contract clause and a test export |
Where identity fits
A SaaS backup tool reads, and often writes, every mailbox, site and record in your tenant. Its app registration, OAuth grant or Salesforce connected app is one of the most privileged non-human identities you own. The Commvault Metallic breach showed the risk: an attacker exploiting CVE-2025-3928 in the vendor's Azure environment may have obtained a subset of the client secrets used to reach customers' Microsoft 365 tenants. CISA's mitigations focused on the customer side: rotate the secrets, apply Conditional Access to the app, restrict sign-ins to the vendor's IP ranges and monitor Entra audit and sign-in logs for credential changes. In ATT&CK terms this is token theft and reuse (T1528 Steal Application Access Token, T1550.001 Application Access Token). See the SaaS API Token Security Guide and the SaaS and OAuth App Governance Guide.
Questions to ask vendors
- Exactly which API permissions does your connector request for each workload, and why each one?
- Does the connector authenticate with client secrets, certificates or workload identity federation, and who holds and rotates that credential?
- Is the connector app single-tenant in our directory or a multi-tenant app you control? Can we restrict its sign-ins by IP or Conditional Access?
- Where are backup copies stored, in which regions, and in a separate security boundary from our tenant?
- Can any of your staff, or any of our admins, delete or shorten retention on backup copies? What approval is needed?
- What measured restore throughput do you achieve for 1,000 mailboxes or sites of our average size?
- How do you handle platform API throttling, and how is a backup that falls behind reported?
- For Salesforce, do you restore metadata and data together and preserve relationships when restoring a subset?
- How did you respond to your last security incident, and how quickly did you notify customers?
- How do we get our data out in bulk if we end the contract?
Red flags
- Connector asks for global admin or broad write permissions where read access and a separate restore permission would do.
- Long-lived client secrets with no rotation process and no option for certificates.
- Backup copies that a single admin account, in your tenant or the vendor console, can delete immediately.
- Restore demonstrations limited to one file or one email, with no bulk figures.
- Vague answers on where data is stored or which sub-processors can access it.
- No audit log export, or audit logs that omit restores and exports.
- Treating native retention or archiving as equivalent to backup in sales material.
Proof of concept
- Create a test tenant or sandbox org and a representative data set: mailboxes, OneDrive and SharePoint sites, Teams, shared drives and Salesforce objects with relationships and metadata.
- Connect the tool using the least-privilege option and record every permission granted. Review the app in your identity provider.
- Run a full backup and a few incremental cycles. Record duration, throttling and failures.
- Simulate incidents: mass deletion by a script, encryption of synced files, purge of a mailbox by an admin and an overwriting Salesforce data load.
- Use change reports or anomaly alerts to pick a clean restore point, then restore in place and to an alternate location. Time every restore.
- Try to delete backup copies or shorten retention with a test admin account, and confirm the attempt is blocked or needs approval and is logged.
- Rotate the connector credential and confirm backups continue. Export logs to your SIEM.
- Run a bulk export to test exit terms. Remove the connector and confirm its permissions and credentials are gone.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support. Browse vendors in our NHI and AI products directory or contact us.
Related NHI Mgmt Group resources: Backup and Cyber Recovery Buyer's Guide · SaaS Security Buyer's Guide · Microsoft 365 Security Guide · Google Workspace Security Guide · Salesforce Security Guide