Skip to content

PCI DSS v4.0

Best for: Any entity that stores, processes, or transmits payment card data from Visa, Mastercard, American Express, Discover, or JCB: merchants, payment processors, acquirers, issuers, and service providers. Transaction volume determines your validation path, a QSA-led Report on Compliance (ROC) or a Self-Assessment Questionnaire (SAQ). Even a small e-commerce site that redirects to a hosted payment page must validate compliance.

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 American Express, Discover, JCB, Mastercard, and Visa. · PCI DSS v4.0 Official source →

Get Started

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

What Compliance.tf Covers vs. What You Handle

  • What Compliance.tf automates

    • Encryption at Rest: Checks encryption configuration on API Gateway caches, Athena workgroups, and AWS Backup recovery points, and verifies that KMS-managed keys are applied where available.
    • Encryption in Transit: Validates TLS enforcement on CloudFront distributions and API Gateway stages (SSL certificate attachment), and checks ACM certificate properties including RSA key length (2048-bit minimum) and expiration within 30 days.
    • Access Control: Verifies that API Gateway v2 routes have authorization types explicitly configured, confirms AWS Organizations governance at the account level, and checks IMDSv2 enforcement on Auto Scaling launch configurations to prevent credential exposure.
    • Logging and Monitoring: Confirms logging is enabled on API Gateway stages and AppSync GraphQL APIs (field-level), checks X-Ray tracing on REST API stages, and validates CloudFormation stack notification configuration for change detection.
    • Data Protection and Backup: Validates that backup plans enforce a minimum 35-day retention period, that recovery points are encrypted, and that manual deletion of recovery points is disabled.
    • Network Security: Checks that API Gateway stages are associated with WAF web ACLs, providing layer 7 filtering on public-facing endpoints.

  • What you handle

    • Encryption at Rest: Key management procedures must be documented per Requirement 3.6, including rotation schedules, split knowledge and dual control for custodians, and the cryptographic key inventory. None of this is enforceable through infrastructure code alone.
    • Encryption in Transit: TLS policy version selection (ensuring TLS 1.2 or higher), cipher suite configuration review, documenting authorized protocols per Requirement 4.2.1, and certificate lifecycle management processes beyond expiration monitoring.
    • Access Control: You own the RBAC design, user provisioning and deprovisioning workflows, quarterly access reviews (Req 7.2.4), and MFA implementation for all access into the CDE (Req 8.4.2).
    • Logging and Monitoring: Log aggregation, correlation, and 12-month retention (Req 10.5.1). Daily log review processes, SIEM integration, alerting rules for security events per Requirement 10.4.1, and defining which events trigger incident response.
    • Data Protection and Backup: Backup restoration testing, documented data retention and disposal policies per Requirement 3.1, and secure media destruction processes for Requirement 9.4.
    • Network Security: WAF rules need human tuning. Annual penetration testing to validate segmentation (Req 11.4.6), firewall rule reviews every six months (Req 1.2.7), and documentation of all inbound and outbound traffic flows are outside what any scanning tool can assess.

Controls by Category

Requirement 10: Log and Monitor All Access (4 controls)

Assessors want logs that capture user identification, event type, timestamp, and success or failure for all access to system components and CHD per Requirement 10.2.1. Disabled logging on API Gateway stages is one of the most common PCI findings in AWS environments. X-Ray tracing and CloudFormation stack notifications both contribute to Requirement 10.4.1's expectation of timely detection for security-relevant changes.

API Gateway REST API stages should have AWS X-Ray tracing enabled API Gateway stage logging should be enabled AppSync graphql API logging should be enabled compliance.tf module CloudFormation stacks should have notifications enabled

Requirement 12: Maintain Security Policies and Data Retention (1 control)

Manual deletion being enabled on backup recovery points is a red flag. It signals weak protection against insider threats and ransomware, and directly conflicts with Requirement 12.3.1's mandate for formal data retention schedules. Assessors also cross-check retention periods against documented organizational policy and the disposal requirements under Requirement 3.1.

Backup plan min frequency and min retention check

Requirement 3: Protect Stored Account Data (2 controls)

Requirement 3.6 is what assessors focus on: are encryption keys managed separately from the data they protect? They will check every data store, cache, and backup connected to the CDE for strong cryptography. Unencrypted backup recovery points and API Gateway caches holding response data are among the most reliably flagged findings.

Athena workgroups should be encrypted at rest API Gateway stage cache encryption at rest should be enabled

Requirement 4: Protect Data in Transit with Strong Cryptography (3 controls)

All CHD transmissions over open, public networks must use TLS 1.2 or higher per Requirement 4.2.1. Assessors check certificate validity, RSA key strength (2048-bit minimum), and HTTPS enforcement on all public-facing endpoints. Expired ACM certificates and CloudFront distributions with HTTP fallback are the gaps that surface most reliably.

API Gateway stage should uses SSL certificate CloudFront distributions should require encryption in transit compliance.tf module RSA certificates managed by ACM should use a key length of at least 2,048 bits compliance.tf module

Requirement 7-8: Access Control and Authentication (1 control)

The first question is whether authorization types on API routes are explicitly configured rather than left open by default. Assessors also want evidence that access is restricted by business need to know (Req 7.2) and that every user has a unique ID (Req 8.2.1). A registered security contact demonstrates incident response readiness tied to Requirement 12.10.1.

API Gateway routes should specify an authorization type
Additional Controls (159)

AWS CloudTrail (4)

At least one enabled trail should be present in a region CloudTrail trails should be integrated with CloudWatch logs CloudTrail trail logs should be encrypted with KMS CMK CloudTrail trail log file validation should be enabled

AWS CodeBuild (4)

CodeBuild project artifact encryption should be enabled CodeBuild project environments should not have privileged mode enabled CodeBuild projects should have logging enabled CodeBuild project S3 logs should be encrypted

AWS Database Migration Service (3)

DMS endpoints for Redis OSS should have TLS enabled DMS endpoints should use SSL DMS replication instances should not be publicly accessible compliance.tf module

AWS IAM (9)

Ensure IAM password policy requires a minimum length of 14 or greater Ensure IAM password policy requires at least one lowercase letter Ensure IAM password policy requires at least one number Ensure IAM password policy requires at least one symbol Ensure IAM password policy requires at least one uppercase letter Ensure IAM password policy prevents password reuse Password policies for IAM users should have strong configurations with minimum length of 8 or greater IAM password policies for users should have strong configurations Ensure IAM password policy expires passwords within 90 days or less

AWS KMS (1)

KMS CMK rotation should be enabled compliance.tf module

AWS Lambda (2)

Lambda functions should be in a VPC compliance.tf module Lambda functions should use latest runtimes compliance.tf module

AWS Secrets Manager (1)

Secrets Manager secrets should be encrypted using CMK compliance.tf module

AWS Step Functions (1)

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

AWS WAF (1)

AWS WAF rules should have CloudWatch metrics enabled

Amazon CloudFront (4)

CloudFront distributions access logs should be enabled compliance.tf module CloudFront distributions should use SNI to serve HTTPS requests compliance.tf module CloudFront distributions should use custom SSL/TLS certificates compliance.tf module CloudFront distributions should have AWS WAF enabled compliance.tf module

Amazon CloudWatch (2)

CloudWatch alarm should have an action configured compliance.tf module Log group retention period should be at least 365 days compliance.tf module

Amazon CloudWatch Logs (1)

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

Amazon DocumentDB (3)

AWS DocumentDB clusters should have an adequate backup retention period AWS DocumentDB clusters should be encrypted at rest DocumentDB instance logging should be enabled

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 (2)

DynamoDB Accelerator (DAX) clusters should be encrypted at rest DynamoDB Accelerator clusters should be encrypted in transit

Amazon EBS (3)

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

Amazon EC2 (10)

EC2 Client VPN endpoints should have client connection logging enabled EC2 instance detailed monitoring should be enabled compliance.tf module EC2 instances should have IAM profile attached compliance.tf module EC2 instances should be in a VPC compliance.tf module EC2 instances should not use key pairs in running state compliance.tf module EC2 instances should not have a public IP address compliance.tf module EC2 instances should use IMDSv2 compliance.tf module Ensure IAM instance roles are used for AWS resource access from instances compliance.tf module AWS EC2 launch templates should not assign public IPs to network interfaces compliance.tf module EC2 transit gateways should have auto accept shared attachments disabled

Amazon ECR (1)

ECR repositories should have image scan on push enabled compliance.tf module

Amazon ECS (3)

ECS clusters should have container insights enabled compliance.tf module ECS fargate services should run on the latest fargate platform version compliance.tf module ECS task definitions should not share the host's process namespace compliance.tf module

Amazon EFS (4)

EFS access points should enforce a root directory EFS access points should enforce a user identity 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 (4)

EKS clusters should have control plane audit logging enabled compliance.tf module EKS clusters endpoint public access should be restricted compliance.tf module 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 EMR (1)

EMR cluster Kerberos should be enabled compliance.tf module

Amazon ElastiCache (5)

ElastiCache clusters should not use the default subnet group ElastiCache Redis cluster automatic backup should be enabled with retention period of 15 days or greater compliance.tf module ElastiCache for Redis replication groups should be encrypted at rest compliance.tf module ElastiCache for Redis replication groups should be encrypted with CMK compliance.tf module ElastiCache for Redis replication groups should be encrypted in transit compliance.tf module

Amazon Kinesis (2)

Kinesis streams should be encrypted with CMK Kinesis streams should have server side encryption enabled

Amazon MQ (1)

Active MQ brokers should stream audit logs to CloudWatch

Amazon MSK (1)

MSK clusters should be encrypted in transit among broker nodes compliance.tf module

Amazon Neptune (4)

Neptune DB clusters should publish audit logs to CloudWatch Logs Neptune DB clusters should have automated backups enabled Neptune DB clusters should be encrypted at rest Neptune DB clusters should have IAM database authentication enabled

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 (18)

Aurora MySQL DB clusters should have audit logging enabled compliance.tf module Aurora PostgreSQL DB clusters should publish logs to CloudWatch Logs compliance.tf module RDS DB clusters should have automatic minor version upgrade enabled RDS DB clusters should be encrypted with CMK compliance.tf module RDS DB clusters should be encrypted at rest compliance.tf module IAM authentication should be configured for RDS clusters 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 instances should be integrated with CloudWatch logs 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 for MariaDB DB instances should publish logs to CloudWatch Logs compliance.tf module RDS DB instances should not use public subnet compliance.tf module RDS for PostgreSQL DB instances should publish logs to CloudWatch Logs compliance.tf module RDS DB instances should prohibit public access compliance.tf module RDS for SQL Server DB instances should publish logs to CloudWatch Logs compliance.tf module

Amazon Redshift (10)

AWS Redshift audit logging should be enabled compliance.tf module AWS Redshift clusters should have automatic snapshots enabled compliance.tf module AWS Redshift should have automatic upgrades to major versions enabled compliance.tf module Redshift cluster encryption in transit should be enabled compliance.tf module Redshift cluster audit logging and encryption should be enabled compliance.tf module AWS Redshift enhanced VPC routing should be enabled compliance.tf module AWS Redshift clusters should be encrypted with KMS compliance.tf module AWS Redshift should have required maintenance settings compliance.tf module Redshift clusters should have Multi-AZ deployments enabled compliance.tf module Redshift clusters should prohibit public access compliance.tf module

Amazon S3 (21)

S3 access points should have block public access settings enabled S3 buckets access control lists (ACLs) should not be used to manage user access to buckets compliance.tf module 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 event notifications enabled 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 bucket object lock should be enabled compliance.tf module S3 buckets object logging should be enabled S3 bucket policy should prohibit public access compliance.tf module S3 bucket cross-account permissions should be restricted 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 Multi-Region Access Points should have block public access settings enabled 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 (6)

SageMaker endpoint configuration encryption should be enabled SageMaker notebook instances should not have direct internet access SageMaker notebook instances should be encrypted using CMK SageMaker notebook instance encryption should be enabled SageMaker notebook instances should be in a VPC SageMaker notebook instances root access should be disabled

Amazon VPC (1)

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

Elastic Load Balancing (4)

ELB application and classic load balancer logging should be enabled compliance.tf module ELB application and network load balancers should only use SSL or HTTPS listeners 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 (11)

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 FSx for OpenZFS file systems should be configured to copy tags to backups and volumes compliance.tf module FSx for Lustre file systems should be configured to copy tags to backups compliance.tf module Access logging should be configured for API Gateway V2 Stages compliance.tf module The default stateless action for Network Firewall policies should be drop or forward for fragmented packets compliance.tf module The default stateless action for Network Firewall policies should be drop or forward for full packets compliance.tf module Amazon Redshift Serverless workgroups should use enhanced VPC routing

  • NIST 800-53 Rev 5 — 🟢 High overlap (65%)

    PCI DSS v4.0 maps extensively to NIST 800-53 Rev 5 control families, especially SC (System and Communications Protection), AC (Access Control), AU (Audit and Accountability), and IA (Identification and Authentication). NIST 800-53 is broader in scope and covers federal information systems, while PCI DSS narrows focus to cardholder data protection. Organizations already compliant with NIST 800-53 will find significant reuse when scoping a PCI assessment.

  • SOC 2 — 🟡 Medium overlap (50%)

    SOC 2 Trust Services Criteria for Security, Availability, and Confidentiality partially overlaps with PCI DSS requirements for access control, logging, encryption, and change management. SOC 2 does not prescribe the same technical specificity (no explicit TLS version requirement or key length mandate), so PCI DSS controls generally satisfy SOC 2 criteria but not the reverse.

  • NIST CSF v1.0 — 🟡 Medium overlap (55%)

    The NIST Cybersecurity Framework maps to PCI DSS across Identify, Protect, Detect, Respond, and Recover functions. PCI SSC publishes an official mapping between PCI DSS v4.0 and NIST CSF. NIST CSF is risk-based and outcome-oriented, while PCI DSS prescribes specific implementation requirements.

Frequently Asked Questions

Does PCI DSS v4.0 apply to my organization if we use a third-party payment processor?

Yes. Using a third-party processor reduces your scope but does not eliminate your compliance obligation. If your systems touch cardholder data at any point, including web pages that host payment fields or redirect to a processor, you are in scope. Most small merchants using hosted payment pages can complete SAQ A, which has the fewest requirements. Your acquiring bank determines your merchant level and the applicable SAQ type.

What changed between PCI DSS v3.2.1 and v4.0 that I need to know?

The largest changes are: expanded MFA requirements covering all access into the CDE, not just remote access (Req 8.4.2); a new requirement for automated log review mechanisms (Req 10.4.1.1); targeted risk analysis replacing the blanket 'periodic' language across several requirements (Req 12.3.1); client-side script integrity monitoring for payment pages (Req 6.4.3); and the customized approach as an alternative validation method. Requirements that were labeled future- dated until March 31, 2025 are now mandatory.

How long does a PCI DSS v4.0 assessment typically take?

It depends on your level and readiness. A Level 1 merchant or service provider undergoing a full QSA-led ROC assessment typically runs 3 to 6 months from gap analysis through final report submission. SAQ completion for smaller merchants can take 2 to 6 weeks. The formal assessment is annual, but quarterly ASV scans and ongoing monitoring run year-round.

What does the 'customized approach' in PCI DSS v4.0 mean for my AWS environment?

The customized approach (defined in PCI DSS v4.0 Section 12.3.2 and Appendix D) lets you meet a requirement's stated objective using a control different from the defined approach. You must document a controls matrix, perform a targeted risk analysis, and have the QSA validate that your custom control meets the objective. For AWS environments, one approach to meeting this would be combining native services (GuardDuty, Security Hub, Config Rules) to satisfy a requirement's intent where the specific prescribed method differs. Be aware that the customized approach requires more documentation and QSA scrutiny, not less.

How many of the 50 mapped controls can compliance.tf automate versus what requires manual evidence?

The 50 controls mapped here cover technical configuration checks: encryption settings, logging enablement, access authorization, certificate validity, and backup policies, all continuously assessable through Terraform and PowerPipe. That said, PCI DSS v4.0 has 64 base requirements across 12 requirement groups, many of which require procedural evidence (written policies, training records, physical security controls, penetration test reports, incident response plans). Expect compliance.tf to automate roughly 40-60% of the technical evidence for Requirements 1 through 4 and 10, with minimal coverage for Requirements 5, 9, 11, and 12, which depend on non-infrastructure evidence.