PCI DSS Data Flow Diagram: Mapping Cardholder Data and Reducing Scope

A PCI DSS assessment usually starts with the same request: show us where card data goes. The diagram on your wiki shows services and arrows, but not which arrows carry a card number, which carry only a token, or why the analytics warehouse is out of scope. Without that, every system becomes a scoping argument.

This post covers what PCI DSS v4.0.1 asks for, scope categories, a worked checkout with hosted payment fields, tokens, segmentation, SAQ types and upkeep. It is not legal or compliance advice: your acquirer or assessor decides what applies, and the official texts are in the PCI SSC Document Library.

What PCI DSS v4.0.1 asks for

PCI DSS v4.0.1, published in June 2024, is the current version at the time of writing (November 2026). Its future-dated requirements became mandatory on March 31, 2025. Three requirements shape your diagrams:

Account data means cardholder data (PAN, cardholder name, expiration date, service code) and sensitive authentication data (full track data, card verification code, PINs and PIN blocks). The PAN is the defining element: store, process or transmit it and you have a cardholder data environment (CDE).

SAQ A contains neither requirement 1 nor 12.5.2, SAQ A-EP includes 1.2.3 and 1.2.4, and SAQ D and full assessments include all three. Under SAQ A, the diagram is still your clearest evidence of eligibility.

Three kinds of systems

Section 4 applies the requirements to the CDE and to anything that "could impact the security of cardholder data and/or sensitive authentication data", wording that v4.0.1 introduced in place of "the security of the CDE". The standard's own example is "a web server that controls the generation of a payment form or page." PCI SSC's scoping guidance sorts systems into three categories, checked from the top:

A system belongs to the highest category it matches. Segmentation is optional, but without it the whole "flat network" is in scope, and encryption alone generally does not take card data out of scope.

The example: a checkout with hosted payment fields

A storefront web app serves the checkout page; its card fields are an iframe from the payment provider, often called hosted fields. An order service charges payments, Postgres stores orders, a nightly job feeds a warehouse, and CI/CD deploys the storefront:

1. The browser loads the checkout page; the provider's script renders the card fields in its own iframe.
2. The customer types the PAN, expiry date and CVC, and the browser sends them over TLS straight to the provider. The same-origin policy keeps the merchant page's scripts out of the iframe.
3. The provider stores the PAN in its vault and returns a token.
4. The page sends the order and the token to the order service.
5. The order service charges the token through the provider's API with a secret key, and the provider requests authorization through the card network.
6. A webhook confirms the result. The order service stores the token ID, card brand and last four digits.

No merchant system stores, processes or transmits the PAN, so the merchant has no CDE; you manage the provider, which has its own assessment, under requirement 12.8. The payment gateway integration diagram shows the same checkout as a sequence, and the e-commerce platform diagram places it among catalog, cart and order services.

The web app stays in scope: an attacker who changes it, or a script it loads, can swap the iframe for a fake form. That attack, e-skimming, is why v4.0 added 6.4.3 (authorize, integrity-check and inventory payment page scripts) and 11.6.1 (detect changes to payment pages). CI/CD is in scope too, since the standard counts deployment tools as system components.

Tokens and what they leave in scope

PCI SSC's tokenization guidelines put the tokenization system, including de-tokenization and PAN storage, in the CDE. Systems that hold only tokens may be out of scope if the PAN cannot be recovered from the tokens, they cannot request de-tokenization or reach the vault, and they are segmented from the CDE.

The provider owns the vault, so the order service and database can qualify, with one catch: a reusable token plus the secret API key can create charges. The guidance says tokens that can initiate a transaction "might be in scope for PCI DSS" and tells merchants to ask their acquirer. Guard the key like any production secret.

Segmentation and how it is tested

Segmentation usually means firewall rules, security groups or separate cloud accounts. If it isolates a CDE, requirement 11.4.5 calls for penetration tests of those controls at least every 12 months and after changes (every six months for service providers), by a qualified, independent tester. On the 1.2.3 network diagram, draw each segment and the controls between them, as in a logical network topology.

With no merchant CDE here, the boundary that matters surrounds whatever can change the checkout page: the order service, warehouse and their credentials must not be able to deploy to the storefront.

Architecture choices and SAQ types

Your checkout design largely decides the self-assessment questionnaire (SAQ); your acquirer confirms it:

The January 2025 SAQ A revision removed 6.4.3 and 11.6.1 from the questionnaire and added an eligibility criterion: the merchant confirms "their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s)." FAQ 1588 allows two ways: protect your page with techniques such as those in 6.4.3 and 11.6.1, or get your provider's confirmation that its solution does, when implemented as instructed. The criterion applies to embedded iframes, not redirects, and both still need quarterly scans by an Approved Scanning Vendor (FAQ 1604). One card field rendered by your own page rules out SAQ A.

Keeping the diagram current

The standard counts "any changes in the flow or storage of account data" as potentially significant. Update the diagram whenever you add a payment method, provider or channel, a checkout script, or an export, log pipeline or support tool that touches payment data.

Watch for card numbers in support tickets and chat: for such an unintended channel, v4.0.1 says to bring it into the CDE or securely delete the data and stop the channel being used for it. Put the date, author and approver on the diagram; the living docs workflow covers owners and update triggers.

The cardholder data flow diagram

How to read it:

• Three zones. Red is the provider's CDE, amber holds merchant systems that can change the checkout page, and teal holds systems that only handle tokens.
• Colors follow the data: red for card data, teal for tokens, gray for neither; dashed means asynchronous.
• Numbers follow one purchase. The red path never enters a merchant frame.
• Two notes mark the remaining risks: page scripts and reusable tokens.
• The legend sums up data classes and scope.

Drawing PCI DSS data flow diagrams clearly

Label every flow and store:

• Draw scope as frames and shade out-of-scope areas, as the 1.2.3 guidance suggests.
• Draw one diagram per channel: e-commerce, phone and terminals differ.
• Include the quiet paths: refunds, chargebacks, backups, logs and support tools.
• Match the network diagram, which the data-flow diagram should augment.
• Leave out calls with no account data or tokens.

A common mistake is a PAN line through token-only systems, which pulls them into scope on paper. See the data flow diagram examples for notation, the threat modeling walkthrough for trust boundaries and the GDPR data map for a similar inventory.

Build it in Archboard

1. Sign in with Google or GitHub and create a diagram.
2. Add a Person from the C4 Model pack for the customer's browser.
3. Add three Frame nodes from the Core pack for the provider (red), merchant in scope (amber) and merchant out of scope (teal).
4. In the provider frame, add two External System nodes from the C4 Model pack for the hosted fields and the payment API, and a Vault from the Security pack. Put an External System for the card networks below the frame.
5. In the amber frame, add a Container from the C4 Model pack for the web app and a Pipeline from the DevOps pack.
6. In the teal frame, add a Container for the order service and Postgres and Data Warehouse nodes from the Data pack.
7. Draw labeled edges: red for card data, teal for tokens, gray otherwise, dashed for the webhook and the export.
8. Add a Markdown legend from the Core pack and two Core Text notes.

For the 1.2.3 network diagram, the Terraform converter gives you a first draft from your .tf files; the payment flow diagram page shows sequence views.

The example uses 14 diagram nodes, within the Free plan.

FAQ

Does PCI DSS require a data flow diagram? Yes. Requirement 1.2.4 in v4.0.1 asks for an accurate data-flow diagram of all account data flows, kept current. SAQ A leaves it out; SAQ A-EP, SAQ D and full assessments include it.

What is the difference between the PCI network diagram and the data flow diagram? The network diagram (1.2.3) shows connections between the CDE and other networks. The data-flow diagram (1.2.4) shows where account data travels and is stored. They should agree.

Does an iframe or hosted payment page take my website out of PCI scope? No. It keeps card data off your systems, but the page that embeds the iframe can still be attacked, so SAQ A asks for quarterly ASV scans and, for iframes, protection against script attacks.

Are systems that store only tokens out of PCI DSS scope? They can be, if the PAN cannot be recovered from the tokens and the systems are segmented from the tokenization system. Tokens that can start a transaction may still be in scope.

How often must PCI scope and diagrams be reviewed? Update the data-flow diagram whenever account data flows change, and confirm scope at least every 12 months and after significant changes (12.5.2), or every six months for service providers.

Start free — one seat, no credit card.