Guidance on Implementing PCI DSS Requirements (11.3.1.2, 11.5.1, 11.5.1.1, 11.5.2, 11.6.1, 6.5.1) in AWS – Org vs. Member Account Best Practices

I believe you may interest to below:

PCI DSS Requirements Breakdown in AWS:

11.3.1.2 – Internal Authenticated Vulnerability Scanning This requirement involves scanning systems within the Cardholder Data Environment (CDE) using credentialed access. In AWS, this is best implemented at the Member account level, because the scans need access to specific EC2 instances, containers, or workloads. You can use AWS Systems Manager to orchestrate scans, or integrate third-party tools like Tenable or Qualys. While orchestration can be centralized, the actual scanning must be scoped to the resources in each account.

11.5.1 – Intrusion Detection/Prevention Across the CDE Perimeter This control is about detecting and preventing intrusions at critical points. In AWS, you can deploy services like AWS GuardDuty, AWS Network Firewall, and AWS WAF. GuardDuty is ideal for Organization-level deployment, using delegated admin to centralize threat detection across accounts. However, firewalls and WAFs are deployed within Member accounts, typically at the VPC level, to protect specific workloads.

11.5.1.1 – Detecting Covert Malware Communication Channels (Service Providers) This is a specialized extension of 11.5.1, focusing on identifying hidden or covert channels used by malware. AWS GuardDuty is again your go-to here, and it can detect DNS tunneling and command-and-control traffic. Since GuardDuty supports centralized management, this control is best implemented at the Organization level, with findings aggregated in Security Hub.

11.5.2 – File Integrity Monitoring (FIM) FIM requires monitoring for unauthorized changes to critical files. This is inherently tied to the operating system and application layer, so it belongs at the Member account level. You can use AWS Systems Manager with custom scripts or third-party tools like Tripwire or Qualys FIM to monitor file paths on EC2 instances. Alerts and logs can be forwarded to a centralized SIEM if needed.

11.6.1 – Change/Tamper Detection on HTTP Headers and Sensitive Web Pages This control focuses on the consumer-facing side—detecting unauthorized changes to web content. It’s best implemented at the Member account level, where the actual web applications live. You can use AWS CloudFront with Lambda@Edge to inspect and log headers, or deploy third-party integrity checkers that monitor page content. This is a workload-specific control, so centralizing it isn’t practical.

6.5.1 – Change Management Procedures for Production Changes This requirement is about managing changes to production systems with proper approvals, testing, and rollback plans. AWS provides tools like AWS CodePipeline, AWS CloudTrail, AWS Config, and AWS Change Manager. These can be orchestrated at the Organization level to enforce consistent change policies across accounts. CloudTrail and Config Aggregator help with audit readiness, while Change Manager supports approval workflows.

Suggested service for the setup:

• Security Hub: Centralize findings from GuardDuty, Inspector, Config, etc. • AWS Config Aggregator: Collect compliance data across accounts. • Systems Manager: Use Run Command and Patch Manager for scan orchestration. • CloudTrail + S3 + Athena: Centralize logs for audit and forensic analysis. • CodePipeline + Change Manager: Enforce change control with approvals and rollback.

https://aws.amazon.com/compliance/pci-dss-level-1-faqs/#topic-1