SaaS Outage Continuity: Keep Critical Work Running When SaaS Fails

When a critical SaaS platform is unavailable, most organisations discover that their continuity plan assumed the data and the process lived somewhere they controlled, and neither does. CRM, ERP, ticketing, HR, payments and collaboration platforms now carry core business processes, and an outage at the provider, a provider side security incident or a problem with your own tenant can stop those processes for hours or weeks. The provider is responsible for restoring its service; the customer is responsible for keeping its own business running in the meantime. This guide covers dependency mapping for non identity SaaS, deciding which processes need a fallback, data exports you can actually use offline, fallback procedures, running an outage, recovery and reconciliation, and testing. It is written for business continuity managers, IT service owners, security leaders and SaaS administrators. Identity provider outages are covered in the Emergency Identity Operations When the Primary IdP Is Unavailable, and long, organisation wide loss of IT in the Degraded-Mode Operations and Manual Workarounds Guide.

Key takeaways

• Map processes to platforms, not platforms to vendors. Start from the business process (take an order, pay staff, answer a customer) and trace every SaaS platform, integration and identity it depends on, including the hidden ones.
• Set tolerances the business has agreed. For each critical process, agree how long it can be down and how much data it can lose, then compare those numbers with what the provider commits to.
• Exports must be usable without the platform. A backup that can only be restored into the same service helps with deletion and ransomware, not with an outage. Keep a current, readable copy of the data each fallback needs.
• Fallbacks are procedures, not intentions. Write down who does what, with which form, spreadsheet or alternative tool, and practise it with the people who will do it.
• Plan the return as carefully as the outage. Back entry, reconciliation, duplicate prevention and integration replays cause as many problems as the outage itself.

Outage scenarios and what each one changes

SaaS outages are not all the same. The scenario decides which fallback works, so plan for at least these five.

The third scenario is the one most plans underestimate. When a provider disconnects its systems to contain an attack, customers can lose the service for weeks, and the provider's recovery priority may not match yours. Provider concentration also matters: several of your processes may depend on the same provider or the same underlying cloud. See the Third-Party Concentration Risk Guide and the Cloud Region Outage Resilience guide.

Mapping critical SaaS dependencies

Most organisations have a list of SaaS subscriptions. Few have a map of which business processes stop when one of them fails. NIST CSF 2.0 asks for both: GV.OC-05 (the outcomes, capabilities and services the organisation depends on are understood) and ID.AM-04 (inventories of services provided by suppliers are maintained).

1. Start from the business impact analysis: Take the processes the BIA marks as time critical. See the Business Impact Analysis Template.
2. Trace each process end to end: For each step, record the SaaS platform, the integration that feeds it, the identity provider that signs users in, and the people who do the work.
3. Find the hidden dependencies: Look for SaaS platforms used by a supplier on your behalf (payroll bureau, outsourced service desk), embedded services (payments, e-signature, mapping, messaging APIs) and shared foundations such as one cloud provider or one email service under several applications.
4. Record the provider facts: Instance or region, status page, notification subscription, support tier and escalation contacts, contractual availability commitment and incident notification terms.
5. Assign owners: Each critical SaaS dependency needs a business owner who decides on fallbacks and a technical owner who maintains exports and access.

Recovery tolerances and provider commitments

Agree a maximum tolerable period of disruption, a recovery time objective and a recovery point objective for each critical process, in business terms. Then compare them with what the provider offers. A monthly availability commitment describes average performance and usually offers service credits, not restoration of your business. The gap between your tolerance and what the provider can deliver is what your fallback has to cover.

• Contract terms to review: availability commitment and how it is measured, incident and security incident notification times, data export rights and formats during the contract and at exit, support response times by severity, and subprocessors the service relies on. See the Third-Party Security Contract Clauses Template.
• Regulated sectors: Financial entities in the EU must manage ICT third-party risk and plan exit strategies for critical services under DORA. See the DORA ICT Third-Party Risk and Register of Information Guide.
• Exit and continuity are linked: The export and fallback capability that lets you survive a long outage is the same capability you need to leave a provider. CSF 2.0 GV.SC-10 covers provisions for the end of a service agreement. See the Cloud Exit Plan Template.

Data exports that work offline

A continuity export has a different purpose from a backup. Backup protects against deletion, corruption and ransomware and is restored into the service. A continuity export is a current, readable copy of the specific data people need to keep working while the service is down. Many organisations need both. See the SaaS Backup Buyer's Guide for backup.

• Protect the export: Exports often contain personal and commercial data. Encrypt them, restrict access to named roles and apply retention rules. The export job's credentials (API keys, integration users) are non-human identities: give them read only scope and an owner. See the SaaS API Token Security Guide.
• Test readability: Open the export on a machine with no access to the SaaS platform and confirm a person can find what the fallback procedure needs.
• Watch for silent failure: Monitor export jobs and alert when one does not complete, because a stale export is often discovered only during the outage.

Provider features for status and data (examples, listed alphabetically)

Two widely used platforms illustrate the provider side settings customers should turn on. Each provider documents its own features; confirm details in the current documentation.

• Microsoft 365: Admins see incidents and advisories under Health then Service health in the Microsoft 365 admin center, and can set email notifications for chosen services. Microsoft describes an advisory as a problem affecting some users while the service remains available, and an incident as a critical problem where a service or major function is unavailable. If the admin center itself is unreachable, Microsoft points to the status page at status.cloud.microsoft. Microsoft 365 Backup restores OneDrive accounts, SharePoint sites and Exchange mailboxes within the Microsoft 365 data boundary, which supports recovery from deletion and ransomware; pair it with offline copies of the critical subset for outage continuity. See the Microsoft 365 Security Guide.
• Salesforce: Trust Notifications send near real-time emails about incidents and maintenance for the instances and products you choose, and anyone can self-subscribe, according to Salesforce's Trust Notifications guide. The Data Export Service produces a zip archive of CSV files weekly or monthly in Enterprise, Performance and Unlimited editions and monthly in other editions; Salesforce deletes the files 48 hours (weekends excluded) after the notification email, so automate collection to an owned store. See the Salesforce Security Guide.

Designing fallback procedures

For each critical process choose a fallback pattern that fits the tolerance and the scenario. Larger organisations usually combine them.

• Collaboration and messaging: Keep an out of band channel for the incident team that does not depend on the failed platform or the same identity provider, and agree it in advance. See the Incident Communication Plan Template.
• Security during fallback: Shadow tools adopted in a hurry create data protection and access problems. Pre approve the fallback tools, and keep sharing settings and access controls in place. Attackers also use outages for phishing that impersonates the provider, so warn staff to use only known status pages.
• Decision authority: Name who can invoke each fallback, at what elapsed time, and who can decide to switch provider temporarily.
• Small organisations: Focus on two or three processes, keep a weekly export and a one page manual procedure for each, and an agreed alternative channel. A full warm standby is rarely proportionate.

Running the outage

1. Detect and confirm: Use the provider's status feed and your own synthetic checks or user reports. Confirm whether the problem is provider wide, regional, your tenant only, or an integration.
2. Classify: Map the affected platform to processes through the dependency map and estimate time against tolerance.
3. Invoke fallbacks: Trigger the procedures whose tolerance will be breached, and start an outage log recording every manual transaction with a reference for back entry.
4. Communicate: Tell staff what to do, tell customers what to expect, and record provider updates with timestamps. Check whether the event triggers regulatory or contractual notifications, for example an incident affecting personal data or an incident at a critical ICT provider under DORA.
5. Escalate with the provider: Use the support tier and contacts recorded in the map. For a provider side security incident, ask what data and integrations are affected, whether credentials or tokens should be rotated, and what evidence the provider will share. See the Vendor SaaS Breach Response Playbook.
6. Review at set intervals: Reassess every few hours whether to move to a longer term fallback.

Recovery, reconciliation and back entry

• Confirm service health before switching back: Wait for the provider's restored status and verify your own tenant, data and integrations.
• Replay integrations in order: Queued messages and failed jobs should be replayed in a controlled sequence to avoid duplicates and out of order updates.
• Back enter manual transactions: Use the outage log references, check for duplicates and get a second person to reconcile totals for financial records.
• After a provider security incident: Rotate API keys, OAuth tokens and integration user credentials connected to the platform before reconnecting, and review audit logs for the period. See the SaaS integration token breach response guide.
• Close down fallbacks: Retire temporary tools and shared spreadsheets, move their data into the system of record and delete copies.

Detection and measurement

Framework mapping

ISO 22301 provides the management system for business continuity as a whole. See the ISO 22301 Business Continuity Guide and the Business Continuity and Disaster Recovery Guide.

Common failure patterns

• Backup mistaken for continuity: The data is protected, but only restorable into the platform that is down.
• Exports nobody collects: Scheduled exports are generated but expire before anyone downloads them, or run under an account that has since been deactivated.
• Status alerts go to one person: The only subscriber is on leave or has left.
• Fallback depends on the failed platform: The runbook, the contact list or the incident channel sits in the SaaS platform or behind the same identity provider.
• No back entry plan: Manual transactions are lost, duplicated or entered without a reference, so finance spends weeks reconciling.
• Integrations reconnected too early: After a provider security incident, tokens are not rotated before integrations resume.

Lessons from incidents

The Change Healthcare Breach 2024 shows what a long provider side outage means for customers. After ransomware was deployed in February 2024, Change Healthcare disconnected its systems to contain the attack, and pharmacies, hospitals and physician practices lost the ability to submit claims and check coverage, with disruption lasting weeks. The customer side lessons are the ones in this guide: know which processes depend on one provider, have an agreed alternative route or supplier for the most time critical ones, plan for cash flow during an extended outage, and rotate connections before reconnecting.

Practitioner checklist

• Map every BIA critical process to the SaaS platforms, integrations and identity services it depends on, with named business and technical owners.
• Record tenant instance or region, status page, support escalation path and contract terms for each critical platform.
• Subscribe at least two people per critical platform to the provider's status notifications.
• Agree recovery tolerances for each critical process and document the gap the fallback must cover.
• Automate continuity exports of the data each fallback needs to an encrypted store outside the provider, with failure alerts.
• Write a fallback procedure per critical process, including decision authority, tools and an outage log for back entry.
• Keep an out of band incident channel and offline copies of runbooks and contact lists.
• Exercise at least one SaaS outage scenario per year, including a multi week provider security incident.
• Rotate integration credentials and review audit logs before reconnecting after a provider security incident.

Standards and references

• NIST: SP 800-34 Rev. 1 Contingency Planning Guide for Federal Information Systems
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5
• NCSC: Principles of supply chain security
• Microsoft Learn: How to check Microsoft 365 service health
• Microsoft Learn: Overview of Microsoft 365 Backup
• Salesforce Help: Export Backup Data from Salesforce
• Salesforce: Trust Notifications Guide

Related NHI Mgmt Group resources: Emergency Identity Operations When the Primary IdP Is Unavailable · Degraded-Mode Operations and Manual Workarounds Guide · Third-Party Incident Response Playbook · Business Continuity Plan Template