Why Standard Controls Matrices Fail During Assessment
A security controls matrix can 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 can create three problems during assessment preparation:
- No evidence trail. A control statement with no corresponding AWS resource ARN, Config rule result, CloudTrail event or application artefact cannot be tested efficiently. The assessment team is forced to repeat discovery and reconstruct the evidence trail.
- Shared responsibility gaps are invisible. AWS manages physical security, hypervisor patching, and managed service infrastructure. An entity can incorrectly claim AWS-managed controls as its own without documenting what the entity is responsible for in the shared model.
- Future-dated v4.0 requirements are missing. Requirements introduced in PCI DSS v4.0 — including 6.4.3 and 11.6.1 — became effective on 31 March 2025. PCI DSS v4.0.1 clarified the standard but did not add or remove requirements.
The matrix below links selected requirement areas to potential AWS evidence sources and the entity-owned artefacts needed to make that evidence understandable and testable. These examples support assessment preparation; they do not establish compliance by themselves.
Evidence boundary: Treat each AWS service, API response and Config result as a potential evidence source — not a compliance conclusion. Evidence sufficiency depends on scope, control design, implementation, sampling and assessor testing. Use the entity-obligation column to assign ownership and identify missing records before the assessment.
Requirement references checked against PCI DSS v4.0.1, Requirements and Testing Procedures. Log retention is Requirement 10.5.1; stored PAN protection is 3.5.1; penetration-testing methodology and internal tests are 11.4.1 and 11.4.2. AWS checks below are supporting inputs, not equivalent controls.
The Controls Matrix: Requirement by Requirement
Requirements 1 & 2 — Network Controls and Secure Configuration
| Sub-req | Control | Potential AWS evidence source | Entity obligation | Example gap to investigate |
|---|---|---|---|---|
| 1.2.1 | Configuration standards for network security control rulesets | Security group, NACL and AWS Network Firewall configurations; AWS Config history | Documented ruleset standard, approved services and business justification | Rules exist, but their purpose, owner and approval cannot be demonstrated |
| 1.2.3 | Accurate network diagram showing CDE connections | AWS Config inventory, VPC route tables, Transit Gateway and load-balancer configuration | Entity-maintained diagram reconciled to the current in-scope architecture | Diagram omits a peering, VPN, third-party or management path |
| 1.2.4 | Accurate account-data flow diagram | Potential supporting inputs from VPC Flow Logs and application architecture records | Entity-maintained data-flow diagram showing storage, processing and transmission | Infrastructure diagram is supplied instead of an account-data flow diagram |
| 1.3.1 | Inbound traffic to the CDE restricted to necessary communications | Security group, NACL, Network Firewall and load-balancer listener configuration | Approved traffic-flow register with source, destination, port, protocol and purpose | Technically allowed flows are not reconciled to documented business need |
| 2.2.1 | Secure configuration standards developed and implemented | AWS Config conformance results, SSM Inventory and approved infrastructure baselines | Entity-defined hardening standards with ownership, review and exception records | Cloud checks exist without an approved configuration standard |
| 2.2.7 | Non-console administrative access encrypted | SSM Session Manager configuration, bastion configuration and relevant network controls | Documented administrative-access method and evidence insecure alternatives are disabled | Secure administration exists, but unmanaged SSH or RDP paths remain |
Requirement 3 — Protect Stored Account Data
| Sub-req | Control | Potential AWS evidence source | Entity obligation | Example gap to investigate |
|---|---|---|---|---|
| 3.3.1 | Sensitive authentication data not retained after authorisation, subject to issuing-service applicability notes | No AWS-native configuration check proves that application stores and logs are free of SAD | Data-flow analysis, code review and testing showing SAD is not written after authorisation | Encryption is cited as a substitute for the prohibition on retaining SAD |
| 3.5.1 | PAN rendered unreadable wherever stored | RDS, S3 and DynamoDB encryption configuration; KMS key references | Evidence of the selected protection method, PAN discovery results and data-level protection or tokenisation where applicable | Encryption-at-rest is shown without proving where PAN is stored or who can retrieve it |
| 3.6.1 | Cryptographic keys used to protect stored account data are secured | KMS key policies, grants, key metadata and relevant CloudTrail events | Documented access model, custodianship and protection procedures for in-scope keys | KMS is enabled, but privileged key access and separation of duties are not evaluated |
| 3.7.4 / 3.7.5 | Keys changed at the end of the defined cryptoperiod or when integrity is weakened | KMS rotation configuration and key metadata, where applicable to the key type | Defined cryptoperiods, rotation method and compromise-response evidence for every in-scope key | Automatic rotation is assumed to cover every key type and every lifecycle event |
Requirements 6 & 11 — Secure Development and Security Testing
| Sub-req | Control | Potential AWS evidence source | Entity obligation | Example gap to investigate |
|---|---|---|---|---|
| 6.3.2 | Inventory of bespoke and custom software and incorporated third-party components | Code repositories, CodePipeline deployment history, ECR image metadata and Lambda versions as supporting inputs | Maintained software and component inventory supporting vulnerability and patch management, with ownership and review records | Deployment history is mistaken for a controlled software inventory |
| 6.4.3 ★ | Payment-page scripts managed through authorisation, integrity and inventory controls | CloudFront configuration and deployment records may support testing but do not prove script authorisation or integrity | Script inventory, written justification, authorisation and evidence of integrity assurance | Delivery logs are supplied without an authorised inventory or integrity method |
| 6.5.5 | Live PAN not used in pre-production unless the environment is included in the CDE and protected | Separate AWS accounts, deployment configuration and Secrets Manager references can support testing | Test-data policy and evidence that live PAN is absent or the environment is appropriately scoped and protected | Environment separation is asserted without examining data and secret sources |
| 11.4.1 / 11.4.2 | Penetration-testing methodology defined; internal testing performed at least annually and after significant changes | AWS configuration and scope inventories can support test scoping; configuration records are not a penetration-test report | Current scoped report, methodology, tester independence and remediation evidence | A vulnerability scan or network-only exercise is supplied as the penetration test |
| 11.5.1 | Intrusion detection or prevention monitors CDE perimeter and critical points, alerts personnel and is kept current | GuardDuty findings and network telemetry may support a layered design but do not prove complete IDS/IPS coverage | Documented coverage, alert handling, tuning and response evidence for all in-scope paths | GuardDuty is enabled and treated as complete IDS coverage without a coverage analysis |
| 11.6.1 ★ | Detect unauthorised changes to payment-page HTTP headers and script contents | Deployment records, CloudFront configuration and monitoring outputs may support testing; WAF logs alone do not prove compliance | Implemented change-detection mechanism, baseline, alert destination and response records | CSP or WAF is presented without evidence that required changes are detected at the required frequency |
★ Introduced in PCI DSS v4.0 and effective from 31 March 2025. PCI DSS v4.0.1 added clarifications, not new requirements.
Requirements 7, 8 & 9 — Access Control
| Sub-req | Control | Potential AWS evidence source | Entity obligation | Example gap to investigate |
|---|---|---|---|---|
| 7.2.2 | User access based on job classification, function and least privilege | IAM policies, role assignments, Access Analyzer findings and access reports | Approved role model, access rationale and review records | Wildcard permissions remain without documented need or compensating restriction |
| 8.2.1 | Users assigned a unique ID before access is allowed | IAM Identity Center assignments, IAM credential report and identity-provider records | Authoritative joiner-mover-leaver records and evidence shared IDs are prohibited | Cloud identities are reviewed without reconciling them to workforce identities |
| 8.4.2 | MFA implemented for non-console access into the CDE, subject to applicability notes | Identity-provider MFA policy, IAM Identity Center settings and relevant sign-in records | Enforcement design, coverage and tested exception or recovery process | MFA registration is shown, but enforcement across every CDE access path is not demonstrated |
| 8.3.9 | For password-only user access: change passwords at least every 90 days OR dynamically analyse account security posture and automatically determine real-time access | IAM or identity-provider password policy and authentication design | Evidence the condition applies, or evidence MFA makes the password-only provision inapplicable | A password-age setting is cited without documenting the authentication factors in use |
| 8.6.1 | Interactive use of application and system accounts is managed | IAM role trust policies, workload identities and relevant AssumeRole events | Documented exceptional-use controls, approval, duration and attribution | Workload credentials are repurposed for interactive debugging without controlled exception handling |
Requirement 10 — Logging and Monitoring
| Sub-req | Control | Potential AWS evidence source | Entity obligation | Example gap to investigate |
|---|---|---|---|---|
| 10.2.1 | Audit logs enabled and active for all system components and cardholder data | CloudTrail trail and event-selector configuration plus application and database audit configuration | Scoped logging design showing which activity is captured at each layer | An enabled CloudTrail trail is treated as proof that all required application and data access is logged |
| 10.2.1.6 | Log initialisation of new audit logs and the starting, stopping or pausing of existing logs | Relevant CloudTrail events and alarms for logging-configuration changes | Evidence the complete logging stack is monitored, including application and database audit services | Only CloudTrail StopLogging is monitored while other audit mechanisms can be disabled silently |
| 10.3.2 | Audit-log files protected against modification by individuals | S3 bucket policy, versioning, Object Lock configuration where used, and KMS access controls | Documented protection design and tests showing unauthorised modification is prevented; change detection is evaluated separately | Immutability is claimed without validating privileged access and retention configuration |
| 10.4.1 | Specified audit logs reviewed at least daily | SIEM cases, CloudWatch alarms and GuardDuty findings may support the workflow | Defined review scope, accountable role and retained evidence of completed reviews and follow-up | Alerts exist, but completed reviews and investigation outcomes cannot be evidenced |
| 10.5.1 | Audit-log history retained for at least 12 months, with the most recent three months immediately available | S3 lifecycle, storage-class and retention configuration for each in-scope log source | Retrieval test and retention evidence covering all required logs, not CloudTrail alone | CloudTrail meets the retention target while application, database or identity logs expire earlier |
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 responsibilities cannot be satisfied by enabling an AWS service alone. AWS artefacts may support parts of the evidence, but the entity must still define, operate and demonstrate the control:
Application-layer SAD detection
No single AWS configuration result proves that sensitive authentication data is absent. The entity needs a scoped investigation of application behaviour, data stores and logs, with appropriate code review and testing.
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 covers security awareness; training includes personnel on hire and at least annually, with the applicable programme requirements. The entity remains responsible for its training programme and evidence of completion.
TPSP agreements and monitoring
Req 12.8 requires written agreements with TPSPs and annual confirmation of their PCI DSS status. The entity must maintain its TPSP register, agreements, responsibility allocation and monitoring evidence.
Physical media controls
Req 9 covers physical access controls and media handling. Evaluate applicable physical and media controls across the scoped environment. AWS data-centre controls do not cover the entity-owned premises, devices or media.
Incident response testing
Req 12.10.2 requires the incident response plan to be tested annually. The entity must retain exercise records, outcomes and follow-up. A service being enabled does not demonstrate that the plan was tested.
AWS Config Checks That Can Support PCI DSS Evidence
These are examples of AWS Config checks that may support evidence collection. They are not a complete PCI DSS control set or an official one-to-one mapping. Confirm rule parameters, AWS Region availability and the coverage of your enabled Security Hub standard before relying on an evaluation.
| Config rule | PCI DSS requirement | What it checks | Limitation |
|---|---|---|---|
| restricted-ssh | 1.3.1 (supporting evidence) | No security groups with unrestricted SSH (port 22) ingress | Does not check application ports or protocol-specific rules |
| rds-instance-public-access-check | 1.4.4 (partial evidence) | RDS instances not publicly accessible | Does not check network path from public subnet to RDS via EC2 |
| kms-cmk-not-scheduled-for-deletion | 3.6.1 (supporting evidence) | 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 | Checks S3 data-event logging for all buckets by default, or the configured S3BucketNames | Reconcile rule parameters and trail event selectors with every in-scope bucket; this does not prove application logging coverage |
| guardduty-enabled-centralized | 11.5.1 | GuardDuty enabled; optional CentralMonitoringAccount parameter constrains allowed centralisation accounts | Does not verify findings are reviewed or that alerts trigger response procedures |
| mfa-enabled-for-iam-console-access | 8.4.2 (partial evidence) | MFA enabled for IAM console users | Does not establish MFA enforcement for every access path into the CDE |
| s3-bucket-server-side-encryption-enabled | 3.5.1 (partial evidence) | Checks bucket default encryption or an explicit policy denying applicable unencrypted uploads | Does not establish PAN discovery, authorised decryption access or whether the selected protection meets Requirement 3.5.1 |
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.
Primary references and review boundary
Reviewed 2 November 2026. Requirement references use PCI DSS v4.0.1. AWS mappings above are editorial supporting-evidence suggestions, not assertions of equivalence or completeness.
- AWS Config: restricted-ssh
- AWS Config: rds-instance-public-access-check
- AWS Config: kms-cmk-not-scheduled-for-deletion
- AWS Config: cloudtrail-enabled
- AWS Config: cloudtrail-s3-dataevents-enabled
- AWS Config: guardduty-enabled-centralized
- AWS Config: mfa-enabled-for-iam-console-access
- AWS Config: s3-bucket-server-side-encryption-enabled
Payment Architecture & Evidence Workspace
Turn this guidance into a structured decision
Open the relevant workspace tool to apply the article to your payment environment. Eligible membership access may be required; the tool page shows access before you begin.
Security Controls Matrix Generator
Turn AWS configuration evidence into a control-by-control gap register. Membership unlocks the complete assessment workflow, saved evidence and exportable outputs for review.