A customer database can be available around the clock and still be difficult to recover after a damaging change. A mistaken deletion, an integration that overwrites records or a compromised administrator account may affect one company's information while the wider software service continues operating normally. For a business that relies on that information to fulfil orders or collect payments, the distinction matters immediately.
Software as a service, or SaaS, transfers much of the responsibility for running an application to its provider. The customer's recovery needs still depend on what data it stores, how employees use the application and what other systems connect to it. A credible plan therefore has to cover both the provider's capabilities and the company's own decisions about access, backup and operational continuity.
The practical objective is to restore a usable business process within an acceptable period. That requires more than knowing that a backup exists. Companies need evidence that the right records can be recovered, that authorised staff can reach them and that the restored information can be reconciled with transactions that happened during the interruption.
Availability and recovery answer different questions
Availability describes whether users can reach a service. Recovery concerns how a company returns to an acceptable state after information or functionality is lost. Those conditions can diverge. An application may be working perfectly for most customers while one organisation has lost a set of records or cannot sign in with its usual identity system.
The UK National Cyber Security Centre's guidance on using SaaS securely advises customers to check that critical data has a resilient backup and to prepare for incidents affecting their own use of an application. It also addresses access recovery and configuration. The guidance makes clear that using a managed application still involves responsibilities specific to the customer's organisation.
Contract discussions should establish which recovery functions the subscription actually includes. A provider may offer different retention periods or restoration options across service plans. Teams should ask whether restoration covers individual records, attachments and settings, and whether it can reverse an unwanted change without replacing later valid work. A general promise of reliable infrastructure does not answer those application-level questions.
Begin with the work that must continue
A recovery plan becomes easier to prioritise when it begins with business activity. Payroll processing, order fulfilment and customer support may tolerate very different interruptions. Treating every application as equally urgent can consume the recovery budget while leaving the most time-sensitive process inadequately protected.
NIST's contingency planning guidance, developed for federal information systems, connects business impact analysis with recovery priorities, testing and plan maintenance. Businesses can use that planning logic without assuming that a federal framework is a universal legal requirement. The useful starting point is to identify the work that depends on each system and what happens when it stops.
Two familiar terms help make that discussion concrete. The recovery time objective describes the target period for restoring a capability. The recovery point objective expresses the tolerable loss of recent data in time. These are planning targets, not guarantees. A team that wants restoration within four hours must test whether its access arrangements, available support and data volume make that target achievable.
An illustrative distributor might tolerate a day without its marketing application but only a short interruption to dispatch records. It could prioritise order history and delivery instructions, then provide a controlled temporary process for new orders. Managers would also need to decide how those temporary records enter the restored system without producing duplicate shipments.
Recover the relationships between records
A spreadsheet export may preserve useful information while losing the relationships that make an application valuable. An order might depend on a customer identifier, an approval history and a document attachment. Restoring the order value alone may not allow staff to establish whether the transaction was authorised or which version of the contract applies.
This is why recovery scope should be described in operational terms. Finance may require supporting documents alongside invoice records. Customer service may need open cases linked to the correct account. Sales managers may need ownership information and consent settings, rather than a simple contact list. Each requirement should be checked against what the provider or backup tool can actually export and restore.
The Center for Internet Security's Data Recovery control focuses on restoring assets to a trusted state. For a SaaS-dependent business, that principle suggests testing record quality as well as technical completion. A restoration job can finish successfully while leaving missing attachments, incorrect permissions or broken links that prevent normal work.
Recovery tests should therefore include an employee who understands the process. The test is stronger when that person can complete a representative task, such as resolving a customer case using restored records, rather than simply confirming that files appeared in a folder. Any gaps should become recorded actions with an owner and a completion date.
Protect the recovery route from the original failure
Copying data to another location does not automatically make it independently recoverable. If the same compromised account can delete both the application records and the backup, the second copy may fail at the moment it is most needed. A separate recovery route has to be assessed by its access controls and dependencies, not just its storage address.
The NCSC's principles for ransomware-resistant cloud backups address destructive actions, continued customer access, recovery from earlier versions and key management. These principles provide useful questions for procurement teams. They should establish who can change retention settings, how destructive actions are controlled and whether someone will receive alerts even when the main environment is unavailable.
CISA's StopRansomware Guide recommends offline, encrypted backups of critical data and regular testing of their availability and integrity. Applying that advice to cloud applications requires attention to the service's design. The appropriate arrangement may combine protected cloud copies with an independently accessible export, rather than assuming that every SaaS application supports the same backup method.
Independence also has a cost. Additional copies create another place where sensitive information must be protected. Separate credentials need maintenance, and recovery keys must remain available to authorised staff. A backup arrangement should reduce the risk of losing data without creating uncontrolled access to it.
Plan for access and integration failures
An organisation can retain all its data and still be unable to use it. A failure in a central identity service, an expired credential or the departure of the only administrator may block recovery. Emergency access procedures should be agreed with the provider, protected against abuse and tested without exposing production information unnecessarily.
Integration can complicate restoration further. Suppose an order-management application sends records to accounting software every few minutes. Restoring one system to an earlier point while leaving the other unchanged could cause repeated invoices or inconsistent balances. The response team needs to understand which connections should be paused and how records will be compared before normal synchronisation resumes.
A useful dependency map shows the systems required to complete each important process. It should include identity, document storage and essential external services where relevant. Recording every connection is less valuable than identifying the dependencies that could prevent restoration or spread an unwanted change. Teams can then rehearse recovery in the right sequence.
Support arrangements belong in the same plan. Provider contact details, escalation rights and the authorised account owner should be available through a route that survives the incident. Keeping the only copy of the recovery instructions inside the affected application creates an avoidable dependency.
Make testing an operational exercise
A meaningful test should answer how long recovery takes and whether the resulting information can be trusted. It can begin with a small representative dataset in an approved test environment. That reduces disruption while exposing limitations in the process. The scope can expand as the company understands its tooling and dependencies.
Tests should include plausible failures beyond wholesale data loss. A recently deleted record, a damaged attachment, an unavailable identity service or an erroneous bulk update may each require a different response. The company should also test how it would locate the appropriate recovery point when the time of the damaging event is uncertain.
Useful evidence includes the actual elapsed recovery time, missing data and any manual steps needed to resume work. A test that exceeds the target should lead to a decision: change the process, invest in a different capability or accept a longer interruption with a documented workaround. Repeatedly recording a failure without changing the plan offers little protection.
Testing frequency should reflect business impact and the rate of change. A new integration, changed retention policy or reassignment of administrators can invalidate an earlier result. Smaller organisations can start with their most important application and a modest exercise, then expand coverage as responsibilities and resources allow.
Keep recovery proportionate and accountable
Retention decisions involve privacy as well as continuity. Keeping every version indefinitely can increase exposure and complicate lawful deletion. Companies need policies that explain what is retained, for how long and how recovered personal information will be handled. The right arrangement depends on applicable law, contractual requirements and the sensitivity of the records.
The Information Commissioner's Office guidance on data security explains the UK requirement to restore availability and access to personal data in a timely manner and to test security measures. It also makes clear that appropriate safeguards depend on the risks of the processing. This is a jurisdiction-specific requirement, rather than a single global recovery deadline.
Accountability should follow the process. Technology staff can run the recovery tools, while the business owner determines whether restored information is sufficient for safe operation. Procurement should verify contractual coverage, and privacy specialists should assess the additional copies. In a small company, one person may hold several responsibilities, but the decisions still need to be explicit.
The strongest basis for approval is a practical demonstration: authorised staff can recover the necessary information, complete essential work and reconcile temporary activity within the organisation's chosen limits. That evidence makes a recovery plan useful when the company actually needs it.
Include recovery in the purchasing decision
A recovery requirement is easier to negotiate before signing than after an interruption. Procurement teams can ask a provider to demonstrate the relevant restore function with representative data. The demonstration should establish what is included in the subscription and what requires additional support, software or payment. A written description of limitations gives the company a clearer basis for comparing offers.
The cost comparison should include the staff time needed to maintain and test the arrangement. An inexpensive backup service can require substantial manual work if its exports do not match the application's structure. Another option may offer more automated recovery while requiring additional permissions that security staff must evaluate. The decision should reflect the cost of meeting the business requirement, rather than the price of storage alone.
Portability is a related question. A usable export can help a company continue essential work during a prolonged interruption or prepare for changing applications. It does not guarantee that another service can import the information without transformation. Teams should distinguish the ability to retrieve data from the ability to rebuild the same process elsewhere.
Before approval, the business owner can record the recovery capability it has chosen, its known limitations and the remaining work needed to meet the target. If a function is important enough to make the application essential, the company should understand how that function would operate during an interruption. This keeps the recovery decision connected to the reason for buying the software.
Questions business leaders ask
Does a SaaS subscription automatically include a suitable backup?
It depends on the provider and plan. Native retention and restore features may cover some incidents, but their scope and limits should be checked against the company's recovery needs.
Is a data export enough for recovery?
An export can support continuity, but it may omit attachments, permissions or relationships. Test whether the exported information can support the intended business process.
Who should approve a recovery test?
The application owner and relevant technology staff should agree the scope. Include privacy or security specialists where the test involves sensitive information or additional access.