Compliance and Data Governance: GDPR, HIPAA, PCI-DSS, and Data Sovereignty
Learn how regulatory frameworks like GDPR, HIPAA, and PCI-DSS shape system design, plus data classification, retention policies, audit logging, and cross-border data transfer.
Compliance Is a System-Design Constraint, Not a Legal Checkbox
It's tempting to treat compliance as something legal signs off on after the system is built. In practice, regulatory requirements shape where data lives, how it's deleted, who can access it, and how it's encrypted — decisions that are architectural, not cosmetic. Retrofitting "delete this user's data everywhere" or "keep this data inside the EU" onto a system that wasn't designed for it is often a multi-quarter project. Getting it right from the start is a design decision, same as choosing a database.
Key insight: If a regulation requires you to delete, locate, or restrict a piece of data, that requirement belongs in your data model and architecture diagrams — not just in a policy document. Ask "can our system actually do this?" before you ask "have we documented that we should?"
GDPR Essentials for Engineers
GDPR (EU General Data Protection Regulation) governs personal data for EU residents, but its patterns show up in similar laws worldwide (CCPA, LGPD, etc.).
Right to Be Forgotten (Data Erasure)
Users can request deletion of their personal data. This sounds simple — DELETE FROM users WHERE id = ? — until you account for everywhere that data actually lives:
This is architecturally hard, and that's the point. Backups are often immutable snapshots not designed for surgical per-record deletion. Event logs and data warehouses are frequently append-only and built for analytics, not for finding and removing one user's rows across years of history. Designing for erasure means either (a) tokenizing/pseudonymizing personal data at ingestion so raw PII lives in one deletable place, or (b) building deletion into the retention policy of every downstream system from day one, rather than promising a capability the architecture can't deliver.
A common practical pattern: store a pseudonymous user ID everywhere (logs, warehouse, analytics events), and keep the mapping from that ID to actual PII in a single, small, deletable table. Erasure then means deleting one row instead of hunting across a dozen systems.
Data Portability
Users can request their data in a structured, commonly used, machine-readable format (JSON/CSV export), not a PDF or a support ticket reply. Designing this well usually means building a "user data export" job as a first-class feature, not a one-off script written under deadline pressure when the first request arrives.
Consent and Purpose Limitation
| Principle | What it means for design |
|---|---|
| Purpose limitation | Data collected for one purpose (e.g., billing) can't silently be repurposed (e.g., ad targeting) without new consent |
| Consent granularity | Consent should be trackable per purpose, not a single global opt-in flag |
| Consent withdrawal | Withdrawing consent must actually stop the downstream use — this implies consent state needs to be checked at the point of use, not just at collection |
HIPAA Essentials
HIPAA governs Protected Health Information (PHI) in US healthcare systems — anything that ties health data to an identifiable person.
Minimum Necessary Access
The core HIPAA principle: every role should see only the PHI it needs for its function, nothing more. A billing service doesn't need diagnosis notes; a scheduling service doesn't need lab results.
Why This Pushes Toward Field-Level Encryption and Strict RBAC
Coarse, table-level or database-level access control can't express "billing sees insurance fields but not diagnosis fields on the same patient record." That pushes designs toward:
- Field-level encryption, where different fields are encrypted with different keys, and services are only granted the keys for the fields their role needs.
- Strict RBAC (or ABAC for finer-grained conditions like "only the treating physician") enforced at the data layer, not just the API layer — because a bug in one API shouldn't mean the database has no second line of defense.
Audit Trail Requirements
HIPAA requires being able to answer "who accessed this patient's record, and when?" for every access, not just writes. This means read access to PHI must be logged — a requirement ordinary application logging usually doesn't meet, since most systems only log writes and errors by default.
A HIPAA audit failure is rarely "we got hacked" — it's more often "we couldn't produce the access log an auditor asked for." Build PHI access logging in from the start; retrofitting it means you can't answer for the gap in your history before it existed.
PCI-DSS Essentials
PCI-DSS governs how payment card data is stored, processed, and transmitted.
Prefer Not to Store Card Data at All
The single most effective PCI-DSS strategy for most systems: don't store raw card numbers, ever. Instead, use a payment processor (Stripe, Braintree, Adyen) that returns a token representing the card, and store the token.
This shrinks your PCI-DSS scope dramatically: if raw card numbers never touch your servers, the compliance burden shifts largely to the processor, which is built and audited for exactly this.
Network Segmentation of the Cardholder Data Environment (CDE)
If any part of your system does need to touch raw card data (rare, and worth avoiding), PCI-DSS requires that environment to be network-isolated — a dedicated segment with tightly controlled ingress/egress, separate from the rest of the application infrastructure, so a breach elsewhere in the system can't reach cardholder data.
| Approach | PCI-DSS scope | Complexity |
|---|---|---|
| Tokenize via processor, never touch raw card data | Minimal | Low |
| Store tokens + last-4 digits for display | Minimal | Low |
| Handle raw card data in-house | Full CDE, network segmentation, annual audit | High |
Scope reduction is the PCI-DSS strategy, not a workaround. The fewer systems that touch raw cardholder data, the fewer systems that need to pass the audit. Most engineering teams should treat "never let raw card numbers reach our servers" as a hard architectural rule.
Data Classification
Before you can apply the right controls, you need to know what kind of data you're looking at. A simple four-tier scheme covers most organizations:
| Tier | Examples | Storage | Encryption | Access |
|---|---|---|---|---|
| Public | Marketing content, published docs | Any | Not required | Anyone |
| Internal | Internal wikis, non-sensitive metrics | Company systems only | In transit | All employees |
| Confidential | Customer PII, contracts, source code | Access-controlled systems | At rest + in transit | Need-to-know roles |
| Restricted | PHI, payment card data, credentials, SSNs | Dedicated, hardened systems | At rest + in transit, often field-level | Named roles, logged access |
Classification isn't a paperwork exercise — it should be a tag on the data itself (a column, a metadata field, a schema annotation) that downstream tooling can act on: encryption-at-rest policies, backup retention, who can query it, and whether access gets audit-logged all flow from this tag.
Retention Policies
"Keep everything forever" feels safe but is actually a growing liability: more data to secure, more data a breach can expose, more data that outlives the legal basis you originally had for holding it, and (under GDPR-style laws) a violation of storage limitation principles in its own right.
What a Retention Policy Needs
| Component | Purpose |
|---|---|
| Retention period per data type | Different data has different justified lifespans (session logs: days; financial records: years, often legally mandated) |
| Automated deletion pipeline | Manual deletion doesn't scale and gets skipped under deadline pressure |
| Legal hold exception | Litigation or investigation can require suspending deletion for specific data — the pipeline must support pausing, not just running on a timer |
| Documented justification | Regulators and auditors will ask "why do you keep this for X years" — have an answer tied to a legal or business requirement |
Legal hold and automated deletion must coexist. A purely automated deletion pipeline that can't be paused for specific records under litigation hold creates real legal risk — deleting evidence you were required to preserve is its own violation, separate from and sometimes worse than over-retention.
Audit Logging
Audit logs answer "who did what, to which record, when" — and they are a distinct system from application logs, not the same thing with a different log level.
| Property | Application Logs | Audit Logs |
|---|---|---|
| Purpose | Debugging, operational visibility | Accountability, compliance evidence |
| Mutability | Can be rotated/deleted freely | Should be immutable / tamper-evident |
| Content | Whatever's useful for debugging | Structured: actor, action, resource, timestamp, outcome |
| Access | Engineering | Restricted — often compliance/security only |
| Retention | Short (days to weeks typical) | Long, often regulator-mandated (years) |
Minimum Audit Log Fields
timestamp, actor_id, actor_role, action, resource_type, resource_id,
outcome (success/denied), source_ip, and — for PHI/restricted-tier data —
the specific fields accessed
Immutability matters as much as content. An audit log a privileged user can quietly edit or delete isn't much of an audit log. Write-once storage (append-only tables, WORM storage, or a separate system the application's normal write path can't reach) is what makes the log trustworthy as evidence.
Data Sovereignty and Cross-Border Transfer
Some regulations (GDPR's restrictions on transfers outside the EU, data-localization laws in countries like Russia, China, and India) require certain data to physically remain within a jurisdiction's borders — not just be accessible from there, but actually stored there.
Why This Constrains Architecture Choices
| Design area | Constraint imposed by data sovereignty |
|---|---|
| Database replication | Can't blindly replicate a customer database globally for read-latency wins — need per-region data stores with jurisdiction-aware routing |
| Backups | Backup storage location matters too — an EU customer's backup landing in a US bucket can itself violate the requirement |
| CDN / caching | Only cache genuinely non-sensitive, non-personal content globally; personal data shouldn't leak into edge caches outside the permitted region |
| Analytics / data warehouse | A single global warehouse pooling all regions' user data may itself be a cross-border transfer — regional warehouses or field exclusion may be required |
| Support tooling | A support engineer in one country pulling up a customer record from another region can itself count as a cross-border data access |
"Multi-region for performance" and "multi-region for sovereignty" are different problems. Performance-driven multi-region design tries to get data close to users everywhere. Sovereignty-driven design tries to keep data confined to where it's allowed to be. A system built only for the first can accidentally violate the second — always check whether "nearest region" also means "permitted region" before treating replication as a pure performance lever.
Compliance Checklist
| Category | Checklist Item |
|---|---|
| GDPR | Erasure requests can actually reach backups, logs, and warehouses, not just the primary DB |
| GDPR | Data export (portability) is a built feature, not a manual script |
| GDPR | Consent is tracked per purpose and enforced at point of use |
| HIPAA | PHI access is logged on read, not just on write |
| HIPAA | Field-level access control enforces minimum-necessary access |
| PCI-DSS | Raw card numbers never touch application servers — tokenize via processor |
| Classification | Every data store has a classification tag driving its controls |
| Retention | Automated deletion pipeline exists and supports legal holds |
| Audit logging | Audit logs are immutable and separate from application logs |
| Sovereignty | Replication, backups, and CDN caching respect jurisdiction boundaries |
What to Remember for Interviews
- Compliance shapes architecture, not just policy: be ready to explain how a regulation like GDPR or HIPAA changes a specific design decision (data model, replication, access control).
- Right to be forgotten is hard because of backups, logs, and warehouses: the fix is usually pseudonymization at ingestion, not a deletion script written after the fact.
- PCI-DSS's best strategy is scope reduction: tokenize via a processor so raw card data never touches your systems.
- Data classification drives everything downstream: encryption, access control, retention, and audit requirements should all follow from a data's classification tag.
- Audit logs are not application logs: they need immutability, structured actor/action/resource fields, and long, often regulator-mandated retention.
- Data sovereignty can conflict with "put data close to users": always check whether a region is both fast and permitted before replicating there.
Practice: When a system design prompt mentions healthcare, payments, or EU users, treat that as a constraint on the data model and architecture from the first whiteboard sketch — not a footnote to add after the design is "done."