Why Standard Controls Matrices Fail QSA Review
Most security controls matrices produced by AWS-hosted entities list control names from a compliance framework — "firewall in place," "access logs enabled," "encryption at rest" — without specifying the AWS artefact that demonstrates the control. This creates three problems in a QSA assessment:
- No evidence trail. A control statement with no corresponding AWS resource ARN, Config rule name, or CloudTrail event cannot be tested. The QSA cannot confirm compliance without re-performing discovery from scratch.
- Shared responsibility gaps are invisible. AWS manages physical security, hypervisor patching, and managed service infrastructure. But entities frequently claim AWS-managed controls as their own without documenting what the entity is responsible for in the shared model.
- 4.0.1 specificity is missing. Requirements added or materially changed in 4.0.1 — Req 6.4.3, 11.6.1, 12.3.2, 12.3.3 — are absent from matrices produced before March 2025.
The matrix below maps each requirement domain to the specific AWS service that provides evidence, the Config rule or API call a QSA will verify, and the gap the entity must close independently of AWS.
How to use this matrix: For each requirement, the "AWS evidence" column identifies what exists in the AWS account. The "entity obligation" column identifies what the entity must produce that AWS does not generate automatically. A finding arises when the entity obligation column is empty in the client's documentation.
The Controls Matrix: Requirement by Requirement
Requirements 1 & 2 — Network Controls and Secure Configuration
| Sub-req | Control | AWS evidence source | Entity obligation | Common gap |
|---|---|---|---|---|
| 1.2.1 | Network controls between CDE and other networks | VPC Flow Logs, Security Group rules (describe-security-groups) | Document which security group rules permit which flows and why | Rules documented without business justification — fails Req 1.2.1(b) |
| 1.2.4 | Accurate network diagram | AWS Config resource inventory, VPC topology | Entity-maintained diagram updated within 30 days of change | Diagram dated before most recent architecture change |
| 1.3.2 | No direct public internet access to CDE | Security Hub: EC2.2 (no public IP on instances), ALB access logs | WAF association documented and rule set reviewed | WAF present but rule set not mapped to specific threat vectors |
| 1.4.2 | Controls between trusted and untrusted networks | Security group rules, NACL configuration | Documented review confirming rules follow least-access principle | Rules reviewed but no evidence review was performed by named individual |
| 2.2.1 | System components use vendor-supported software | AWS Systems Manager Patch Compliance, Inspector findings | Patch SLA policy signed by information security owner | Patch policy exists but not signed or lacks SLA commitment |
| 2.2.7 | All non-console admin access encrypted | CloudTrail: ConsoleLogin events, SSM Session Manager logs | Policy prohibiting unencrypted administrative access | SSH/RDP used for management alongside SSM — dual-path not reconciled |
Requirement 3 — Protect Stored Account Data
| Sub-req | Control | AWS evidence source | Entity obligation | Common gap |
|---|---|---|---|---|
| 3.3.1 | SAD not retained post-authorisation | No AWS service detects SAD in application data — this is entirely entity obligation | Code review or DAST scan confirming no SAD in write paths; log scrubbing evidence | Assumed compliant with no technical evidence — most frequent Req 3 finding |
| 3.4.1 | PAN rendered unreadable in storage | RDS encryption (Config: RDS.3), S3 SSE (Config: S3.4), DynamoDB encryption at rest | KMS key policy confirming entity controls key rotation; truncation at application layer | AWS-managed KMS keys used — entity does not control key policy or rotation |
| 3.5.1 | Cryptographic key management procedures | KMS key rotation config (describe-key-rotation-status), CloudTrail: GenerateDataKey events | Documented key lifecycle (generation, distribution, retirement, destruction) | Key management procedure exists but does not address compromise response |
| 3.7.1 | Key rotation at least annually | KMS automatic rotation enabled (verify via Config rule: KMS.4) | Confirmation of rotation for all CMKs including those not auto-rotated | Rotation enabled for some CMKs but not all — asymmetric keys often missed |
Requirements 6 & 11 — Secure Development and Security Testing
| Sub-req | Control | AWS evidence source | Entity obligation | Common gap |
|---|---|---|---|---|
| 6.3.2 | Inventory of bespoke and custom software | CodePipeline history, ECR image manifest, Lambda version history | Maintained software inventory with version, owner, and last-reviewed date | Version history exists in AWS but no maintained inventory document |
| 6.4.3 ★ | Payment page scripts inventoried and integrity-protected | CloudFront access logs (script delivery), WAF logs | Script inventory with authorisation, integrity hash (SRI), and monitoring evidence | New in 4.0.1 — most entities have no script inventory at all |
| 6.4.4 | Test data removed before production | CodePipeline environment gates, separate account for test workloads | Evidence that production deployments do not carry test data or test credentials | Shared accounts between test and prod — test credentials found in prod Secrets Manager |
| 11.3.1 | Internal penetration test annually | No AWS service performs pen testing — AWS authorises but does not conduct | Pen test report from qualified tester, scoped to CDE, within 12 months | Pen test scoped to network only — application layer not tested |
| 11.5.1 | Intrusion detection in CDE | GuardDuty (threat detection), VPC Flow Logs anomaly alerting | Documented alert response procedure; evidence GuardDuty findings are reviewed | GuardDuty enabled but findings not reviewed — no response procedure documented |
| 11.6.1 ★ | Change/tamper detection for payment pages | CloudFront logs (header changes), WAF (request anomalies) | CSP violation reporting to monitored endpoint; monitoring procedure | New in 4.0.1 — CSP absent or reporting endpoint not monitored |
★ New or materially changed in PCI DSS 4.0.1
Requirements 7, 8 & 9 — Access Control
| Sub-req | Control | AWS evidence source | Entity obligation | Common gap |
|---|---|---|---|---|
| 7.2.2 | Access limited to least privilege | IAM Access Analyzer findings, IAM credential report | Role-based access model documentation; access review records | Wildcard IAM actions on in-scope resources — iam:* or s3:* in production roles |
| 8.2.1 | All users have unique IDs | IAM credential report (no shared users) | Evidence no shared IAM users exist; service access via roles only | Shared IAM users found in older accounts — often inherited from early setup |
| 8.3.6 | MFA for all non-consumer access to CDE | IAM: GetAccountSummary (MFA devices), CloudTrail: ConsoleLogin MFA status | MFA enforcement policy; evidence MFA cannot be bypassed | MFA configured but not enforced by SCP or permission boundary |
| 8.3.9 | Passwords/passphrases changed every 90 days (if used) | IAM password policy (GetAccountPasswordPolicy) | Confirmation of password policy enforcement and exception process | Password policy set to 90 days but max age not enforced for IAM users with API keys |
| 8.6.1 | Interactive login for system/application accounts restricted | CloudTrail: AssumeRole events for service roles | Evidence service accounts cannot be used for interactive login | Lambda execution roles also assigned to IAM users for debugging — not decommissioned |
Requirement 10 — Logging and Monitoring
| Sub-req | Control | AWS evidence source | Entity obligation | Common gap |
|---|---|---|---|---|
| 10.2.1 | Log all individual access to CHD | CloudTrail data events on in-scope S3/DynamoDB; application logs | Application-layer logging of CHD access by user/session ID | CloudTrail management events enabled but data events on CHD stores not enabled |
| 10.2.7 | Log all initialisation, halt, or pause of audit logs | CloudTrail: StopLogging events; CloudWatch alarm on StopLogging | Alert confirmed as active and tested in last 12 months | CloudTrail log integrity validation disabled — log tampering undetected |
| 10.3.2 | Audit log files protected from destruction | S3 Object Lock on CloudTrail bucket; MFA delete enabled | Confirmation bucket policy prevents log deletion by any principal | S3 bucket allows log deletion by account root — Object Lock not enabled |
| 10.4.1 | Logs reviewed at least daily | CloudWatch alarms, SIEM alerts, GuardDuty findings | Documented daily review process with evidence of reviews performed | Automated alerts exist but no evidence of human review or alert response |
| 10.7.1 | Log retention: 12 months, 3 immediately available | S3 lifecycle policy on CloudTrail bucket | Lifecycle policy confirmed — Glacier transition not before 90 days | Logs archived to Glacier at 30 days — immediate access unavailable for 3-month window |
The Shared Responsibility Gap: What AWS Does Not Cover
The AWS shared responsibility model is documented by AWS primarily from an infrastructure perspective. For PCI DSS, the boundaries are more nuanced. The following controls are not covered by any AWS service and are entirely the entity's obligation — they appear frequently in assessments because entities assume AWS handles them:
Application-layer SAD detection
No AWS service scans application code or database contents for retained SAD (CVV, full track data). Static code analysis tools and database scanning must be procured and run by the entity.
Information security policy
AWS does not produce, maintain, or review the entity's information security policy (Req 12.1). This document must be authored, reviewed annually, and distributed by the entity.
Security awareness training
Req 12.6 requires annual security awareness training for all personnel. AWS provides no training records. The entity must maintain training completion evidence.
TPSP agreements and monitoring
Req 12.8 requires written agreements with TPSPs and annual confirmation of their PCI DSS status. AWS provides no TPSP management tooling — the entity must maintain a TPSP register.
Physical media controls
Req 9 covers physical access controls and media handling. For AWS-hosted environments this primarily applies to offices and employee endpoints — AWS covers data centre physical security only.
Incident response testing
Req 12.10.2 requires the incident response plan to be tested annually. No AWS service generates evidence of incident response exercises — tabletop or simulation records must be produced by the entity.
AWS Config Rules That Map to PCI DSS Controls
AWS Security Hub's PCI DSS standard runs a subset of these Config rules automatically. The following rules are the most useful for QSA evidence collection — verify they are active in all in-scope accounts and regions:
| Config rule | PCI DSS requirement | What it checks | Limitation |
|---|---|---|---|
| restricted-ssh | 1.2.1 | No security groups with unrestricted SSH (port 22) ingress | Does not check application ports or protocol-specific rules |
| rds-instance-public-access-check | 1.3.2 | RDS instances not publicly accessible | Does not check network path from public subnet to RDS via EC2 |
| kms-cmk-not-scheduled-for-deletion | 3.5.1 | No KMS CMKs scheduled for deletion | Does not verify key policy restricts access to authorised principals only |
| cloudtrail-enabled | 10.2.x | CloudTrail enabled in account | Does not verify data events are enabled or log integrity validation is active |
| cloudtrail-s3-dataevents-enabled | 10.2.1 | S3 data events logged | Does not verify the specific S3 buckets storing CHD are covered |
| guardduty-enabled-centralized | 11.5.1 | GuardDuty enabled and centralised | Does not verify findings are reviewed or that alerts trigger response procedures |
| mfa-enabled-for-iam-console-access | 8.3.6 | MFA enabled for IAM console users | Does not verify MFA is enforced via SCP — only checks if configured |
| s3-bucket-server-side-encryption-enabled | 3.4.1 | S3 buckets use SSE | Does not distinguish between AWS-managed and customer-managed keys |
Assessment note: AWS Security Hub findings are a starting point, not a controls assessment. Security Hub does not test procedural controls, application-layer controls, or the quality of entity-produced documentation. A passing Security Hub posture score does not indicate PCI DSS compliance — it indicates that a subset of AWS-native configuration checks passed.
Interactive assessment
Apply this in your assessment
This assessment maps directly to the controls in this article. Use it to generate gap evidence, cardholder data flow diagrams, or scoping documentation for a PCI DSS assessment — free with a Sync Your Cloud account.
Security Controls Matrix Generator
Generate a PCI DSS 4.0.1 security controls matrix mapped to AWS services, Config rules, and CloudTrail evidence — with entity obligation columns and a gap register ready for QSA review.