Can your SaaS supplier restore your tenant’s data?

A SaaS supplier’s backup schedule does not establish whether it can recover records deleted from your organisation’s environment. The useful evidence is a tested restore covering the data, settings and access your team needs, with the limitations recorded.

For this review, a tenant means your organisation’s environment within a shared SaaS service. Ask whether the supplier can restore that tenant, or selected records within it, without overwriting unrelated work. A platform-wide disaster recovery test may answer a different question.

The method below is an original assessment aid. It does not prescribe a regulatory test frequency or a universal recovery target.

Start with one data-loss scenario

Choose a failure that matters to your service. Accidental deletion, an incorrect bulk update and a platform outage need different recovery actions. Specify which one you want the supplier to demonstrate.

In this fictional example, Banksia Services uses a SaaS case-management application. An authorised user accidentally deletes a group of cases. Other cases remain available, and staff continue updating them. Banksia needs the deleted cases restored with their attachments, ownership and access permissions, while keeping those newer updates.

The supplier provides evidence that it can rebuild its production database from backup. That is relevant, but the evidence does not say whether it can recover only Banksia’s deleted cases. Restoring an entire tenant to an earlier point could also remove valid changes made after that point.

Banksia therefore requests a selective-restore demonstration in an agreed test environment. If the service cannot do that, the supplier should explain the supported alternative and its consequences before anyone accepts it as a workable recovery method.

Write down who does each part

Shared responsibility needs to describe actual actions. Who selects the backup scope, enables any optional protection, requests recovery, authorises an overwrite and validates the result?

ASD’s cloud assessment guidance explains that security responsibilities, including backups, can sit with one party or be shared. It also warns that a SaaS provider does not automatically inherit every control offered by its underlying cloud provider.

Record the arrangement for your purchased service, plan and region. Include any reseller or separate backup operator. Your organisation still owns its risk decisions and applicable compliance responsibilities; allocating a technical task to a supplier does not settle those decisions.

An ISACA article on cloud risk management makes a useful related point: backup-control ownership varies with the arrangement. Its examples are professional commentary, not Australian regulatory requirements.

Request evidence that answers the restore question

Send a scoped request with the selected scenario. Ask for the following information rather than another general statement that backups exist.

• Covered content: the records, attachments, configuration, permissions and history included or excluded. Ask how relationships between objects survive restoration.
• Recoverable points: backup frequency, retention, available versions and any conditions that make older points unavailable. Identify the timestamp of the data actually recovered.
• Restore granularity: whether recovery applies to individual objects, a selected group, a tenant or the whole service. Ask how unaffected tenants and valid newer work are protected.
• Request dependencies: the authorised requester, support route, service hours, approvals, charges and access needed. Include what happens if the normal administrator account is unavailable.
• Protection and isolation: how backups resist unauthorised alteration or deletion, and whether a compromised production account could affect them. Request evidence suitable for security review, not credentials or sensitive architecture dumps.
• Observed results: the test date, service configuration, volume, start and finish definitions, failures, exclusions and validation results. Separate a promised recovery target from the time observed in the test.

Ask which parts of the evidence apply to your configuration. A redacted report or supervised demonstration may be sufficient; another customer’s personal information is unnecessary. If the supplier declines a request, record the resulting uncertainty rather than treating silence as a failed technical test.

Test whether the restored data is usable

ASD’s September 2026 Information Security Manual includes coordinated testing of restoration of data, applications and settings to a common point in time. That supports looking beyond a successful backup-job notification. Apply the guidance within your organisation’s relevant security requirements.

For Banksia’s fictional exercise, use synthetic cases and an approved, isolated environment. Agree the expected case identifiers, attachment links, owners and permissions before the test. Include an unaffected case updated after the selected recovery point so the team can check whether the restore preserves that change.

Run the supported request process and record waiting time separately from technical restoration time. Note the recovered data timestamp and any missing changes. Check that authorised users can open the restored cases and attachments, and that restricted users still cannot.

A discussion can establish responsibilities, but it cannot substitute for executing the restore. Equally, a small successful demonstration does not prove recovery at production volume. Keep the differences between the exercise and the live service beside the result.

Keep unresolved limits in the decision

Banksia’s technical and service owners should accept the result against the agreed criteria, recording which method worked, which data it covered and which exceptions remain. If attachment recovery is untested, leave that gap open with an owner and a next test. Do not close it because the database restore passed.

Review SaaS service-level commitments separately: an uptime percentage does not establish tenant-data recoverability. Once restoration is demonstrated, use the supplier recovery and backlog guide for the later decision about resuming business work.

Start with one important SaaS service and one plausible deletion scenario. Ask its owner to identify the evidence that your tenant’s data can be restored using the service you actually buy.