Compliance regimes are not one checklist

“Make it compliant” hides the first architecture question: which regime applies to which data flow, entity and deployment? GDPR is a data-protection law, HIPAA governs regulated US healthcare actors and protected health information, and FedRAMP is a federal cloud authorization and ongoing-evidence program. They overlap on security controls, but their load-bearing constraints are not interchangeable.

scope before controlsGDPR · rights + purpose HIPAA · PHI + BAAFedRAMP · boundary + authorization evidence

Educational architecture guide — not legal advice. Applicability and exact obligations are fact-specific and change with jurisdiction, contracts, agency requirements and system categorization. Use counsel, privacy/security officers and the relevant authorizing officials to decide what applies. The scores below only count whether an architecture conversation has covered the named capability; they do not certify compliance.

Run one architecture through three lenses

Choose a preset or toggle controls manually. Each bar counts requirements represented in this teaching model; red blockers are regime-specific design decisions still missing. A generic “secure AI” baseline covers only 2/7 GDPR capabilities, 2/5 HIPAA capabilities and 2/7 FedRAMP capabilities.

Architecture readiness coverage — not a compliance score

architecture preset

inspect one regime

The concrete differences

regime	scope question	load-bearing constraints	architecture consequence
GDPR	Are you processing personal data in a context within its territorial/material scope? Who is controller vs processor?	lawful basis and purpose limitation; minimization; processor terms; data-subject rights; retention/erasure with applicable exceptions; safeguards for relevant international transfers; privacy by design	inventory every copy and purpose; tag provenance/processing purpose; build access/correction/deletion workflows through source, index, cache, trace and backup policy; control processor/subprocessor and transfer paths
HIPAA	Is a covered entity or business associate creating, receiving, maintaining or transmitting PHI/ePHI?	permitted uses/disclosures and minimum necessary; BAAs with business associates/subcontractors where required; administrative, physical and technical safeguards; unique access and audit controls; incident/breach duties	draw the PHI boundary before the pilot; do not send PHI to a service until the contractual and safeguard path is approved; scope retrieval/tools to minimum necessary; retain protected, reviewable audit evidence
FedRAMP	Is a cloud service offering handling federal information for agency use, and what impact level/path does the agency require?	defined authorization boundary; NIST SP 800-53 baseline implementation and assessment evidence; external-service/inheritance story; agency authorization/acceptance; continuous monitoring, vulnerability and POA&M operations; required validated cryptography	choose dependencies from an acceptable authorized path; include model/API calls and metadata flows in the boundary analysis; maintain SSP/control evidence; design change control, scans, incident reporting and ConMon as product operations

The preset measurements make the non-equivalence concrete. The privacy architecture reaches 7/7 on the GDPR teaching lens but remains 2/5 for HIPAA because it has no BAA, PHI boundary or minimum-necessary design; it remains 2/7 for FedRAMP because it has no authorization boundary, accepted dependency path, control evidence or continuous monitoring. The healthcare preset reaches 5/5 HIPAA and still does not acquire GDPR rights workflows or a FedRAMP authorization package by resemblance. Shared controls are reusable; scope and regime-specific evidence are not.

Three traps to refuse in a design review

“Health data means HIPAA.” Health-adjacent data can be outside HIPAA, while a business associate's handling of PHI can be inside it. Determine actors, data and purpose; do not infer scope from a field name.
“We encrypt, so GDPR is done.” Security helps, but encryption does not create a lawful basis, purpose limitation, processor terms, data-subject workflows or a transfer mechanism.
“The hosting layer is FedRAMP authorized, so our whole stack is.” Authorization has a boundary and an accepted package. External model APIs, operations, metadata and inherited controls must be represented; one authorized dependency does not automatically authorize the composed service.

# the architect's first-page regime map
data_flow -> people/data/agency context -> applicable regime(s) -> accountable role
GDPR      -> purpose + lawful basis + minimization + rights + transfers + deletion propagation
HIPAA     -> PHI boundary + BAA chain + minimum necessary + access/audit + incident process
FedRAMP   -> authorization boundary + accepted services + control evidence + continuous monitoring

# shared control evidence can be reused; the applicability decision and package cannot
owner = privacy_officer | security_officer | authorizing_official | counsel
evidence = data_map + contracts + tests + logs + assessments + change/incident records

⚠️ Traps & honesty: the 7/5/7 capability model is deliberately small and educational — real obligations contain far more detail · a 100% bar means only “all capabilities named on this page are represented,” never “compliant” or “authorized” · multiple regimes can apply at once, along with state, sectoral, contractual and agency-specific requirements · data-subject rights and breach duties include conditions, exceptions and timelines this architecture explainer intentionally does not adjudicate · FedRAMP processes and baselines evolve, so use current official templates and the agency's chosen path.

Takeaways: decide applicability and accountable roles before selecting controls · GDPR makes purpose, minimization and operable rights/data-lifecycle paths architectural · HIPAA makes the PHI boundary, permitted flow, BAA chain, minimum necessary and audit safeguards architectural · FedRAMP makes the authorization boundary, assessed control evidence, acceptable dependencies and continuous monitoring architectural · shared security controls are a foundation, not proof that the regimes are interchangeable. Next: turn quality promises into SLOs.

Primary sources (verify the current version with your reviewers): EUR-Lex · GDPR · HHS · HIPAA Security Rule summary · HHS · Business Associates · FedRAMP · CSP Authorization Playbook.