This is a ready-to-use RACI (Responsible, Accountable, Consulted, Informed) matrix covering the full control set for a cloud or SaaS GxP system, audit trail, patching, provisioning, encryption, backup, incident response, vendor-release impact assessment, and decommissioning, not only backup and restore, which already has its own dedicated matrix. It exists because a single “shared” label on a responsibility table, without separately naming who is Responsible and who is Accountable on each side, is exactly the gap inspectors find: a control both parties assumed the other owned. 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
- List the parties actually involved in your header: the SaaS vendor, the underlying cloud infrastructure provider if it is a separate company, and your organization.
- For every row, assign Responsible (R, does the work) and Accountable (A, owns the outcome and answers for it) separately on the vendor side and the customer side. A control can have a vendor R and a customer A at the same time, meaning the vendor performs the activity but the customer is answerable for confirming it happened and was adequate. Exactly one party is Accountable for the operational execution of a row; where both sides genuinely co-own different aspects, split the row rather than writing “shared” with no further detail.
- For every row where information has to pass between vendor and customer, name the specific evidence the customer keeps. An accountability with no evidence behind it is not a control, it is an assumption.
- Resolve every blank before go-live. Fold the resolved matrix into the quality or technical agreement and the system’s periodic review.
- Re-confirm on contract renewal, a material vendor or sub-processor change, and the system’s normal periodic review cadence.
RACI key
- R = Responsible, performs the activity.
- A = Accountable, owns the outcome and answers for it at inspection. Exactly one Accountable party per control area (vendor or customer), even where both have an R.
- C = Consulted, provides input before a decision.
- I = Informed, told after the fact.
- A blank cell means that party has no role in that row.
The matrix
| # | Control area | Vendor R | Vendor A | Customer R | Customer A | Evidence the customer keeps |
|---|---|---|---|---|---|---|
| 1 | Audit trail capability exists and is tamper-evident by design | <<FILL: R>> | <<FILL: A>> | <<FILL: C>> | Vendor design/test documentation; supplier audit report | |
| 2 | Audit trail switched on and scoped to GxP events in the production tenant | <<FILL: I>> | <<FILL: R>> | <<FILL: A>> | Configuration verification record (IQ); screenshot of live config | |
| 3 | Audit trail review performed at a risk-based frequency | <<FILL: R>> | <<FILL: A>> | Audit trail review records | ||
| 4 | Operating system and database patched and qualified (SaaS/PaaS) | <<FILL: R>> | <<FILL: A>> | <<FILL: C>> | Vendor patch/change records; SOC 2 / ISO 27001 evidence | |
| 5 | Application code patched, and defects tracked to resolution | <<FILL: R>> | <<FILL: A>> | <<FILL: I>> | Vendor release notes; defect tracking evidence where disclosed | |
| 6 | User provisioning, role assignment, and least-privilege design | <<FILL: C>> | <<FILL: R>> | <<FILL: A>> | Access provisioning tickets; role design record | |
| 7 | Periodic access review and deprovisioning of leavers | <<FILL: I>> | <<FILL: R>> | <<FILL: A>> | Access review records; joiner/mover/leaver tickets | |
| 8 | Identity provider (SSO/MFA) configuration and failure-mode testing | <<FILL: C>> | <<FILL: R>> | <<FILL: A>> | IdP configuration record; tested failure scenario | |
| 9 | Encryption of data at rest and in transit | <<FILL: R>> | <<FILL: A>> | <<FILL: I>> | Vendor security documentation; certification scope statement | |
| 10 | Tenant isolation in a multi-tenant deployment | <<FILL: R>> | <<FILL: A>> | <<FILL: C>> | Penetration test summary scope-checked by customer | |
| 11 | Backup execution and platform-level restore capability | <<FILL: R>> | <<FILL: A>> | <<FILL: C>> | Vendor backup logs / attestation | |
| 12 | Restore proven to return usable, intact GxP data with audit trail | <<FILL: I>> | <<FILL: R>> | <<FILL: A>> | Documented restore test with audit trail verification | |
| 13 | Security incident detection and vendor-side response | <<FILL: R>> | <<FILL: A>> | <<FILL: I>> | Vendor incident notification and post-incident report | |
| 14 | Customer-side incident escalation and regulatory reportability assessment | <<FILL: I>> | <<FILL: R>> | <<FILL: A>> | Internal incident record; reportability decision | |
| 15 | Vendor release notes reviewed for every release, minor or major | <<FILL: R>> | <<FILL: I>> | <<FILL: R>> | <<FILL: A>> | Vendor release review log entry for every release |
| 16 | Impact assessment of a vendor release and revalidation decision | <<FILL: R>> | <<FILL: A>> | Change record citing release notes and the risk decision | ||
| 17 | Sandbox / staging validation of a major release before production | <<FILL: R>> | <<FILL: C>> | <<FILL: R>> | <<FILL: A>> | Sandbox test record for the release |
| 18 | Sub-processor disclosure and fourth-party risk assessment | <<FILL: R>> | <<FILL: I>> | <<FILL: R>> | <<FILL: A>> | Sub-processor list; customer’s fourth-party assessment record |
| 19 | Compliance documentation (SOC 2, ISO 27001, Part 11 self-assessment) provided and current | <<FILL: R>> | <<FILL: A>> | <<FILL: C>> | Current reports on file, scope confirmed to cover this service | |
| 20 | Audit rights exercised (on-site, remote, or report review) | <<FILL: C>> | <<FILL: R>> | <<FILL: A>> | Audit or report-review record with outcome | |
| 21 | Data export mechanism provided and kept current | <<FILL: R>> | <<FILL: A>> | <<FILL: I>> | Export mechanism documentation | |
| 22 | Data export exercised and verified readable without vendor software | <<FILL: I>> | <<FILL: R>> | <<FILL: A>> | Export test record, periodic | |
| 23 | Data destruction confirmed at contract end | <<FILL: R>> | <<FILL: I>> | <<FILL: R>> | <<FILL: A>> | Destruction confirmation matched against a prior verified export |
| 24 | Folding vendor evidence and customer test results into periodic system review | <<FILL: R>> | <<FILL: A>> | Periodic review record referencing this matrix |
The pattern to hold onto: where the vendor is Accountable, the customer’s job is still to obtain, read, and retain the evidence, never to file it unread. Where the customer is Accountable, the customer generates and keeps its own record regardless of what the vendor provides. No row has a vendor R with no customer entry at all; even the most vendor-owned control still has a customer C or I that keeps someone at the customer paying attention to it.
Acceptance criteria
The matrix is defensible when:
- Every row has exactly one Accountable party named on either the vendor or customer side, never left blank and never assigned to both.
- Every row names the specific evidence the customer keeps, even where the vendor is Accountable for performing the activity.
- The matrix reflects the actual product and contract in place, not a generic assumption about what “the cloud” covers.
- It is referenced from the quality or technical agreement and the system’s validation or periodic review file.
- It is reviewed on contract renewal, a material vendor or sub-processor change, and the system’s periodic review cadence.
Filled specimen
The following shows selected rows completed for a SaaS quality management system running deviations and CAPAs, hosted by a vendor that itself runs on a separate hyperscale cloud infrastructure provider. Illustrative content; replace with your own.
| # | Control area | Vendor R | Vendor A | Customer R | Customer A | Evidence |
|---|---|---|---|---|---|---|
| 2 | Audit trail switched on and scoped | I | R | A | IQ configuration verification record dated 12 Mar 2026, confirming audit trail enabled and scoped to record creation, modification, deletion, and signature events | |
| 6 | User provisioning and least-privilege design | C | R | A | Role design record: 4 roles mapped to least privilege, reviewed by process owner and QA | |
| 9 | Encryption at rest and in transit | R | A | I | Vendor security white paper confirms AES-256 at rest and TLS 1.2+ in transit; keys held by vendor, documented, not assumed | |
| 15 | Release notes reviewed every release | R | I | R | A | Vendor release review log: 14 releases in the last 12 months, all reviewed, 2 escalated to a full change impact assessment |
| 16 | Impact assessment of a vendor release | R | A | Change record CC-2026-0311 citing release note item 6.2 (workflow engine change) and the resulting regression test scope | ||
| 18 | Sub-processor disclosure | R | I | R | A | Sub-processor list names the underlying cloud infrastructure provider and region; customer’s fourth-party assessment confirms the vendor’s SOC 2 report scope covers that layer |
| 22 | Export exercised and verified | I | R | A | Two export test records in 2026, both confirmed readable in a spreadsheet application with no vendor software installed, audit trail intact |
Read as a story: the vendor builds and secures the platform and tells the customer what changed, the customer decides what the change means for its own use, provisions and reviews its own users, discloses and checks the layer underneath the vendor, and proves, with a real test, that it could walk away with its data intact. Nothing is left as “the vendor handles it” with no evidence behind the sentence.
Common inspection findings this matrix prevents
- A generic “shared” label on a responsibility table with no separate Responsible and Accountable calls, so neither party can say who actually answers for the control at inspection.
- Audit trail, access review, or patching treated as vendor-owned with no customer evidence at all, because the customer assumed vendor accountability meant customer inaction.
- A matrix built once at go-live and never revisited, so a new sub-processor, a changed release cadence, or a new incident-response contact is not reflected anywhere.
- Two parties both believing they are Accountable for the same control, which in practice means neither one checks it.
- A control area (patching, provisioning, incident response) simply missing from the responsibility documentation because the original matrix only covered backup and restore.
How to adapt this matrix
- List your real parties in the header, including the underlying cloud infrastructure provider if the vendor discloses one.
- Walk every row and assign R and A on each side based on your actual contract and technical architecture, not a generic assumption.
- Split any row where both sides genuinely co-own different aspects into two rows rather than leaving a single ambiguous “shared” cell.
- Name the real evidence artifact for every row, not “vendor confirms,” and assign who at your organization is responsible for collecting and reviewing it.
- Reconcile this matrix with your quality and technical agreement so the operational and contractual views match, and attach it to the system’s validation file.
- Set the review trigger and re-confirm the matrix on that schedule.