Regulatory & Compliance

Compliance in the context of system design means that regulatory and legal requirements are treated as architectural constraints from day one — not retrofitted after the system is built. Privacy by Design (Ann Cavoukian, adopted into GDPR Article 25) mandates data minimization, purpose limitation, and user rights (access, deletion, portability) as architectural requirements. Data classification (Public, Internal, Confidential, Restricted) drives encryption, access control, and audit logging decisions at the field level. Engaging legal and compliance teams during architecture review — not at the end of development — prevents costly re-architecture and regulatory penalties.

Key Points

• GDPR Article 25 (Privacy by Design): data minimization (collect only what is necessary), purpose limitation (use data only for stated purpose), storage limitation (delete when no longer needed), and integrity/confidentiality (encrypt and access-control all personal data)
• Data classification framework: Public (freely shareable) → Internal (employee-only) → Confidential (limited need-to-know, encrypted at rest) → Restricted (PII, PHI, PCI data; MFA-gated, audit-logged, encrypted in transit and at rest)
• Right to erasure (GDPR Art. 17): must be able to delete all PII for a user on request within 30 days; in distributed systems, this requires tracking all systems that hold user data (often a data catalog or "data map") and propagating deletion events
• Audit trails: compliance-grade audit logs must be tamper-evident (append-only, cryptographically signed), timestamped with NTP-synchronized clocks, retained for the required period (SOC 2: 1 year, HIPAA: 6 years, PCI-DSS: 1 year), and stored separately from application logs
• PCI-DSS scope reduction: never store raw card numbers (PAN), CVV, or magnetic stripe data; use tokenization (Stripe, Braintree) to replace card data with tokens; dramatically reduces PCI audit scope
• HIPAA technical safeguards: PHI (Protected Health Information) requires access controls, audit controls, integrity controls (hash verification), and transmission security (TLS 1.2+); applies to all systems that store, process, or transmit PHI
• Engaging legal early: bring compliance requirements into the architecture discovery phase (sprint 0); a 1-hour legal briefing can prevent 3 months of re-architecture; legal teams need to understand data flows, not code
• Compliance as code: encode compliance requirements into automated tests (data classification checks, encryption validation, audit log format verification) so that violations are caught in CI/CD before deployment