This is a ready-to-use shared-responsibility matrix for backup, restore, and disaster recovery on a cloud-hosted or SaaS GxP system. It closes the accountability gap that shows up most often in cloud-era backup programs: the customer assumes the vendor’s infrastructure backups double as a validated GxP restore control, the vendor assumes the customer knows what is and is not covered, and neither side has ever actually proven a restore of the customer’s own tenant data. The matrix names an owner for every backup-lifecycle duty and, for every shared duty, the evidence that proves it is happening. Replace every <<FILL: ...>> placeholder. A filled specimen follows. This content is educational and general; adapt it and verify it before use.
How to use this matrix
- Identify the parties actually involved: the cloud infrastructure provider (if the SaaS vendor itself runs on a hyperscale platform), the software vendor, and your organization. Sometimes the infrastructure provider and the software vendor are the same company; note that in the header.
- Assign an owner to every row below (Vendor, Customer, or Shared). For every “Shared” row, name the specific evidence that proves the duty is being met and who is responsible for obtaining it.
- Resolve every blank before go-live. An unassigned row is the accountability gap you are closing. If a vendor will not commit to a row in writing, that is itself a risk finding to document and mitigate, not a detail to skip past.
- Fold the resolved matrix into the quality or service agreement and the system’s periodic review cycle, referencing it from the backup, restore, and disaster recovery validation program for the system.
- Re-confirm the matrix on contract renewal, on a material vendor change (acquisition, infrastructure migration, subprocessor change), and at the system’s normal periodic review cadence.
Ownership key
- V = Vendor (software vendor, or the infrastructure provider where noted) owns and performs.
- C = Customer (the regulated company) owns and performs.
- Sh = Shared; the row names the evidence and the mechanism that makes it work.
The allocation matrix
| # | Backup / restore / DR duty | Owner (V / C / Sh) | What the owner does | Evidence (for Sh rows) |
|---|---|---|---|---|
| 1 | Physical infrastructure durability and redundancy | <<FILL: V>> | Operates redundant storage, hardware, and geographic replication for the hosting platform | — |
| 2 | Application-consistent backup execution | <<FILL: V>> | Runs database- and application-aware backups on a defined schedule, not raw file copies of open systems | — |
| 3 | Backup scope definition (what is and is not included) | <<FILL: Sh>> | Vendor states, in writing, exactly what is backed up (data, audit trail, configuration, workflow rules, attachments); customer confirms it matches what the system actually needs recoverable | Vendor to customer: written backup specification |
| 4 | Backup frequency and committed RPO | <<FILL: Sh>> | Vendor commits a schedule and RPO; customer sets the requirement from its own business impact analysis and confirms the vendor’s commitment meets it | Contractual RPO clause tied to the customer’s BIA |
| 5 | Backup encryption and key management | <<FILL: V, unless customer holds its own keys>> | Encrypts backups at rest and in transit; documents key custody and recovery | — |
| 6 | Backup job monitoring and failure alerting | <<FILL: V>> | Monitors backup jobs and alerts on failure; discloses material failures affecting customer data | — |
| 7 | Vendor’s own restore testing | <<FILL: V>> | Periodically restores its own backups and confirms recoverability at the platform level | — |
| 8 | Independent attestation of backup/restore controls | <<FILL: Sh>> | Vendor provides an attestation (for example SOC 2 Type II or ISO/IEC 27001); customer confirms the attestation’s scope actually covers backup and restore testing, not only security and change management | Vendor to customer: current attestation, scope-checked by customer |
| 9 | Customer-initiated data export / portability | <<FILL: Sh>> | Vendor provides an export mechanism (on-demand export, API, reporting extract) covering data, audit trail, and metadata; customer exercises it | Vendor to customer: export mechanism; customer’s own export test record |
| 10 | Periodic customer-side export or restore drill | <<FILL: C>> | Customer periodically pulls a full export or exercises any available restore/preview right and verifies completeness and readability against a reference | — |
| 11 | Committed RTO for the customer’s process | <<FILL: Sh>> | Vendor commits a technical recovery time; customer confirms it meets the RTO required by the GxP process the system supports | Contractual RTO clause tied to the customer’s BIA |
| 12 | Configuration and workflow-rule recoverability | <<FILL: Sh>> | Vendor states whether tenant configuration and workflow rules are included in backup/restore; where not included, customer maintains its own configuration export or rebuild procedure | Vendor statement of scope; customer’s own configuration export record |
| 13 | Data retention and secure disposal at contract end | <<FILL: Sh>> | Vendor executes deletion per the agreed schedule; customer confirms a complete, verified export was taken and accepted before deletion proceeds | Customer’s completed export confirmation, dated before vendor deletion |
| 14 | Notification of a data-loss or backup-failure event | <<FILL: V>> | Notifies the customer without undue delay of any event that could affect the recoverability or integrity of the customer’s data | — |
| 15 | Change notification for backup method, schedule, or platform | <<FILL: V>> | Gives advance written notice of a material change to backup architecture, schedule, or hosting platform | — |
| 16 | Impact assessment of a vendor backup-method change | <<FILL: C>> | Assesses each notified change against the system’s RTO/RPO and, where warranted, requires a re-test before accepting the change | — |
| 17 | Business continuity / manual workaround during a vendor-side outage | <<FILL: C>> | Customer maintains its own manual fallback for the regulated process, since the vendor cannot operate the customer’s business during an outage of the vendor’s service | — |
| 18 | Right to audit or request evidence | <<FILL: Sh>> | Contract grants the customer the right to request and review backup/restore evidence on a defined cadence; customer exercises the right and records the outcome | Contractual audit/evidence-request clause; customer’s request log |
| 19 | Folding vendor restore evidence into periodic system review | <<FILL: C>> | QA incorporates the vendor’s restore evidence, attestations, and the customer’s own export drill results into the system’s periodic review | — |
| 20 | Sub-processor / fourth-party backup responsibility | <<FILL: Sh>> | Where the vendor itself relies on a separate cloud infrastructure provider, vendor discloses the sub-processor and confirms its own contractual coverage from that provider flows through to the customer’s commitments | Vendor to customer: sub-processor disclosure and coverage statement |
The principle that survives every product and contract variation: the vendor owns operating the platform and proving it can recover its own service, the customer owns proving that the vendor’s recovery capability actually meets the requirement the customer’s regulated process needs, and any row where information has to pass from one side to the other is shared, which is where the accountability gap otherwise opens.
Acceptance criteria
The matrix is defensible when:
- Every row has a named owner; no cell reads “unassigned,” “TBD,” or “vendor handles it” without evidence behind that statement.
- Every “Shared” row names the specific evidence and who is responsible for obtaining and reviewing it.
- The matrix reflects the product and contract actually in place, not a generic assumption about what “the cloud” covers.
- It is referenced from the quality or service agreement and from the system’s backup and restore validation record.
- It is reviewed on contract renewal, on a material vendor or sub-processor change, and at the system’s periodic review cadence.
Filled specimen
The following shows selected rows completed for a SaaS quality management system where the software vendor itself runs on a separate hyperscale cloud infrastructure provider. Illustrative content; replace with your own.
| # | Duty | Owner | What that party does | Evidence |
|---|---|---|---|---|
| 3 | Backup scope | Sh | Vendor’s written spec confirms database, audit trail, and attachments are backed up; workflow configuration is explicitly excluded from standard backup | Written backup specification, reviewed at onboarding |
| 4 | Backup frequency / RPO | Sh | Vendor commits nightly full plus 15-minute transaction log shipping, RPO 1 hour; customer’s BIA requires RPO of 4 hours for this process, so the commitment exceeds the requirement | Quality agreement clause, RPO 1 hour vs BIA requirement of 4 hours |
| 8 | Independent attestation | Sh | Vendor provides a current SOC 2 Type II report; customer’s IT quality lead confirmed the report’s system description explicitly covers backup and restore testing, not only logical access | SOC 2 Type II report, scope confirmed 14 May 2026 |
| 9 / 10 | Export / customer drill | Sh / C | Vendor provides a self-service export (JSON plus attachments and audit trail) within the application; customer pulls a full export twice a year and verifies a sample against the live system | Export test records, 12 Feb 2026 and 09 Aug 2026, both Pass |
| 12 | Configuration recoverability | Sh | Workflow configuration is not in vendor backup scope; customer maintains a documented, version-controlled export of its own configuration, refreshed after every change | Configuration export log, current as of last change |
| 20 | Sub-processor coverage | Sh | Vendor discloses its hyperscale infrastructure provider and confirms its own infrastructure SLA and backup redundancy flow through to the customer’s committed RTO/RPO | Sub-processor disclosure in the quality agreement, reviewed annually |
Read as a story: the vendor commits, in writing, to backup scope and objectives that meet the customer’s actual business requirement, provides independent evidence its own restore capability works, and discloses the infrastructure layer underneath it. The customer does not stop at the marketing claim: it holds its own tested export of both data and configuration, and it folds the whole picture into the system’s periodic review. Nothing is left as an assumption, so when an inspector asks who is accountable for proving this system’s records can actually be recovered, there is one clear, evidenced answer.
Common inspection findings this matrix prevents
- No documented allocation of backup/restore responsibility for a SaaS system; the customer assumes “the vendor handles it” with nothing in writing.
- A vendor attestation on file that was never checked for whether it actually covers backup and restore testing.
- Tenant configuration and workflow rules assumed to be backed up along with the data, never confirmed, and lost when a real recovery is needed.
- No customer-side export or restore evidence at all, so the only proof of recoverability is the vendor’s own unverified claim.
- A sub-processor or infrastructure change that the customer never learned about until after it happened, with no mechanism in the contract requiring notice.
How to adapt this matrix
- List the parties in your header exactly as they exist in your contract stack (software vendor, infrastructure provider if separate, and your organization).
- Walk every row and assign V, C, or Sh based on what your actual contract and technical architecture provide, not what you assume a typical SaaS product includes.
- For every Sh row, name the real evidence artifact (a report, a log, a contractual clause) and who is responsible for collecting and reviewing it.
- Reconcile this matrix with your quality or service agreement so the operational and contractual views match, and attach it to the system’s backup and restore validation file.
- Set the review trigger (renewal, vendor change, periodic review) and re-confirm the matrix on that schedule.