Ask most infrastructure teams what their backup strategy covers and they will describe virtual machines, databases and file shares, increasingly protected with immutable cloud vaults. That was a reasonable scope a decade ago. In 2026, a large share of the data and configuration a business needs to operate lives elsewhere: in collaboration suites and CRM platforms, in the identity system that controls access to everything, and in a fast-growing set of AI assets such as vector indexes, prompt libraries, fine-tuned models and agent configurations.
This article explains why backup scope has to expand, what the shared responsibility model really means for SaaS and identity, how to protect AI-era data, and how to build a program that can restore what matters in the order the business needs it.
Why Traditional Backup Scope Falls Short
Three shifts have changed what “critical data” means. First, business processes have moved into SaaS. Sales pipelines live in CRM, documents and conversations live in collaboration suites, and HR, finance and service management increasingly run on SaaS platforms. Second, identity has become the control plane for the enterprise. If your directory, conditional access policies or application registrations are deleted or corrupted, nobody can reach the systems you so carefully backed up. Third, AI applications introduce new data types that are expensive to rebuild: embeddings generated from millions of documents, curated evaluation sets, model weights and the configuration that defines how agents behave.
Attackers have noticed. Google Cloud’s H1 2026 Threat Horizons Report notes that major ransomware groups were deleting logs and backups in late 2025 to hinder recovery. TechTarget’s analysis of SaaS shared responsibility describes a 2025 social engineering campaign against Salesforce customers in which data was extracted, and notes that organizations without independent backups faced paying a ransom or accepting permanent loss. Destructive attacks increasingly target whatever is easiest to destroy and hardest to restore.
The Shared Responsibility Gap in SaaS
SaaS providers are responsible for running the platform: availability, infrastructure security and the durability of their storage. They are generally not responsible for protecting you from your own users, compromised accounts, misconfigured integrations or malicious deletion. TechTarget’s summary puts it plainly: the customer remains responsible for its data.
Native retention features help, but they are operational safety nets rather than backup. TechTarget cites Microsoft’s defaults as an example: deleted Exchange Online items are retained for 14 days by default, configurable up to 30, and SharePoint and OneDrive recycle bin items for 93 days. After that, data may be gone. Retention policies and legal holds can preserve content for compliance, but they are not designed for fast, granular, point-in-time restoration after a mass deletion or ransomware event.
Providers have responded by adding native backup products, such as Microsoft 365 Backup and Salesforce’s own backup offering, alongside a large market of third-party SaaS backup platforms. The decision is no longer whether SaaS backup is possible, but which approach gives you independence, recovery speed and coverage across all the SaaS platforms you depend on.
Identity: The System You Must Restore First
Identity is the dependency underneath every recovery plan. If an attacker or a faulty automation script deletes groups, modifies conditional access policies or removes application registrations, users and workloads lose access even though the data behind them is intact.
Microsoft’s move into this space illustrates the trend. According to Microsoft 365 for IT Pros, Microsoft quietly released a preview of Entra ID Backup and Recovery to tenants in March 2026. The preview backs up core tenant objects, including users, groups, applications, service principals, conditional access policies, authentication methods and named locations, once a day, keeping five rolling backups. The same review highlights limitations at preview stage: hard-deleted objects cannot be recovered, difference reports can be slow, and large recoveries can take many hours. Microsoft has indicated that recovering 500,000 changes may take up to 30 hours.
The lesson is not to rely on any single mechanism. A robust identity recovery strategy typically combines:
- Configuration as code for conditional access, application registrations and role assignments, so known-good state can be redeployed.
- Native backup and soft-delete features for rapid rollback of recent changes.
- Independent exports or third-party backups with longer retention, stored outside the tenant’s administrative blast radius.
- Protected actions and privileged access controls that make destructive changes harder in the first place.
- Break-glass accounts excluded from conditional access and monitored closely, so administrators can sign in during an identity incident.
The same principles apply to other identity providers and to cloud IAM configuration in AWS, Azure and Google Cloud, which should be captured in version-controlled infrastructure as code.
Protecting AI-Era Data
AI applications create new categories of data that many backup programs do not yet recognize. Before designing protection, classify each by how hard it is to rebuild:
- Source documents and training data: usually covered by existing backups, but confirm that curated datasets, labels and lineage metadata are included.
- Vector indexes and embeddings: technically reproducible from source data, but re-embedding large corpora can take days and cost significant compute. For critical retrieval applications, back up indexes directly or keep snapshots.
- Fine-tuned model weights and adapters: store in versioned, immutable object storage with replication, alongside training configuration.
- Prompts, system instructions, tool definitions and agent configuration: manage in source control and treat as code.
- Evaluation datasets and test results: often painstakingly curated and essential for safely redeploying models after an incident.
- Conversation and memory stores: may contain personal data, so balance retention for recovery with privacy obligations.
Also consider integrity, not just availability. Data and model poisoning appear in the OWASP Top 10 for LLM Applications. If a retrieval index or training set is tampered with, you need to know which point-in-time copy is clean, which argues for immutable, versioned backups with change history.
Back up what is hardest to rebuild, restore identity first, and keep at least one copy outside the administrative reach of the system it protects.
A Practical Program: Step by Step
- Inventory critical services and their data. List every SaaS platform, identity system and AI application the business depends on, with an owner and a criticality tier.
- Map responsibilities. For each platform, document what the provider covers, what native features you have licensed, and the gaps, as TechTarget recommends, by reading contracts rather than marketing material.
- Define recovery objectives per tier. Set recovery point and recovery time objectives for each service, and a restoration order that starts with identity, then core communication and collaboration, then revenue-critical systems.
- Choose protection mechanisms. Combine native features, independent backup platforms and configuration as code. Favor solutions that store copies outside the source tenant, support immutability and offer granular and bulk restore.
- Map retention to obligations. Compare regulatory and contractual retention requirements with vendor defaults and close the gaps, coordinating with legal and privacy teams.
- Secure the backup plane. Use separate administrative identities for backup systems, require multi-factor authentication and multi-person approval for deletion, and monitor for suspicious changes to backup policies.
- Test restores regularly. Run granular restores monthly and at least one large-scale scenario, such as a mass mailbox deletion or a corrupted conditional access configuration, each year.
- Assign executive ownership. Make one leader accountable for backup coverage across infrastructure, SaaS, identity and AI.
Setting Recovery Tiers for SaaS, Identity and AI
Recovery objectives for SaaS and identity are often left undefined because teams assume the provider handles availability. But availability of the platform is not the same as recoverability of your data and configuration. A simple tiering model makes expectations explicit and drives tool choices:
- Tier 0, foundational: identity provider configuration, privileged access, break-glass accounts and the backup platform itself. Target recovery within hours, with configuration restorable from code and independent copies.
- Tier 1, business-critical: email, collaboration and messaging, CRM and any SaaS that directly supports revenue or customer service. Aim for recovery of individual items within minutes and of whole workloads within a day, with daily or more frequent recovery points.
- Tier 2, important: customer-facing AI assistants, internal knowledge search, project tools and departmental SaaS. Accept longer recovery times, but document whether you will restore from backup or rebuild, and how long rebuilding takes.
- Tier 3, deferrable: experimental AI applications, sandboxes and tools with easy workarounds. Basic protection and a documented rebuild path are usually enough.
Two details deserve attention when setting these tiers. First, SaaS restore throughput is often limited by provider API throttling, so the time to restore thousands of mailboxes or sites may be far longer than the time to back them up. Ask vendors for evidence of restore rates at your scale and test them yourself. Second, dependencies matter as much as individual objectives. An AI assistant cannot be restored usefully until identity, the document store and the vector index are all back, so write recovery runbooks around end-to-end services rather than individual components, and record the order explicitly so that the on-call team does not have to work it out under pressure.
Evaluating SaaS Backup Options
When comparing native and third-party options, focus on recovery outcomes rather than feature lists. Useful questions include:
- Where are backup copies stored, and are they outside the source tenant’s administrative control?
- Is immutability enforced, and who can shorten retention or delete backups?
- How quickly can the tool restore a single item, a single user and an entire workload at scale?
- Which applications are covered, and how quickly does coverage follow new features?
- Can restores go to an alternative location or tenant for clean recovery after compromise?
- Does it support data residency requirements and provide audit logs for compliance?
- What does it cost at your data volume and retention, including restore and egress charges?
Hypothetical Worked Example: A Professional Services Firm
Consider a hypothetical professional services firm with about 3,000 staff. Its infrastructure backup program is mature, with immutable vaults for cloud VMs and databases. But its client work lives in a collaboration suite, its pipeline in CRM, and a new AI knowledge assistant answers staff questions from an index of past engagement documents.
A tabletop exercise exposes the gaps. In the scenario, an attacker compromises a privileged account, deletes thousands of documents, modifies conditional access to lock out administrators and deletes the vector index. Native recycle bins would recover many documents, but not at the required speed or with confidence. No independent copy of the identity configuration exists, and rebuilding the index from source would take several days of compute.
The resulting program adds an independent SaaS backup service for collaboration and CRM data with immutable storage, exports conditional access and application configuration to version control and uses native identity backup for rapid rollback, snapshots the vector index weekly with change logs, and stores agent prompts and tool definitions in source control. Restoration order is documented: break-glass access and identity, then collaboration, then CRM, then the AI assistant. A follow-up exercise confirms each step can be executed by the on-call team.
Pitfalls to Avoid
- Assuming SaaS providers back up your data for you.
- Confusing retention and legal hold features with recoverability.
- Backing up data but not configuration, leaving you unable to rebuild access and integrations.
- Storing backups under the same administrative identities an attacker would compromise.
- Ignoring AI assets until a rebuild proves slow and expensive.
- Never testing large-scale restores, then discovering throttling limits during an incident.
Outlook: Where Backup Scope Is Heading
Over the next few years, expect backup to become “data resilience” in the broadest sense: covering infrastructure, SaaS, identity, configuration and AI assets under one policy framework. Native identity and SaaS backup features from major providers will mature, but independent copies will remain important for clean recovery after compromise. Regulations such as DORA, NIS2 and sector rules for operational resilience will keep pushing organizations to prove they can restore critical services, not just that backups exist. And as AI agents take on operational tasks, their configuration and memory will become recovery-critical in their own right.
Conclusion
A backup strategy that stops at VMs and databases no longer protects the business. Extend scope to SaaS platforms, identity configuration and AI assets; understand exactly what providers do and do not cover; keep independent, immutable copies; restore identity first; and test realistic scenarios. The organizations that do this will recover in hours from incidents that leave others rebuilding for weeks.
How Hanoi Technology Can Help
Hanoi Technology helps organizations extend backup and recovery to SaaS, identity and AI assets, design restoration runbooks and test them regularly.