SaaS Configuration Backup and Recovery Guide

SaaS backup products protect mailboxes, files and records, but almost none of them can put back a transport rule, a Teams external access policy or a Salesforce permission set that an attacker changed last night. Tenant configuration lives in the provider's control plane, it changes in place, and the native audit trail tells you what changed without keeping a copy you can restore from. This guide covers configuration backup and recovery for the workloads around the identity provider: Exchange Online, Teams, Intune, Purview and SharePoint in Microsoft 365, Google Workspace, and Salesforce. It explains the native tools, the config-as-code options, how to detect malicious drift, and a tested restore sequence. It is for SaaS platform owners, identity engineers and resilience leads; for Entra ID and Okta specifically, see the IdP configuration backup and restore for Entra ID and Okta.

Key takeaways

Data backup is not configuration backup. Mailbox, OneDrive and CRM record backup restores content; it does not restore the policies, rules, connectors and permissions that decide who can reach that content.
Native snapshots are short lived. Microsoft Graph tenant configuration management keeps a snapshot for a maximum of seven days, so anything you need for a longer look-back must be exported and stored outside the tenant.
Audit logs say what changed, not what it was. Google's Admin log events record old and new values for six months, and Salesforce's SetupAuditTrail covers at least 180 days, but neither gives you a restorable copy of the whole configuration.
Config-as-code is the restore path. A versioned export in Git, compared on a schedule and reapplied through the same tooling, is the only way to roll back a malicious change at scale with evidence of what was restored.
The export identity is a crown jewel. A service principal that can read and write tenant configuration is exactly what attackers target, as the ConnectWise Cloud Backup incident showed in October 2026.

What attackers change, and why it matters for recovery

Once an attacker holds an administrator or a privileged application, configuration changes are how they persist, hide and widen access. Most of these changes survive a password reset, which is why they must be found and reversed during recovery rather than left to the next audit.

Configuration target	Example malicious change	ATT&CK technique	What a restore needs
Mail flow (Exchange transport rules, Gmail routing)	Rule that BCCs finance mail to an external address	T1114.003 Email Forwarding Rule	Known-good rule set to compare against and reapply
Mailbox and inbox rules	Rule that moves security alerts to a hidden folder	T1564.008 Email Hiding Rules	Rule inventory per mailbox; delete rather than restore
Tenant policies (sharing, external access, domain federation)	External sharing opened to anyone; a new federated domain	T1484 Domain or Tenant Policy Modification, T1484.002 Trust Modification	Previous policy values with timestamps
Access policies	Conditional Access exclusion for an attacker location	T1556.009 Conditional Access Policies	See the IdP guide; restore with the IdP baseline
Application credentials and roles	New secret added to an existing app; app added to an admin role	T1098.001 Additional Cloud Credentials, T1098.003 Additional Cloud Roles	App and role assignment baseline; credential reissue, never restore
Salesforce setup (profiles, permission sets, connected apps, sharing rules)	Permission set granting "View All Data" assigned to an integration user	T1098.003 Additional Cloud Roles	Metadata in source control, deployable

The Microsoft Midnight Blizzard Breach is the clearest example of configuration as persistence: an OAuth application in a forgotten test tenant was used to create further applications and grant them access to corporate mailboxes. A configuration baseline for applications and their permissions is what turns that from a months-long investigation into a diff.

What each platform gives you natively

Every major SaaS platform provides change history. Few provide a restore. The table summarises the native capabilities as documented by each provider, checked November 2026.

Platform	Native capability	Retention or limits	Can it restore?
Microsoft 365: tenant configuration management (TCM) in Microsoft Graph v1.0	configurationSnapshotJob extracts current configuration across Defender, Entra, Exchange Online, Intune, Purview and Teams; configurationMonitor compares against a baseline and records drifts	Snapshots kept up to 7 days; 20,000 resources per tenant per month; up to 30 monitors, run every 6 hours, 800 resources per day per tenant; resolved drifts deleted after 30 days	No. Microsoft says drifts are resolved "by using the relevant admin centers or other available methods"
Microsoft 365: Purview audit	Admin activity across workloads	Audit (Standard) 180 days; Audit (Premium) one year for Exchange, SharePoint, OneDrive and Entra records of E5-licensed users	No, history only
Google Workspace: Admin log events	Actor, event, setting name, organisational unit, old value and new value	Six months; export up to 100,000 rows to Sheets or CSV	No, history only
Salesforce: Setup Audit Trail (SetupAuditTrail object)	Setup changes with action, section and description	At least the last 180 days	No, history only
Salesforce: Metadata API	Retrieve and deploy customisation such as object definitions, layouts, profiles and permission sets	Not every feature is exposed: Salesforce documents that some metadata types are not available in the Metadata API	Yes, by redeploying retrieved metadata

A seven-day snapshot only helps if the change is found within a week, and audit history gives the old value of one setting at a time, which does not scale to fifty changes.

Config-as-code options by platform

Microsoft 365 workloads

Microsoft365DSC: an open-source PowerShell Desired State Configuration module maintained in Microsoft's GitHub organisation. Export-M365DSCConfiguration takes a snapshot of an existing tenant as a DSC configuration file, which you commit to Git. The same configuration can be applied to bring a tenant back to that state, and the DSC Local Configuration Manager can monitor for drift, logging each drift in the M365DSC event log journal, or correct it automatically in ApplyAndAutocorrect mode.
Authentication caveats: the project recommends a service principal, and notes that MFA on user credentials is not supported for unattended runs. Supported methods differ by workload, and the export skips components that cannot be reached with the chosen method (Security and Compliance, for example, does not accept an application secret). Check what was skipped on every run, or your backup silently misses a workload.
TCM snapshots as a second source: schedule configurationSnapshotJob runs and download the result before the seven-day expiry. Keep the TCM output separate from Microsoft365DSC exports, so a fault in one tool does not corrupt both copies.

Google Workspace

No first-party configuration export: Google provides audit history and APIs, not a tenant snapshot. CISA's ScubaGoggles uses the Admin SDK API to export relevant settings to JSON and compares them with the SCuBA baselines using OPA Rego. Its JSON output, kept in Git, works as a settings record even though its purpose is assessment.
Terraform: the HashiCorp Google Workspace provider is archived, with no new releases and issues not monitored. Do not build a new restore path on it; if you already use it, plan a replacement.
Restore is manual or scripted per API: for most Admin console settings the realistic restore is to reapply the old value from the Admin log event or the exported record, through the Admin console or the relevant Admin SDK API. Write a runbook per critical setting group (sharing, routing, third-party app access, domain-wide delegation).
Domain-wide delegation: treat the list of delegated client IDs and scopes as configuration and baseline it. See the Google Workspace Domain-Wide Delegation Security Guide.

Salesforce

Metadata in source control: generate a manifest with sf project generate manifest, pull metadata with sf project retrieve start and commit it. Salesforce describes the Metadata API's main purpose as moving metadata between orgs, which is exactly what a restore is: moving known-good metadata back into a changed org.
Preview before deploying: sf project deploy preview shows what would deploy and the conflicts, before sf project deploy start applies it. Restore into a sandbox first when the change set is large.
Coverage gaps: check the Metadata Coverage report for the setup areas you care about. Anything not in the Metadata API needs a manual runbook and a screenshot or export record.
Integration users and connected apps: include permission sets, connected app and external client app definitions in the baseline. See How to review Salesforce connected apps and integration users.

Choosing an approach

Approach	Strength	Weakness	Best fit
Native snapshots and audit only	No extra tooling or privileged identity	Seven-day or six-month horizon; no bulk restore	Small tenants with few administrators and no regulatory restore target
Scheduled exports to Git (read only)	Long history, diffable, low privilege	Restore is manual from the diff	Most organisations as a first step
Full config-as-code (export, review, apply)	Bulk, repeatable restore with change review	Write-capable identity; tooling drift as APIs change	Large or regulated tenants, multi-tenant estates
Commercial SaaS configuration backup	Supported coverage and restore UI	Supplier holds tenant-wide access to your control plane	Teams without engineering capacity; assess the supplier as a privileged third party

Small versus large: a small organisation gets most of the value from a weekly read-only export of the top twenty settings into a private repository, plus forwarding of admin audit logs to a store with longer retention. A large organisation should separate the read identity (daily export) from the write identity (restore), keep the write identity disabled until a restore is approved, and run drift monitoring continuously. When buying, see the SaaS Backup Buyer's Guide and ask specifically about configuration objects, not only data.

Restoring after a malicious change: a tested sequence

Contain the actor first. Revoke sessions and credentials for the compromised administrator or application before restoring anything, or the attacker re-applies their change. Follow the Identity Incident Response Playbook.
Freeze the evidence. Export the current, changed configuration and the relevant audit records before you touch anything. The diff between this and your baseline is the scope of the incident.
Choose the restore point. Pick the last baseline taken before the earliest malicious change in the audit trail, and verify its integrity (commit signature, hash, repository access log) before using it, as NIST CSF 2.0 RC.RP-03 expects.
Review the diff, line by line. Separate malicious changes from legitimate changes made since the baseline, so you do not roll back a week of genuine work. Record the decision for each item.
Restore in priority order. Identity and access policies first (with the IdP baseline), then mail flow and forwarding, then sharing and external access, then application roles and permissions, then everything else.
Reissue, do not restore, credentials. Any application secret, certificate or token touched by the attacker is replaced with a new one. A restored secret is still a stolen secret.
Validate. Run the export again and diff it against the chosen baseline; run ScubaGear or ScubaGoggles to confirm security settings meet your baseline; check that business flows (mail delivery, integrations) still work.
Raise the drift alarm threshold. Watch the restored objects closely for 30 days, since a re-applied change means the actor still has access somewhere.

Testing and rollback: rehearse the sequence in a test tenant or Salesforce sandbox at least twice a year, including a deliberate malicious change made by the red team. Every restore run must itself be reversible: keep the pre-restore export so a wrong restore can be undone. See the Backup and Recovery Testing Checklist.

Detection and measurement

Forward audit logs: stream Purview audit, Google Admin log events and SetupAuditTrail into your SIEM, so history outlives the native retention of 180 days or six months.
High-signal changes to alert on: new or changed transport and forwarding rules, new federated domains or trust changes, new credentials on existing applications, application role assignments, changes to external sharing defaults, and Salesforce permission set assignments that include broad data access.
Drift comparison: run the export on a schedule and diff it against the approved baseline in Git; any diff without a matching change ticket is an incident candidate.

Metric	What good looks like (NHI Mgmt Group recommendation)
Configuration baseline age	Under 24 hours for critical workloads, under 7 days for the rest
Workload coverage	Share of in-scope workloads with a successful export, with skipped components listed and explained
Unexplained drift	Number of diffs per month with no matching change record, trending down
Restore test success	Last rehearsal date and time to restore the top twenty settings
Export identity hygiene	Credential age, role scope and sign-in locations for each backup identity, reviewed monthly

Where identity fits

Configuration backup only works through a non-human identity with tenant-wide read rights, and restore needs write rights. That identity is one of the most privileged in the estate. In the ConnectWise Cloud Backup Breach 2026, an attacker used the backup application's own credential to sign in to customer Microsoft 365 tenants with no user involved, and related service principals gave themselves directory roles. Apply the same controls you would to any privileged machine identity: certificate or workload identity federation instead of client secrets, separate read and write identities, the write identity disabled by default, sign-in location restrictions, and alerts on any role or credential change. Store exports in a repository with its own access control, because a configuration export maps your defences for an attacker. See the Backup Identity Isolation Guide.

Common failure patterns

Assuming the data backup covers settings: the mailbox restores but the forwarding rule that leaked it comes back with it, or the policy that allowed the leak was never recorded.
Silent partial exports: an authentication method that one workload does not accept means that workload is skipped, and nobody reads the warning.
Relying on seven-day snapshots: the malicious change is found on day twenty, and the only native copy has already been deleted.
Restoring without containment: the attacker's application still holds a valid credential and re-applies its change within hours.
Building on archived tooling: restore pipelines built on an unmaintained provider fail when the underlying API changes, usually during the incident.
Over-privileged, always-on backup identity: a single app with tenant-wide write access and a long-lived secret becomes the attacker's route in.

Framework mapping

Framework	Reference	How configuration backup supports it
NIST CSF 2.0	PR.PS-01, PR.DS-11, ID.RA-07, DE.CM-09, RC.RP-03	Configuration management, backups created and tested, changes tracked, monitoring, backup integrity verified before restore
NIST SP 800-53 Rev 5	CM-2, CM-3, CM-6, CP-9, CP-10, AU-6, SA-9	Baseline, change control, settings, backup, recovery, audit review, external services
ISO/IEC 27001:2022 Annex A	5.23, 8.9, 8.13, 8.32	Cloud services security, configuration management, information backup, change management
CIS Controls v8.1	Control 4, Control 11	Secure configuration of enterprise assets and software; data recovery
MITRE ATT&CK	T1484, T1484.002, T1556.009, T1114.003, T1564.008, T1098.001, T1098.003	Configuration changes attackers make that a baseline exposes

Practitioner checklist

List every SaaS workload in scope and the configuration objects that matter in each.
Schedule a read-only configuration export to Git for each workload and check skipped components on every run.
Download Microsoft TCM snapshots before their seven-day expiry if you use them.
Forward Purview, Google Admin and Salesforce setup audit logs to storage that outlives native retention.
Alert on forwarding rules, trust changes, new app credentials, role assignments and sharing changes.
Separate read and write backup identities, use certificates or federation, and keep the write identity disabled until needed.
Write a restore runbook per platform, with containment first and credential reissue instead of restore.
Rehearse a restore from a simulated malicious change in a test tenant or sandbox twice a year.
Replace any restore tooling that depends on an archived or unmaintained provider.

SaaS Configuration Backup and Recovery: Restore Tenant Settings After Malicious Change