What Requirement 1.2.4 Actually Demands
PCI DSS Requirement 1.2.4 states that an entity must maintain an accurate and current diagram of all connections between the cardholder data environment (CDE) and other networks, including wireless networks. What it does not say is that a single network topology diagram satisfies this — and this is where most submissions fall apart.
The standard requires two distinct outputs that are often conflated:
- Network diagram (Req 1.2.4): shows all connections into and out of the CDE, including segmentation controls, firewall positions, and network zones. This is the topology view — VPCs, subnets, security groups, transit gateways, Direct Connect circuits.
- Data flow diagram (Req 12.3.3 + 12.4.1): shows how cardholder data (PAN, SAD, CVV) moves between entities — not how systems connect. This is the data movement view: who sends what to whom, in what format, encrypted or not, retained or discarded.
4.0.1 change: Requirement 12.3.3 in PCI DSS 4.0.1 adds a formal requirement to document all cryptographic cipher suites and protocols in use across the CDE. Your data flow diagram must now show encryption method at each flow boundary, not just "encrypted in transit."
For AWS environments, the network diagram and data flow diagram often end up as the same drawing — which creates a document that is too dense to review and too imprecise to scope from. The practical guidance for QSAs working with AWS-hosted payment environments is to require them as two separate artefacts.
Required Elements in a Compliant CDF Diagram
The following elements are required for a cardholder data flow diagram to pass QSA review. Missing any one of these is grounds for return.
AWS-Specific Scoping: Where QSAs Get Caught
The AWS shared responsibility model creates scoping ambiguity that does not exist in on-premises environments. The following AWS services commonly pull additional components into scope that clients do not initially flag:
CloudWatch Logs and CloudTrail
If an application logs payment-related activity — even partially masked PANs, transaction IDs that map back to a cardholder, or authentication tokens used in payment flows — the CloudWatch Log Group receiving those logs is in scope. CloudTrail, if configured to log data events on S3 buckets storing CHD, is also in scope. Both services must appear on the diagram.
Lambda /tmp and execution environment
Lambda functions handling payment authorisation or tokenisation process CHD in memory and may cache it in the /tmp directory (512 MB - 10 GB depending on configuration). The execution environment persists between invocations within the same container lifecycle. This constitutes in-scope temporary storage. The Lambda function, its VPC configuration, and the layers it uses must be on the diagram.
SQS, SNS, and EventBridge
Queuing services that carry payment events — including failed payment notifications, retry messages, and webhook payloads from payment processors — are in scope if the message body contains CHD. This is frequently overlooked in event-driven architectures. Encryption at rest (SSE-KMS) and access policy must be documented on the diagram.
API Gateway and VPC Endpoints
API Gateway receives inbound payment requests and sits at the CDE boundary. WAF associations, resource policies, and TLS termination must be documented. VPC Endpoints used to route payment data between services without traversing the public internet must be included and their endpoint policies stated.
Common miss: Clients frequently omit the path from API Gateway to the Lambda authoriser, and the path from Lambda to Secrets Manager (where payment processor API keys are retrieved). Both are in-scope flows and both must appear on the diagram.
PCI DSS 4.0.1 Changes That Affect the Diagram
PCI DSS 4.0.1, effective 31 March 2025, introduced changes that have a direct impact on what a compliant cardholder data flow diagram must contain:
| Requirement | Change from 3.2.1 | Impact on CDF diagram |
|---|---|---|
| 6.4.3 | All payment page scripts must be authorised and have integrity checked | Client-side script inventory must appear in the data flow — including CSP headers, SRI hashes, and the script origin |
| 11.6.1 | Change- and tamper-detection for payment pages | The monitoring mechanism (script monitoring service, CSP violation reporting endpoint) must be shown as a flow from the payment page |
| 12.3.2 | Targeted risk analysis for requirements not using the defined approach | Any customised implementation must include the data flow as part of its risk analysis documentation |
| 12.3.3 | Cryptographic cipher suite inventory | Specific cipher suites (not just "TLS 1.2+") must be named at each boundary on the diagram |
| 3.6.1 | Key management procedures formalised | KMS CMK ARNs, HSM locations, and key rotation schedules must be documented and referenced from the storage nodes on the diagram |
The Five Most Common QSA Rejection Reasons
These are the five reasons a cardholder data flow diagram is most commonly returned on first pass. Reviewing these before submission eliminates most first-pass failures:
Scoping the CDE Boundary on AWS
The CDE boundary in an AWS environment is defined by the outermost control that prevents unauthorised network access to systems that store, process, or transmit CHD. In practice this maps to the following layers:
QSA Pre-Submission Review Checklist
Use this checklist before accepting a CDF diagram from a client. Each item that cannot be confirmed is a finding that needs resolution before the diagram can be marked as satisfying Req 1.2.4 and Req 12.3.3.
- All PAN flows are traced end-to-end from card entry to authorisation response
- All SAD flows (CVV, expiry date) are shown and deletion points are marked
- Every storage location (database, cache, queue, log) is identified and labelled as in-scope or out-of-scope with rationale
- Encryption protocol and cipher suite is specified at every flow boundary
- All third-party service providers are named with their PCI DSS certification status noted
- CDE boundary is drawn and every crossing is labelled with the controlling mechanism
- All human roles and service accounts that access CHD are identified
- Diagram version number and review date are present
- AWS-specific services (CloudWatch, SQS, Lambda) that receive CHD are included
- For 4.0.1: client-side payment scripts are inventoried and script origin flows are shown
- For 4.0.1: cipher suite inventory (Req 12.3.3) is captured on the diagram or in a companion document
- Diagram has been reviewed and signed off following the most recent infrastructure change
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.