Compliance & Privacy Engineering

Compliance arrives in most engineers' lives as a spreadsheet from someone in legal, and it feels like paperwork bolted onto a system that already exists. That framing is exactly why it goes badly. Nearly every requirement in GDPR, SOC 2, HIPAA, or PCI DSS translates into an architectural property — can you enumerate where personal data lives, can you delete it on request, can you prove who accessed what, can you demonstrate the control was operating for the whole period — and properties like those are cheap to design in and brutally expensive to retrofit.

The clearest example is deletion. "Delete this user's data" sounds like a DELETE statement until you count the copies: the primary database, its read replicas, last night's backup, the search index, the analytics warehouse, the CDC stream sitting in Kafka, three log aggregators, and a vendor's system you forwarded events to. A team that never asked the question ships a product where the honest answer to a legally binding request is "we don't know."

The useful mental shift is to treat these as engineering requirements with unusual stakeholders. Data inventories, retention policies, audit trails, and consent state are all just system design — they simply have regulators rather than product managers as the requesting party.

TL;DR

• Compliance requirements are architectural properties, not paperwork. Design them in.
• You cannot protect, delete, or report on data you haven't inventoried. Start there.
• Deletion is the hardest requirement — count every copy: replicas, backups, indexes, warehouses, logs, vendors.
• Audit logs must be append-only, tamper-evident, and cover access as well as change.
• Retention is a deletion obligation, not a storage preference. Data you keep is data you must protect.
• Consent must be granular, revocable, and enforced by the system rather than by policy.
• SOC 2 is about evidence that controls operated continuously — automate the evidence.
• Minimize. The cheapest way to comply with a data rule is not to hold the data.

The Recurring Requirements

Featured Topics

Privacy Fundamentals

• Privacy by Design — Data minimization, purpose limitation, and defaults that protect
• PII & Sensitive Data Handling — Classification, discovery, encryption, tokenization, and masking
• GDPR for Engineers — Lawful basis, data subject rights, and what the regulation asks of a codebase

Data Lifecycle

• Data Retention & Deletion — Retention schedules, cascading deletes, backups, and crypto-shredding
• Consent Management — Capturing, storing, propagating, and revoking consent

Controls & Evidence

• Audit Logging — Append-only, tamper-evident records of who did what to which data
• SOC 2 & Security Compliance — Trust services criteria, evidence automation, and surviving Type II
• PCI DSS for Developers — Scope reduction, tokenization, and never storing card data

Common Questions

Isn't compliance the legal team's problem?

Legal determines what the obligation is; engineering determines whether the system can meet it. That split breaks down constantly, because most obligations only become concrete as system properties — a lawyer can tell you a deletion request must be honored within 30 days, and only an engineer can tell you whether the analytics warehouse has a user identifier in it. The teams that struggle are the ones where these two groups meet for the first time during an audit.

Where should we start?

A data inventory. Which systems hold personal data, what fields, whose data, why you have it, how long you keep it, and which third parties receive it. It's tedious and it's the prerequisite for everything else — retention, deletion, access control, breach assessment, and every framework's documentation requirement all depend on it. Most organizations discover during this exercise that they're holding data nobody knew about and nobody needs, which is the cheapest possible compliance win. See PII & Sensitive Data Handling.

How much does this slow down engineering?

Designed in from the start, very little — a classification annotation on a schema field, a retention policy on a table, an audit event on a sensitive read. Retrofitted, enormously: a deletion capability added to a mature system that never contemplated it is a multi-quarter project touching every data store. The cost differential between the two is probably the strongest argument for treating this as ordinary architecture rather than as a compliance project.

Do these rules apply to a small company?

Usually yes for privacy law, which generally applies based on whose data you process rather than on your size — GDPR applies to any organization handling EU residents' data, and CCPA has revenue and volume thresholds but catches many small companies. Certifications like SOC 2 are market-driven rather than legal: you get one because enterprise customers require it, which typically happens the first time you try to sell upmarket. Building the underlying capabilities early is much cheaper than the scramble that follows a large deal.

What's the single highest-value practice?

Don't collect it. Data you don't hold needs no encryption, no retention policy, no deletion mechanism, no access control, no breach notification, and no line in the inventory. Every framework rewards minimization, and it's the only control with no ongoing cost. The second highest is knowing where the data you do hold actually lives.

Related Hubs

• Security — Encryption, access control, and threat modeling
• Databases — Row-level security, backups, and retention at the storage layer
• Observability — Logging practices that don't leak personal data
• DevOps — Evidence automation and infrastructure as code as a control
• Analytics Engineering — Where personal data quietly accumulates