CCSP Privacy Issues: GDPR, HIPAA, PIPEDA, ISO/IEC 27018, GAPP and PIAs

Regulated private data carries protection duties imposed by law; contractual private data carries duties the parties agreed to. Personally identifiable information (PII) under a privacy statute and protected health information (PHI) under HIPAA are regulated: the obligations exist whether or not any contract mentions them, and a regulator enforces them. Payment card data under PCI DSS is the classic contractual example: the PCI Security Standards Council, an industry body, writes and maintains the standard, and it becomes binding on a merchant through its merchant agreement with the acquiring bank (and on service providers through their contracts).

The two stack rather than replace each other. A payroll provider working for an insurer must meet the privacy law that governs the employees' PII and any extra terms the insurer's contract adds, such as shorter retention periods or audit rights. Breaking the statute exposes the provider to regulators; breaking the extra terms exposes it to its client. One system can also hold both kinds: a subscription business's customer table may carry regulated PII next to card numbers in PCI DSS scope, and each obligation is then enforced through its own channel, the agreement for the card data and the regulator for the personal data.

Enforcement of PCI DSS runs through the payment chain, not through a regulator: consequences flow from the card brands, via the acquirer, to the merchant under its agreement. Writing a standard and assessing against it are different roles from holding the contractual leverage to enforce it.

Protected health information is individually identifiable health information held or transmitted by a HIPAA covered entity or its business associate, covering a person's past, present or future health condition, the care they receive and the payment for that care. Both halves of the definition matter: what the data is, and who holds it.

• Covered entities are health plans, health care clearinghouses and health care providers that conduct standard electronic transactions. A sleep-tracking or diet app sold directly to consumers, working for none of them, is outside HIPAA, so the identifiable health details it collects are not PHI (consumer-protection and state privacy laws can still apply).
• Payment data is PHI: records of what a patient was charged or paid are PHI wherever the covered entity keeps them, whichever department or system handles them.
• Employment records a covered entity holds in its role as employer (such as personnel files or drug-test results held for hiring) are expressly excluded from PHI, as are education records covered by FERPA. Other employment and disability laws protect them.
• De-identified data is not PHI. HIPAA offers two methods: Safe Harbor, which removes eighteen listed identifiers (not only names but also dates more specific than the year, geographic units smaller than a state including most of the ZIP code, record numbers such as a medical record number, and others) with no actual knowledge that the rest identifies someone; and expert determination, where a qualified expert documents that re-identification risk is very small. Stripping only the obvious direct identifiers is therefore not enough.

A business associate is a person or organisation that creates, receives, maintains or transmits PHI on behalf of a covered entity. HHS guidance on HIPAA and cloud computing applies this directly: a cloud provider that stores ePHI is a business associate even when it stores only encrypted data and holds no decryption key (a 'no-view' service). The covered entity needs a business associate agreement (BAA) with it, and the provider is directly liable for complying with the applicable Security Rule requirements. Customer-held keys reduce risk and affect breach analysis, but they do not take the provider outside HIPAA.

The conduit exception is narrow: it is meant for mere carriers, whose only role is moving PHI from one point to another and which hold it no longer than the movement itself requires, such as a telecommunications carrier or internet service provider. A service that keeps PHI for any purpose beyond that, however the data is encrypted, is a business associate. Hosting a covered entity's records does not make the host a covered entity in its own right; it acts on the covered entity's behalf.

HIPAA attaches to the covered entity and its business associates, not to a location: a covered entity that hosts ePHI with a provider outside the United States keeps every HIPAA duty and still needs the BAA. Domain 6.3 covers HIPAA and HITECH as audit and compliance requirements for regulated industries.

FERPA (the US Family Educational Rights and Privacy Act) protects education records held by schools and institutions that receive US Department of Education funding. Disclosing them normally needs written consent from the parent or, once the student is 18 or in post-secondary education, the eligible student. Outsourcing to a cloud vendor works through the school-official exception: an institution may treat a contractor as a school official when the contractor

1. performs an institutional service or function the institution would otherwise use its own employees for;
2. is under the institution's direct control regarding the use and maintenance of the records;
3. uses the records only for the purposes for which they were disclosed, and does not redisclose them without authorisation; and
4. meets the criteria the institution states in its annual notification of FERPA rights for who counts as a school official with a legitimate educational interest.

Purpose limitation is a condition of the exception, not a negotiable term: a vendor that uses education records for its own ends, such as training a product it sells elsewhere, is no longer acting as a school official, and internal approvals cannot stretch the exception to cover that. Directory information (such as names and enrolment status, disclosable after notice and an opt-out) is a separate, narrower exception for low-sensitivity data and does not reach academic performance. Technical safeguards protect records, but FERPA's question is whether a disclosure is authorised, and the answer comes from consent or an exception.

PIPEDA (Canada's Personal Information Protection and Electronic Documents Act) rests on ten fair information principles, the first being accountability: an organisation is responsible for personal information in its possession or custody, including information transferred to a third party for processing, and must use contractual or other means to give it a comparable level of protection while the third party holds it. Moving a database to a SaaS provider, even one abroad, therefore leaves accountability with the Canadian organisation; it is not split with the provider or handed to a foreign regulator.

The Privacy Commissioner's guidelines on processing across borders treat a transfer to a processor as a use of the information for the purpose it was collected for, so it rests on the consent already obtained for that purpose rather than a new authorisation step, and PIPEDA does not dictate where processing happens. What it does require, under the openness principle, is transparency: organisations should tell individuals that their information may be processed in another country and may be accessible to the courts, law enforcement and national security authorities there.

India's Digital Personal Data Protection Act, 2023 (DPDP Act) governs the processing of digital personal data, and uses its own vocabulary for the familiar roles:

Cross-border transfer uses a negative-list model: transfers are allowed by default, and the central government can block particular destinations by publishing a notification. That is the reverse of the GDPR, where a third country needs an adequacy decision or another safeguard. The Act itself sets no general localisation requirement, but it preserves any other Indian law that gives a higher degree of protection or restricts transfers, so sector regulators can still require localisation for particular data. The Act's implementing rules bring its obligations into force in phases.

The main structural difference is sectoral versus omnibus. The United States has no single comprehensive federal privacy law for private-sector data; obligations come from laws aimed at particular sectors or data types, such as HIPAA for health, GLBA for financial institutions, FERPA for education records and COPPA for children online, plus a growing set of state privacy and breach-notification laws. The federal Privacy Act of 1974 applies to federal agencies, not companies. The EU applies one comprehensive regulation, the GDPR, to personal data across almost all sectors, with member-state laws filling defined gaps. Canada (PIPEDA, for private-sector commercial activity) and India (DPDP Act) also take a broad, cross-sector approach.

For a cloud architect this changes how obligations are mapped. On the EU side, one regulation covers health, financial and marketing data alike, with stricter rules for special categories such as health data. On the US side the analysis runs dataset by dataset, against the sector law that applies (HIPAA only if the organisation is a covered entity or business associate; GLBA only if it is a financial institution), plus the laws of the states where the individuals live: California's CCPA, for instance, protects California residents and applies to businesses that meet its thresholds and do business in California, wherever the data is stored. The result is a matrix rather than a baseline: each dataset is checked against whichever sector and state rules reach it.

Building everything to the strictest law is a sound design instinct but not a compliance strategy: stricter is not the same as compliant. US sector laws carry specific requirements (a BAA under HIPAA, GLBA's safeguards and notices) that GDPR compliance does not deliver, and the GDPR has rules no US law has. Map each dataset to every law that attaches to it.

Moving data to a cloud region does not shed the laws that already apply to it. Privacy laws attach to the organisation (where it is established, what sector it is in) and to the people whose data it is (where they are or live). Storage location can add a law, typically governing the provider, but it rarely removes one. Several regimes therefore commonly apply at once.

• A US health plan that runs claims processing in an overseas region is still a HIPAA covered entity; nothing in HIPAA depends on where the servers sit.
• A German manufacturer that keeps its customer-service records in a provider region in Brazil still processes them in the context of an EU establishment: the GDPR keeps applying, the move is a transfer needing a Chapter V mechanism, and the provider may additionally answer to the law of the place where it operates.
• A Japanese web shop with no EU presence that sells to customers in Italy is subject to its own country's law and, through Article 3(2), the GDPR, wherever it hosts the data. Choosing an EU region does not, by itself, turn it into an EU-established controller; the provider's processing there is processor activity.

Location still matters for other reasons: it can trigger transfer rules, localisation requirements and access by foreign authorities. Conflicts between jurisdictions, such as foreign lawful-access laws, are covered in Domain 6.1.

The GDPR applies under Article 3 on two grounds. Article 3(1): processing in the context of the activities of an establishment in the EU, regardless of where the processing takes place. Article 3(2): a controller or processor not established in the EU that offers goods or services to people in the Union or monitors their behaviour there, for example profiling app users' browsing habits to personalise what they see. The test is the person's location in the Union, not citizenship, and storage location is irrelevant.

A non-EU organisation caught by Article 3(2) must generally designate in writing a representative established in a member state where the data subjects are (Article 27). The exceptions are narrow: occasional processing that excludes large-scale special-category or criminal data and is unlikely to result in risk, or a public authority. The representative is a point of contact for supervisory authorities and individuals; appointing one does not give the organisation an EU establishment.

Transfers of personal data to a third country fall under Chapter V:

Constraints decide between workable options. SCCs can cover intra-group transfers, but every exporter-importer relationship must be covered by them (the 2021 clauses allow several parties in one agreement and a docking clause for entities that join later). BCRs instead give the group one internal framework, approved by a supervisory authority, that binds every member, which is why groups seeking a single group-wide mechanism choose them. BCRs are for a group's own entities, not for a contract with an outside provider. Derogations such as consent suit occasional transfers, and in employment consent is hard to show as freely given. For a US provider relying on the Data Privacy Framework, verify that its certification is active and that its scope covers the data. Certification is not all-or-nothing: personal data from the employment relationship is in scope only where the organisation certified for HR data, which also commits it to cooperate with EU data protection authorities. The Framework has faced legal challenge, so confirm its current status before relying on it. An ISO/IEC 27018 certificate is evidence of good processor practice, not a transfer mechanism.

Article 5 sets the principles every processing activity must meet, and the controller must be able to demonstrate compliance with them (accountability, Article 5(2)):

• Lawfulness, fairness and transparency: a legal basis, and clear information to individuals.
• Purpose limitation: collected for specified purposes, not used in incompatible ways.
• Data minimisation: adequate, relevant and limited to what is necessary for the purpose (how much data).
• Accuracy: kept accurate and up to date.
• Storage limitation: kept in identifiable form no longer than necessary (how long). Retention with no defined end point, justified only by possible future use, is the classic conflict with this principle.
• Integrity and confidentiality: appropriate security.

Minimisation is applied to the purpose, not to a general sense of risk. If a delivery dashboard only needs average delivery times per city, the best design exports the city and the time and nothing that identifies a customer. Replacing an identifier with a token or hash produces pseudonymised data, which remains personal data under the GDPR (Recital 26) because it can be linked back to a person with additional information; a stable token still singles each person out. Only truly anonymous data falls outside the Regulation. Encryption protects confidentiality but does not reduce how much data leaves: minimisation and security are separate principles. Data protection by design and by default (Article 25) favours reducing data at the source.

ISO/IEC 27018 is the code of practice for protecting PII in public clouds acting as PII processors. It extends the ISO/IEC 27002 controls with processor-specific ones, built on the ISO/IEC 29100 privacy principles. The controls most often applied:

• Act on the customer's instructions: the processor processes PII only for the cloud service customer's purposes.
• No marketing or advertising use without express consent, and that consent must not be a condition of receiving the service. The consent has to be a separate, specific choice the customer can refuse while still using the service, and data stays PII while anything remains that can single a person out.
• Legally binding disclosure requests (for example from law enforcement) are notified to the customer in line with the procedures and time periods agreed in the contract, unless notification is otherwise prohibited, and PII disclosures are recorded (what, to whom, when). The standard ties timing to the contract rather than fixing it.
• Disclose subcontracted processing before use and disclose the countries where PII may be processed, so the customer, as controller, can check its own obligations (such as transfer rules) before a change.
• Return, transfer or securely dispose of PII at contract end, notify the customer of breaches involving its PII, and bind staff to confidentiality.

ISO/IEC 27017 (cloud security controls) is its sibling; choosing providers by their certifications is covered in Domain 1.5.

The Generally Accepted Privacy Principles (GAPP), developed by the AICPA and CICA (now CPA Canada), set out ten principles for a privacy programme. (The AICPA has since published a Privacy Management Framework as GAPP's successor, but CCSP names GAPP.)

The near-twins are the trap. Access is the individual's own route to review and correct what is held about them, while Quality is the organisation's duty to keep data accurate whether or not anyone asks. Disclosure to third parties governs any sharing outside the organisation, even though consent also has a principle of its own; Use, retention and disposal governs what the organisation itself does with the data.

A privacy impact assessment (PIA) evaluates how a project's handling of personal information could affect the people that information is about, and how to reduce that impact. It describes the data, the data flows and the parties involved, tests whether the processing is necessary and proportionate to its purpose, identifies harm people could suffer (including from lawful but excessive use) and decides the mitigations. ISO/IEC 29134 gives guidelines for conducting one.

Security is one input to a PIA, but a sound security posture does not show that collection, use, sharing and retention are appropriate, so a completed security assessment does not replace it. Timing is the point: a PIA starts during design and is completed before processing begins, so its findings can still change what is collected, which provider is used and which safeguards apply. Any later point leaves in place risks that could have been designed out. It is revisited when the processing changes: a new purpose, a new category of recipient or a new processing location can invalidate the original conclusions, so reassessment comes before the follow-up work, because its findings decide what that work must be.

Under the GDPR the formal version is the data protection impact assessment (DPIA, Article 35). It is required before processing that is likely to result in a high risk to individuals, especially with new technologies; the trigger is the risk of the processing itself. Article 35(3) names three cases that always need one:

1. systematic and extensive evaluation of personal aspects based on automated processing, including profiling, that produces legal or similarly significant effects (such as automated screening that rejects job applicants without human involvement);
2. processing of special categories (health, biometric and so on) or criminal-offence data on a large scale; and
3. systematic monitoring of a publicly accessible area on a large scale.

Supervisory authorities publish further lists. 'Large scale' matters: Recital 91 says processing of patient data by an individual physician is not large scale, so that alone is not an automatic case. Changing where an existing, unchanged operation runs is not high-risk processing in itself; the test looks at the nature, scope, context and purposes of the processing. The controller carries out the DPIA, seeks its data protection officer's advice, and the processor assists.

If the DPIA shows a high residual risk the controller cannot mitigate, Article 36 requires prior consultation with the supervisory authority before processing starts; the authority can advise in writing or use its powers, up to banning the processing. The controller cannot simply accept that risk internally and proceed. Breach notification is a different duty, covered with data roles and enterprise risk in Domain 6.4.