Most organisations have a plan for getting a deleted document or mailbox back. Fewer have rehearsed what happens when the identity service that controls access to those applications is the thing that fails.

That gap matters as businesses move more day-to-day work into Microsoft 365, Google Workspace, Salesforce and other SaaS platforms. A backup can contain the data, but recovery still depends on people being able to authenticate, reach administration tools and restore the right configuration in the right order.

Keepit’s Annual Data Report 2026 offers a useful prompt for reviewing that dependency. The report is based on aggregated, anonymised backup and restore activity from Keepit’s production environment between 1 January and 31 December 2025. It is operational data rather than a survey, but it reflects activity within Keepit’s own customer environment and should not be read as a universal industry benchmark.

Three findings worth taking seriously

Keepit highlights three patterns in the report:

• Bulk recovery is being tested: nine in ten enterprises in the dataset had validated bulk recovery. That is an encouraging sign that many organisations are practising larger-scale recovery, not just assuming it will work.
• Identity recovery gets less attention: identity systems were tested around four times less often than productivity systems. That is a significant gap when identity is the control plane for access to other SaaS applications.
• Most restores are small and targeted: 90% of restores were single-file downloads. Everyday recovery is often about putting one item back quickly, rather than rebuilding an entire environment.

The takeaway is not that every business needs to run a full disaster-recovery exercise every week. It is that recovery testing should reflect the incidents teams are likely to face, while also covering the less frequent failures that could lock administrators out of everything else.

Why identity can become the recovery bottleneck

Identity platforms manage much more than usernames and passwords. They can control single sign-on, multifactor authentication methods, conditional access policies, group membership, privileged roles, application registrations and service principals used by integrations and automation.

If a user deletes a file, an administrator may be able to restore that file while the rest of the tenant keeps working. If a privileged identity is compromised, a conditional access policy is changed incorrectly, or a critical application registration disappears, the impact can spread across multiple services.

There is also a recovery dependency that is easy to miss: administrators may need the identity platform to sign in to the backup console, ticketing system, documentation repository or cloud management portal. If the identity service is unavailable or untrusted, a recovery plan that starts with “log in and restore” may not be usable.

That is why identity should be treated as part of the recovery sequence, not simply as another SaaS workload to protect.

Where Keepit’s product direction fits

Keepit’s product story is increasingly framed around protecting a trusted copy of business data that can be used for recovery and, over time, as a governed foundation for AI. In August 2026, the company announced AI Truth Cloud, organised around five pillars: Protect, Observe, Recover, Prove and Integrate.

Keepit described AI Connector Backup, its Model Context Protocol platform and AI Safe Room as core capabilities forming the immediate roadmap foundation. The announcement discusses protection for AI-related assets such as agent configurations, skills, projects and models, as well as ways to connect AI workflows to managed data. Buyers should confirm which of these capabilities are generally available, which are in development, and what is included in their specific subscription before treating them as deployable features.

Keepit also publishes protection services for business applications including Microsoft 365, Microsoft Entra ID, Salesforce, Google Workspace, Jira, Confluence and Okta. For an organisation, the practical question is whether the applications and data objects it relies on are covered at the level needed for a real recovery scenario.

A practical recovery checklist for IT teams

1. Map the dependencies. List the SaaS services that support critical business processes, then map the identity provider, SSO configuration, DNS, administrator accounts and integrations each one depends on. Include the systems used to access backup and recovery tools.
2. Test more than file restores. Keep granular tests for deleted files, messages and records, but add controlled exercises for bulk recovery and identity configuration. Include representative users, groups, privileged roles, authentication methods, conditional access policies and application registrations.
3. Prove you can get in during an identity incident. Validate break-glass accounts, offline runbooks and emergency access to backup tooling. Use credentials and administration paths that do not rely entirely on the identity service being tested.
4. Keep the recovery copy outside the production blast radius. Ask how backup data is isolated, whether it is immutable, who can administer or delete it, and whether production administrators can shorten retention or alter recovery points. Separate credentials and administrative control are as important as the storage location.
5. Measure recovery against business needs. Set realistic recovery time and recovery point objectives for each application. During exercises, record how long it takes to locate the right restore point, recover the data, validate permissions and dependencies, and return the service to users.
6. Review data location and handling. Ask where backup data is stored, who can access it for support, whether subprocessors are involved, how long data is retained, and how deletion and incident notification are handled. Organisations should assess any overseas transfer of personal data against the PDPA’s Transfer Limitation Obligation, and ensure reasonable protection and appropriate retention practices. A backup product does not by itself make an organisation PDPA-compliant.
7. Include AI-related data in the inventory. If teams use AI assistants or agents connected to SaaS applications, identify the configurations, prompts, project data, permissions and integration records that would be difficult to recreate. Ask vendors what is protected today and what remains on the roadmap.

Residency is not the same as recoverability

Keepit’s October 2026 writing on cloud sovereignty makes a useful distinction: knowing where data is stored and who controls the provider is not the same as knowing whether the organisation can restore data after an outage, compromise or accidental deletion. Its discussion of the proposed EU Cloud and AI Development Act is about a European policy proposal, not a legal requirement. The broader procurement lesson still applies here: evaluate both data control and the independence of the recovery path.

For buyers, that means asking not only where a backup resides, but also whether it is separately administered, protected from production credentials, recoverable if the primary identity service is down, and handled in line with the organisation’s own privacy and retention obligations.

Turn backup confidence into tested recovery

Keepit’s report points to a straightforward improvement: do not let identity recovery remain the part of the SaaS plan that nobody practises. Start with one critical workload, test a small set of identity objects in a controlled environment, and then run an exercise that follows the full sequence from emergency access through to application recovery.

That kind of rehearsal gives IT leaders something more useful than a green backup dashboard: evidence that people, access paths and recovery procedures can work together when the business needs them most.