Privacy must be built into architecture, not added as remediation
Aliases: privacy engineering · architectural privacy · data protection by design
What it is
Privacy by design makes data protection an architectural constraint rather than a policy notice or settings panel added after implementation. It asks whether data must exist, where computation occurs, which actors can link records, when copies expire, and what failure paths disclose. Its scope includes schemas, logs, caches, trust boundaries, and vendor interfaces as well as visible controls.
Why it happens
Architecture creates facts that later interfaces cannot undo. A stable key joining datasets makes purpose separation costly; raw events copied into centralized logs remain available after a front-end toggle changes. Local processing, compartmentalized stores, short-lived identifiers, and capability-limited interfaces instead constrain observability, linkability, and retention. Privacy is therefore path-dependent: early choices determine the ceiling of later remediation.
Studying it
Useful approaches combine data-flow mapping, privacy threat modeling, code and configuration audits, impact assessments, and usability tests of control tasks. Measures can include identifiable data generated, trust-boundary crossings, exposure under defaults, and the effort needed to exercise a control. Audits must sample failure, debugging, support, analytics, and recovery paths; studying only visible screens systematically misses backstage flows.
Where it stops holding
Architecture cannot remove every legitimate disclosure. Statutory retention, fraud prevention, and security auditability may require selected records, while end-to-end encryption still leaves some metadata observable. Early prototypes legitimately change, but uncertainty does not justify indefinite collection: assumptions need expiry dates and review. Passing a compliance checklist also does not establish contextual appropriateness for users.
Applying it
- Map collection, inference, sharing, backup, and deletion before feature approval, assigning an owner to every trust boundary.
- Prefer non-collection, on-device computation, aggregation before upload, and ephemeral identifiers; treat centralized raw-data retention as an exception requiring evidence.
- Encode constraints in APIs, schemas, logging, retries, and processor contracts rather than relying on interface copy.
- Exercise core and failure journeys with test accounts, inspect network and storage traces, and block release when undeclared copies or unresolved deletion paths remain.