Regulatory Compliance Frameworks (GDPR, HIPAA, FedRAMP)
CoreDesign for regulatory compliance across GDPR, HIPAA, and FedRAMP · Difficulty 3/5
Explanation
Architects must design to the regulatory context of the data and industry they operate in. Three frameworks recur on the exam, each with a distinct design implication.
The Three Frameworks
| Regulation | What it governs | Design implication |
|---|---|---|
| GDPR | EU personal-data protection | Data minimization, lawful basis, data-subject rights, residency; don't send more PII than needed |
| HIPAA | US protected health information | Safeguards for PHI; use HIPAA-eligible services and agreements; restrict/redact PHI |
| FedRAMP | US federal cloud security | Authorized environments and controls for government workloads |
Compliance Is a System Property
The most important exam framing: compliance is a property of the whole system -- data handling, access, retention, and contracts -- not of the model in isolation. An architect deploying a Claude system that processes protected health information cannot rely on "the model is HIPAA-compliant"; there is no such thing in isolation. The correct framing is that compliance requires HIPAA-eligible services, restricting/redacting PHI, and controlling access and retention across the entire pipeline.
Anthropic's Enterprise Compliance Features
Anthropic's enterprise offering provides compliance-relevant features an architect leans on to meet these obligations: HIPAA-eligible options, audit logs, data-retention controls, and SSO/SCIM. These are building blocks, not automatic compliance -- the architect still has to map the specific regulatory requirement to what data is collected, where it's processed and stored, who can access it, and how long it's retained.
Common exam traps
- Assuming "the model is compliant." Compliance is a property of the whole system -- data handling, access, retention, and contracts -- not of the model in isolation. Encrypting the prompt, alone, is not sufficient either; access, retention, and contractual controls all matter too.
Key Takeaways
- GDPR: data minimization, lawful basis, data-subject rights, residency
- HIPAA: PHI safeguards, HIPAA-eligible services, restrict/redact PHI
- FedRAMP: authorized environments and controls for government workloads
- Compliance is a whole-system property -- data handling, access, retention, contracts -- not the model alone
- Anthropic's enterprise features (HIPAA-eligible options, audit logs, retention controls, SSO/SCIM) support but do not automatically satisfy compliance
Glossary Terms
The Federal Risk and Authorization Management Program, a US government standard for security assessment and authorization of cloud services used by federal agencies. Design implication: use authorized cloud environments and controls appropriate to the workload's authorization level for any Claude deployment serving government workloads.
The EU General Data Protection Regulation, governing the protection of personal data for EU data subjects. Design implications include data minimization, establishing a lawful basis for processing, honoring data-subject rights, and respecting data-residency requirements.
The US Health Insurance Portability and Accountability Act, governing the protection of protected health information (PHI). Design implications include using HIPAA-eligible services and business associate agreements, and restricting or redacting PHI across the pipeline rather than assuming the model alone is compliant. Compliance is a property of the whole system -- data handling, access, retention, and contracts -- not of the model in isolation.
Related Concepts