Legal, regulatory, organizational and industry requirements
Domain 3 tests converting legal, regulatory, contractual, and organizational obligations into architecture requirements, including resolving conflicts.
Layers and precedence
Obligations stack: law, then regulation, then contract, then internal policy, then industry standard. Examples: GDPR (EU data subjects, 72-hour breach notification to the supervisory authority, Article 30 records, DPIA), HIPAA Security Rule (risk analysis, addressable specifications), SOX (change control and financial reporting integrity), PCI DSS v4.0 (future-dated requirements became mandatory 31 March 2025), DORA and NIS2 in the EU, NYDFS 500, PIPL, CCPA/CPRA. Export controls (EAR, ITAR) restrict where technical data and staff may be located. Contracts flow obligations down to subprocessors.
Method
Build an obligation register; classify data; map each obligation to one or more controls; identify conflicts (retention vs erasure, lawful intercept vs encryption, residency vs global support) and document precedence and compensating measures. Jurisdiction follows the data subject and the data, not the server.
Worked example
A US healthcare SaaS serves EU patients. HIPAA permits PHI use for treatment, payment, and operations; GDPR requires a lawful basis, minimization, and honoring access and erasure requests. The architect designs an EU region with EU-resident keys, pseudonymization, a DSAR workflow with deletion propagation to backups, BAAs with subprocessors, and SCCs plus a transfer impact assessment for any US support access. Reasoning: both regimes apply simultaneously; the stricter rule wins per data element, and rights must be technically executable, not merely documented.
Traps
Assuming US law follows the data; forgetting subprocessor flow-down; equating ISO/IEC 27001 certification with legal compliance; mixing HIPAA's 60-day individual notification with GDPR's 72-hour regulator notification; no mechanism for erasure in backups; ignoring sector regulators.