# PCI DSS Data-Flow Diagrams: What QSAs Need to Validate Scope Payment teams often treat a data-flow diagram as an illustration to complete shortly before a PCI DSS assessment. A Qualified Security Assessor (QSA), however, uses it as evidence of how well the organisation understands the movement of payment account data and the boundaries of its cardholder data environment (CDE). That difference matters. A polished diagram can still require revision if it omits a flow, uses ambiguous labels or no longer reflects the deployed environment. Conversely, PCI DSS does not prescribe a particular visual style, a fixed set of payment journeys or a special diagramming tool. The objective is an accurate, current representation of all account-data flows across systems and networks. This guide explains what PCI DSS v4.0.1 actually requires, what information makes a diagram useful during assessment, and how fintech teams can reduce avoidable review cycles without making claims that a diagram alone proves compliance. What PCI DSS v4.0.1 actually requires The relevant requirement is PCI DSS v4.0.1 Requirement 1.2.4. It requires an accurate data-flow diagram, or diagrams, that: shows all account-data flows across systems and networks; and is updated as needed when the environment changes. The PCI Security Standards Council (PCI SSC) defines a data-flow diagram as a diagram showing how and where data flows through an entity's applications, systems and networks, and to and from external parties. This is different from Requirement 1.2.3, which concerns an accurate network diagram showing all connections between the CDE and other networks, including wireless networks. A network diagram describes connectivity and boundaries. A data-flow diagram describes the movement of account data. One well-designed artefact may contain both views, but combining them must not obscure either requirement. PCI DSS uses account data as an umbrella term covering cardholder data (CHD) and sensitive authentication data (SAD). Teams should therefore avoid reducing the exercise to a diagram showing only where a primary account number (PAN) is stored. The review needs to consider where applicable account data enters, moves, is processed, is returned and leaves the environment. PCI DSS does not mandate a universal diagram template. It also does not state that every organisation must document exactly three flows, such as checkout, refund and webhook. The requirement is to show all flows that exist in the assessed environment. What a useful PCI DSS data-flow diagram should show Requirement 1.2.4 is deliberately outcome-focused. The following details are practical ways to make the required flows understandable and reviewable. They are not presented as a separate PCI SSC checklist of mandatory drawing elements. 1. Data entry points and sources Show where account data first enters the relevant environment. Depending on the payment model, this might include a hosted payment page, embedded payment component, payment terminal, call-centre process, API or file transfer. Label the data accurately. A PAN, a token and an internal transaction reference are not interchangeable. If a label simply says “payment data,” the reviewer cannot reliably determine what is present or how it affects scope. 2. Systems and services that receive or handle the data Identify the applications, services, databases, queues, logging systems and administrative components involved in the flow. Include relevant cloud services and externally operated platforms where they form part of the journey. The diagram should reflect the deployed architecture rather than an intended future state. If a component appears in production but not in the diagram, the assessor will need to determine whether the omission affects scope or testing. 3. Direction and purpose of each flow Arrows should show the direction in which data moves. A short label can identify the purpose of the exchange, such as authorisation request, payment response, refund instruction or settlement file. Bi-directional arrows can hide important differences between the data sent in each direction. Separate arrows are often clearer when the request and response contain different data types. 4. Storage, processing and transmission Make it clear where account data is stored, processed or transmitted. This includes temporary storage and less obvious destinations such as application logs, observability platforms, backups, support tools and dead-letter queues where applicable. Do not mark a system as “no card data” solely because it was not designed to retain PAN. Check its actual configuration and representative records. A diagram is only as reliable as the evidence behind it. 5. External parties Show relevant flows to and from payment service providers, acquirers, processors and other third-party service providers. The PCI SSC definition expressly includes flows to and from external parties. Outsourcing payment processing does not, by itself, remove all PCI DSS responsibilities. The organisation still needs to understand its payment channels, the services provided by third parties and which responsibilities remain with each party. 6. Scope boundaries and segmentation assumptions Where the organisation relies on segmentation to reduce PCI DSS scope, show the relevant CDE boundary and the systems or networks that connect to it. The supporting network diagram and technical evidence must substantiate the boundary. A line labelled “out of scope” is not proof. The scoping decision depends on the system's function, connectivity, access and ability to affect the security of account data. 7. Document control Give the diagram an owner, version and review date. Record the architecture or environment to which it applies. These details do not replace the requirement to keep the content accurate, but they make it easier to demonstrate that the artefact is governed and has been reviewed after relevant changes. Why a QSA may request revisions A revision request does not necessarily mean the underlying payment architecture is non-compliant. It may mean the diagram is not yet sufficient to test the relevant requirements or confirm the assessment scope. Common causes include: A real flow is missing Teams often document the main authorisation journey but omit refunds, chargebacks, recurring-payment processes, manual support procedures, batch transfers or webhooks that are genuinely present. Not every organisation has all these flows. The point is to document the ones it does have. The diagram does not match production Architecture evolves. A new queue, log destination, support platform, cloud account or third-party integration can make an older diagram inaccurate. Requirement 1.2.4 therefore calls for updates as needed when the environment changes. Data labels are too vague Terms such as “customer data,” “payment details” or “tokenised data” may be insufficient. The reviewer needs enough clarity to distinguish account data from tokens and unrelated identifiers and to understand whether the original PAN can be recovered or accessed. Third-party hand-offs are unclear A box labelled only with a provider's name may not show what service is used, which data crosses the boundary or what returns. The diagram should make the actual exchange understandable without implying that the provider's compliance status automatically covers the merchant's responsibilities. Scope decisions are asserted rather than supported Hosted payment components and tokenisation can reduce exposure and may affect scope, but the outcome depends on the implementation and the applicable validation method. A browser, server or integration does not become out of scope merely because PAN is intended to be handled elsewhere. The artefact is stale or unowned An undated diagram with no identifiable owner makes it difficult to establish whether it reflects current operations. Document control is a simple way to make ownership and review visible. Tokenisation does not make every connected system out of scope Tokens can help reduce the presence of PAN in an environment, but “token” is not a complete scoping conclusion. The team should establish: what the token represents; where tokenisation occurs; whether the token can be reversed and by whom; whether the system also receives PAN, even temporarily; whether the system can connect to or affect the security of the CDE; and which provider and customer responsibilities apply. The diagram should label tokens and PAN separately and show the point at which the data changes form. The final scope determination should be validated against the actual architecture, applicable PCI SSC guidance and the organisation's assessor or compliance-accepting entity. How to show encryption without inventing a PCI DSS rule Recording the actual transport protocol or encryption state can make a diagram more useful, particularly where it helps distinguish clear-text, encrypted and tokenised data. However, PCI DSS does not prescribe TLS 1.3 as the only acceptable version. PCI SSC states that PCI DSS does not define a specific TLS version. It also states that SSL and vulnerable early TLS—including, at a minimum, TLS 1.0 and TLS 1.1—are not considered strong cryptography. The relevant question is whether the implementation uses strong cryptography with secure configurations and without known exploitable vulnerabilities. For that reason, write what is actually implemented and verify it against configuration evidence. Do not upgrade a diagram label to “TLS 1.3” simply because it appears more secure. What changes when AI agents touch the payment workflow? There is no separate PCI DSS rule that automatically makes an AI agent part of the CDE. Apply the same scoping questions used for any other component: Does it store, process or transmit account data? Can it connect to the CDE? Can it affect the security of account data or the CDE? What tools, logs, prompts, memory stores and external services does it use? Could account data be copied into an unauthorised model, log or support workflow? If the agent only receives a non-sensitive internal reference and cannot affect CDE security, that is different from an agent with access to payment logs, production credentials or administrative tools. The diagram and supporting inventory should reflect the real implementation rather than the “AI” label. How to calculate rework cost honestly PCI SSC does not set QSA day rates, and assessment contracts vary. It is therefore unsafe to claim that every diagram revision costs a fixed amount or delays an assessment by a fixed number of weeks. Use the organisation's own evidence instead: External review cost Contracted assessor rate × additional billable review time Internal rework cost Engineering, compliance and product hours × the organisation's loaded hourly cost Delay impact Only the commercial milestone demonstrably affected by the delay—for example, a scheduled customer launch—using an agreed internal estimate Not every revision creates an extra fee, and not every documentation issue delays onboarding or funding. If no internal data exists, describe the impact qualitatively: additional review time, diverted engineering effort and reduced confidence in the scope definition. A pre-assessment review checklist Before sharing the diagram, ask the following: Does it show every account-data flow that exists in the assessed environment? Does it distinguish PAN, SAD, tokens and non-account-data references accurately? Are data sources, destinations, directions and relevant external parties clear? Does it identify where data is stored, processed or transmitted? Does it agree with the network diagram, inventories and deployed cloud configuration? Are segmentation and “out-of-scope” conclusions supported by technical evidence? Have logs, queues, backups, support processes and administrative access been considered? Is the diagram owned, versioned and current? Has it been reviewed after relevant architecture or payment-flow changes? Can engineering, security and compliance explain the same data journey consistently? This review cannot guarantee that a QSA will accept the diagram without questions. It can make the evidence clearer and reduce avoidable ambiguity. What an automated diagram tool can—and cannot—do Automation can help convert structured architecture inputs into a consistent first draft. It can prompt teams to consider systems, flows, external parties and data states that might otherwise be missed. It cannot inspect an organisation's complete environment merely from a short questionnaire, determine PCI DSS compliance or guarantee acceptance by a QSA, acquirer or payment brand. Any generated diagram should be reviewed by the people responsible for the architecture and compliance programme, checked against production evidence, and validated through the organisation's assessment process. Used in that way, automation supports documentation. It does not replace scoping, evidence or professional judgement. The practical outcome A good PCI DSS data-flow diagram is not the most visually impressive one. It is the one that accurately describes the current environment, makes every real account-data flow understandable and agrees with the evidence used to validate scope. For fintech teams, the best time to create it is not the week before an assessment. Maintain it alongside architecture and change-control records. That turns the diagram from a last-minute audit deliverable into a working model of how payment account data moves through the business. Authoritative references PCI SSC Document Library — PCI DSS v4.0.1 PCI SSC Glossary — Data-Flow Diagram and account-data terminology PCI SSC payment-data security standards PCI SSC merchant resources — PCI DSS applicability PCI SSC FAQ 1491 — Does PCI DSS define which versions of TLS must be used? This article provides general educational information. PCI DSS scope and validation depend on the organisation's actual environment, applicable payment-brand or acquirer programme, and assessment method. Confirm decisions with the appropriate assessor or compliance-accepting entity.