Compliance Obligation Mapping
Translating regulatory text into specific, testable technical requirements attached to the systems they apply to.
Regulation arrives as prose and is frequently treated as a general anxiety rather than a set of requirements. The mapping converts it into things that can be designed for and verified.
The chain: regulation → obligation → control → evidence. GDPR's right to erasure becomes an obligation to delete personal data on request, which becomes controls — knowing where personal data resides, a deletion capability across every store including backups and derived data, and a defensible approach to immutable logs — which become evidence: a tested deletion procedure, a data inventory, and audit records.
What the exercise reliably reveals: data in places nobody had inventoried, including analytics platforms, log stores, backups, caches and third-party services; derived data such as embeddings and model training sets that carry personal information and are rarely considered; and conflicting obligations, most commonly a retention requirement against an erasure requirement, which needs a legal position rather than an engineering one.
Two architectural consequences worth designing in early because retrofitting is expensive: data residency constrains regional topology and may force partitioning regardless of scale; and deletion must be designed into event-sourced and append-only systems from the start — crypto-shredding is the usual mechanism and it cannot be added afterwards.