AWS Well-Architected Security PillarPCI DSS 4.0

AWS Well-Architected Security Pillar covers 25.3% of PCI DSS 4.0

63 of the 249 controls in PCI DSS 4.0 are already satisfied by evidence you collected for AWS Well-Architected Security Pillar. 186 are genuine gaps. Every claim below was judged against both control sets and then argued against; the ones that did not survive are published further down with the reason each failed.

25.3%
of the target already covered
63
controls evidenced
186
genuine gaps
0
claims rejected in review

This number is directional. It says how much of PCI DSS 4.0 your AWS Well-Architected Security Pillar evidence satisfies. The reverse pair is a different number, often very different, because a security standard has enormous depth for access control and almost none for lawful basis or data subject rights.

129 candidate mappings were examined and 0 were removed. Signed off 2026-08-19, review level machine verified. Mappings were judged by Claude Code rather than read line by line by a practitioner. Every claim shows its reasoning so you can check it. Ask and a practitioner will review this pair.

Where the gaps are

Coverage is never evenly spread. A source standard usually satisfies one part of a target almost completely and barely touches another, and which part is which is the thing worth knowing before you plan the work.

Req 7: Restrict Access by Need to Know7 of 12 evidenced, 5 to do
Req 6: Secure Systems and Software11 of 19 evidenced, 8 to do
Req 2: Secure Configurations5 of 11 evidenced, 6 to do
Req 8: Identify and Authenticate Users12 of 29 evidenced, 17 to do
Req 10: Logging and Monitoring9 of 27 evidenced, 18 to do
Req 4: Protect Cardholder Data in Transit2 of 6 evidenced, 4 to do
Req 1: Network Security Controls6 of 19 evidenced, 13 to do
Req 11: Test Security Regularly5 of 21 evidenced, 16 to do
Req 3: Protect Stored Account Data3 of 29 evidenced, 26 to do
Req 12: Information Security Policies3 of 37 evidenced, 34 to do
Req 5: Anti-Malware0 of 13 evidenced, 13 to do
Req 9: Restrict Physical Access0 of 26 evidenced, 26 to do

Theme level, not control level, deliberately. The per-control list of what is evidenced and what is a gap is the report itself, so publishing it here would be publishing the thing being sold.

Claims that held

A sample. Each one names the control whose evidence does the work, the control it satisfies, and why.

SEC 5: How do you protect your network resources? | SEC05-BP041.2.8argued against and upheld
Configuration files secured and synchronised

Network config held as version controlled code with drift detection evidences secured, synchronised configurations.

SEC 5: How do you protect your network resources? | SEC05-BP021.3.1argued against and upheld
Inbound traffic to CDE restricted

Restricting inbound flows to only those each component needs is the same tested control.

SEC 5: How do you protect your network resources? | SEC05-BP021.3.2argued against and upheld
Outbound traffic from CDE restricted

Same control restricts egress from workload components to only necessary flows.

SEC 5: How do you protect your network resources? | SEC05-BP011.4.1argued against and upheld
NSCs between trusted and untrusted networks

Public, private and restricted subnet layering is the network security control between trusted and untrusted zones.

SEC 5: How do you protect your network resources? | SEC05-BP011.4.2argued against and upheld
Inbound traffic from untrusted networks restricted

Layering places only internet facing components in public subnets, restricting inbound untrusted traffic.

SEC 5: How do you protect your network resources? | SEC05-BP011.4.4argued against and upheld
Account data not stored on internet-accessible systems

Isolating data tiers from internet facing components is exactly this requirement.

SEC 3: How do you manage permissions for people and machines? | SEC03-BP071.4.4argued against and upheld
Account data not stored on internet-accessible systems

Access Analyzer public access findings evidence that data stores are not reachable from untrusted networks.

SEC 4: How do you detect and investigate security events? | SEC04-BP0110.2.1argued against and upheld
Audit logs enabled on system components

CloudTrail across all accounts and regions plus service logs is audit logging enabled everywhere.

Claims that did not hold

Nothing proposed for this pair was rejected in review. That is unusual and worth knowing rather than hiding: it means the candidate set was small and every candidate held.

The full report

Everything above is a sample. The report is every evidenced control and every gap, with the reasoning and the source document behind each one, in a form you can hand to an assessor. $299, emailed immediately.

Buy this crosswalk