Regulatory Architecture

Definition

Regulatory architecture translates legal obligations into structural properties: residency as a placement rule, retention as a job that runs, access as a policy evaluated per request.

The principle

Enforce at runtime, do not document. A model that lives in a spreadsheet describes what was intended; one that lives in the request path describes what happens. Only the second survives an audit, and only the second actually protects anyone.

Concretely: residency is a routing and placement rule the system cannot violate, not a policy people follow. Retention is a deletion job with monitoring, not a documented period. Access is evaluated on every request, not granted and forgotten.

The highest-value move: scope reduction

Everything in regulatory scope must be controlled, evidenced and audited — every year, forever, and the cost scales with the number of systems.

So the best architectural move is frequently to arrange not to be subject to the obligation: do not store the regulated data, keep it in one bounded system, or let a specialist provider hold it. Tokenising card data at the edge so card numbers never enter your systems is the canonical example, and it is worth more than any number of controls applied to a wider scope.

The obligations that recur

• Residency — data must remain in a jurisdiction.
• Retention floors and ceilings, which conflict and are resolved field by field rather than record by record.
• Auditability — who did what, when, in a tamper-evident record.
• Explainability — for automated decisions affecting people.
• Subject rights — access, correction, deletion, portability.
• Resilience and exit — in regulated sectors, demonstrable recovery and a plan for leaving a provider.

Making evidence automatic

Auditors want proof a control operated throughout the period, not that it exists today. If evidence is screenshots and spreadsheets, compliance consumes engineering time every year forever.

If access reviews, change approvals, scans, backup tests and deletion jobs emit structured evidence as a side effect of normal operation, the audit is an export. That is the difference between compliance as a project and compliance as a property of the platform.

Failure scenarios

• Everything in scope, because nothing was segmented.
• Controls documented but not enforced.
• A compliance boundary that does not match a technical boundary, so the assertion cannot be demonstrated.
• Evidence gathered manually.
• Regulation engaged late, when the design is fixed and the constraint is expensive.

Interview question

"How do you make a data residency requirement a structural property rather than a policy?"