Privacy by Design
Building privacy protections into a system's structure from the start, rather than adding controls to a design that already collects and keeps everything.
A legal expectation under GDPR (Article 25, "data protection by design and by default") and a sound engineering principle independently.
The architectural moves, in rough order of effect:
Data minimisation — collect only what a stated purpose requires. The most powerful control available, because data you never held cannot be breached, subpoenaed, mis-shared or subject to an erasure request. It is also the one most often lost to "we might want it later".
Purpose limitation — record why each field was collected, because reuse for a new purpose may require a new lawful basis.
Pseudonymisation and tokenisation — replace identifiers with tokens so most systems handle data that cannot identify a person, which shrinks both breach impact and compliance scope.
Retention and deletion designed in — including in backups, event logs, search indexes, analytics copies and third-party processors. This is where most designs fail, because deletion was never a requirement when the pipeline was built.
Access control by default — no ambient access to personal data; every read authorised and audited.
The recurring conflict worth anticipating: the right to erasure against append-only event logs and immutable backups. The usual answers are crypto-shredding (encrypt per subject, destroy the key) or keeping personal data out of the immutable store behind a reference.