Skip to content

PCI DSS v3.2.1

Deprecated Framework

This framework has been superseded by PCI DSS v4.0. Organizations should migrate to the newer version, which became mandatory for compliance assessments after March 31, 2024.

Best for: Any merchant, service provider, payment processor, acquirer, or issuer that stores, processes, or transmits cardholder data from major card brands (Visa, Mastercard, Amex, Discover, JCB). PCI DSS v3.2.1 applied regardless of transaction volume, though validation requirements varied by merchant level (Level 1: over 6 million transactions/year required a QSA audit; Levels 2-4 could self-assess).

Mandatory?Mandatory for any entity processing card data
Who validates?QSA (Level 1 merchants/SPs); SAQ self-assessment (Levels 2–4)
RenewalAnnual
ScopeCardholder data environment (CDE) and connected systems

🏛 PCI Security Standards Council (PCI SSC), founded by Visa, Mastercard, American Express, Discover, and JCB International. · PCI DSS v3.2.1 (superseded by v4.0) Official source →

Get Started

module "..." {
  source  = "pcidssv321.compliance.tf/terraform-aws-modules/<module>/aws"
  version = "<version>"
}

What Compliance.tf Covers vs. What You Handle

  • What Compliance.tf automates

    • Encryption in Transit: Runs 4 controls checking CloudFront distribution TLS configuration, SSL protocol versions, origin encryption settings, and ACM certificate expiration. Covers Requirement 4.1 enforcement for AWS CDN infrastructure.
    • Audit Logging and Monitoring: Verifies CloudTrail is enabled across all regions with read/write events, S3 data event logging, CloudWatch integration, log file validation, 365-day log group retention, and Config recorder delivery. Ten controls total, mapping to Requirements 10.1-10.3 and 10.7.
    • Encryption at Rest: Checks that CloudTrail logs are encrypted with customer-managed KMS CMKs rather than default S3 encryption. Maps to Requirement 3.4's mandate to render stored data unreadable.
    • Network Security: Checks that Auto Scaling launch configurations do not assign public IPs and that API Gateway stages are associated with WAF web ACLs. Maps to Requirements 1.2 and 1.3 for restricting connections to the CDE.
    • Secure Development Practices: Three controls: CodeBuild projects must not run in privileged mode, must not expose sensitive AWS values in plaintext environment variables, and must use OAuth for source repository access.

  • What you handle

    • Encryption in Transit: Documenting all CHD transmission flows, verifying TLS configuration on non-AWS endpoints, and maintaining a protocol inventory across the CDE.
    • Audit Logging and Monitoring: Setting up log alerting for Requirement 10.6 daily reviews, defining incident response procedures for log anomalies, and demonstrating that logs are reviewed by personnel or automated tooling.
    • Encryption at Rest: Documenting key management procedures per Requirements 3.5-3.6, implementing key rotation, restricting key custodian access, and encrypting all other data stores (RDS, DynamoDB, EBS) that may contain cardholder data.
    • Network Security: Maintaining network diagrams (Requirement 1.1.2), documenting all allowed services and ports (Requirement 1.1.6), performing firewall rule reviews every six months (Requirement 1.1.7), and configuring security groups and NACLs beyond what these controls check.
    • Secure Development Practices: Implementing a full secure SDLC per Requirement 6.3, conducting code reviews (Requirement 6.3.2), deploying patches within one month (Requirement 6.2), and training developers on secure coding (Requirement 6.5).

Controls by Category

Requirement 10: Track and Monitor All Access to Network Resources and Cardholder Data (5 controls)

This is the largest control area in most PCI DSS assessments. The scope is broad: Requirements 10.2-10.3 specify which events must be captured, Requirement 10.7 sets retention at one year with three months immediately available, and Requirement 10.5.5 requires file integrity monitoring on the logs themselves, which CloudTrail's log file validation directly addresses. Failed Config recorder deliveries are a reliable audit flag because they mark a window where configuration changes went unrecorded.

API Gateway stage logging should be enabled At least one enabled trail should be present in a region CloudTrail trails should be integrated with CloudWatch logs CloudTrail trail log file validation should be enabled Log group retention period should be at least 365 days compliance.tf module

Requirement 3: Protect Stored Cardholder Data (1 control)

A common gap here is encrypting primary data stores while leaving audit logs unprotected. Requirement 3.4 applies to any mechanism that renders stored cardholder data unreadable, and assessors extend that scrutiny to CloudTrail logs that may reference CHD. Expect questions about KMS key rotation schedules and who holds key custodian access under Requirements 3.5-3.6.

CloudTrail trail logs should be encrypted with KMS CMK

Requirement 4: Encrypt Transmission of Cardholder Data Across Open Networks (1 control)

The check is straightforward: TLS 1.2 or higher on every data path touching the CDE, with SSLv3 and early TLS explicitly disabled. Expired ACM certificates get flagged not just as a hygiene issue but because a lapsed cert can force fallback to unencrypted connections or prompt staff to implement insecure workarounds under operational pressure.

CloudFront distributions should require encryption in transit compliance.tf module

Requirement 6: Develop and Maintain Secure Systems and Applications (1 control)

Plaintext AWS credentials in CodeBuild environment variables are a direct Requirement 6.3.2 violation and one of the first things an assessor checks in the build pipeline. Privileged mode in build containers draws similar scrutiny because it grants host-level access that can compromise pipeline integrity. Assessors also verify that source repository access uses OAuth rather than embedded credentials.

CodeBuild project environments should not have privileged mode enabled
Additional Controls (74)

AWS Database Migration Service (1)

DMS replication instances should not be publicly accessible compliance.tf module

AWS IAM (2)

Ensure IAM password policy prevents password reuse IAM password policies for users should have strong configurations

AWS Lambda (1)

Lambda functions should be in a VPC compliance.tf module

AWS Step Functions (1)

Step Function state machines should have logging turned on compliance.tf module

Amazon CloudWatch Logs (1)

Log group encryption at rest should be enabled compliance.tf module

Amazon DynamoDB (3)

DynamoDB table should be encrypted with AWS KMS compliance.tf module DynamoDB table should have encryption enabled compliance.tf module DynamoDB table point-in-time recovery should be enabled compliance.tf module

Amazon DynamoDB Accelerator (1)

DynamoDB Accelerator (DAX) clusters should be encrypted at rest

Amazon EBS (2)

Attached EBS volumes should have encryption enabled compliance.tf module EBS volume encryption at rest should be enabled compliance.tf module

Amazon EC2 (2)

EC2 instances should be in a VPC compliance.tf module EC2 instances should not have a public IP address compliance.tf module

Amazon EFS (2)

EFS file system encryption at rest should be enabled compliance.tf module EFS file systems should be encrypted with CMK compliance.tf module

Amazon EKS (2)

EKS clusters endpoint should restrict public access compliance.tf module EKS clusters should be configured to have kubernetes secrets encrypted using KMS compliance.tf module

Amazon ElastiCache (1)

ElastiCache Redis cluster automatic backup should be enabled with retention period of 15 days or greater compliance.tf module

Amazon OpenSearch Service (7)

OpenSearch domains should have audit logging enabled. compliance.tf module OpenSearch domains should have encryption at rest enabled compliance.tf module OpenSearch domains should have fine-grained access control enabled compliance.tf module OpenSearch domains should use HTTPS compliance.tf module OpenSearch domains should be in a VPC compliance.tf module OpenSearch domains logs to AWS CloudWatch Logs compliance.tf module OpenSearch domains node-to-node encryption should be enabled compliance.tf module

Amazon RDS (12)

RDS DB clusters should have automatic minor version upgrade enabled IAM authentication should be configured for RDS clusters compliance.tf module RDS database clusters should use a custom administrator username compliance.tf module RDS DB instance automatic minor version upgrade should be enabled compliance.tf module RDS DB instance backup should be enabled compliance.tf module RDS DB instances backup retention period should be greater than or equal to 7 compliance.tf module RDS DB instance encryption at rest should be enabled compliance.tf module RDS DB instances should have iam authentication enabled compliance.tf module Database logging should be enabled compliance.tf module RDS database instances should use a custom administrator username compliance.tf module RDS DB instances should not use public subnet compliance.tf module RDS DB instances should prohibit public access compliance.tf module

Amazon Redshift (5)

AWS Redshift audit logging should be enabled compliance.tf module AWS Redshift clusters should have automatic snapshots enabled compliance.tf module Redshift cluster audit logging and encryption should be enabled compliance.tf module AWS Redshift should have required maintenance settings compliance.tf module Redshift clusters should prohibit public access compliance.tf module

Amazon S3 (15)

S3 bucket cross-region replication should be enabled compliance.tf module S3 bucket default encryption should be enabled compliance.tf module S3 bucket default encryption should be enabled with KMS compliance.tf module S3 buckets should have lifecycle policies configured compliance.tf module S3 bucket logging should be enabled compliance.tf module S3 bucket MFA delete should be enabled compliance.tf module S3 bucket ACLs should not be accessible to all authenticated user compliance.tf module S3 buckets object logging should be enabled S3 bucket policy should prohibit public access compliance.tf module S3 buckets should prohibit public read access compliance.tf module S3 buckets should prohibit public write access compliance.tf module S3 buckets with versioning enabled should have lifecycle policies configured compliance.tf module S3 bucket versioning should be enabled compliance.tf module S3 public access should be blocked at account level compliance.tf module S3 public access should be blocked at bucket levels compliance.tf module

Amazon SNS (1)

SNS topics should be encrypted at rest compliance.tf module

Amazon SageMaker (3)

SageMaker notebook instances should not have direct internet access SageMaker notebook instances should be encrypted using CMK SageMaker notebook instance encryption should be enabled

Amazon VPC (1)

VPC Security groups should only allow unrestricted incoming traffic for authorized ports compliance.tf module

Elastic Load Balancing (6)

ELB application and classic load balancer logging should be enabled compliance.tf module ELB application load balancers should be configured with defensive or strictest desync mitigation mode compliance.tf module ELB application load balancers should be configured to drop HTTP headers compliance.tf module Application Load Balancer should be configured to drop invalid http headers compliance.tf module Application and Network Load Balancer listeners should use secure protocols to encrypt data in transit compliance.tf module ELB classic load balancers should be configured with defensive or strictest desync mitigation mode compliance.tf module

Other (5)

Elasticsearch domains should have audit logging enabled ES domain encryption at rest should be enabled ES domains should be in a VPC Elasticsearch domain should send logs to CloudWatch Elasticsearch domain node-to-node encryption should be enabled

  • PCI DSS v4.0 — 🟢 High overlap (85%)

    PCI DSS v4.0 is the direct successor. Most v3.2.1 requirements carry forward, but v4.0 adds 64 new requirements (many with extended timelines to March 2025), introduces a customized approach as an alternative to the defined approach, and strengthens multi-factor authentication and password requirements. Organizations should migrate assessments to v4.0.

  • NIST 800-53 Rev 5 — 🟡 Medium overlap (55%)

    NIST 800-53 Rev 5 covers a much broader set of security and privacy controls. PCI DSS Requirements 1-2 map to NIST's SC and CM families, Requirement 10 maps heavily to AU controls, and Requirement 3 aligns with SC-28. NIST provides depth in areas PCI DSS does not emphasize, like supply chain risk management.

  • SOC 2 — 🟡 Medium overlap (45%)

    SOC 2 Trust Services Criteria partially overlaps with PCI DSS in access control (CC6.x maps to Requirements 7-8), logging and monitoring (CC7.x maps to Requirement 10), and encryption (CC6.1 maps to Requirements 3-4). SOC 2 is broader in its scope of organizational controls but less prescriptive about specific technical configurations.

Frequently Asked Questions

PCI DSS v3.2.1 was retired March 31, 2024. Can I still be assessed against it?

No. After March 31, 2024, all PCI DSS assessments must use v4.0 or later. A v3.2.1 Report on Compliance (ROC) or Self-Assessment Questionnaire (SAQ) completed before that date remains valid until its expiration (typically one year from the assessment date), but new assessments and renewals must use PCI DSS v4.0.1. The compliance.tf benchmark for v3.2.1 remains available for gap analysis and historical comparison; use the v4.0 benchmark for current compliance work.

What changes between v3.2.1 and v4.0 affect my AWS controls?

Several changes are worth noting. Requirement 8.3.1 now mandates MFA for all access to the CDE, not just remote access. Requirement 6.4.2 introduces a web application firewall requirement for all public-facing web applications, removing the manual code review alternative. Requirement 12.3.1 requires a targeted risk analysis for each PCI DSS requirement where the organization uses flexibility. New Requirement 5.4 adds anti-phishing controls. Most of the 50 controls mapped in v3.2.1 carry forward to v4.0 with minor renumbering, but additional controls will be needed for the new requirements.

These 50 controls only cover AWS. Does that satisfy my full PCI DSS assessment?

No. These controls automate checks for a subset of PCI DSS requirements as they apply to AWS infrastructure. A full PCI DSS assessment covers physical security (Requirement 9), security policies and procedures (Requirement 12), personnel security awareness training (Requirement 12.6), and vendor management (Requirement 12.8), none of which can be verified through Terraform or cloud API checks. Use these controls to maintain continuous visibility into your AWS CDE posture between annual assessments, and pair them with manual evidence collection for non- technical requirements.

How do I scope my AWS environment for PCI DSS?

Start by identifying every AWS account, VPC, subnet, and service that stores, processes, or transmits cardholder data. Then identify all connected systems, meaning any resource that can communicate with CDE components, including shared services like Active Directory, DNS, logging pipelines, and CI/CD tooling. Network segmentation using separate VPCs or accounts with strict security group and NACL rules can reduce scope. AWS accounts with no network path to cardholder data that provide no security services to the CDE can be excluded. Document your scoping decisions; a QSA will validate them.

The benchmark shows 50 controls, but PCI DSS v3.2.1 has over 250 sub-requirements. What is missing?

The 50 controls cover requirements that can be automatically verified through AWS API checks, concentrated in Requirements 1, 2, 3, 4, 6, and 10. Requirements with no automated AWS equivalent include Requirement 5 (anti-virus, which depends on OS-level agents), Requirement 7 (role-based access models that require business context), Requirement 8 (password policies that may live in identity providers outside AWS), Requirement 9 (physical security), Requirement 11 (penetration testing and IDS/IPS), and Requirement 12 (policies and procedures). Treat the automated benchmark as one input to your compliance program, not the complete picture.