Show where account data moves—and which systems can affect it.

Start with the correct requirement

PCI DSS 1.2.3 covers an accurate network diagram showing connections between the cardholder data environment (CDE) and other networks, including wireless networks. Requirement 1.2.4 covers an accurate account-data flow diagram across systems and networks. Both must be updated as the environment changes.

Requirement 12.3.3 addresses cryptographic protocols and cipher suites and their review; it is not the data-flow diagram requirement. A companion inventory can support the diagram without turning every review record into a label on the drawing.

Prepare two views of one payment journey

Network view

Begin with an inventory of the relevant AWS accounts, VPCs, subnets, network controls and external connections. Reconcile the drawing against route tables, peering, VPNs, Transit Gateway and load-balancer configuration where used. Record management paths and third-party connections as well as customer-facing entry points.

Account-data view

Trace each relevant data movement from entry through processing, storage and onward transmission. Label the data category and the systems involved. Distinguish a full account-data payload from a transaction reference, token or operational event; do not assume those have identical scope implications.

Use synthetic examples and placeholders. Never include real PANs, security codes, credentials or private keys in a public diagram.

Use AWS configuration as supporting evidence

For each arrow, ask the implementation owner to identify its source, destination, purpose, transport and access controls. For each store, ask what is retained, how it is protected, how long it remains and who can retrieve it. These are review questions, not assertions that a named AWS service automatically meets the corresponding control.

Inspect application and database configuration alongside infrastructure records. In your review plan, explicitly consider queues, caches, temporary files, backups and observability systems. Establish what they actually receive before assigning scope; a service name or the presence of a payment-related identifier alone is insufficient to make a definitive scoping determination.

Keep storage and scope assumptions visible

Requirement 3.3.1 generally prohibits retaining sensitive authentication data after authorisation, even when encrypted; apply the standard's specific issuing-service applicability notes where relevant. Encryption is not a substitute for that prohibition. Avoid designing raw card data into ordinary audit logs.

Record connected and security-impacting systems as well as systems handling account data. Do not equate a VPC boundary, encryption setting or tokenisation label with an automatically out-of-scope environment. Confirm scope against the standard, actual implementation and applicable validation process.

Make the next review straightforward

Our suggested handover includes a diagram owner, version, last review date, source configuration references, unresolved scope questions and a change-review trigger. Reconcile it with the implemented environment after changes. Keep design assumptions separate from controls that have been implemented and tested.

Primary reference

PCI SSC: PCI DSS v4.0.1, Requirements and Testing Procedures — Requirements 1.2.3, 1.2.4, 3.3.1, 12.3.3 and scope guidance. The standard and its applicability notes take precedence over this summary.

Need a second opinion on a payment architecture decision? Explore the £950 Payments Architecture Health Check.