Shared Responsibility and Data Residency in the Cloud

Shared Responsibility and Data Residency in the Cloud (CDPSE – Privacy Engineering)

Overview
Shared responsibility and data residency are two of the most heavily tested cloud privacy concepts in the ISACA CDPSE (Certified Data Privacy Solutions Engineer) exam, particularly within the Privacy Engineering domain. Together they answer two critical questions: Who is responsible for protecting personal data in the cloud? and Where is that personal data physically and legally located? A privacy engineer must understand both in order to design, assess, and operate cloud-based systems that meet regulatory, contractual, and ethical obligations.

Why It Is Important
1. Accountability cannot be outsourced. Under laws such as GDPR, CCPA/CPRA, LGPD, PIPEDA and many others, the data controller (the organization that determines the purposes and means of processing) remains accountable for personal data even when it is processed by a cloud service provider (CSP). Misunderstanding the shared responsibility model leads to security gaps where each party assumes the other is handling a control.
2. Most cloud breaches are customer-side failures. Misconfigured storage buckets, excessive permissions, unencrypted data, and weak identity controls are typically the customer's responsibility, not the CSP's. Knowing the boundary of responsibility prevents these failures.
3. Cross-border transfer restrictions. Many jurisdictions restrict or condition the transfer of personal data outside their borders (for example, GDPR Chapter V, China's PIPL, Russia's data localization law, India's DPDP Act, and sectoral rules in banking, health and government). Data stored or replicated in the wrong region can create unlawful transfers.
4. Government access and legal conflicts. Data residing in, or controlled by companies subject to, certain jurisdictions may be exposed to foreign government access laws (e.g., the US CLOUD Act). This affects risk assessments, transfer impact assessments, and customer trust.
5. Contractual and audit obligations. Data processing agreements (DPAs), service level agreements (SLAs), and audit rights must reflect who does what and where data lives. Privacy engineers translate these requirements into technical controls.

What It Is
The Shared Responsibility Model
The shared responsibility model is a framework that divides security and privacy obligations between the CSP and the cloud customer. The general principle is: the CSP is responsible for security of the cloud (physical facilities, hardware, host infrastructure, virtualization layer), while the customer is responsible for security in the cloud (data, identities, access, configurations, applications). The exact split depends on the service model:

Infrastructure as a Service (IaaS) – The CSP manages physical data centers, network hardware, storage hardware and the hypervisor. The customer manages the guest operating system, patching, middleware, applications, network configuration (security groups, firewalls), identity and access, encryption and data. The customer carries the most responsibility.
Platform as a Service (PaaS) – The CSP additionally manages the operating system, runtime and middleware. The customer manages applications, application-level security, identity, access configuration and data.
Software as a Service (SaaS) – The CSP manages almost the entire stack including the application. The customer still manages its data, user accounts, access rights, configuration settings offered by the application, and its own usage decisions (what data is put in, who can see it, retention settings).

Responsibilities that ALWAYS remain with the customer (data controller):
- Classification and ownership of data
- Determining lawful basis and purpose of processing
- Identity and access management decisions (who gets access)
- Data subject rights fulfillment (the CSP may assist, but the controller is accountable)
- Selecting and governing the CSP (due diligence, contracts)
- Breach notification to regulators and data subjects (the processor must notify the controller)
- Overall accountability and compliance

Data Residency, Data Sovereignty and Data Localization
These terms are related but distinct, and the exam may test the difference:
Data residency – The physical or geographic location where data is stored and processed. Often a business or customer choice (e.g., selecting an EU region).
Data sovereignty – The concept that data is subject to the laws and governance of the country in which it is located (and sometimes of the country of the entity controlling it).
Data localization – A legal requirement that certain data must be stored and/or processed within a specific country's borders.
Related concepts include cross-border data transfer (moving or making data accessible across borders, including remote access from another country) and onward transfer (a processor passing data to sub-processors in other locations).

How It Works
1. Determine roles. Identify the controller, processor(s) and sub-processors. In most cloud arrangements the customer is the controller and the CSP is a processor. Document this in a DPA.
2. Map the responsibility matrix. Use the CSP's published shared responsibility documentation, and build a RACI or responsibility matrix covering each control: encryption, key management, logging, IAM, patching, backup, incident response, deletion, data subject requests. Frameworks such as the CSA Cloud Controls Matrix (CCM) and CAIQ help with this.
3. Perform due diligence on the CSP. Review independent assurance reports (SOC 2 Type II, ISO/IEC 27001, ISO/IEC 27017 for cloud security, ISO/IEC 27018 for protection of PII in public clouds, ISO/IEC 27701 for privacy information management, CSA STAR). Remember: these reports cover the CSP's side only; they do not prove the customer's configuration is secure.
4. Establish contractual controls. The contract and DPA should include: processing only on documented instructions, confidentiality, security measures, sub-processor approval and flow-down obligations, assistance with data subject rights and DPIAs, breach notification timeframes, data location commitments, audit rights, and data return/deletion at contract end.
5. Address data residency.
- Inventory and map data flows, including backups, disaster recovery replicas, logs, telemetry, support access and sub-processors.
- Select regions that meet legal requirements and configure policies to prevent deployment or replication outside approved regions (e.g., organization-level policy restrictions).
- Verify where support personnel access data from, since remote access can constitute a transfer.
- Use legal transfer mechanisms when data leaves a jurisdiction: adequacy decisions, Standard Contractual Clauses (SCCs), Binding Corporate Rules (BCRs), certification frameworks (e.g., EU-US Data Privacy Framework), or derogations.
- Perform Transfer Impact Assessments (TIAs) where required, assessing the destination country's laws and supplementary measures.
6. Apply technical supplementary measures. Encryption at rest and in transit, customer-managed keys (BYOK), hold-your-own-key (HYOK) or external key management where keys stay in-jurisdiction, pseudonymization, tokenization, and confidential computing. If the customer controls the keys and the CSP cannot access plaintext, foreign access risk is significantly reduced.
7. Monitor and audit continuously. Use cloud security posture management (CSPM), logging, configuration monitoring, periodic reviews of CSP certifications and sub-processor lists, and exercise audit rights.
8. Plan for exit and deletion. Ensure data portability, verified deletion (including backups), and certificates of destruction or crypto-shredding at contract termination.

Common Scenario Examples
- A company stores customer records in a SaaS CRM and an employee shares a report publicly. Responsibility: customer (access and configuration).
- A data center suffers a physical intrusion. Responsibility: CSP (physical security), though the customer must still assess impact and may need to notify regulators.
- An unpatched guest OS on IaaS virtual machines is exploited. Responsibility: customer.
- A hypervisor vulnerability exposes tenants. Responsibility: CSP.
- EU personal data is replicated to a US region for disaster recovery without an approved transfer mechanism. Responsibility: controller, because it chose or failed to restrict the configuration and must ensure lawful transfer.

Exam Tips: Answering Questions on Shared Responsibility and Data Residency in the Cloud
Tip 1 – Accountability stays with the controller. If a question asks who is ultimately accountable for personal data or for compliance, the answer is almost always the organization (data controller), not the CSP, regardless of service model. Responsibility for tasks can be shared or delegated; accountability cannot.
Tip 2 – Know the stack per service model. Memorize: IaaS = customer handles OS upward; PaaS = customer handles applications and data; SaaS = customer handles data, users and configuration. Data and access are always the customer's.
Tip 3 – Look for the BEST or FIRST answer. ISACA questions often ask what should be done FIRST. Typically the first step is to identify and classify the data, understand legal/regulatory requirements, or define roles and responsibilities before selecting technical controls. Data inventory and mapping often precede region selection.
Tip 4 – Contracts are the primary mechanism for defining responsibility. When asked how to ensure a CSP meets privacy obligations, prefer answers involving the contract/DPA, right to audit, and independent assurance reports over informal assurances or verbal commitments.
Tip 5 – Assurance reports have scope limits. A SOC 2 or ISO 27001 certificate of the CSP does not cover the customer's configuration. If a question implies the certification removes the need for customer controls, it is a distractor. Also check that the report's scope covers the services and regions being used.
Tip 6 – Residency includes backups, logs and support access. Watch for scenarios where primary data is in-region but backups, DR sites, analytics, or support staff are elsewhere. That is still a cross-border transfer concern.
Tip 7 – Distinguish residency, sovereignty and localization. Residency = where data is; sovereignty = whose laws apply; localization = legal mandate to keep data in-country.
Tip 8 – Encryption with customer-controlled keys is the strongest technical supplementary measure. When asked how to mitigate foreign government access or CSP insider risk, customer-managed keys stored outside the CSP's control (HYOK/external KMS) is usually the best answer.
Tip 9 – Sub-processors matter. The controller must know and approve sub-processors, and obligations must flow down contractually. Answers that ensure visibility and approval of sub-processor changes are usually correct.
Tip 10 – Breach notification chain. The processor (CSP) notifies the controller without undue delay; the controller notifies the regulator and data subjects. Do not choose answers where the CSP is solely responsible for regulator notification unless the scenario states otherwise.
Tip 11 – Think like a privacy engineer. Favor answers that embed privacy by design: configuration policies that technically prevent deployment outside approved regions, automated monitoring, data minimization before migration, and pseudonymization over relying only on policy documents.
Tip 12 – Eliminate absolute answers. Options claiming the CSP is fully responsible, or that the cloud eliminates compliance obligations, are almost always wrong.

Quick Review Checklist
- Controller is accountable; CSP is typically a processor.
- Security OF the cloud = CSP; security IN the cloud = customer.
- Data, identity, access and configuration = always customer.
- Use DPAs, SCCs/BCRs/adequacy, TIAs for cross-border transfers.
- Check residency of backups, replicas, logs, support access and sub-processors.
- Validate CSP with ISO 27001/27017/27018/27701, SOC 2, CSA STAR, within scope.
- Encryption with customer-controlled keys reduces residency and access risk.
- Plan exit: portability and verified deletion.

Mastering these principles allows you to quickly identify who owns a control, whether a data location is lawful, and which mitigating action is most appropriate, which is exactly what CDPSE scenario questions are designed to test.