Personally Identifiable Information

Personally Identifiable Information (PII) is the umbrella term for any data that can — alone or in combination — identify a specific human being. The engineering importance of PII is not the term itself but the regulatory regime that attaches once a system holds PII: laws like the EU’s General Data Protection Regulation (GDPR), California’s Consumer Privacy Act (CCPA) and its 2023 amendment the California Privacy Rights Act (CPRA), the US Health Insurance Portability and Accountability Act (HIPAA) for medical data (PHI — Protected Health Information), and the contractual Payment Card Industry Data Security Standard (PCI-DSS) for cardholder data each impose specific, sometimes-conflicting requirements on storage, transit, access, retention, deletion, breach notification, and cross-border transfer.

This is one combined note rather than five separate ones because the regulations all answer the same engineering question — given that I hold sensitive personal data, what must my system do? — and the patterns (encryption, access control, pseudonymization, data residency, deletion pipelines) are reused across them. Splitting GDPR from PHI from PCI from CCPA into atomic notes would force a reader to reconstruct the cross-cutting picture every time. The five regulations differ in who they cover, what data they cover, and what fines they impose, but the engineer-facing controls they demand are largely overlapping.

A separate atomic note can be split out later for any one regulation if a topic deserves much deeper standalone treatment (e.g., a future “PCI-DSS Cardholder Data Environment Architecture” note). For now, the integrated treatment captures the operational reality.

1. PII — The General Term

The US National Institute of Standards and Technology (NIST) defines PII in SP 800-122 as “any information about an individual maintained by an agency, including (1) any information that can be used to distinguish or trace an individual’s identity… and (2) any other information that is linked or linkable to an individual.”

The two clauses correspond to two attack models:

Direct identifiers — fields that identify a person on their own: full name, government ID number (Social Security Number, passport number), email address, phone number, biometric template (face, fingerprint), home address, employee ID. These are obvious and well-handled by most systems.

Indirect identifiers / quasi-identifiers — fields that are not identifying alone but become so when combined. Latanya Sweeney’s famous result (Simple Demographics Often Identify People Uniquely, Carnegie Mellon 2000) showed that 87% of the US population (roughly 216 million of 248 million people) had reported characteristics that likely made them unique based only on the combination of (5-digit ZIP code, gender, date of birth) — three pieces of demographic data that no individual user thinks of as sensitive. The 87% figure was computed against 1990 US Census summary data; a later reanalysis by Philippe Golle (Revisiting the Uniqueness of Simple Demographics in the US Population, WPES 2006) using 2000 Census data put the figure at about 63% — still a clear majority, and the qualitative point (a triple of “harmless” demographics re-identifies most people) stands regardless of which figure you use. This is the linkage attack: an adversary who has one anonymized dataset and one identified dataset can join on quasi-identifiers and re-identify individuals.

The implication for engineers: “we don’t store PII” is almost never true once a system has user records. An IP address can be personal data under GDPR — but the precise basis is more nuanced than it is often stated. Recital 30 does not flatly declare IP addresses to be personal data; it says that online identifiers such as IP addresses and cookies “may be used to create profiles of the natural persons and identify them” when combined with other information. The authoritative ruling is the Court of Justice of the EU’s Breyer decision (Case C-582/14, 19 October 2016), which held that a dynamic IP address held by an online-service operator is personal data for that operator when it has legal means likely to be used to identify the data subject (e.g., by compelling the ISP to link the address to a subscriber). So an IP address is personal data in most real deployments, but as a contextual judgement about means-of-identification, not as a blanket recital-30 declaration. A device fingerprint is similarly personal data. A login timestamp + ZIP code + browser version is, in combination, PII. The conservative engineering posture is: assume any user-derived data is PII unless explicitly proven otherwise via an identifiability analysis.

2. PHI — Protected Health Information

PHI is a stricter subset defined by HIPAA. PHI is any individually identifiable health information held or transmitted by a “covered entity” (healthcare provider, health plan, healthcare clearinghouse) or its “business associate” (any third party processing PHI on behalf of a covered entity — billing companies, cloud providers, EHR vendors).

PHI specifically includes 18 identifiers per the HIPAA Privacy Rule §164.514(b)(2): names, geographic subdivisions smaller than state, dates more granular than year, telephone numbers, fax numbers, email, SSN, medical record numbers, health plan numbers, account numbers, license numbers, vehicle identifiers, device identifiers, URLs, IP addresses, biometrics, full-face photos, and any “other unique identifying number, characteristic, or code”. A dataset stripped of all 18 is “de-identified” under HIPAA’s safe harbor.

Critical engineering implications of HIPAA:

• Business Associate Agreement (BAA) — every vendor (AWS, GCP, Stripe, Twilio, etc.) that touches PHI must sign a BAA. Without a BAA, sending PHI to that vendor is a HIPAA violation per se, regardless of the vendor’s actual security posture.
• Minimum Necessary rule — only the minimum PHI required for a task may be accessed or shared. RBAC is mandatory.
• Audit logs — access to PHI must be logged with user, time, accessed record, and action. Logs must be retained for at least 6 years.
• Breach notification — a breach of unsecured PHI (i.e., not encrypted to an approved standard) of 500+ individuals must be reported to HHS and to media within 60 days.

HIPAA only applies to US covered entities and their BAs. A consumer fitness app that voluntarily collects health data is not a HIPAA covered entity (controversial — see the FTC’s expanding interpretation). But once that app’s data is shared with a doctor or insurer, it enters HIPAA’s domain.

3. GDPR — The EU’s Comprehensive Privacy Regulation

The General Data Protection Regulation (Regulation (EU) 2016/679) took effect 25 May 2018 and is the most influential modern privacy law. Its scope is extraterritorial: it applies to any company processing the personal data of individuals (called data subjects) in the EU, regardless of where the company is located. A US startup with a single EU user is in GDPR scope.

GDPR’s key concepts:

3.1 Lawful Basis for Processing

Every processing operation must have one of six lawful bases (Art. 6):

1. Consent — explicitly given, specific, informed, freely-revocable.
2. Contract — necessary to perform a contract with the data subject.
3. Legal obligation — required by law (e.g., tax records).
4. Vital interests — to protect life.
5. Public task — official authority.
6. Legitimate interests — the catch-all, subject to a balancing test against the data subject’s rights.

Engineering implication: every database column storing personal data should map to a lawful basis. If you cannot articulate which basis covers a particular use, the use is probably not lawful.

3.2 Data Subject Rights (Arts. 15–22)

Data subjects have enforceable rights:

• Right of access — receive a copy of what is held about them.
• Right to rectification — correct inaccurate data.
• Right to erasure (“right to be forgotten”) — have data deleted, with narrow exceptions.
• Right to restrict processing — pause processing while a dispute is resolved.
• Right to data portability — receive the data in a machine-readable format and have it transmitted to another controller.
• Right to object — to processing under “legitimate interests” or for direct marketing.
• Rights regarding automated decisions and profiling — including a right to human review of significant automated decisions.

These rights translate to concrete API endpoints / operational runbooks: “export my data”, “delete my account”, “stop emailing me”. The infrastructure to fulfill them must exist by design, not bolted on after the regulator complains. Many engineering teams discover during their first GDPR access request that their data is sharded across 12 services, several backups, and a data lake and there is no inventory of where one user’s records live.

3.3 Data Protection by Design and by Default (Art. 25)

Privacy must be considered from the earliest stage of system design — not patched in after the fact. Examples cited by regulators:

• Default privacy-preserving settings (opt-in, not opt-out).
• Pseudonymization where the use case allows.
• Encryption at rest and in transit.
• Data minimization (collect only what is needed).

3.4 Breach Notification (Art. 33)

A personal-data breach must be reported to the supervisory authority within 72 hours of becoming aware of it. If the breach poses a high risk to data subjects, those individuals must also be notified. Encryption is a partial safe harbor: if the breached data is encrypted with strong, current crypto and the keys are not also exposed, the notification-to-individuals requirement may be waived.

3.5 Data Protection Officer

Organizations whose core activities involve large-scale monitoring or processing of special-category data must appoint a Data Protection Officer (DPO) with regulatory contact responsibilities. Smaller organizations may also appoint one voluntarily.

3.6 Fines

GDPR fines tier at:

• Tier 1: up to €10 million or 2% of global annual turnover, whichever is higher (recordkeeping, breach-notification failures).
• Tier 2: up to €20 million or 4% of global annual turnover, whichever is higher (basic principles, lawful basis, data subject rights, cross-border transfers).

Real fines have hit eye-popping numbers: Meta €1.2 B (issued 22 May 2023 by the Irish Data Protection Commission for unlawful EU→US transfers of Facebook user data under Standard Contractual Clauses — the largest GDPR fine to date), Amazon €746 M (issued July 2021 by Luxembourg’s CNPD for ad personalization without valid consent), and Google €50 M (issued 21 January 2019 by France’s CNIL for lack of transparency and absence of valid consent for ad personalization, the first major GDPR fine). Note that the Amazon fine is no longer settled law: in 2025 the Luxembourg Administrative Court annulled the €746 M penalty and returned the case to the CNPD for reconsideration, finding the regulator had failed to perform two required analyses — so it stands today as a contested, remanded decision rather than a collected fine. Most fines are far smaller (€10K–€10M range), but the headline-risk is real and the enforcement appetite is increasing.

3.7 Cross-Border Transfer

GDPR restricts transfer of personal data outside the European Economic Area unless the destination country provides “adequate protection”. The US was deemed inadequate by the Court of Justice of the EU twice — first in Schrems I (2015, invalidating Safe Harbor) and then in Schrems II (2020, invalidating Privacy Shield). The current mechanisms (SCCs) require additional safeguards (encryption, transfer impact assessments, contractual clauses); the EU-US Data Privacy Framework (2023) attempts to restore adequacy and is again being challenged.

The engineering response is data residency: keep EU residents’ data in the EU. Implementations include:

• Per-region Multi-Region Active-Active Architecture with regional partitioning by residency.
• Region-aware routing at the API gateway based on user residency.
• Backups stored in-region only.
• Logs scrubbed of PII before cross-region replication.

4. CCPA / CPRA — California’s Consumer Privacy Law

The California Consumer Privacy Act took effect 1 January 2020; the California Privacy Rights Act (CPRA) amended and strengthened it effective 1 January 2023. Together they form the strongest US state-level privacy regime and are the de facto US privacy floor — most companies that comply with CCPA/CPRA simply apply the same controls nationwide because building per-state behavior is impractical.

CCPA/CPRA grants California residents:

• Right to know what personal information is collected, where it came from, what it is used for, and with whom it is shared.
• Right to delete personal information held about them (with broader exceptions than GDPR — e.g., businesses can retain for fraud prevention, legal compliance, internal uses reasonably aligned with consumer expectations).
• Right to correct inaccurate information (added by CPRA).
• Right to opt out of sale of personal information. The “Do Not Sell My Personal Information” link must be on every covered company’s homepage.
• Right to limit use of sensitive personal information (added by CPRA).

CCPA defines a “business” by thresholds (gross revenue >$25M, or buys/sells/shares personal info of >100K California consumers, or derives >50% of revenue from selling personal info). A pure B2B SaaS with few California consumers may be out of scope.

Compared to GDPR:

• GDPR requires a lawful basis upfront; CCPA permits processing absent opt-out.
• GDPR’s right to erasure is broader; CCPA permits more retention exceptions.
• GDPR fines scale with turnover; CCPA fines are per-violation. The statutory base amounts are $2,500perunintentionalviolationand$7,500 per intentional violation, and CPRA added a flat $7,500foranyviolationinvolvingthepersonalinformationofaconsumerunder16,intentionalornot.Thesecapsareinflation-adjusted:asof2026theadjustedmaximaareroughly$2,663 (unintentional) and $7,988 (intentional / minor-related). Critically, each affected California consumer counts as a separate violation, so totals scale with the size of the affected population.
• GDPR requires consent for cookies in many cases; CCPA only requires opt-out for “sale” or “sharing” (where “sharing” includes ad-tech use).

The pragmatic engineering position is to build a single privacy infrastructure that satisfies the stricter regulation (typically GDPR), then layer per-jurisdiction differences as feature flags.

5. PCI-DSS — Cardholder Data, Contractually Enforced

PCI-DSS is not a law. It is a contractual requirement imposed by the major card networks (Visa, Mastercard, American Express, Discover, JCB) on every merchant and service provider that handles cardholder data. Failure to comply means losing the ability to accept card payments — commercially fatal for an e-commerce business.

The standard (PCI Security Standards Council, currently v4.0) defines 6 control objectives and 12 requirements:

1. Install and maintain a firewall configuration.
2. Do not use vendor-supplied defaults for system passwords.
3. Protect stored cardholder data (encryption at rest).
4. Encrypt transmission of cardholder data across open, public networks (TLS).
5. Use and regularly update antivirus software.
6. Develop and maintain secure systems and applications (patching, secure SDLC).
7. Restrict access to cardholder data by business need-to-know (RBAC).
8. Identify and authenticate access to system components (MFA, unique user IDs).
9. Restrict physical access to cardholder data.
10. Track and monitor all access to network resources and cardholder data (audit logs).
11. Regularly test security systems and processes (vulnerability scans, penetration tests).
12. Maintain an information security policy.

The compliance level depends on transaction volume:

• Level 1 (>6M transactions/year): annual on-site assessment by a Qualified Security Assessor (QSA). Expensive ($50K–$500K), invasive.
• Level 2 (1M–6M): annual self-assessment + quarterly scan by an Approved Scanning Vendor.
• Levels 3–4 (<1M): self-assessment.

Cardholder Data Environment (CDE) is the key architectural concept: the network segment(s) where cardholder data is stored, processed, or transmitted. The CDE must be isolated from the rest of the corporate network, and PCI-DSS requirements apply most strictly within the CDE. The aggressive engineering pattern is CDE minimization: route all card data through a third-party processor (Stripe, Adyen, Braintree) so it never enters your servers, removing 90% of PCI scope.

This is why nearly every modern e-commerce platform tokenizes card data at Stripe Elements (the card number goes browser → Stripe directly via JavaScript SDK; only an opaque token is returned to the merchant’s backend). The merchant is reduced to SAQ-A scope — a minimal self-assessment questionnaire — because the merchant’s servers never see the card number.

PCI-DSS prohibits storing certain data after authorization at all: full track data, CVV/CVV2, PIN data — even encrypted. Storing the PAN (Primary Account Number) is permitted only if encrypted, masked when displayed (showing only last 4), and accompanied by strong key management. Most teams simply do not store the PAN; they keep Stripe’s token instead.

6. The Engineering Implications, Cross-Cutting

Across GDPR, CCPA, HIPAA, PCI-DSS — and most modern privacy laws including Brazil’s LGPD, Canada’s PIPEDA, and India’s DPDP Act — the engineer-facing controls cluster:

6.1 Encryption in Transit

TLS 1.2+ for every connection, mTLS within service meshes (see Mutual TLS). HTTP-only is non-compliant in every regime. Modern best practice: TLS 1.3, HSTS preload, certificate pinning for high-value paths.

6.2 Encryption at Rest

Disk-level encryption (AWS EBS encryption, GCP CMEK, on-prem LUKS) is now table stakes. Database-level transparent encryption is layered on top. Field-level encryption (“encrypt the SSN column with a separate key”) is the highest tier — used for the most sensitive fields like SSNs, full PANs, biometric templates. Key management is the hard part: the AWS KMS / GCP KMS / Azure Key Vault pattern is standard, where applications request decryption rather than holding keys directly.

6.3 Access Control

Role-Based Access Control (RBAC) is the baseline. Attribute-Based Access Control (ABAC) handles finer cases (e.g., “doctors can only access their own patients’ charts”). Every regulation requires the principle of least privilege: only the minimum access necessary for a job.

Engineering pattern: every PII-touching query is mediated through an authorization layer (Open Policy Agent, AWS IAM-conditioned access, application-level guards), with policy decisions logged.

6.4 Audit Logging

Who accessed what, when, for what reason. HIPAA mandates this; GDPR Art. 30 effectively requires it (records of processing activities); PCI-DSS Req. 10 lists required log fields. The logs themselves must be tamper-evident (write-once or append-only stores like AWS CloudTrail, Splunk on immutable storage) and retained for the regulatory minimum (6 years for HIPAA; 1 year hot + 1 year cold for PCI; “as long as needed” for GDPR).

A trap: audit logs containing PII are themselves PII stores subject to the same regulations. Logs must be access-controlled, access-logged, and (for GDPR) deletable on right-to-erasure requests.

6.5 Pseudonymization

Pseudonymization replaces direct identifiers with reversible tokens, with the mapping held in a separate, more-tightly-controlled vault. Example: replace email with a stable hash HMAC(K_pseudo, email) (see Hash-based Message Authentication Code for why HMAC, not plain hash — the keyed version is unforgeable). Analytics queries operate on the token; the email-to-token vault is queried only when re-identification is needed (e.g., to send a transactional email).

GDPR explicitly recognizes pseudonymization as a privacy-enhancing measure (Art. 4(5)): pseudonymized data is still personal data (because re-identification is possible), but it qualifies for reduced obligations.

True anonymization (irreversibly stripping all linkable information) takes the data out of GDPR scope entirely — but anonymization is empirically very hard. The Sweeney 2000 result showed 87% of Americans uniquely identified by ZIP+gender+DOB. The Netflix Prize de-anonymization (Narayanan & Shmatikov 2008) showed users re-identified from supposedly anonymized movie ratings cross-referenced with IMDB. k-anonymity, l-diversity, t-closeness, and differential privacy are the formal frameworks; in practice, achieving meaningful anonymization usually requires aggregating to populations of hundreds.

6.6 The Right-to-Erasure Pipeline

The hardest engineering problem GDPR creates. A “delete my account” request must propagate to:

• Primary databases (transactional record).
• Analytics warehouses / data lakes (see Data Lake Architecture) — often a Frankenstein of S3 + Spark + dbt, not designed for selective row deletion.
• Caches (Redis, Memcached, CDN edge caches with PII in URLs).
• Search indexes (Elasticsearch, Algolia).
• Backups (the canonical hard case — most teams do not delete from backups; instead they document a retention policy and ensure restored backups go through a deletion-replay step).
• Logs (PII in logs is the most-violated rule).
• Third-party processors (the CRM, the email provider, the customer-support tool — each must propagate the deletion).
• Derived data (ML training sets that included this user’s data; recommendation embeddings).

Mature implementations build a deletion orchestration service: the user-facing endpoint enqueues a deletion job, which fans out to every system known to hold the user’s data, tracks completion, retries failures, and escalates if any sub-deletion exceeds the SLA (typically 30 days under GDPR). Building this after the fact is a multi-year project. Building it before the fact requires architectural discipline most teams discover they lack.

6.7 Breach Response

GDPR’s 72-hour notification requirement collapses normal incident-response timelines. A typical pre-GDPR incident response was: detect → triage → contain → forensics → public statement → user notification — over weeks. GDPR forces decisions in days.

Encryption at rest is the major mitigation: if a stolen disk is encrypted to AES-256-GCM with keys stored separately and not also exposed, GDPR’s safe harbor applies and the notification-to-individuals requirement may be waived (the supervisory authority must still be notified). This converts encryption from “nice to have” to “the difference between a quiet incident and a public-relations catastrophe”.

6.8 Data Residency

GDPR’s cross-border restrictions, plus Russia’s data-localization law (Federal Law No. 242-FZ), plus China’s Personal Information Protection Law, plus India’s DPDP Act, plus emerging Brazilian and Saudi requirements, mean data residency is now a deployment-architecture concern. The pattern: per-region active-active deployment with a region-aware identity layer that routes each user’s traffic and stores their data in the region of their residency.

Implications:

• ID generation must be region-stamped (so a query knows which region’s database to consult).
• Cross-region features (e.g., a global leaderboard) require either anonymized aggregation or per-region siloing.
• Backups must be in-region.
• The CDN must serve only public, non-PII content cross-region (or regional CDN POPs only).

This is part of why Multi-Region Active-Active Architecture is now a default for any global SaaS, not just for latency or availability.

7. Real-World Compliance Architectures

Stripe absorbs PCI-DSS Level 1 compliance for its merchants. A merchant integrating Stripe Elements never sees a PAN — the card number is collected by JavaScript loaded directly from Stripe’s domain, sent to Stripe, and only an opaque token returned. The merchant’s PCI scope drops to SAQ-A. This is the largest single engineering simplification in modern e-commerce.

AWS HIPAA-eligible services (AWS HIPAA Compliance) are a subset (~150) of AWS services covered by AWS’s BAA. Storing PHI on a HIPAA-eligible service (S3, RDS, EC2, etc.) plus a signed BAA plus appropriate configuration (encryption at rest, encryption in transit, audit logs to CloudTrail) constitutes a HIPAA-compliant deployment. Storing PHI on a non-eligible service (e.g., SimpleDB, certain analytics services) is a violation.

Cloudflare and the Privacy Shield Era: Cloudflare’s global edge serves traffic from EU-resident IPs through whichever POP is closest, which raised cross-border-transfer questions under GDPR. Cloudflare’s response includes regional POPs, the Cloudflare-EU SLA, and per-feature data-flow documentation. This illustrates how GDPR’s constraints reshape even global-edge architectures.

Apple’s privacy positioning — App Tracking Transparency, on-device ML, end-to-end encryption for iCloud where possible — is a competitive bet that compliance posture is also a marketing asset. GDPR did not require ATT; Apple chose to exceed regulation.

8. Pitfalls

8.1 Logging PII (The Canonical Violation)

log.info("User signed up: %s", user.email) is a GDPR violation if logs are retained beyond the operational need or copied to non-EU log aggregators. Emails, phone numbers, IPs, raw request bodies — every common log line is a potential leak.

The fix is a log-scrubbing layer: a structured-logging library that automatically redacts known-sensitive fields, plus a CI check that flags new code logging variables matching PII regexes (e-mail, phone, credit card patterns). Mature shops also do periodic post-hoc audits of log archives.

8.2 Backup Retention Conflicts with Right-to-Erasure

A backup retention policy of 90 days conflicts directly with a 30-day deletion SLA: a backup taken today contains user X’s data, the user requests deletion tomorrow, the deletion completes in primary stores in days, but the backup containing the user’s data still exists for 89 more days.

The pragmatic resolution most teams adopt: document the policy explicitly. Backups are write-once and not selectively edited; on restore, the deletion log is replayed against the restored data before any production traffic touches it; backups age out past retention and are then unrecoverable. This passes GDPR scrutiny if documented and consistent.

8.3 Tracking Pixels + IP + Browser Fingerprint Re-Identifies “Anonymous” Users

A common anti-pattern: an analytics or ads SDK collects “anonymous” usage events tagged only with a session ID. But the same SDK has previously seen this device’s IP, user-agent, screen resolution, font list, canvas-render fingerprint — together a unique device identifier. Any later re-identification of one event with a real user identity (via a logged-in event) re-identifies all the previous “anonymous” events.

GDPR considers this combination personal data. Building “anonymous” telemetry that is actually anonymous requires aggressive aggregation, fingerprint-resistant collection, and short retention — most off-the-shelf analytics SDKs do not meet that bar.

8.4 Consent Fatigue and Dark Patterns

The GDPR-mandated cookie banner has become an infamous user-experience failure: walls of toggles, “Reject All” buttons hidden behind two clicks while “Accept All” is one tap. The European Data Protection Board has explicitly ruled many such designs unlawful (consent must be as easy to refuse as to give). Real consent rates for ad tracking, when banners are designed honestly, are below 20%.

Engineering implication: the analytics and ad-tech architecture must function with most users opted out. Server-side analytics (events emitted by the backend, not the browser) becomes more valuable; cohort-level aggregations replace user-level event streams; first-party data becomes more strategic.

8.5 Cross-Border Transfer Mechanisms Keep Getting Invalidated

The Schrems I (2015), Schrems II (2020), and the now-being-challenged 2023 EU-US Data Privacy Framework demonstrate the legal volatility. Building infrastructure on the assumption that “we’ll just rely on Privacy Shield” or any single mechanism is dangerous. The robust posture is technical minimization — keep EU data in EU regions and avoid transfer where possible — with SCCs as a backstop for the unavoidable cases.

8.6 Confusing PII for the Definition of “Sensitive”

GDPR has a special category of “sensitive personal data” (Art. 9) that requires additional protections: racial/ethnic origin, political opinions, religious beliefs, trade union membership, genetic data, biometric data (for unique identification), health data, sex life or sexual orientation. CCPA’s CPRA amendment introduced a “sensitive personal information” category with similar contents.

Storing a religion or sexual_orientation field in a database is materially different from storing name and email — additional safeguards (tighter access control, more aggressive minimization, often explicit opt-in consent regardless of other lawful basis) are required. Many engineering teams treat all PII uniformly and miss this distinction, which is a documented enforcement target.

9. Worked Example: An E-commerce Platform’s Compliance Map

Consider an e-commerce platform with 12 microservices, 3 regions, and several hundred employees. The map of what data lives where and what regulations apply:

Service inventory and data classification:

Service	Data held	Classification	Regulation
user-profile	name, email, phone, addresses	PII	GDPR, CCPA
auth	password hashes, MFA secrets, JSON Web Tokens	PII (sec credentials)	GDPR, CCPA
payment	Stripe customer IDs, last 4, expiration	Tokenized — not PCI scope	PCI-DSS (SAQ-A only)
cart	session IDs, product IDs	Quasi-identifier (session)	GDPR (IP)
orders	order details, shipping address	PII	GDPR, CCPA
recommendations	user-product affinity vectors	Pseudonymized PII	GDPR
support	chat transcripts, attached files	Potentially-sensitive PII	GDPR, CCPA
analytics	event streams (clicks, views)	Pseudonymized PII	GDPR, CCPA
notifications	email, SMS templates, send logs	PII	GDPR, CCPA
health-app-feature	wellness program biometrics	PHI (potentially)	HIPAA if BAA in place
data-warehouse	snapshot of all of the above	PII + PHI + tokenized PCI	All four
audit-log	who accessed what when	PII	GDPR, HIPAA

Encryption:

• All inter-service traffic is mTLS via Service Mesh System Design.
• All databases are encrypted at rest with KMS-managed keys (AES-256-GCM).
• Especially-sensitive fields (SSN-equivalents in tax records, the health-app’s biometric templates, password hashes) are field-level-encrypted with a separate key from the row encryption.
• Backups are encrypted with a third key class; key custody is held by a separate ops team.

Access control:

• RBAC via the auth layer; ABAC for cases like “support agents can read only the customer they’re currently chatting with”.
• Production database access is via a JIT (just-in-time) approval workflow — an engineer needing to query the prod DB raises a ticket, gets time-boxed access, and every query is logged.
• Audit logs go to an append-only S3 bucket with object-lock enabled, retained for 7 years.

Right-to-erasure flow:

A user submits “delete my account” via the user-profile UI. Behind the scenes:

1. The user-profile service marks the user’s record as deletion_requested_at = now. This is the deletion event.
2. A Kafka topic user-deletion-events is published with the user’s ID.
3. Each downstream service has a consumer subscribing to this topic. On receipt, each service runs its deletion logic:
   • auth invalidates all sessions and JWT denylists the outstanding tokens.
   • orders retains the orders themselves (legitimate-interest exception for tax records, 7-year retention) but anonymizes the personal fields (name → [redacted], address → [redacted], leaves the order line items).
   • payment calls Stripe’s API to delete the customer (Stripe in turn handles its own deletion).
   • recommendations deletes the user’s affinity vectors and triggers a model-retraining job (since the model itself encoded the user’s preferences in its weights — a well-known GDPR problem with ML).
   • support purges chat transcripts older than the legal-hold period.
   • analytics propagates a deletion event into the data warehouse.
   • notifications removes the user from all suppression and active-send lists.
   • health-app-feature follows the HIPAA-stricter retention rules: PHI is destroyed per the HIPAA breach-notification standard.
4. A central deletion-tracker service consumes acks from each service. If all 12 services have not acked within 30 days, the tracker pages an on-call engineer.
5. After the SLA window, the user-profile service finalizes the deletion: hard-deletes the row, removes from search indexes, invalidates all caches.
6. Backups: the deletion event is recorded in a permanent ledger. On any future backup restore, the restored data is filtered against the ledger and any deleted users’ rows are excluded before the restored database accepts traffic.

This pipeline takes years to build correctly. Most teams are still building it under regulatory pressure.

Cross-border:

• EU-resident accounts are stamped at signup with region=eu in their profile.
• All API calls for EU users route to the EU region (eu-west-1).
• Per-region databases hold EU data only.
• Backups stay in-region.
• The data warehouse has per-region partitions; cross-region analytics use only aggregated, anonymized, k-anonymity-validated data.
• The audit log is per-region; a global compliance dashboard aggregates only counters, not raw events.

10. The Big-Picture Takeaway

PII / PHI / GDPR / CCPA / HIPAA / PCI-DSS are not five separate engineering problems. They are five regulatory frames over the same engineering substrate: systems that hold sensitive personal data must encrypt it, control who reads it, log who accessed it, minimize what is retained, prove they can delete it on request, notify rapidly on breach, and keep it within geographic boundaries when required.

The architectural patterns — encryption, RBAC/ABAC, audit logging, pseudonymization, per-region data residency, deletion orchestration — are reusable across all of them. A system designed correctly for GDPR is largely correct for CCPA, mostly correct for HIPAA (assuming the BAAs and access-log retention are extended), and partially correct for PCI-DSS (which adds physical-access and CDE-isolation requirements not directly mirrored in privacy laws).

The economic shift since GDPR enforcement began is that compliance cost has become a real budget line at any company processing user data at scale. A 2023 PwC survey put the median GDPR compliance program at $3Mformid-sizedfirms,andlargefirmsspend$50M+/year on privacy operations. This is dwarfed by the fines, breach-response costs, and brand damage of getting it wrong — but it is a substantial recurring cost that engineering leadership must plan for, not treat as a one-time legal-team project.

Uncertain uncertain

Verify: the specific compliance-cost dollar figures above (“median GDPR program ~$3Mformid-sizedfirms;largefirms$50M+/year”). Reason: these are secondary, survey-derived numbers that vary widely by source, methodology, firm size, and year, and the originating PwC survey was not re-fetched and verified against a primary publication during this revision. The directional claim — that GDPR turned privacy compliance into a substantial recurring budget line rather than a one-off legal-team project — is well supported; the precise dollar amounts are not. To resolve: pull the current IAPP-EY Annual Privacy Governance Report or a dated PwC/Gartner privacy-spend study and replace the figures with cited, year-stamped numbers.

11. See Also

• Mutual TLS — encryption-in-transit foundation for cross-service calls handling PII.
• JSON Web Tokens — the access-token format whose claims often carry PII (email, name).
• OAuth 2.0 — authorization framework whose scopes determine what PII a third party can access.
• OpenID Connect — the authentication layer; ID Token claims are PII.
• Hash-based Message Authentication Code — used for pseudonymization (HMAC of email as a stable token).
• API Gateway System Design — the layer enforcing access control, rate limiting on PII endpoints, audit logging.
• Service Mesh System Design — service-to-service mTLS for in-cluster PII traffic.
• Webhook Delivery System Design — webhooks often carry PII; HMAC signing protects integrity in transit.
• Multi-Region Active-Active Architecture — implements data residency.
• Data Lake Architecture — the most painful place to implement right-to-erasure.
• SWE Interview Preparation MOC
• Authentication MOC
• Major System Designs MOC