AWS Compliance Guide: HIPAA, GDPR, PCI DSS & SOC 2

Compliance in the cloud is simultaneously easier and harder than compliance in a traditional data center. Easier because AWS provides a vast array of security controls, automated monitoring tools, and pre-built compliance frameworks. Harder because the shared responsibility model means you must understand exactly where AWS's obligations end and yours begin—and most regulatory frameworks were not written with cloud architectures in mind.

This guide covers the four most common compliance frameworks organizations encounter when running workloads on AWS: HIPAA for healthcare data, GDPR for European data protection, PCI DSS for payment card data, and SOC 2 for service organization controls. For each framework, we explain the key requirements, how AWS helps you meet them, and what you are responsible for configuring yourself.

The Shared Responsibility Model

Before diving into specific frameworks, it is essential to understand the AWS shared responsibility model, because it underlies every compliance conversation.

• AWS is responsible for security "of" the cloud. This includes physical data center security, hypervisor security, network infrastructure, and the security of managed services' underlying systems. AWS maintains its own compliance certifications (SOC 2, ISO 27001, PCI DSS, and others) for this infrastructure.
• You are responsible for security "in" the cloud. This includes IAM configuration, network settings, encryption, operating system patching, application security, and data classification. Your compliance obligations fall squarely in this category.

A common misconception is that because AWS is PCI DSS or HIPAA compliant, workloads running on AWS automatically inherit that compliance. This is incorrect. AWS's compliance covers the infrastructure; you must separately ensure that your configurations, applications, and processes meet regulatory requirements.

HIPAA Compliance on AWS

The Health Insurance Portability and Accountability Act (HIPAA) governs the protection of protected health information (PHI) in the United States. Any organization that creates, receives, maintains, or transmits PHI must comply with HIPAA, including cloud environments where PHI is stored or processed.

Business Associate Agreement (BAA)

The first step for HIPAA compliance on AWS is signing a Business Associate Agreement (BAA). AWS will not be liable as a HIPAA business associate until a BAA is in place. You can request a BAA through your AWS account manager or through the AWS Artifact service.

The BAA covers only HIPAA-eligible services. As of 2026, these include over 160 services (check the current list) such as EC2, S3, RDS, Lambda, ECS, EKS, DynamoDB, CloudTrail, CloudWatch, KMS, and many more. If you use a service not covered by the BAA for PHI workloads, you are operating outside the agreement.

PHI Protection Requirements

• Encrypt PHI at rest and in transit. Use SSE-KMS for S3, encrypted EBS volumes, encrypted RDS instances, and TLS 1.2+ for all data in transit. HIPAA does not technically mandate encryption, but the OCR has made it clear that unencrypted PHI breaches carry significantly higher penalties.
• Implement access controls. Only authorized workforce members should access PHI. Use IAM policies scoped to the minimum necessary standard—the HIPAA equivalent of least privilege.
• Enable comprehensive audit logging. HIPAA requires audit controls that record and examine activity in systems containing PHI. Enable CloudTrail for API activity, VPC Flow Logs for network activity, and S3 access logging for data access.
• Implement backup and disaster recovery. The HIPAA Security Rule requires contingency planning. Use S3 cross-region replication, RDS automated backups, and multi-AZ deployments to protect against data loss.
• Isolate PHI workloads. Run PHI workloads in a dedicated AWS account with strict access controls. This simplifies compliance by limiting the scope of your HIPAA environment.

Common HIPAA Pitfalls

• Using non-HIPAA-eligible services for PHI workloads.
• Failing to sign a BAA before processing PHI.
• Not encrypting EBS snapshots or AMIs that contain PHI.
• Allowing PHI to appear in CloudWatch log data without encryption.
• Granting overly broad access rather than applying the minimum necessary standard.

GDPR Compliance on AWS

The General Data Protection Regulation (GDPR) is the European Union's comprehensive data protection regulation. It applies to any organization that processes personal data of EU residents, regardless of where the organization is located. GDPR carries penalties of up to four percent of global annual revenue or 20 million euros, whichever is greater, for the most severe violations. Less severe violations carry penalties of up to two percent of global annual revenue or 10 million euros.

Data Residency and Processing Location

• Choose EU regions for EU data. AWS offers multiple regions within the EU: Ireland (eu-west-1), Frankfurt (eu-central-1), Paris (eu-west-3), Stockholm (eu-north-1), Milan (eu-south-1), and Spain (eu-south-2). Store and process EU personal data in these regions to simplify data residency compliance.
• Restrict data transfer with SCPs. Use Service Control Policies to prevent resources from being created outside approved regions. This provides a guardrail against accidental data transfers to non-EU regions.
• Use the AWS Data Processing Addendum (DPA). AWS provides a GDPR-compliant DPA that governs AWS's processing of personal data on your behalf. This is available through AWS Artifact.

Right to Erasure (Right to Be Forgotten)

• Build data deletion capabilities. GDPR requires you to delete personal data upon request. This is straightforward for databases but more complex for backups, logs, and replicated data. Design your architecture to support targeted deletion.
• Tag data with retention metadata. Use S3 object tags and DynamoDB attributes to track data retention requirements. Automate deletion using lifecycle policies and Lambda functions.
• Address data in backups. European data protection authorities (formerly the Article 29 Working Party, now the EDPB) guidance acknowledges that deleting specific records from encrypted backups may be impractical. Document your approach to handling erasure requests for backup data, including timelines for when backups expire naturally.

Data Protection by Design

• Encrypt all personal data. Use KMS customer-managed keys so you maintain full control over encryption and decryption.
• Implement pseudonymization. Where possible, replace identifying data with pseudonymous identifiers. Store the mapping separately with stricter access controls.
• Enable CloudTrail for processing records. GDPR Article 30 requires maintaining records of processing activities (ROPA), which is a documentation obligation typically satisfied through governance tools. CloudTrail complements ROPA by providing tamper-evident API activity logs for audit purposes.
• Conduct Data Protection Impact Assessments (DPIAs). For high-risk processing activities, perform a DPIA before deploying the workload. Document the AWS services used, data flows, security controls, and risk mitigations.

PCI DSS on AWS

The Payment Card Industry Data Security Standard (PCI DSS) applies to any organization that stores, processes, or transmits cardholder data. PCI DSS version 4.0, which replaced PCI DSS v3.2.1 in March 2024, with its future-dated requirements becoming mandatory in March 2025, introduced significant new requirements including more rigorous authentication, expanded encryption mandates, and targeted risk analysis.

Network Segmentation

• Isolate cardholder data environments (CDE). Place PCI workloads in a dedicated VPC (or dedicated AWS account) with strict network controls. The CDE should be segmented from all non-PCI systems.
• Use security groups as micro-segmentation. Define security groups that allow only the specific ports and protocols needed for each component. Document every allowed connection and its business justification.
• Implement stateful firewalls. AWS Network Firewall provides stateful inspection for VPC traffic, complementing the stateful filtering of security groups and the stateless filtering of NACLs.
• Use private subnets for CDE components. No CDE component should have a public IP address. Use NAT gateways for outbound internet access and Application Load Balancers for inbound traffic.

Encryption Requirements

• Encrypt cardholder data at rest with strong cryptography. PCI DSS 4.0 requires strong cryptography (AES-128 or stronger). Use SSE-KMS with customer-managed keys, which provides the key management and audit trail PCI requires.
• Encrypt data in transit with TLS 1.2 or later. Configure ALBs and API Gateways with security policies that enforce TLS 1.2 minimum. Disable older protocols entirely.
• Implement key management procedures. PCI DSS Requirement 3.6 mandates documented key management procedures including generation, distribution, storage, rotation, and destruction. Use KMS key policies and rotation configurations to meet these requirements.
• Render PAN unreadable. If you must store primary account numbers (PANs), render them unreadable using strong one-way hashing, truncation, index tokens, or strong cryptography. KMS integrates with application-level encryption to support this requirement.

Logging and Monitoring

• Log all access to CDE resources. PCI DSS Requirement 10 mandates comprehensive logging. Enable CloudTrail for API activity, VPC Flow Logs for network traffic, and application-level logging for cardholder data access.
• Retain logs for at least one year. PCI requires 12 months of audit log history with the most recent three months immediately available. Use S3 lifecycle policies to manage log retention and tier older logs to S3 Glacier.
• Implement automated alerting. PCI DSS 4.0 Requirement 10.4.1.1 requires automated mechanisms to detect and alert on security events. Use CloudWatch alarms, GuardDuty, and Security Hub to meet this requirement.

SOC 2 on AWS

SOC 2 (Service Organization Control 2) is a framework for managing data based on five trust service criteria: security, availability, processing integrity, confidentiality, and privacy. SOC 2 reports are increasingly required by enterprise customers evaluating SaaS vendors and service providers.

Security Controls (Common Criteria)

• Logical access controls. Implement IAM best practices: MFA, least privilege, role-based access, regular access reviews, and separation of duties. Document your access control policies and evidence of enforcement.
• Network security. Implement VPC segmentation, security groups, NACLs, and VPC Flow Logs. Document your network architecture and demonstrate that controls are consistently applied.
• Change management. Use Infrastructure as Code (CloudFormation or Terraform) with version control and peer review. Demonstrate that changes to production infrastructure follow an approved change management process.
• Incident response. Document incident response procedures that include detection, analysis, containment, eradication, and recovery. Demonstrate that GuardDuty, Security Hub, and CloudWatch alarms are configured and that the team has rehearsed response procedures.

AWS Artifact

AWS Artifact provides on-demand access to AWS's own compliance reports, including SOC 2 Type II reports. You can share these reports with your auditor to demonstrate that the underlying AWS infrastructure meets SOC 2 requirements. Your auditor will then assess your configurations on top of that infrastructure.

Evidence Collection

• Use AWS Audit Manager. Audit Manager automates evidence collection for SOC 2 assessments. It continuously collects evidence from AWS Config, CloudTrail, and other sources, mapping findings to specific SOC 2 controls.
• Maintain configuration records. AWS Config provides a timeline of resource configurations. This is invaluable during SOC 2 audits for demonstrating that controls were in place throughout the audit period.
• Generate compliance reports. Security Hub provides a compliance score against multiple frameworks, including CIS Benchmarks, which provide useful technical baselines but do not fully satisfy SOC 2 Trust Service Criteria (additional organizational controls are required).

AWS Compliance Tools

AWS provides several services specifically designed to support compliance programs. Using these tools can significantly reduce the manual effort required for audit preparation and continuous compliance monitoring.

AWS Config

AWS Config records the configuration of your AWS resources and evaluates them against rules. For compliance, Config provides:

• Conformance packs. Pre-built collections of Config rules mapped to specific frameworks: CIS Benchmarks, NIST 800-53, PCI DSS, HIPAA, and others. Deploy a conformance pack to immediately start evaluating your environment against a framework.
• Configuration timeline. A historical record of how each resource was configured at any point in time. Auditors can use this to verify that controls were consistently in place.
• Remediation actions. Config can automatically remediate non-compliant resources using Systems Manager Automation documents. For example, automatically enable encryption on unencrypted S3 buckets.

AWS Audit Manager

Audit Manager streamlines audit preparation by:

• Mapping controls to evidence sources. Define which AWS data sources provide evidence for each control in your framework.
• Automating evidence collection. Audit Manager continuously collects evidence from Config, CloudTrail, Security Hub, and other services.
• Generating assessment reports. Export comprehensive reports that you can share directly with auditors.

AWS Security Hub

Security Hub aggregates findings from GuardDuty, Inspector, Macie, IAM Access Analyzer, Firewall Manager, and Config into a single dashboard. It provides:

• Automated compliance checks. Security Hub continuously evaluates your resources against security standards including CIS AWS Foundations Benchmark, PCI DSS, and NIST 800-53.
• Compliance scores. Track your compliance posture over time and identify areas that need attention.
• Cross-account visibility. When used with Organizations, Security Hub provides compliance visibility across all accounts from a single delegated administrator account.

AWS Artifact

Artifact is your portal to AWS's own compliance documentation:

• AWS compliance reports. Access SOC 2, ISO 27001, PCI DSS, and other reports that document AWS's controls for the infrastructure layer.
• Agreements. Accept and manage agreements such as the BAA (for HIPAA) and the DPA (for GDPR) directly through the Artifact console.

Building a Compliance Framework on AWS

Rather than approaching each regulation independently, build a unified compliance framework that satisfies the common requirements across all applicable regulations.

Step 1: Identify Your Obligations

Determine which regulations apply to your organization. Many organizations are subject to multiple frameworks simultaneously. A healthcare SaaS company might need HIPAA, SOC 2, and potentially GDPR if serving European customers.

Step 2: Map Controls to AWS Services

Most compliance requirements map to a relatively small set of AWS security controls:

• Access control → IAM, Organizations, SCPs
• Encryption → KMS, ACM, S3 encryption, EBS encryption, RDS encryption
• Logging → CloudTrail, CloudWatch, VPC Flow Logs, S3 access logging
• Monitoring → GuardDuty, Security Hub, Config, CloudWatch alarms
• Network security → VPCs, security groups, NACLs, Network Firewall, WAF
• Data protection → Macie, S3 Object Lock, backup and replication

Step 3: Automate Compliance Monitoring

Deploy Config conformance packs, enable Security Hub standards, and configure Audit Manager assessments. These tools provide continuous monitoring rather than point-in-time assessments, which both reduces audit preparation effort and improves your actual security posture.

Step 4: Document Everything

Compliance is fundamentally about evidence. Document your policies, procedures, and technical controls. Use AWS Config, CloudTrail, and Audit Manager to generate automated evidence. Maintain a compliance calendar with review dates for access reviews, risk assessments, and control evaluations.

Step 5: Conduct Regular Assessments

Perform internal audits quarterly and engage external auditors annually (or as required by your framework). Use the automated evidence from AWS tools to streamline the assessment process.

Conclusion

Compliance on AWS is achievable, but it requires a deliberate, structured approach. The shared responsibility model means that AWS's certifications do not automatically extend to your workloads; you must configure and manage your environment to meet regulatory requirements.

The good news is that AWS provides excellent tooling for compliance: Config conformance packs map directly to regulatory frameworks, Audit Manager automates evidence collection, Security Hub provides continuous compliance scoring, and Artifact gives you access to AWS's own compliance documentation. When used together, these tools transform compliance from a painful annual audit exercise into a continuous, automated process.

If you are navigating compliance requirements on AWS and need expert guidance, our AWS security consulting services include compliance assessment and remediation. We have helped organizations achieve and maintain compliance with HIPAA, GDPR, PCI DSS, SOC 2, and other frameworks. Our approach combines technical implementation with the documentation and processes your auditors require, ensuring you are not just technically compliant but audit-ready.