Compliance Frameworks & Regulatory Design

Every framework is a list of architectural constraints

Compliance frameworks feel like legal noise until you realize each one is really a list of architectural constraints. The senior move is to map every framework to the concrete controls it forces, then notice how much they overlap so you build one control set that satisfies several regimes.

Framework   Protects              Core demand on architecture
GDPR/CCPA   EU/CA personal data   Data-subject rights (access, erasure), lawful basis, residency
SOC 2       customer trust        Trust Services Criteria, controls that operate over time, evidence
HIPAA       US health PHI         Safeguards for PHI, BAAs with every processor, audit controls
PCI-DSS     cardholder data       Isolate/encrypt PAN, network segmentation, scope reduction

The shared baseline

Encryption in transit (TLS 1.2+) and at rest (AES-256 with KMS-managed keys), least-privilege access control (RBAC/ABAC with MFA), centralized logging and monitoring, tested backups and DR, vendor/processor management, and change management show up in all four. Build those once and you have cleared most of the surface area. Then you layer the framework-specific non-negotiables: GDPR needs a lawful basis and honored data-subject rights; HIPAA needs a signed BAA (Business Associate Agreement) with every subprocessor that touches PHI; PCI needs network segmentation isolating the cardholder data environment; SOC 2 needs the controls to demonstrably operate over a period, not just exist on audit day.

Data residency is the load-bearing requirement

The single most architecturally load-bearing requirement is data residency. GDPR restricts moving EU personal data outside approved regions. This is not a config checkbox, it is a sharding decision. It forces you to region-pin storage and processing so EU user data lives in eu-central-1 and never silently replicates to us-east-1. Cross-border transfer needs a legal mechanism (Standard Contractual Clauses, or an adequacy decision like the EU-US Data Privacy Framework), and that legal mechanism only works if your architecture can actually keep the data regional. Teams that treat residency as a checkbox discover it late, when a global DynamoDB table or a CDN log has already scattered EU data across continents.

Interview nuance: the sharpest scope-reduction lever is tokenization. If you never store the raw card number (PAN), and instead hand it to a PCI-certified provider (Stripe, Adyen) that returns a token, then most of your systems fall out of PCI scope entirely. Your database holds tok_1a2b, not a card. The same idea reduces GDPR and HIPAA blast radius: the less sensitive data you hold, the fewer systems the auditor examines. Data minimization is a security control, not just a privacy nicety.

Rounding it out: DPAs (Data Processing Agreements) govern each processor, DPIAs (Data Protection Impact Assessments) are required before high-risk processing, and SOC 2 evidence means access reviews, change tickets, and log retention you can produce on demand.

Recap: build the shared baseline (encryption, access control, logging, backups) once, layer framework-specific non-negotiables on top, treat data residency as a regional-sharding driver rather than a checkbox, and use tokenization to pull whole systems out of PCI/PHI scope.