Your SaaS provider has backups. Can you restore your tenant?
The supplier says backups exist. The business expects recovery within eight hours. Both statements can be accurate while your ability to recover remains unknown.
For an incoming platform owner, the useful question is specific: can the customer recover the required records and attachments for this tenant, after this failure, within the business tolerance?
Start with the business requirement
A recovery time objective describes the target time for restoring the required service. A recovery point objective describes the target point to which data should be recovered, expressed as an acceptable data-loss interval.
Record who set the requirements, which process and data they cover, and what the business would do if those targets were missed. Their existence does not demonstrate that the service can achieve them.
Do not assume a tolerance from a platform’s label. An HRIS, CRM or collaboration tool may support several processes with different consequences of disruption.
Ask what the supplier statement actually covers
A supplier may describe infrastructure recovery, replicated data, platform backups or customer export. Read the statement in its actual scope.
Find out whether a customer can request restoration after accidental deletion, an incorrect bulk update or malicious modification. Ask what is restored, what cannot be restored, who initiates the request, the applicable time window and any additional fee.
Vendor documentation is useful evidence of a stated capability or obligation. A tenant-specific test answers a narrower operational question: what happened when the relevant recovery scenario was exercised?
Separate four different mechanisms
| Mechanism | Question it helps answer | Limit to check |
|---|---|---|
| Backup | Is there a protected recovery copy for the relevant scope? | Retention, coverage and restore access may be unclear. |
| Export | Can the customer retrieve data in a usable format? | Relationships, attachments and re-import may be incomplete. |
| Restore | Can the required service and records be recovered and validated? | A test may cover a different tenant or failure. |
| Continuity workaround | Can the business operate for a bounded period without the service? | Duration, capacity and later reconciliation may be limited. |
A successful demonstration in one row does not automatically establish the others.
What useful restore evidence looks like
Request a test record that identifies the tenant or approved test environment, failure scenario, data coverage, recovery point, elapsed time and result of business validation.
Also check who observed the test, when it happened, what failed and whether the environment has materially changed since then. A record of a test being scheduled is different from a result.
The right test should answer the decision you face. You may need to know whether a set of records can be recovered after a mistaken update, rather than whether the supplier can recover its entire hosting environment.
Route a proposed test through the actual technical and production authorities. A takeover checklist is not permission to perform a destructive test.
A fictional HRIS example
In the kit’s fictional case, Aster HR holds 2,400 worker records. The business requires an RTO of eight hours and an RPO of 24 hours. The supplier says backups exist, but no tenant restore result is available.
The team has demonstrated a four-hour manual intake fallback. That supports a limited continuity option. It does not show that records can be restored or that the workaround can support a prolonged outage.
The incoming owner requests a decision on a capped EUR 4,000 restore exercise. The decision belongs to the fictional Executive Risk Sponsor. At Day 30 it remains Pending, and the eight person-days needed for the exercise remain conditional on funding, a supplier slot and an approved environment.
All organisations, evidence and decisions in this example are invented. It is a teaching scenario, not a client result or a project of the author’s employers.
What to do when evidence is missing
Record the missing proof and the business consequence of delay. Assign a request owner and a latest useful date. Maintain only the controls and workarounds that are actually operating.
If potential consequences are severe or outside your mandate, use the appropriate escalation route even when an illustrative risk score appears modest. Do not reduce the likelihood of a failed restore merely because manual intake works.
Compare the real options: request existing supplier proof, fund a controlled exercise, strengthen temporary containment or change the business process. Record which authority can decide and what new evidence could change the choice.
A useful management statement
“The eight-hour recovery target is agreed. Tenant restoration remains unverified. A four-hour manual intake fallback has been demonstrated within a limited scope. The Service Owner is requesting an authorised recovery exercise. Funding and the supplier slot are still pending.”
That gives management a decision to make without creating false assurance.
Read the decision in context
The two-page public sample shows the evidence, options and operating boundary. The complete toolkit connects this finding to risk, decisions, backlog and the executive page.
Source basis
NIST’s RTO glossary and RPO glossary, citing SP 800-34 Rev. 1, support the recovery terminology. The descriptions above are plain-language explanations for a platform review.
NIST CSF 2.0 PR.DS-11 supports creating, protecting, maintaining and testing backups. It does not establish any SaaS vendor’s restoration capability or prescribe the fictional budget, score or schedule.
Microsoft’s shared-responsibility guidance explains responsibility boundaries across cloud service models. Use it to frame questions. Confirm the obligations for your actual SaaS product in its documentation and agreement.