Privacy in Cloud Service and Deployment Models

Privacy in Cloud Service and Deployment Models: A Complete CDPSE Guide

Introduction
Privacy in Cloud Service and Deployment Models is a core topic in the CDPSE (Certified Data Privacy Solutions Engineer) Privacy Engineering domain. Organizations increasingly move personal data to the cloud. A privacy engineer must understand how the choice of cloud service model and deployment model changes privacy risk, control ownership, accountability and legal compliance.

Why It Is Important
1. Accountability cannot be outsourced: Under GDPR, CCPA/CPRA, LGPD and similar laws, the organization that determines the purposes and means of processing (the data controller) remains accountable, even when a cloud service provider (CSP) processes the data.
2. Shared responsibility creates gaps: Misunderstanding who is responsible for which control is a leading cause of cloud data breaches, such as misconfigured storage buckets.
3. Data location and cross-border transfers: Cloud data may be stored or replicated across jurisdictions. This triggers transfer restrictions such as GDPR Chapter V, Standard Contractual Clauses (SCCs) and data localization laws.
4. Loss of direct control and visibility: Organizations rely on contracts, certifications and audit reports instead of physical oversight.
5. Multi-tenancy: Shared infrastructure raises risks of data leakage between tenants.
6. Data subject rights: The organization must still be able to locate, access, correct, port and delete personal data held by the CSP.
7. Vendor lock-in and exit: Data must be returned and securely deleted when the contract ends.

What It Is
Cloud Service Models (NIST SP 800-145)
1. Infrastructure as a Service (IaaS): The CSP provides compute, storage and networking. Examples are AWS EC2, Azure VMs and Google Compute Engine.
Customer responsibility: the operating system, middleware, runtime, applications, data, identity and access management, encryption configuration, and most privacy controls.
Privacy implication: This model gives the customer the most control and the most responsibility. The CSP handles physical security and the hypervisor.

2. Platform as a Service (PaaS): The CSP provides the OS, runtime and development platform. Examples are Azure App Service, Google App Engine and managed databases.
Customer responsibility: applications, data, access configuration, and privacy by design in the code.
Privacy implication: Control is shared. The customer must ensure the applications it builds embed data minimization, consent handling and logging.

3. Software as a Service (SaaS): The CSP provides the complete application. Examples are Salesforce, Microsoft 365 and Workday.
Customer responsibility: the data it enters, user access management, configuration settings, and vendor due diligence.
Privacy implication: The customer has the least technical control, so it relies heavily on contracts, Data Processing Agreements (DPAs), SOC 2 or ISO 27701 reports, and CSP privacy features.

Other models: Function as a Service (FaaS, serverless), Database as a Service, Security as a Service and Identity as a Service each follow the same logic. The more the provider manages, the less direct control the customer has.

Cloud Deployment Models
1. Public Cloud: Infrastructure is owned by the CSP and shared among many tenants. It is cost-effective and scalable. Privacy risks include multi-tenancy, data location uncertainty, government access requests and limited audit rights.
2. Private Cloud: Infrastructure is dedicated to one organization, either on-premises or hosted. It offers the greatest control and isolation, which suits highly sensitive data such as health, financial or biometric data. It costs more and needs more internal expertise.
3. Community Cloud: Infrastructure is shared by organizations with common concerns, such as government agencies or healthcare consortiums. Members share compliance requirements, but governance agreements between participants are critical.
4. Hybrid Cloud: This combines two or more models, for example sensitive personal data in a private cloud and less sensitive workloads in a public cloud. Risks include data flows between environments, consistent policy enforcement, and data classification accuracy.
5. Multi-cloud: Multiple public CSPs are used together. This complicates data inventory, consistent controls, and records of processing activities.

How It Works
1. The Shared Responsibility Model
The division of responsibilities shifts by service model:
- On-premises: The customer owns everything.
- IaaS: The CSP covers the physical layer, network infrastructure and virtualization. The customer covers the OS and everything above it.
- PaaS: The CSP also covers the OS and runtime. The customer covers applications and data.
- SaaS: The CSP covers nearly the whole stack. The customer covers data, users and configuration.
Constant across all models: The customer is always responsible for its data, data classification, access governance, and legal accountability to data subjects and regulators.

2. Privacy Lifecycle in the Cloud
- Collection: Collect only what is needed and capture consent where required.
- Storage: Use encryption at rest, data residency selection and segregation.
- Use and processing: Apply purpose limitation, role-based access and pseudonymization.
- Transfer: Use encryption in transit (TLS) and transfer mechanisms such as SCCs, BCRs or adequacy decisions.
- Retention and disposal: Use automated retention policies, crypto-shredding, and certificates of deletion at contract termination.

3. Key Technical Privacy Controls
- Encryption and key management: Customer-managed keys (BYOK, Bring Your Own Key) or Hold Your Own Key (HYOK) reduce CSP access to plaintext. Crypto-shredding enables deletion even in multi-tenant storage.
- Tokenization, pseudonymization and anonymization before data enters the cloud.
- Identity and Access Management: least privilege, MFA, federation and privileged access monitoring.
- Data Loss Prevention (DLP) and Cloud Access Security Brokers (CASB): These provide visibility into SaaS usage and shadow IT.
- Logging and monitoring: Audit trails support accountability and breach detection.
- Data residency controls: Region pinning keeps data within specific jurisdictions.
- Confidential computing: This protects data in use through trusted execution environments.

4. Key Governance and Contractual Controls
- Data Processing Agreement (DPA): defines processing instructions, sub-processors, breach notification timelines, audit rights, assistance with data subject requests, and return or deletion at exit.
- Vendor due diligence: review SOC 2 Type II, ISO/IEC 27001, ISO/IEC 27017 (cloud security), ISO/IEC 27018 (PII in public clouds), ISO/IEC 27701 (PIMS), and CSA STAR.
- Privacy Impact Assessment (PIA) or DPIA before migration.
- Sub-processor management: notification of and the right to object to new sub-processors.
- Right to audit or reliance on independent third-party attestations.
- Exit strategy: data portability formats and verified deletion.
- Government access and law enforcement requests: transparency commitments and a transfer impact assessment (post-Schrems II).

5. Roles
The cloud customer is usually the controller, and the CSP is usually the processor. A CSP may become a controller for its own purposes, such as billing or service analytics. Privacy engineers must map these roles accurately.

Exam Tips: Answering Questions on Privacy in Cloud Service and Deployment Models
Tip 1: Accountability stays with the data owner. If a question asks who is ultimately accountable for personal data in the cloud, the answer is the organization (controller), not the CSP. Responsibility for some tasks can be delegated, but accountability cannot.

Tip 2: Map control to service model. IaaS means the most customer control. SaaS means the least customer control and the most reliance on contracts and assurance reports. If a scenario says the organization needs maximum control over OS-level privacy settings, think IaaS or private cloud.

Tip 3: Sensitive data suggests private or hybrid cloud. When scenarios involve highly regulated data with strict residency requirements, private or hybrid deployment, or public cloud with strong customer-managed encryption, is usually the best answer.

Tip 4: Prioritize contracts for SaaS. With SaaS, the BEST way to ensure privacy is usually a strong DPA, a review of independent audit reports, and configuration of available privacy settings. Technical controls the customer cannot implement are unlikely answers.

Tip 5: Look for the FIRST or BEST step. Before moving personal data to the cloud, the first step is typically to perform a PIA or DPIA and classify the data, then conduct vendor due diligence. Do not jump straight to encryption or technology selection.

Tip 6: Encryption key ownership matters. If the concern is CSP or government access to data, the best answer is usually customer-managed keys (BYOK or HYOK) stored outside the CSP's control.

Tip 7: Data deletion in multi-tenant environments. Physical media destruction is not possible in public cloud. Crypto-shredding and contractual deletion certificates are the preferred answers.

Tip 8: Cross-border transfers. Watch for keywords such as replication, global regions and backup in another country. The correct answer usually involves verifying data location, selecting specific regions, and applying legal transfer mechanisms such as SCCs, BCRs or adequacy decisions.

Tip 9: Sub-processors. If the CSP uses third parties, the customer needs visibility and approval rights through the contract. Flow-down obligations are key.

Tip 10: Hybrid and multi-cloud risk. The main privacy challenge is consistent policy enforcement and data flow visibility across environments. Answers involving centralized data inventory, data classification, CASB and unified IAM are strong.

Tip 11: Shadow IT. Unsanctioned SaaS use is a privacy risk. A CASB, discovery tools and governance policies are the typical answers.

Tip 12: Know the ISO standards. ISO/IEC 27018 covers PII protection in public clouds acting as processors. ISO/IEC 27017 covers cloud security controls. ISO/IEC 27701 extends 27001 and 27002 for privacy management. These often appear as distractors or correct answers.

Tip 13: Eliminate extreme answers. Options such as 'avoid the cloud entirely' or 'transfer all liability to the CSP' are rarely correct. CDPSE favors risk-based, balanced and engineering-focused solutions.

Tip 14: Read for the role perspective. CDPSE is technical and engineering-oriented. Prefer answers that embed privacy by design into architecture, such as minimization, pseudonymization, access control and logging, over purely legal answers. Choose the legal answer only when the question explicitly concerns contracts or compliance.

Quick Summary
- Service models (IaaS, PaaS, SaaS) determine who controls which layers.
- Deployment models (public, private, community, hybrid) determine isolation, ownership and jurisdiction risk.
- The shared responsibility model clarifies duties, but accountability always remains with the data controller.
- Combine technical controls (encryption, key management, IAM, DLP, residency) with governance controls (DPIA, DPA, audits, exit plans).
- In the exam, identify the service model, the data sensitivity, and whether the question asks for the first, best or most effective action. Then choose the risk-based, privacy-by-design answer.