Restore the shared backup into a separate resource, recover only the target tenant's data from it, and copy that into the live tenant scope after checking ownership. Authorize the operator for that tenant, record what you did, and prove with a two-tenant test that nobody else's data moved.
Why this is a security task
A shared backup holds every tenant's data. If a customer asks you to roll back their data after a mistake, restoring the whole backup over production would overwrite or expose everyone else's rows. Giving the customer's operator access to the backup would expose all tenants at once.
The OWASP Multi-Tenant Security Cheat Sheet addresses this directly. For a single-tenant recovery from a shared database, it advises restoring into a separate resource and selectively recovering the target tenant's data, as described in Azure's multitenant storage guidance. It also says not to give a tenant operator access to a shared backup.
Step by step
- Confirm the request. Verify who is asking and that they are entitled to act for this tenant. Treat a restore request like any privileged action.
- Authorize the operator. The person doing the restore needs approval for the target tenant, and nothing broader.
- Restore to an isolated environment. Use a separate database or storage account that no customer can reach.
- Extract only the target tenant. Filter by tenant ID in the isolated copy, for rows and for objects.
- Check ownership before copying. For each record or object, confirm it belongs to the target tenant before it goes into the live scope.
- Apply current rules. The sheet says to reapply current access and retention rules, since a backup can carry old memberships or data that should no longer be accessible.
- Record the event. Log the source backup, target, reason and outcome.
- Destroy the temporary copy when done, under your retention rules.
What to watch for
| Risk | Control |
|---|---|
| Old memberships restored with the data | Reapply current access and retention after restore |
| Foreign keys pointing at other tenants' rows | Validate references stay inside the tenant |
| Object versions from other tenants in the same bucket | Filter by tenant prefix and verify metadata |
| Operator with broader access than needed | Scope the operator to the tenant for this task |
| Temporary restore left running | Time-box and delete it |
The two-tenant test
The sheet gives a clear test. Use a backup with two tenants, recover one of them, then verify:
- The other tenant's records and objects are absent from the restored result.
- A restore request by an unauthorized actor is rejected.
Run it before you need it. A restore procedure first used during an incident is a bad time to learn it copies everything.
Include restores in offboarding too
Tenant offboarding has the same problem in reverse. The sheet asks for a documented retention and deletion policy across active stores, caches, object versions, replicas, exports and backups, with legally required records restricted. A deleted tenant may still exist in last month's backup. Decide how long that is acceptable, and make sure a restore cannot silently bring them back into active use.
A short runbook outline
- Trigger: customer request or incident.
- Approvals: named approver for the tenant, named operator.
- Environment: isolated restore target.
- Method: filter by tenant ID, ownership checks, current access rules.
- Evidence: log entry with backup, target, reason and outcome.
- Cleanup: remove the temporary copy.
- Drill: rehearse with two tenants on a schedule.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a control is tied to evidence, which is what a restore log provides.
Safeguard provides compliance and evidence automation, with a free scan at gold.safeguard.sh/scan.
Quick check
Can I just restore the whole backup and delete the rest?
Not into production. That risks overwriting other tenants and exposing their data during the window. Use an isolated restore target.
Should the customer see the backup?
No. Give them the recovered data for their tenant only, after your checks, never access to the shared backup.
Sources
Last reviewed: 19 October 2026.
