Privacy Issues — CCSP Study Guide

Classify the data first: PII, PHI, contractual vs regulated

Picture two datasets landing in the same public cloud bucket on the same afternoon: a clinic's appointment records and a newsletter's subscriber list. Both are personal data, yet only the first carries statutory breach-notification duties and criminal liability for mishandling. Every privacy decision in the cloud starts by placing the data on two axes at once, and getting that placement wrong is how the right controls go missing.

The first axis is what kind of personal data it is. Personally identifiable information (PII) is any information that identifies or can be linked to a natural person, either directly through an identifier like a name or government ID, or indirectly when combined with other data, such as an IP address tied to a timestamp. Protected health information (PHI) is the narrower, heavily regulated subset: health information linked to an identifiable individual and held by a HIPAA covered entity or its business associate. The relationship is nested, not parallel: all PHI is PII, but most PII is not PHI. Other special categories the exam expects you to recognize include cardholder data (under PCI DSS^[1], contractual) and the GDPR "special categories" of data such as health, biometrics, and political opinions, which get heightened protection.

The second axis is what governs its handling. Contractual private data is protected because a contract says so, for example a payment-card dataset under PCI DSS or customer data covered by a master service agreement; the remedy for mishandling is contractual, meaning penalties, indemnities, or termination. Regulated private data is protected by statute such as the EU General Data Protection Regulation (GDPR)^[2] or the US Health Insurance Portability and Accountability Act (HIPAA)^[3], and the remedy is enforcement by a regulator with administrative fines and mandatory breach notification. The two are not mutually exclusive: a single record can be both contractual and regulated. When obligations overlap or conflict you satisfy the stricter one. A contract can always add protections beyond the statutory floor, but it can never waive a statutory duty, which is the single most testable consequence of this split.

PII is the outer set; PHI and cardholder data are special subsets. Governance (regulated vs contractual) is a separate axis, and one record can sit on both.

GDPR roles and duties: controller, processor, and the cloud DPA

The clearest line GDPR draws is between two roles, and the cloud almost always assigns them the same way. The controller decides why and how personal data is processed and carries the accountability; the processor acts only on the controller's documented instructions and processes nothing for its own purposes. Moving data into a cloud service does not transfer controllership: the customer remains the controller, and the cloud provider becomes a processor. A provider the cloud provider engages to help deliver the service (a downstream vendor) is a sub-processor. Reading the provider as the controller is the classic mistake, because it leads a team to assume the provider owns a compliance duty that legally still sits with the customer.

Because the customer stays accountable, GDPR Article 28^[2] requires a written data processing agreement (DPA) before the processor touches personal data. The DPA must bind the processor to process only on documented instructions, keep the data confidential, apply appropriate security, assist the controller with data-subject requests and breach notification, disclose and gate sub-processors, and either delete or return the data at the end of the engagement. Article 28 also makes the processor jointly liable when it acts outside instructions, which is why the agreement, not a marketing assurance, is the control.

Data-subject rights the controller must satisfy

GDPR gives individuals rights the controller must be able to honor, and in the cloud that means the contract has to obligate the processor to help: access (a copy of their data), rectification, erasure (the "right to be forgotten"), restriction, portability, and objection. The cloud wrinkle is that satisfying erasure or portability depends on the provider's tooling and on knowing every location the data was dispersed to, so these rights are a design requirement, not an afterthought.

Cross-border transfer in one line

GDPR restricts moving personal data outside the EU/EEA unless a lawful transfer mechanism applies: an adequacy decision for the destination country, standard contractual clauses (SCCs), or binding corporate rules. The reason this lands under privacy and not just general legal risk is that an unlawful transfer is itself a GDPR violation, independent of any breach. The broader conflicting-law and government-access analysis (for example the US CLOUD Act) lives in the Legal Requirements and Unique Risks subtopic; here the point is narrower: pick a transfer basis before the data crosses the border.

In the cloud the customer is the GDPR controller and the provider the processor; Article 28 requires a data processing agreement to bind the whole chain.

Name the right standard: ISO/IEC 27018, GAPP, GDPR

CCSP privacy questions frequently test whether you reach for the correct named standard, and the trap is that they sound interchangeable but answer different questions. The crisp rule: when the question is about protecting PII in a public cloud where the provider is the processor, the answer is ISO/IEC 27018.

ISO/IEC 27018^[4] is a code of practice that extends ISO/IEC 27001/27002^[5] with controls specific to a public-cloud PII processor. Its hallmarks are exactly the duties a cloud customer needs from a provider: process PII only on the customer's instruction, do not use it for the provider's own advertising or marketing, support the customer in meeting data-subject requests, disclose any sub-processors and the countries where data may be processed, and notify the customer of data breaches and of any government request for the data. Certification to 27018 is a way a provider demonstrates these processor commitments, which is why it shows up in provider-evaluation questions.

GAPP, the Generally Accepted Privacy Principles from the AICPA/CICA (later folded into the AICPA privacy management framework), is different in kind: it is a management framework organized around principles such as notice, choice and consent, collection, use and retention, access, disclosure, security, quality, and monitoring. Reach for GAPP when the question is about building or assessing an organization's overall privacy program, not about a specific cloud-processor control. GDPR, by contrast, is binding law, not a voluntary code; it sets enforceable rights and duties and its fines (up to the greater of 20 million euros or 4% of global annual turnover for the most serious infringements) are what make it the privacy statute the exam leans on. A provider can be certified to ISO/IEC 27018 and still leave the customer responsible for GDPR compliance, because a standard demonstrates control maturity while the law assigns the legal duty.

Quick disambiguation

ISO/IEC 27018 answers: how does a public-cloud provider protect the PII it processes? (cloud-PII code of practice)
GAPP answers: how do we structure and assess our privacy program? (management framework)
GDPR answers: what does the law require and what happens if we fail? (binding regulation)
Do not confuse 27018 with ISO/IEC 27017, the cloud security (not privacy) controls standard, or with ISO/IEC 27701, the privacy information management system extension.

Privacy Impact Assessments (PIA / DPIA)

A Privacy Impact Assessment (PIA) is the process of identifying and reducing the privacy risk of an activity before it goes live, so it is a preventive control, not a post-incident review. Under GDPR the same exercise is called a Data Protection Impact Assessment (DPIA), and GDPR makes it mandatory when processing is likely to result in a high risk to individuals, for example large-scale processing of special-category data, systematic monitoring of a public area, or large-scale profiling that produces legal effects.

The value of a PIA in cloud is timing: it forces the privacy questions while you can still change the design, such as choosing a region for data residency, deciding to tokenize or pseudonymize before upload, or rejecting a sub-processor whose locations you cannot accept. Run it too late and the only options left are expensive retrofits.

The DPIA flow the exam expects

The assessment moves through a predictable sequence. First, describe the processing: what data, whose, why, how, and where it flows. Second, assess necessity and proportionality: is this processing actually needed for the purpose, and is the data minimized? Third, identify and rate the risks to individuals (re-identification, unlawful transfer, excessive retention). Fourth, identify mitigations and decide whether the residual risk is acceptable. If high risk remains after mitigation, GDPR requires the controller to consult the supervisory authority before proceeding. The output is a documented record the controller keeps as evidence of accountability.

The cloud-specific twist is that several DPIA inputs (data location, sub-processor list, breach-notification timelines, deletion guarantees) come from the provider, which ties the DPIA back to the data processing agreement and to the provider's ISO/IEC 27018 disclosures. A DPIA done without those provider facts is incomplete.

DPIA sequence (GDPR Articles 35-36): describe, test necessity, rate risk, mitigate; if high risk remains, consult the supervisory authority before proceeding.

Exam-pattern recognition

CCSP privacy items reward whoever classifies the data and names the right artifact fastest. A handful of stems recur, and each has a tell.

"Who is the controller / processor?"

When a scenario puts a company's customer data into a SaaS or IaaS provider and asks who is responsible, the company is the controller and the provider is the processor; the company keeps accountability. The tempting wrong answer is to make the provider the controller because it physically holds the data. Physical custody does not confer controllership; deciding the purpose does.

"Which agreement is required?"

If the data is EU personal data going to a processor, the answer is a GDPR Article 28 data processing agreement. If the data is US PHI going to a vendor, the answer is a HIPAA business associate agreement (BAA). Distractors swap these or offer a generic NDA, which protects confidentiality but does not satisfy either statutory requirement.

"Which standard protects PII in the cloud?"

The answer is ISO/IEC 27018. The distractors are ISO/IEC 27001 (the ISMS, broader and not PII-specific), ISO/IEC 27017 (cloud security, not privacy), and GAPP (a privacy management framework, not a cloud-processor control set). Match the word "cloud" plus "PII" to 27018.

"When must you do a DPIA?"

When processing is high risk to individuals (large-scale special-category data, systematic monitoring, large-scale profiling). The trap answer treats a DPIA as either always required or merely optional; it is conditional on high risk, and a DPIA done after deployment has lost its purpose because it is a preventive control.

"Is this still personal data?"

Anonymized-beyond-recovery data is out of scope; pseudonymized data that can be re-linked with a key is still personal data and stays in scope. The classic miss is treating pseudonymization as if it were anonymization and concluding the privacy rules no longer apply.

Contractual vs regulated conflict

When a contract term appears to permit something a statute forbids, the statute wins; a contract can raise the protection floor but cannot waive a regulator-enforced duty. An answer that says "the contract allows it, so it is fine" is wrong whenever a privacy law is in play.

Privacy obligations by data type and governing source

Dimension	Contractual private data	Regulated PII	Regulated PHI
Governing source	A contract you negotiated (e.g. PCI DSS, MSA)	Privacy statute (e.g. GDPR)	Health statute (e.g. HIPAA/HITECH)
Who enforces	The counterparty, via contract terms	A data protection authority / regulator	HHS Office for Civil Rights (US)
Typical penalty	Contractual fines, termination, liability	Administrative fines up to 4% of global turnover	Civil and criminal penalties per violation
Cloud agreement needed	Terms in the MSA / DPA as negotiated	Article 28 data processing agreement	Business associate agreement (BAA)
Can a contract waive it?	Yes, parties set the terms	No, statutory duty stands regardless	No, statutory duty stands regardless

Decision tree

Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

PHI is a regulated subset of PII, not a parallel category

Personally identifiable information (PII) is anything that identifies a person directly (name, government ID) or indirectly (an IP address plus a timestamp). Protected health information (PHI) is the narrower set: health data tied to an identifiable individual and held by a HIPAA covered entity or business associate. Treat them as nested, all PHI is PII, but most PII is not PHI, because the label drives which controls legally attach.

Trap Treating PHI and PII as separate, parallel buckets and applying only baseline PII handling to health data, which strips the stronger HIPAA controls PHI legally requires.

Indirect identifiers still make data PII

Data does not need a name to be personal; if it can be linked to an individual when combined with other data, it counts. An IP address, a device ID, or a location trail plus a timestamp are PII under GDPR's broad definition. The practical effect is that telemetry you assumed was anonymous becomes in-scope the moment it can be joined back to a person.

Trap Assuming only direct identifiers like names count as PII, so quasi-identifiers (IP, device ID, geolocation) escape privacy obligations.

Pseudonymized data is still personal data; only true anonymization is out of scope

Pseudonymization replaces identifiers with a token but keeps a key that can re-link to the individual, so under GDPR it remains personal data with full obligations. Only irreversible anonymization, where no one can re-identify the person, falls outside privacy law. Pseudonymization is a risk-reducing security measure, not a get-out-of-scope move.

Trap Treating pseudonymized data as anonymized and concluding the privacy rules no longer apply; the re-linking key keeps it in scope.

1 question tests this

During a compliance audit, an organization discovers that cloud audit logs forwarded to its centralized SIEM contain personally…

Contractual private data is what you promised; regulated private data is what the law commands

Contractual private data is protected because a contract says so, such as cardholder data under PCI DSS or customer data under a service agreement, and the remedy is contractual (penalties, termination). Regulated private data is protected by statute like GDPR or HIPAA, and the remedy is a regulator's fines and mandatory breach notification. A single record can be both at once.

A contract can raise the privacy floor but never waive a statutory duty

When a contract term and a privacy statute conflict, the statute wins; a contract can add protections beyond the law but cannot contract out of a regulator-enforced obligation. So an answer that says the provider's terms permit something a privacy law forbids is wrong whenever a statute is in play. Where obligations overlap, you satisfy the stricter one.

Trap Reasoning that because the cloud contract allows a use of personal data, it is compliant, even though a statute like GDPR forbids it.

In the cloud the customer is the controller and the provider the processor

The controller decides why and how personal data is processed and holds the accountability; the processor acts only on the controller's documented instructions. Putting data in a cloud service does not transfer controllership: the customer stays the controller and the provider becomes a processor (or sub-processor). Physical custody of the data does not make the provider the controller.

Trap Naming the cloud provider as the controller because it physically holds the data, which wrongly shifts the accountability that stays with the customer.

6 questions test this

GDPR Article 28 requires a data processing agreement before processing

Because the customer stays accountable, GDPR Article 28 requires a written data processing agreement (DPA) before a processor touches personal data. The DPA must bind the processor to act only on documented instructions, keep data confidential, secure it, assist with data-subject requests and breach notice, gate and disclose sub-processors, and delete or return data at the end. The DPA, not a marketing assurance, is the control.

Trap Relying on a generic NDA or the provider's standard terms of service in place of a DPA; an NDA protects confidentiality but does not meet Article 28.

US PHI to a cloud vendor needs a HIPAA business associate agreement

When PHI flows from a covered entity to a vendor that handles it, HIPAA requires a signed business associate agreement (BAA) making the vendor a business associate bound to the Security and Privacy Rules. A cloud provider that stores or processes PHI is a business associate even if it never views the data. No BAA means the arrangement is non-compliant from the start.

Trap Substituting a GDPR-style DPA or a generic NDA for a BAA when the regulated data is US PHI; HIPAA specifically requires the BAA.

4 questions test this

ISO/IEC 27018 is the code of practice for protecting PII in public clouds

ISO/IEC 27018 extends ISO/IEC 27001/27002 with controls for a public-cloud provider acting as a PII processor: process PII only on customer instruction, do not use it for the provider's own marketing, support data-subject requests, disclose sub-processors and data locations, and notify the customer of breaches and government access requests. Provider certification to 27018 is how it demonstrates these commitments.

Trap Choosing ISO/IEC 27017 (cloud security controls) or ISO/IEC 27001 (the general ISMS) when the question specifically asks about protecting PII in the cloud; 27018 is the cloud-PII answer.

7 questions test this

GAPP is a privacy management framework, not a cloud-processor control set

The Generally Accepted Privacy Principles (GAPP) from the AICPA/CICA organize a privacy program around principles such as notice, choice and consent, collection, use and retention, access, disclosure, security, quality, and monitoring. Reach for GAPP when assessing or building an organization's overall privacy program, not when picking a specific cloud-provider control. It is a framework, not law and not a cloud-specific standard.

Trap Picking GAPP for a question about a specific public-cloud PII control; GAPP frames a whole program, while ISO/IEC 27018 names the cloud-processor control.

GDPR is binding law with fines up to 4% of global turnover

GDPR is enforceable EU regulation, not a voluntary code, and its most serious infringements carry administrative fines up to the greater of 20 million euros or 4% of total worldwide annual turnover. That enforcement power is why GDPR is the privacy statute CCSP leans on. A provider being certified to ISO/IEC 27018 does not discharge the customer's GDPR duty.

Cross-border transfer of EU personal data needs a lawful mechanism

GDPR restricts moving personal data outside the EU/EEA unless a transfer mechanism applies: an adequacy decision for the destination country, standard contractual clauses (SCCs), or binding corporate rules. An unlawful transfer is itself a GDPR violation independent of any breach. Confirm the basis before the data crosses the border, not after.

Trap Assuming encryption or a contract clause alone legitimizes an international transfer; without an adequacy decision, SCCs, or BCRs the transfer is unlawful.

2 questions test this

The controller must be able to satisfy data-subject rights

GDPR gives individuals rights the controller must honor: access, rectification, erasure (right to be forgotten), restriction, portability, and objection. In the cloud, satisfying erasure or portability depends on the provider's tooling and on knowing every location the data was dispersed to, so the DPA must obligate the provider to assist. Build for these rights up front rather than retrofitting.

3 questions test this

A PIA is a preventive control run before processing begins

A Privacy Impact Assessment (PIA) identifies and reduces privacy risk before an activity goes live, so it is preventive, not a post-incident review. In the cloud its value is timing: it forces choices like data residency, tokenization, or rejecting an unacceptable sub-processor while the design can still change. Run it after deployment and only costly retrofits remain.

Trap Treating a PIA as a post-deployment audit; assessing privacy risk after go-live forfeits the point of the control.

1 question tests this

Your company is building a new cloud application that will collect PII through public-facing APIs. According to the privacy by design…

GDPR makes a DPIA mandatory for high-risk processing

Under GDPR the PIA is called a Data Protection Impact Assessment (DPIA), and it is required, not optional, when processing is likely to be high risk to individuals: large-scale special-category data, systematic monitoring of a public area, or large-scale profiling with legal effects. A DPIA is conditional on high risk, neither always required nor merely a nice-to-have.

Trap Claiming a DPIA is always required or always optional; it is specifically triggered by high-risk processing.

If high risk remains after a DPIA, consult the supervisory authority first

A DPIA moves through describe the processing, test necessity and proportionality, rate the risks to individuals, then apply mitigations. If high risk still remains after mitigation, GDPR requires the controller to consult the supervisory authority before proceeding. The documented DPIA is kept as evidence of accountability.

Trap Proceeding with processing that is still high risk after mitigation without prior consultation; GDPR requires consulting the supervisory authority first.

Cloud DPIA inputs come from the provider, tying it to the DPA

Several DPIA inputs (data location, sub-processor list, breach-notification timelines, deletion guarantees) are facts only the provider can supply, which links the DPIA back to the data processing agreement and the provider's ISO/IEC 27018 disclosures. A DPIA written without those provider facts is incomplete and understates the real risk.

Jurisdiction is set by where data subjects are, not only where servers sit

GDPR applies extraterritorially: it covers processing of EU residents' personal data even by a controller or processor with no EU establishment, when it offers goods or services to, or monitors, people in the EU. So choosing a non-EU cloud region does not by itself escape GDPR if the data subjects are in the EU. Privacy obligations follow the people, not just the hardware.

Trap Assuming hosting data outside the EU removes GDPR obligations; the regulation reaches processing of EU residents' data regardless of server location.

Country-specific privacy laws layer on top of the baseline

Beyond GDPR, regional statutes add their own duties: HIPAA/HITECH for US health data, and other national or sector laws for the same dataset depending on where individuals reside. When a dataset spans jurisdictions, the controller must meet each applicable law, and overlapping obligations resolve to the stricter requirement. Map the data subjects to laws before designing controls.

ISO/IEC 27018 is distinct from 27017 and 27701

Keep the cloud ISO family straight: 27018 is cloud PII protection (privacy, provider as processor), 27017 is cloud security controls (not privacy), and 27701 is the privacy information management system extension to 27001 that operationalizes a PIMS. A question naming public-cloud PII processing points to 27018 specifically.

Trap Confusing ISO/IEC 27018 with 27017 (cloud security) or 27701 (privacy management system); only 27018 is the cloud-PII processor code of practice.

Enforce privacy data minimization with least-privilege, field-level IAM

Data minimization (GDPR Articles 5(1)(c) and 25) is enforced technically by restricting access to only the data each role needs. Role-based or attribute-based IAM that limits visibility to the required PII fields, plus periodic entitlement reviews to strip unneeded permissions, is the direct control; when a PIA finds excessive exposure, tightening these access controls is the first corrective step.

Trap Reaching for broad encryption or logging first, when minimization is about restricting who can see which fields.

8 questions test this

Pick static masking, dynamic masking, or tokenization by where the data lives and who sees it

De-identification choices differ by use case: static data masking irreversibly replaces PII with realistic fictitious values in a non-production copy for dev/test; dynamic data masking redacts fields at query time based on IAM role so support staff see only what they need; tokenization replaces values (such as PANs) with non-sensitive tokens, narrowing PCI-DSS scope, but the token vault holding the originals stays subject to data-residency and sovereignty law.

Trap Using dynamic masking to create a dev/test dataset, when only static masking gives an irreversibly de-identified copy.

4 questions test this

Centralize consent and data-subject-right enforcement at the API gateway

Privacy-by-design favors a single policy enforcement/decision point rather than scattering checks across services. A consent-management API acts as a policy decision point that evaluates each data-access query against stored consent before processing, and a dedicated data-subject-request endpoint at the API gateway orchestrates actions like Article 17 erasure across all downstream microservices.

3 questions test this

Classify the data first: PII, PHI, contractual vs regulated

GDPR roles and duties: controller, processor, and the cloud DPA

Data-subject rights the controller must satisfy

Cross-border transfer in one line

Name the right standard: ISO/IEC 27018, GAPP, GDPR

Quick disambiguation

Privacy Impact Assessments (PIA / DPIA)

The DPIA flow the exam expects

Exam-pattern recognition

"Who is the controller / processor?"

"Which agreement is required?"

"Which standard protects PII in the cloud?"

"When must you do a DPIA?"

"Is this still personal data?"

Contractual vs regulated conflict

Privacy obligations by data type and governing source

Decision tree

Cheat sheet

References