Skip to main content

Concepts

Privacy and compliance by design: residency, minimization, and audit trail

Intuition

Think of a doctor's office that keeps patient records. Good practices say: write down only what is really necessary, keep the records in a locked cabinet inside the country where the patient lives, let only those who need it open the cabinet, log in a book who opened which record and when, and throw away records that are no longer useful. If you only think about this after the office is set up, you'll have to renovate everything; if you think about it from the design stage, the rules become part of the house's blueprint.

How it works

Industry terminology (not from any paper in the corpus): privacy by design treats personal data protection requirements as architectural constraints, not as a final review. Data residency (also called data localization) requires certain data to stay physically in a given region or country; in practice this means partitioning or pinning the data by region, routing each user to the shard of their jurisdiction and keeping derived indexes, caches, queues, logs and backups there as well. Minimization and purpose limitation call for collecting only the fields needed for a stated purpose and not reusing them for another; pseudonymization replaces direct identifiers with tokens, keeping the mapping table separate and more heavily protected, which reduces the damage of a leak but does not make the data anonymous. Retention and deletion (the right to erasure) define lifetimes per data category and a deletion path that reaches all copies; this conflicts with immutable logs and backups, and the common ways out are not writing personal data to immutable logs, storing only references or tokens, or using crypto-shredding, that is, encrypting each data subject with their own key and deleting the key to make all copies unreadable, backups included. Encryption in transit (TLS) and at rest, with key management in a KMS, rotation, and separate keys per region or per tenant, limits what improper access to storage reveals. Least-privilege access, with narrow roles and short-lived credentials, is complemented by an append-only audit trail, preferably with integrity verification such as hash chaining or write-once storage, recording who accessed what, when and why. There is an explicit tension with geo-replication and DR (see concept_geo_replication_failover_rpo_rto): replicating across regions to get a low RPO and fast failover can copy personal data outside the permitted jurisdiction, so the set of replica regions and backup destinations must be restricted by the residency policy, accepting worse RPO/RTO or region pairs within the same jurisdiction.

In practice

In real systems this shows up as personal data mapping (inventory), region selection per tenant, retention policies with TTL, export and deletion flows on data subject request, and access logs for sensitive data, and it is decisive when there are users under regimes such as GDPR (European Union) and LGPD (Brazil, Law 13.709/2018), which regulate personal data; the engineering consequence is to design residency, deletion and auditing from the start, since retrofitting is expensive. Canonical references: the text of the GDPR, Law 13.709/2018 (LGPD) and Ann Cavoukian's work 'Privacy by Design'; the exact obligations depend on the jurisdiction and must be validated with the legal team. When designing, first decide which data is personal and where it may live, and only then choose replication topology, backup and observability within those limits.

Use it in a design

Practice the cases that rely on this concept in the System Design school.