13.2 Privacy Requirements (Domain 6.2)
Key Takeaways
- Domain 6.2 covers contractual vs regulated private data (including PHI and PII), country-specific privacy legislation, jurisdictional differences, standard privacy requirements (ISO/IEC 27018, GAPP, GDPR), and Privacy Impact Assessments (PIA).
- Contractual privacy obligations (MSA, DPA, customer agreements) can be stricter than baseline law and remain enforceable even when a statute does not apply.
- Jurisdictional differences in definition of personal data, lawful bases, cross-border transfer, and breach notification drive cloud region design, contracts, and operational playbooks.
- ISO/IEC 27018, GAPP, and GDPR-style principles provide overlapping but distinct vocabularies for protecting personal data in public cloud and enterprise programs.
- On CCSP items, classify data type and jurisdiction first, then choose controls, notices, and DPIA/PIA steps—do not treat all “private data” as identical.
Privacy Requirements
Domain 6.2 requires the CCSP to understand privacy requirements in cloud environments. The outline organizes the topic as:
- Contractual vs regulated private data (e.g., PHI, PII)
- Country-specific legislation related to private data (e.g., FERPA, PIPEDA, GDPR, HIPAA, Digital Personal Data Protection Act)
- Jurisdictional differences in data privacy
- Standard privacy requirements (e.g., ISO/IEC 27018, GAPP, GDPR)
- Privacy Impact Assessments (PIA)
Privacy is broader than confidentiality. Confidentiality is a security property; privacy concerns lawful, fair, and transparent handling of information about people—including purpose limitation, minimization, individual rights, and accountability. Cloud multiplies privacy risk through scale, secondary processing, global support, and complex controller/processor chains.
Contractual vs Regulated Private Data
Not all sensitive data is regulated the same way, and not all privacy duties come from statutes.
| Category | Source of duty | Examples | Cloud notes |
|---|---|---|---|
| Regulated private data | Statute or regulation | PII under privacy law; PHI under health privacy rules; student education records under FERPA | Triggers mandatory safeguards, rights, breach notice, possible residency |
| Contractual private data | Agreement between parties | Customer data protected by MSA/DPA even if a statute is unclear; “confidential information” schedules | May impose stricter retention, audit, or location limits than law |
| Both | Law + contract | PHI processed under HIPAA and a Business Associate Agreement; EU personal data under GDPR and a DPA | Follow the stricter applicable obligation for each control |
| Organizationally sensitive (not necessarily “personal”) | Policy / trade secret regime | Mergers data, source code | Protect as confidential; privacy statutes may not apply if no personal data |
PII and PHI (Exam Vocabulary)
| Term | Working meaning | Typical protections |
|---|---|---|
| Personally Identifiable Information (PII) | Information that identifies or can reasonably identify an individual (definitions vary by law—some use “personal data” more broadly, including online identifiers) | Access control, encryption, minimization, retention limits, subject rights where applicable |
| Protected Health Information (PHI) | Individually identifiable health information in regulated contexts (U.S. HIPAA-oriented term) | Sector safeguards, BAAs, minimum necessary, audit controls, breach assessment rules |
Exam trap: Treating “PII” and “PHI” as interchangeable. All PHI that identifies a person is sensitive personal information in health context; not all PII is PHI. Payment card data is often governed primarily by contractual PCI DSS obligations plus privacy law if it identifies a person.
Why the Distinction Matters Operationally
- Scoping encryption and DLP: Regulated classes may require specific safeguards; contracts may add more.
- Breach notification: Legal clocks vs contractual notice to a customer/controller may both apply—use the earliest hard deadline after counsel review.
- Cloud sharing models: Moving data into a new SaaS tool can create processor relationships requiring DPAs even when security looks fine.
- Audit evidence: Regulators ask about law; enterprise customers ask about contract and SOC mappings.
Country-Specific Legislation Related to Private Data
The outline lists representative laws. Learn what each is about and the cloud design implication, not trivia case citations or invented pass rates.
| Law / regime | Jurisdiction (primary) | Core focus | Cloud implications |
|---|---|---|---|
| GDPR (General Data Protection Regulation) | European Union / EEA (influences global practice) | Personal data processing principles, lawful bases, rights, DPIA for high risk, breach notification, cross-border transfer rules, controller/processor duties | Region selection, SCCs or other transfer tools, records of processing, DPA with CSP, privacy by design |
| HIPAA (Health Insurance Portability and Accountability Act) | United States (health sector context) | Privacy and security rules for protected health information; covered entities and business associates | BAA with CSP/SaaS when they create/receive/maintain/transmit PHI; access controls, audit logs, encryption as addressable/required safeguards in practice |
| HITECH (often tested with HIPAA) | United States | Strengthened enforcement, breach notification concepts, business associate accountability | Cloud BAAs and breach assessment workflows; not a substitute for Security Rule safeguards |
| FERPA (Family Educational Rights and Privacy Act) | United States (education records) | Student education records privacy; parental/student rights | EdTech SaaS must respect school/district control of education records; directory information rules |
| PIPEDA (Personal Information Protection and Electronic Documents Act) | Canada (federal private-sector baseline; provinces may differ) | Fair information principles for personal information in commercial activity | Accountability for transfers, safeguards, breach reporting under applicable Canadian rules |
| Digital Personal Data Protection Act | India (outline-named example of modern national DPDP-style law) | Digital personal data processing, consent/legitimate uses as defined in the Act, rights, obligations of data fiduciaries/processors (local terminology) | Localization-sensitive design where required, contracts with processors, purpose limitation for cloud analytics |
| Other notable models (awareness) | Various | e.g., sector rules, state privacy laws, APAC privacy acts | Multi-national cloud programs need a matrix, not a single “global privacy” checkbox |
Comparative Themes Across Privacy Laws
| Theme | Typical requirements | Cloud control examples |
|---|---|---|
| Lawful basis / consent | Process only with a valid basis | Purpose tagging, consent records, disable secondary AI training on customer data if not allowed |
| Transparency | Notices and policies | In-product notices; processor registers |
| Data subject / individual rights | Access, correction, deletion, portability (varies) | Export tools, deletion workflows across SaaS and backups (with legal hold exceptions) |
| Security safeguards | Appropriate technical and organizational measures | Encryption, IAM, logging, testing |
| Breach notification | Notify authorities and/or individuals within timelines | IR playbooks with privacy counsel; CSP-to-customer notice clauses |
| Cross-border transfer | Restrictions and mechanisms | Region pinning, transfer impact assessments, contractual clauses |
| Processor obligations | Only process on instructions; assist controller | DPA, subprocessors, audit/assurance rights |
HIPAA note for cloud: A CSP that handles PHI for a covered entity or business associate generally needs a Business Associate Agreement and appropriate safeguards. Shared-responsibility still applies: the customer configures access and often encryption keys; the CSP secures the underlying service as contracted.
GDPR note for cloud: Roles matter. A customer organization is often a controller (or joint controller); the CSP is frequently a processor for customer content, while acting as controller for its own account data (billing contacts, etc.). Exam stems that ignore role labels often pick the wrong duty.
Jurisdictional Differences in Data Privacy
Jurisdiction is the authority of a legal system to regulate conduct and enforce rules. Privacy outcomes change when data subjects, controllers, processors, or infrastructure sit in different places.
| Difference area | Why exams care | Design response |
|---|---|---|
| Definition of personal data | Broader definitions pull more logs, IPs, and device IDs into scope | Classify telemetry and logs, not only CRM fields |
| Children’s data | Extra restrictions | Age-gating, parental consent flows, separate storage |
| Employee monitoring | Works council / labor rules in some countries | Privacy notice, proportionality, local HR legal review |
| Government access | Different surveillance and production powers | Transparency reports awareness; encryption and key custody strategy |
| Breach thresholds | Risk-based vs fixed clocks | Dual-track IR procedures |
| Enforcement culture | Administrative fines, private rights of action, criminal exposure | Board-level risk reporting |
| Data localization | Some categories must stay in-country | Sovereign regions, on-prem for edge cases |
| Sector overlays | Health, finance, telecom add rules | Map sector + general privacy together |
Multi-Jurisdiction Operating Model
- Data map — systems, regions, flows, recipients, retention.
- Law matrix — which statutes apply to which processing activities.
- Strictest applicable baseline for global platforms where feasible; localize where law demands divergence.
- Regional processing for high-risk data rather than default global replication.
- Unified IR privacy annex listing authority contacts and content requirements.
- Vendor management that reassesses when a SaaS enables a new region or AI feature.
Exam cue: “We use a U.S. SaaS with EU employees and customers” is a jurisdictional difference problem. Correct answers often include transfer mechanisms, EU-region options, DPA updates, and minimization of employee monitoring data stored globally—not “privacy law does not apply because the vendor is American.”
Standard Privacy Requirements: ISO/IEC 27018, GAPP, and GDPR
Beyond individual statutes, CCSP expects fluency with recognized privacy requirement sets used in enterprise programs and cloud procurement.
ISO/IEC 27018
ISO/IEC 27018 provides a code of practice for protecting Personally Identifiable Information (PII) in public clouds acting as PII processors. It builds on information security management concepts (aligned with the ISO/IEC 27002 control style) with cloud-processor-oriented guidance.
| 27018-oriented theme | Practical meaning |
|---|---|
| Consent / purpose | Process PII only for specified purposes on customer instruction |
| Transparency to cloud customer | Disclose subprocessors and practices relevant to PII processing |
| Customer control | Return, transfer, or dispose of PII on contract end as instructed |
| Security controls | Apply appropriate measures for confidentiality, integrity, availability of PII |
| Data subject rights assistance | Help the cloud customer respond to access/deletion requests |
| Disclosure to third parties | Limit and notify per contract/law; document government requests per policy |
| Breach treatment | Notify cloud customer of PII breaches under agreed terms |
Exam use: When a question asks for a standard aimed at public cloud PII processors, ISO/IEC 27018 is the outline’s anchor. It complements—not replaces—GDPR or local law.
Generally Accepted Privacy Principles (GAPP)
GAPP (developed in the accounting/assurance community) organizes privacy into principles commonly used for privacy programs and attestation discussions:
| GAPP-style principle | Essence |
|---|---|
| Management | Define, document, communicate, assign accountability for privacy policies |
| Notice | Inform individuals about privacy policies |
| Choice and consent | Describe choices and obtain consent where required |
| Collection | Collect only for identified purposes |
| Use, retention, disposal | Limit use; retain only as needed; dispose securely |
| Access | Allow individuals access to their information as appropriate |
| Disclosure to third parties | Disclose only per policy/consent/law |
| Security for privacy | Protect against unauthorized access |
| Quality | Keep information sufficiently accurate and relevant |
| Monitoring and enforcement | Monitor compliance; address complaints and disputes |
GAPP is excellent for program structure questions: policies, notice, choice, collection limitation, and monitoring.
GDPR Principles (as a Standard Requirements Lens)
Even outside Europe, GDPR’s principles are a common exam checklist for “good privacy design”:
| Principle | Cloud design question |
|---|---|
| Lawfulness, fairness, transparency | Do we have a basis and clear notices? |
| Purpose limitation | Is analytics/AI use within stated purpose? |
| Data minimization | Do logs and data lakes keep only needed fields? |
| Accuracy | Can we correct bad profile data across SaaS? |
| Storage limitation | Are retention schedules enforced in object stores and backups? |
| Integrity and confidentiality | Are IAM, encryption, and testing adequate? |
| Accountability | Can we demonstrate compliance (ROPA, DPIA, contracts, logs)? |
Side-by-Side Comparison
| Framework | Best exam hook |
|---|---|
| ISO/IEC 27018 | Public cloud PII processor controls and customer assurance |
| GAPP | Enterprise privacy program principles and assurance language |
| GDPR | Comprehensive legal personal-data regime + global baseline influence |
Use them together: law (GDPR or local) sets mandatory duties; GAPP structures the program; 27018 informs CSP processor control expectations in contracts and certifications.
Privacy Impact Assessments (PIA)
A Privacy Impact Assessment (PIA) — closely related to Data Protection Impact Assessment (DPIA) under GDPR-style regimes — is a structured analysis of how a project, system, or process affects privacy, what risks it creates for individuals, and which mitigations reduce those risks to an acceptable level.
When to Perform a PIA
| Trigger | Examples |
|---|---|
| New cloud service processing personal data | HR SaaS, customer data lake, global CRM |
| Significant change | Enabling generative AI on support tickets; new multi-region replication |
| High-risk processing | Large-scale monitoring, special-category data, systematic profiling, children’s data |
| Cross-border transfer expansion | Moving processing to a new country |
| M&A / data sharing | Combining customer databases across entities |
| Regulatory expectation | DPIA required for high-risk processing under GDPR-like rules |
PIA Process (Practical)
- Describe the processing: purposes, data categories, data subjects, recipients, locations, retention, technologies (including CSP services).
- Consult stakeholders: business owner, security, legal/privacy, and where appropriate works councils or data subjects’ representatives.
- Identify risks to individuals (discrimination, identity theft, loss of confidentiality, chilling effects, incorrect automated decisions).
- Map existing controls (encryption, IAM, minimization, contractual clauses, training).
- Propose additional mitigations (pseudonymization, region lock, disable secondary use, shorten retention, human review of automated decisions).
- Residual risk decision — approve, approve with conditions, or do not proceed; record accountability.
- Monitor — reassess after incidents, feature changes, or law updates.
| PIA output | Use |
|---|---|
| Risk register for privacy | Feeds enterprise risk (Domain 6.4) |
| Required contract clauses | DPA, BAA, transfer tools |
| Control requirements for architecture | Logging, encryption, residency |
| Rights-handling procedures | Access/deletion runbooks across cloud apps |
| Go/no-go recommendation | Governance gate before production |
Cloud-Specific PIA Pitfalls
- Assessing only the application database while ignoring SaaS subprocessors, support access, and backup regions.
- Treating anonymization claims casually—re-identification risk in cloud analytics platforms can remain high.
- Skipping PIA because “the CSP is ISO-certified.” Certification does not assess your purpose, lawful basis, or UI consent design.
- Conducting PIA after go-live only when a regulator asks—late assessments miss design-time privacy by default.
- Confusing security testing (pen test) with privacy assessment; both are needed.
Exam Approach for Domain 6.2
- Classify data as PII, PHI, education records, payment, or other, and note contract vs statute duties.
- Identify jurisdiction(s) of subjects, controller, and processing.
- Match the stem to a named law or standard (HIPAA/BAA, GDPR/processor, 27018, GAPP principle, PIA).
- Prefer privacy by design answers: minimization, purpose binding, residency, DPA, PIA before high-risk go-live.
- Remember security controls support privacy but do not alone satisfy notice, lawful basis, or rights.
Common Traps
- Assuming encryption eliminates privacy obligations.
- Using U.S.-only breach playbooks for EU personal data incidents.
- Ignoring contractual privacy that exceeds legal minimums.
- Equating “de-identified for marketing” with formal anonymization under strict regimes without analysis.
- Deploying global HR monitoring tools without jurisdictional labor/privacy review.
A covered entity plans to store electronic PHI in a public cloud object store. Which combination best reflects Domain 6.2 expectations?
Which standard is specifically oriented toward protecting PII in public cloud services acting as PII processors?
An organization enables a new multi-region analytics feature that profiles customer behavior at large scale using personal data. What privacy governance step should precede production use?
Under a GDPR-style controller/processor model, a customer uses a SaaS CSP solely to process customer-content personal data on documented instructions. Which statement is most accurate?