Compliance Frameworks at a Glance
Before you can architect for compliance, you need to understand which frameworks apply to your business, what they require, and where they overlap. This page gives you a practical comparison of the seven most relevant compliance frameworks for companies building on AWS.
Framework Comparison​
| Framework | Who It Applies To | What It Protects | Mandatory? | Key Focus |
|---|---|---|---|---|
| HIPAA | Healthcare providers, health plans, business associates, HealthTech companies | Protected Health Information (PHI) | Yes (US law) | Privacy and security of health data |
| HITRUST CSF | Healthcare organizations seeking a certifiable framework | PHI and other sensitive data | No (voluntary certification) | Comprehensive control framework that harmonizes HIPAA, ISO, NIST, and others |
| PCI DSS | Any organization that stores, processes, or transmits cardholder data | Cardholder data (card numbers, CVVs, PINs) | Yes (contractual via card brands) | Payment card data security |
| GDPR | Any organization processing personal data of EU residents, regardless of where the org is based | Personal data of EU data subjects | Yes (EU law) | Data privacy rights and consent |
| CCPA | Businesses meeting revenue or data volume thresholds that handle California residents' data | Personal information of California consumers | Yes (California law) | Consumer privacy rights and transparency |
| SOC 2 | Service organizations, especially SaaS companies serving enterprise customers | Customer data handled by the service | No (voluntary, but often required by customers) | Trust Service Criteria: Security, Availability, Confidentiality, Processing Integrity, Privacy |
| FedRAMP | Cloud service providers selling to US federal agencies | Federal data and systems | Yes (for federal contracts) | Standardized cloud security assessment |
Key Requirements Summary​
HIPAA​
- Implement administrative, physical, and technical safeguards for PHI
- Execute Business Associate Agreements (BAAs) with all vendors handling PHI
- Conduct regular risk assessments
- Maintain audit logs for all PHI access
- Implement breach notification procedures (60-day requirement)
HITRUST CSF​
- Implement controls across 19 domains (access control, audit logging, risk management, etc.)
- Choose assessment type: self-assessment, validated, or certified
- Map controls to your specific risk factors (organizational, regulatory, system)
- Maintain evidence of control effectiveness over time
PCI DSS​
- Build and maintain a secure network (firewalls, no vendor defaults)
- Protect stored cardholder data with encryption
- Implement strong access control measures and MFA
- Regularly monitor and test networks
- Maintain an information security policy
- 12 requirements organized into 6 control objectives
GDPR​
- Establish a lawful basis for processing personal data
- Honor data subject rights: access, rectification, erasure, portability, restriction, objection
- Implement data protection by design and by default
- Conduct Data Protection Impact Assessments (DPIAs) for high-risk processing
- Report breaches to supervisory authorities within 72 hours
- Appoint a Data Protection Officer (DPO) where required
CCPA​
- Provide consumers the right to know what data is collected
- Honor right to delete and right to opt out of data sale
- Provide equal service regardless of privacy choices
- Disclose data collection and sharing practices
- Implement reasonable security measures
SOC 2​
- Meet Trust Service Criteria relevant to your service
- Security (Common Criteria) is always required
- Availability, Confidentiality, Processing Integrity, and Privacy are optional
- Type I: controls designed effectively at a point in time
- Type II: controls operating effectively over a period (usually 6-12 months)
FedRAMP​
- Implement NIST SP 800-53 controls at the appropriate impact level (Low, Moderate, High)
- Undergo assessment by a Third Party Assessment Organization (3PAO)
- Achieve Authorization to Operate (ATO) from an agency or through the Joint Authorization Board (JAB)
- Perform continuous monitoring and annual assessments
AWS Services That Help​
| AWS Service | HIPAA | PCI DSS | GDPR | SOC 2 | HITRUST | FedRAMP |
|---|---|---|---|---|---|---|
| AWS Config | Rules for PHI resources | CDE compliance rules | Data handling rules | Control monitoring | Control evidence | Continuous monitoring |
| AWS CloudTrail | PHI access audit trail | CDE activity logging | Processing activity records | Audit logging | Activity monitoring | Audit trail |
| Amazon Macie | PHI discovery | Cardholder data detection | PII discovery and classification | Data classification | Sensitive data identification | Data classification |
| AWS KMS | PHI encryption | Cardholder data encryption | Personal data encryption | Encryption key management | Encryption controls | Encryption management |
| AWS Security Hub | HIPAA compliance checks | PCI DSS standard checks | GDPR-related findings | Security posture | Consolidated findings | Security standard checks |
| AWS Audit Manager | HIPAA framework assessment | PCI DSS assessment | GDPR assessment | SOC 2 assessment | Control evidence | FedRAMP assessment |
| Amazon GuardDuty | Threat detection for PHI environments | CDE threat monitoring | Unauthorized access detection | Threat detection | Threat detection | Threat detection |
| AWS IAM | PHI access control | CDE access management | Access governance | Access controls | Identity management | Access management |
The Shared Responsibility Model for Compliance​
This is the single most important concept for cloud compliance. AWS operates under a shared responsibility model, and compliance follows the same split:
AWS is responsible for:
- Physical security of data centers
- Hardware and infrastructure maintenance
- Network infrastructure security
- Hypervisor and host OS security
- Achieving and maintaining AWS's own compliance certifications (SOC 2, ISO 27001, PCI DSS as a service provider, etc.)
You are responsible for:
- Configuring AWS services correctly for your compliance requirements
- Managing your own IAM policies, encryption keys, and access controls
- Implementing application-level security
- Data classification, handling, and retention
- Logging, monitoring, and incident response for your workloads
- Demonstrating compliance of your workloads to your auditors
AWS being compliant does not make your application compliant. AWS provides the tools. You must use them correctly.
Common Compliance Myths​
Myth: "We're on AWS, so we're compliant." Reality: AWS provides compliant infrastructure. Your application, configuration, and operational practices must also be compliant. An S3 bucket on AWS-compliant infrastructure can still be publicly exposed.
Myth: "AWS certifications cover our application." Reality: AWS certifications (e.g., AWS is PCI DSS Level 1 compliant) cover the infrastructure layer only. Your cardholder data environment, access controls, and application logic are your responsibility.
Myth: "Compliance is a one-time project." Reality: Compliance is continuous. Configurations drift, new services get deployed, team members change. You need ongoing monitoring, regular assessments, and continuous evidence collection.
Myth: "We can handle compliance manually." Reality: Manual compliance does not scale. As your infrastructure grows, manual checks become error-prone and expensive. Compliance as code is the only sustainable approach.
Myth: "Encryption solves everything." Reality: Encryption is necessary but not sufficient. Compliance also requires access controls, audit logging, incident response, data classification, retention policies, and much more.
Flashcards​
What is the shared responsibility model for compliance on AWS?
Click to revealAWS secures the underlying cloud infrastructure and maintains its own certifications. You are responsible for configuring services correctly, managing access controls, data handling, logging, and demonstrating compliance of your workloads to auditors.