VND-011 Shared Responsibility Model and Customer Security Communication
Description
A shared responsibility matrix available to customers states, for each service offered, which security controls the organisation operates, which the customer operates and which are shared. It describes the system boundary and the security commitments made to customers. The matrix names the control set it is expressed against and records each responsibility that passes to a sub-processor or an infrastructure operator. Changes that affect the security of a customer's environment are made on authorised request or announced to customers before they take effect, under published terms. The matrix and the commitments are reviewed at defined intervals and after any change to the service boundary. The reviewed version is the one customers can obtain. The matrix and the commitments are published where a prospective customer can read them without an account and the customer agreement names where they are published. The published statement describes the technical, organisational and contractual measures that stand between customer data and an authority outside the organisation's jurisdiction. The commitments state what is undertaken for the availability, the integrity, the confidentiality and the authenticity of customer data, authenticity being the attributability of data, instructions and messages to the party they claim to come from.
Rationale
AICF is written for the provider, but the vendor domain described only the buyer's side of the same relationship: VND-004 is what the organisation owes its own cloud provider and nothing said what it owes its customers. Seven CSA rows and SOC 2 CC2.3 sat unmapped as a result. INC-006 holds notification after an incident; VND-011 holds the standing statement of who is responsible for what before anything goes wrong, which is what a customer scopes its own controls against. VND-002 holds the contractual security terms the organisation signs with its own suppliers, which is where the supply chain half of the model is enforced. GOV-011 holds the internal assessment of the organisation's own share. The usual artefacts are a trust centre page, a responsibility matrix keyed to a published control set and a customer change notice term in the service agreement. Publication is the difference between a statement a customer relies on and one it is shown during a sales cycle, and an agreement that names the page turns that reliance from reputational into contractual. Authenticity is the property the library carried nowhere as a customer-facing commitment: DAT-003 and DAT-004 hold confidentiality in storage and in transit, APP-015 holds integrity detection and MON-010 holds availability, while nothing said the organisation commits to a customer that data and instructions are attributable to their claimed source. VND-012 handles a governmental request once it arrives; the measures described here are what stands in its way before it does. VND-013 carries the same commitments where a customer contract has to state them as terms.
Applicability (9 profiles)
The shared responsibility matrix exists because the customer's workload runs on the provider's service.
Condition: deployment_model in on-prem, hybrid, edge, on-device, embedded, air-gapped
Where the deployer runs the AI system on infrastructure it controls, it owns the responsibility split it publishes to whoever consumes that service. Under cloud-saas or cloud-single-tenant the row is satisfied by the provider: the deployer receives the matrix under VND-004 and reads it against this profile so each inherited control has a named owner.
Condition: deployment_model in cloud-saas, cloud-single-tenant
The shared responsibility matrix exists because the customer's workload runs on the provider's service. Conditional since 1.1: the profile lists every deployment model and this row is a commitment of a hosted service, so a provider that publishes weights or runs on infrastructure the customer controls has no hosted service to carry it (ADR-046 amendment, 2026-09-16).
The shared responsibility matrix exists because the customer's workload runs on the provider's service.
Condition: deployment_model in on-prem, hybrid, edge, on-device, embedded, air-gapped
Where the deployer runs the AI system on infrastructure it controls, it owns the responsibility split it publishes to whoever consumes that service. Under cloud-saas or cloud-single-tenant the row is satisfied by the provider: the deployer receives the matrix under VND-004 and reads it against this profile so each inherited control has a named owner.
EX-103 written in S8 wave B (migration 057). The matrix and the commitments are published where a prospective customer can read them without an account, the customer agreement names where they are published, and the published statement describes the technical, organisational and contractual measures that stand between customer data and an authority outside the organisation's jurisdiction. Art. 28(1)(b) and Art. 28(2) hold full. Art. 28(1) stays partial because its point (a) content, the jurisdiction each service's infrastructure is subject to, sits on DAT-022.
EX-103 and the Art. 30(2)(c) authenticity clause written in S8 wave B (migration 057), on the product owner's decision of 2026-09-14. The commitments now state what is undertaken for the availability, the integrity, the confidentiality and the authenticity of customer data, authenticity being the attributability of data, instructions and messages to the party they claim to come from, so Art. 30(2)(c) holds full. Art. 30(1) still asks for one written contract including the service level agreements, which rules out a boundary published only as a matrix the provider can revise unilaterally; VND-013 carries the contractual form.
The shared responsibility matrix exists because the customer's workload runs on the provider's service.
The shared responsibility matrix exists because the customer's workload runs on the provider's service.
Framework Mappings (29)
| CCC-05 | Change Agreements | full |
| STA-02 | SSRM Policy and Procedures | full |
| STA-03 | SSRM Supply Chain | partial |
| STA-04 | SSRM Guidance | full |
| STA-05 | SSRM Control Ownership | full |
| STA-06 | SSRM Documentation Review | full |
| STA-07 | SSRM Control Implementation | partial |
| CCC-05 | Change Agreements | full |
| STA-02 | SSRM Policy and Procedures | full |
| STA-03 | SSRM Supply Chain | partial |
| STA-04 | SSRM Guidance | full |
| STA-05 | SSRM Control Ownership | full |
| STA-06 | SSRM Documentation Review | full |
| STA-07 | SSRM Control Implementation | partial |
| DORA-Art.28.3 | Register of information on contractual arrangements | informative |
| DORA-Art.30.1 | Written allocation of rights and obligations | informative |
| DORA-Art.30.2.a | Description of functions and ICT services, and subcontracting permission | informative |
| DORA-Art.30.2.c | Availability, authenticity, integrity and confidentiality of data | full |
| DORA-Art.30.2.e | Service level descriptions and their revisions | informative |
| DORA-Art.30.3.a | Full service level descriptions with performance targets | informative |
| DORA-Art.30.3.b | Notice periods and reporting obligations of the provider | informative |
| DORA-ITS-2024/2956-Art.3 | Register of information templates and data quality | informative |
| EU-DA-Art.23 | Removal of Switching Obstacles | informative |
| EU-DA-Art.28.1 | Website Publication of International Access Information | partial |
| EU-DA-Art.28.1.b | Measures Preventing International Governmental Access | full |
| EU-DA-Art.28.2 | Website Reference in Service Contracts | full |
| NIS2-CIR-3.3 | Event Reporting | informative |
| MG-4.1-005 | Post-Deployment AI System Monitoring | MG-4.1-005 | informative |
| CC2.3 | COSO Principle 15: Communicates Externally | full |
Evidence (3)
The shared responsibility matrix published to customers, with the control set it is expressed against, the system boundary description and its review date. The published statement also carries the commitments for availability, integrity, confidentiality and authenticity and the description of the measures that resist access by an authority outside the organisation's jurisdiction.
Example: Shared Responsibility Matrix v4.0, reviewed 2026-07-30, covering the platform and two optional services, expressed against CSA CCM v4.1 with the owner of each control marked provider, customer or shared.
Test: Request the shared responsibility matrix customers are given. Verify: (1) every service offered appears, (2) each control in the named control set is marked as operated by the organisation, by the customer or shared, with no control left unassigned, (3) responsibilities passing to a sub-processor or infrastructure operator are identified, (4) the system boundary and the security commitments are described, (5) the review date falls within the defined interval and follows the most recent change to the service boundary. (6) the commitments name availability, integrity, confidentiality and authenticity and state what is undertaken for each rather than listing the properties, (7) the statement describes the technical, organisational and contractual measures that resist access by an authority outside the organisation's jurisdiction.
Inspection of the customer-facing location where the matrix and the security commitments are published, confirming which version a customer can actually obtain. The inspection is performed without an account, by the route a prospective customer would take.
Example: Walkthrough of the trust centre on 2026-09-08, showing the matrix available on request behind a customer login and the version served matching the reviewed version.
Test: Ask a member of staff to obtain the matrix by the route a customer would use. Verify: (1) the document is reachable by that route without an internal system, (2) the version served is the reviewed version rather than an earlier one, (3) the security commitments shown match those in the matrix, (4) where the route requires a request, the request is answered within the stated time. (5) the route works without an account and without a request being answered, (6) the customer agreement names the location the statement is published at and that name resolves to the page served.
The customer-facing terms governing changes that affect a customer's environment, with the notices issued under them during the period.
Example: Master service agreement clause 9.3 on change notification, with the four customer change notices issued between January and August 2026.
Test: Request the change notification terms and the notices issued in the period. Verify: (1) the terms state which changes require an authorised customer request and which require notice, (2) the notice period is stated, (3) each change in the period that affected customer environments has a matching notice or an authorised request, (4) notices were issued before the change took effect.
Questions (3)
Is the shared responsibility matrix published where a prospective customer can read it without an account?
The test is publication, not existence. A matrix supplied on request, behind a customer login or under a non-disclosure agreement does not meet this, because a customer scoping its own controls before it signs cannot reach it.
What does the customer-facing security documentation cover?
Naming the control set is what makes the matrix usable: a customer scoping its own audit needs to know which framework the rows correspond to. Authenticity is the commitment most often absent, because it is the one no encryption setting produces on its own. The last item is a statement about what is in place, not about how a request is handled once it lands.
When is the shared responsibility documentation reviewed?
Options run from strongest to weakest. A new service or a new sub-processor is what makes the matrix wrong, so the trigger matters as much as the cycle.