How to Create a PCI DSS Payment Data Flow Diagram

You do not need to be a security architect or draw a highly technical diagram.

The goal is to clearly show how cardholder data moves through (or around) your systems so PCI DSS scope can be defined accurately.

Why PCI DSS requires a payment data flow diagram

PCI DSS scope is determined by where cardholder data flows.

A payment data flow diagram helps to:

Identify systems in scope (the Cardholder Data Environment, or CDE)
Identify systems connected to the CDE
Support correct SAQ selection
Explain scope decisions to banks, processors, or assessors
Reduce unnecessary PCI DSS effort

Under PCI DSS v4.x, organisations are expected to understand and document their payment architecture — this diagram is a key part of that.

What a payment data flow diagram should (and shouldn’t) be

It should

Show how card data enters, moves through, and exits your environment
Focus on flows, not deep technical detail
Be understandable by a non-technical reviewer
Reflect how payments work today

It should not

Be a full network diagram
Include IP addresses or firewall rules
Try to cover your entire IT estate
Be overly complex

If someone unfamiliar with your systems can understand it, you’ve done it right.

Step-by-step: How to create your diagram

Step 1: Start with the customer

Begin with where the card data originates.

Examples:

Customer web browser
Customer mobile app
Customer on the phone (manual entry)
Customer at a physical terminal

This is always the starting point.

Step 2: Show how card details are entered

Next, show how card details are captured, for example:

Redirect to a hosted payment page
Embedded payment form or iFrame
Card details entered directly into your website or app
Card details entered into a virtual terminal

This step often determines PCI DSS scope and SAQ selection.

Step 3: Identify your payment provider

Add your payment service provider (PSP), such as:

Stripe
PayPal
Adyen
Worldpay

Show clearly:

Where card data is sent
Whether it goes directly to the PSP or passes through your systems

Step 4: Add your systems (only if relevant)

Include your systems only if they can affect payment security, such as:

Website or web application
Mobile app
Backend services or APIs
Admin or support portals
Logging or monitoring systems

If card data never touches a system, it may still need to appear if it can impact the payment flow.

Step 5: Indicate where card data is (and is not) stored

Clearly show:

Where card data is not stored (most modern setups)
If tokenisation or references are used instead of raw card data
Any temporary handling or redirection

Explicitly stating “No card data stored” is helpful.

Step 6: Show access paths (at a high level)

Indicate:

Admin or staff access to payment-related systems
Third-party access (e.g. MSPs)

This helps identify connected-to-CDE systems.

Step 7: Keep it high-level and label clearly

Use:

Simple boxes
Clear arrows
Short labels

Avoid:

Technical acronyms without explanation
Overcrowding

Common mistakes to avoid

❌ Forgetting embedded scripts or iFrames
❌ Excluding admin or support access paths
❌ Including systems unrelated to payments
❌ Treating the diagram as “one-and-done”

The diagram should be reviewed whenever payment flows change.

When this diagram should be created and reviewed

Created: During PCI DSS scoping (Step 1)
Reviewed: During readiness assessment (Step 3)
Referenced: During SAQ completion and validation

What happens after you create the diagram

We’ll use your diagram to:

Confirm PCI DSS scope
Validate your SAQ selection
Identify in-scope and connected systems
Support evidence and audit discussions

This diagram becomes part of your PCI DSS evidence set.

Key takeaway

A good PCI DSS payment data flow diagram is:

Simple
Accurate
Easy to explain

It doesn’t need to be perfect — it needs to be useful.