SaaS outage: a business continuity plan

The CRM is unavailable. Employees cannot sign in to email. Files are visible, but nobody can download them. The provider reports “intermittent issues,” yet an hour later there is still no recovery estimate.

This is often when a company discovers that its continuity plan covers only the servers it operates directly. Sales, customer service, finance and internal communication have moved to SaaS platforms, but responsibility for business continuity has not moved with them.

This guide explains how to prepare for a critical SaaS outage without maintaining an expensive duplicate of every platform. The goal is a proportionate plan: know what must continue, how much disruption is acceptable and how the team will work until the main service returns.

Start with business processes, not an application list

A subscription inventory does not show which services are critical. The same platform may be a convenience for one department and essential infrastructure for another.

For each important service, document:

the business process it supports,
the teams that use it every day,
the data stored in it,
its integrations and downstream dependencies,
what fails after 15 minutes, four hours and two days,
whether a manual or reduced process is possible,
the business owner accountable for decisions.

A CRM outage, for example, may not stop sales immediately. However, if website forms submit leads only through the CRM API, the same incident may silently stop lead capture. The risk is no longer limited to missing customer history; new opportunities may be lost as well.

Define RTO and RPO in business terms

Two parameters turn “the system must be available” into a decision that can be tested.

RTO (Recovery Time Objective) is the maximum acceptable interruption to the process.
RPO (Recovery Point Objective) is the maximum acceptable amount of recent data loss.

A booking system may require an RTO of one hour and an RPO of several minutes. An internal knowledge base may tolerate a one-day RTO and a 24-hour RPO. There is no universal value.

The process owner should approve these targets. The business understands the cost of delayed orders, invoices or customer responses. IT can then assess whether the architecture, contract and operating procedures can actually meet those expectations.

Check what the provider really guarantees

A status page and an availability percentage in marketing materials are not a continuity plan. For each critical service, check:

how the contract defines availability and exclusions,
whether the SLA specifies recovery objectives or only service credits,
where incidents are announced and how a critical ticket is escalated,
response times for the subscription tier you use,
whether data can be exported through the interface or API,
whether exports include attachments, history, permissions and metadata,
how long data remains available after contract termination,
whether an independent backup can be stored outside the production account.

An SLA frequently offers a modest invoice credit rather than compensation for business losses. Its operational value lies mainly in clear escalation channels and measurable expectations.

A SaaS export is not necessarily a backup

An “Export” button is often mistaken for backup. A quarterly export may support a migration but rarely meets a short RPO. Meanwhile, the provider’s backups may protect its infrastructure without allowing a customer to restore one record deleted by mistake.

A useful strategy answers four questions:

What is copied? Core records, attachments, configuration, users, permissions, logs and relationships.
How often? According to the approved RPO, not whenever someone remembers.
Where is it stored? Outside the same service and preferably outside the same administrative identity.
How will it be used? For restoration, emergency read-only access or migration to another system.

The test matters most. A ZIP archive in object storage does not provide continuity if nobody understands its structure or if the relationships between records are missing.

Design a minimum viable fallback

Running a full standby environment for every SaaS platform would be costly and hard to keep synchronized. A minimum viable fallback is usually more practical: a restricted process that supports the most important operations for several hours or days.

Examples include:

website forms writing to a queue or encrypted store while the CRM API is unavailable,
a current, read-only export of critical contacts available to designated staff,
orders temporarily recorded in a controlled template with unique identifiers,
a pre-approved alternative communication channel,
outbound invoices queued and delivered after the integration recovers,
a single dashboard showing the state of critical services.

Fallback mode should reduce scope rather than create a second source of chaos. Define who may activate it, where new data goes and how the records will be reconciled safely when the main platform returns.

Write a short incident runbook

A runbook does not need fifty pages. Two or three pages for one service can be enough if they include:

symptoms and a method for confirming the outage,
the business and technical owners,
support contacts and the contract number,
criteria for activating fallback mode,
steps to protect data waiting in integrations,
prepared messages for employees and customers,
the frequency of status updates,
conditions for returning to normal operations,
a post-recovery checklist.

The runbook must remain accessible when the main document platform is down. An offline copy or emergency repository helps only if on-call staff know where it is and have current access.

Account for integrations and in-flight data

When the SaaS interface comes back, the business process may still be broken. Queues may be full, API tokens may have expired, webhooks may have stopped and automations may have skipped events.

The recovery checklist should cover:

pending and rejected operations,
API and webhook logs,
forms and messages received during the outage,
scheduled jobs that did not retry,
record consistency between systems,
user permissions and sessions,
the final incident communication.

Unique identifiers and idempotent operations are particularly valuable. They allow the team to replay a queue without creating duplicate orders, invoices or support tickets.

Run a tabletop exercise without stopping production

You can test the plan without causing a real outage. In a 60–90-minute exercise, give the team a scenario: “The CRM has been unavailable since 09:10. The provider has no recovery estimate, and a campaign is generating a high volume of leads.”

Walk through the decisions:

Who detects and confirms the incident?
Who activates fallback operations?
How are new records protected?
What do employees, customers and management need to know?
When do you escalate, and when would migration become an option?
How will data completeness be verified after recovery?

The exercise tends to expose simple but serious gaps: an old support number, a runbook stored in the unavailable platform, no decision owner, or an export that nobody has ever opened.

A 30-day implementation plan

Start with the three services whose failure would have the greatest impact on revenue, customers or regulatory duties.

Week 1: priorities

assign business owners,
map processes and integrations,
approve RTO and RPO,
select the most important outage scenario.

Week 2: data and contracts

review the SLA and escalation path,
perform a full export,
confirm data scope and readability,
identify gaps in independent backup coverage.

Week 3: fallback operations

define the minimum operating process,
prepare communications and contacts,
protect queues and integrations,
store a short runbook outside the primary service.

Week 4: exercise and corrections

run a tabletop exercise,
measure the time required to make key decisions,
assign owners to every gap,
schedule the next test.

When a service also needs an exit plan

A short outage is not the only scenario. A provider may change its terms, discontinue a product, increase prices substantially or cease to meet company requirements. Critical SaaS therefore also needs an exit plan.

The plan should identify export formats, potential target systems, identity and permission migration, migration waves, any parallel-running period and data acceptance criteria. The business does not need to operate a permanent replacement. It does need to know whether leaving would take two days, two months or a year.

If the goal is to reduce dependency on a global workplace suite, see European alternatives to Microsoft 365 and Google Workspace. Continuity, backups and supplier management should also be considered alongside the NIS2 and KSC 2026 cybersecurity checklist.

Summary

SaaS continuity does not mean assuming that a large provider will never fail. It means ensuring that one provider incident does not become a loss of data, customers and control over communication.

A good plan establishes ownership, RTO and RPO, independent access to data, a minimum fallback process, integration recovery and return-to-service criteria. Most importantly, it is tested before it is needed.

If you want to inventory critical services, assess dependencies and prepare practical runbooks, see our IT Partner service. Techcroud can bring continuity, monitoring, backups and exit planning together in one workable operating model.