Draft guide

Why SaaS business data may need its own backup

Using a cloud application does not remove the need to understand how its business data can be recovered. A separate backup service may provide another recovery path for covered information.

Many businesses depend on software delivered through an application cloud. Staff use these services to communicate, manage work, store records, and support customer or internal processes. The platform provider operates the service, but the organization still needs to understand what data matters, how it is protected, and what would happen if information were deleted or changed unexpectedly. The answer depends on the application, its own retention and recovery features, and the responsibilities assigned to the business and provider.

Understand the shared responsibility boundary

Cloud services can offer availability, security controls, and tools for managing information, but those capabilities do not automatically answer every organization-specific recovery question. A business should review the provider's terms and features, understand which actions administrators and users can take, and identify what recovery needs the organization has. The precise responsibilities differ among services and configurations, so it would be misleading to assume one rule applies everywhere.

For example, an accidental deletion, a synchronization mistake, or an account issue may require a particular item or set of records to be restored. The business needs to know whether the service's own tools address that case, for how long, and what steps or permissions are required. A separate SaaS backup service can provide an additional copy and restore path for applications and objects that are included in its configuration. This does not replace understanding the original platform or the agreed scope of the backup service.

ExcelyTech's SaaS backup service overview lists Microsoft 365, Entra ID, Dynamics 365, Salesforce, Google Workspace, and Zendesk as platforms discussed by the service. Which applications, objects, and restore options are actually covered must be confirmed in the service agreement. That qualification matters because support and restore capabilities can vary.

Start with the data and business process

Rather than beginning with a product list, begin with how the business uses the information. Which records support daily work? Which teams rely on them? Would a missing item interrupt a business process or create additional work? What would need to be restored together for the information to be useful? These questions help establish what is important and whether current retention or recovery features meet the need.

Next, identify the data types and objects involved. A platform may contain messages, files, calendars, records, or other content. Not every backup product supports every object or restore action for every edition. Record what is expected to be covered, which restore choices are available, and what limitations apply. Avoid treating “the application is backed up” as a complete description unless the covered services and data have been checked.

Recovery readiness also includes access and dependencies. Who can request a restore? Who can authorize it? What account or administrative access is needed? Are there business or technical steps after data is returned? These details help explain the full path from a protected copy to information that people can use again.

Plan retention and restore expectations

Retention describes how long protected copies remain available. The appropriate period depends on business, operational, and other requirements, along with the capabilities and settings of the selected service. Businesses should understand how retention works, how recovery points are selected, and whether the configuration aligns with the time period in which an issue might be discovered. The answer should be based on the chosen service and configuration, not a general assumption.

Restore expectations deserve the same care. A service may offer different ways to retrieve data, but a specific restore path should not be promised until support has been confirmed. Determine whether the organization expects a full object, selected information, or a broader set to be restored. Ask what the result looks like, whether the original location can be used, and what actions remain for the business. These questions should be answered within the agreed service scope.

Testing or validation can help teams understand a process before an incident. It should be framed as a readiness activity, not as proof that every future recovery will succeed. Where validation is available and agreed, record what was checked and what was outside the exercise.

Make a practical SaaS protection inventory

A concise inventory can list each business application, the information it holds, the business owner, existing provider recovery features, and any additional protection under consideration. Note which configuration is in use and who administers it. Add the expected retention and restore needs, including any time or data-loss objectives the business has established. Unknown answers are useful findings; they show where clarification is needed.

Then compare the inventory with the service agreement and actual configuration. Confirm which apps and objects are covered, how copies are created, what restore options are supported, and who performs each task. Keep the legal and technical boundaries visible. A plan should state “where supported” or “within agreed service scope” when those limits apply, rather than implying universal coverage.

For related planning, see on-premises business backup and recovery and the ExcelyTech data protection approach. Businesses in Ontario, Canada and the United States can contact ExcelyTech to discuss SaaS data and recovery requirements.

Draft note: This guide is a working draft and should be reviewed for technical accuracy, platform coverage, and service alignment before publication.