What a PCI DSS network diagram must show before an assessor will accept it
If a payment contract, acquirer or QSA is asking for your diagrams, the short answer is this: Requirements 1.2.3 and 1.2.4 require an accurate network diagram showing all connections to the cardholder data environment (CDE) and an accurate data-flow diagram of all account data flows. Both must match the environment as it actually runs today, not as it was designed. What makes your version of that answer different is the shape of your environment: how many connections reach the CDE, how many cloud accounts and subscriptions carry payment traffic, which third parties send or receive card data, and how often any of that changes. A single data center with one firewall pair needs a short diagram. A payment flow spread across several cloud accounts, a managed service and a payment page provider needs a diagram that traces every hop, including the trust boundaries between them.
Your organization owns both the diagrams and the scope they define. An implementation partner can help you draw them, reconcile them against firewall rulesets, cloud network configuration and the system inventory, and document the gaps. That work is useful, but it does not make the diagrams evidence. Only the independent QSA or assessor, through the Report on Compliance or the relevant self-assessment, accepts them. Before you hand anything over, confirm with your assessor which format and level of detail they expect, which accounts and tools count as the source of truth, and who signs off on each version. Ask them early whether an infrastructure-as-code template or a live network export will be treated as the diagram or as supporting evidence.
Treat the diagram as a test you can fail. Pick a payment transaction and trace it from the point of capture to storage, transmission and any third party, then check that every hop appears on the data-flow diagram and every connection into the CDE appears on the network diagram. Any connection that exists in a firewall rule, a cloud security group or a vendor integration but not on the drawing is an accuracy defect. Keep the diagram tied to the scope review you carry out at least every 12 months and after significant change, so that it is updated when the environment changes rather than only when the assessment is due.
Network diagram versus data-flow diagram: what each one answers
This table compares the network diagram and the data-flow diagram that Requirements 1.2.3 and 1.2.4 call for, showing the question each one answers and the elements it must contain. Read it as two views of the same environment: one shows where systems connect, the other shows how account data moves and where it rests.
| Aspect | Network diagram | Data-flow diagram |
|---|---|---|
| Question it answers | Which components connect to the CDE, and through which controls? | How does account data enter, move through, and leave the environment? |
| Connections to the CDE | Every connection into and out of the CDE, including networks, hosts and cloud links | Only the paths that carry account data, with the points where data crosses each boundary |
| Segmentation controls | Firewalls, NSCs and segment boundaries that separate the CDE from other networks | Where data is protected in transit or at rest and where segmentation limits its spread |
| Third-party connections | Links to service providers, payment processors and vendor access paths | Every hand-off of account data to or from a third party, with the direction of flow |
| Account data storage locations | Shown only where a storage system sits on the network | Every location where account data is stored, processed or transmitted, including backups and logs |
| Typical source | Network engineering, cloud architecture and firewall rulesets, often exported from infrastructure as code | Payment application design, integration specifications and interviews with the teams that handle transactions |
| Notation and tool | Chosen by the organization; the standard sets content, not format | Chosen by the organization; the standard sets content, not format |
| Who confirms accuracy | Network and security engineers verify against live configuration | Application owners and payment operations verify against actual transaction paths |
Which elements an assessor expects to find on the diagrams
An assessor compares the diagrams against what actually runs, so each element below must appear on both the network diagram and the data-flow diagram where it applies. Omissions tend to surface when the assessor traces a single card transaction end to end and finds a hop, system or connection the diagrams never showed.
Connections into and out of the CDE
Every path that enters or leaves the cardholder data environment should appear on the network diagram, including internet links, corporate network links, remote administration paths, and inbound or outbound API calls. Assessors commonly question connections that exist in firewall rules or cloud security groups but were left off the drawing. Check the diagram against the NSC ruleset and cloud network configuration, and confirm that each allowed flow maps to a drawn connection with a stated purpose.
Segmentation points separating the CDE
The diagram should show where the CDE is separated from other networks, such as firewalls, VLANs, VPC or VNet boundaries, and subnet controls, and name the device or service that enforces each boundary. Assessors question segmentation drawn as a single line without the controls that make it work. Evidence includes the segmentation control list, the ruleset for each boundary, and results from segmentation testing where the entity relies on it to reduce scope.
Third-party and service provider connections
Connections to payment processors, hosting providers, managed security services, support vendors and remote access partners belong on the diagram, labeled with the provider and the data or access involved. Assessors often find vendor links that appear in change tickets or contracts but not on the drawing. Confirm each third-party connection against the provider inventory and the responsibility matrix, and record who holds the access path and how it is authenticated.
Where account data is received and processed
The data-flow diagram must show each point where account data enters the environment, such as checkout pages, payment terminals, call center systems or file imports, and where it is processed or transformed. Assessors question missing entry points because a single unlisted intake can bring unexpected systems into scope. Check the flow against application code, API specifications and interface logs, and confirm each intake point has a named owner.
Where account data is stored and transmitted
Storage locations, including databases, backups, logs, file shares, caches and message queues, and every transmission path between them should be drawn with the data element and protection applied at each hop. Assessors commonly find backups, log files and replicas that the diagram omits. Compare the diagram against data discovery results and storage inventories, and verify that the protection shown matches the configuration of each store.
The CDE trust boundary
The trust boundary marks where the CDE begins and ends, and it should be drawn consistently on both diagrams and tied to the scope statement. Assessors question boundaries that shift between documents or leave out systems that authenticate into the CDE, such as identity providers, jump hosts and management tooling. Confirm that the boundary matches the scope confirmation performed at least every 12 months and after any significant change, and that the diagrams are updated when it moves.
Why annual scope confirmation under Requirement 12.5.2 depends on current diagrams
Requirement 12.5.2 requires the entity itself to confirm its PCI DSS scope at least every 12 months and whenever a significant change occurs. The confirmation has to identify the data flows, the locations of account data, the connected components, the segmentation controls and the third-party connections that sit around the cardholder data environment. Service providers carry a tighter cycle: under 12.5.2.1 they must perform the same confirmation every six months. The network diagram and the data-flow diagram from Requirement 1.2 are the primary record that this confirmation is checked against, so an out-of-date diagram means the confirmation starts from a false picture of the environment.
Diagrams do not prove scope on their own. An assessor will compare the drawings with the system inventory required by Requirement 12.5.1, the live firewall and segmentation rulesets, and the discovery results gathered during the confirmation. A diagram that omits a connection, a storage location or a third-party link will fail that comparison even if it looks complete. Before the annual cycle opens, ask who owns each diagram, when it was last reconciled against the running environment, and whether the people who approved recent changes were required to update it. Where infrastructure as code defines the network, the code and the drawing should be reviewed together so that the record and the configuration agree.
Plan for the confirmation to be triggered outside the calendar as well. PCI SSC FAQ 1317 lists significant changes that call for a scope review, including new CDE hardware or software, changes to data flows or storage, and changes to the CDE boundary or supporting infrastructure. Each of these changes should send a task to the diagram owner before the change is closed, not at the next annual review. Confirm with your assessor which of your planned changes they would treat as significant, because the answer depends on your environment and the way your segmentation is built.
Who maintains the diagrams: your team, an implementation partner, or the assessor
Your organization owns the network diagram and the data-flow diagram. The entity under assessment is responsible for its own scope, so the diagrams must reflect your real environment, approved by someone accountable for the cardholder data environment. Your compliance lead usually coordinates the work, while platform and network owners supply the technical detail that makes the diagrams accurate.
- Ownership: Name one accountable owner for each diagram and a backup who can answer assessor questions.
- Approval: Record who reviewed and approved each version and the date, so the approval can be shown later.
- Currency: Update the diagrams after significant changes, such as new CDE hardware or software, changed data flows or a moved CDE boundary.
- Connections: Platform owners confirm every connection into, out of and within the CDE, including third-party and administrative paths.
- Annual confirmation: The annual scope confirmation under Requirement 12.5.2 depends on these diagrams, so schedule the review before it is due.
Confirm with your QSA which format and level of detail they expect before you invest in tooling.
An implementation partner such as DeployOpen can help prepare the diagrams and the evidence behind them. Work is typically fixed in scope and agreed in writing before it starts. The partner works inside your environment and reconciles what the diagrams say with what the systems actually do, but the partner does not own the scope decision and does not issue any report.
- Draft preparation: Build draft network and data-flow diagrams from configuration, architecture records and interviews with system owners.
- Reconciliation: Compare diagrams against firewall rulesets, cloud network settings and infrastructure as code to find undocumented paths.
- Process documentation: Write the procedure for updating diagrams on change, including who triggers the update and how it is approved.
- Evidence packaging: Organize configuration exports and change records that show the diagrams match the environment.
- Independence: Your team signs off on the content, and the assessor's findings come from the assessor alone.
Ask any partner to state in the written scope which deliverables it produces and which decisions remain with you.
The Qualified Security Assessor or other assessor tests the diagrams as part of the assessment and issues the Report on Compliance or other validation documentation. The assessor checks that the diagrams are accurate, complete and consistent with the scope, the configuration and the inventory, and that they are kept current. The assessor does not draw the diagrams for the client, because doing so would compromise the independence of the assessment.
- Accuracy testing: The assessor compares the diagrams against live configuration, sample system components and observed traffic.
- Completeness testing: The assessor looks for connections to the CDE, third parties and administrative paths that the diagrams omit.
- Currency testing: The assessor asks for change records to confirm the diagrams were updated after significant changes.
- Reporting: The assessor records findings in the ROC or the relevant documentation and issues the attestation.
- Independence boundary: A consultant who prepared the diagrams can help you answer questions, but the assessor forms its own conclusion.
Settle with your assessor early which diagrams and evidence they will request, so the work is not repeated late in the cycle.
Treating infrastructure as code as configuration under Requirement 1.2.8
Under Requirement 1.2.8, the SAQ D notes treat infrastructure as code, scripts, automated controls and backed-up or remotely stored settings used to configure or synchronize network security controls (NSCs) as configuration files. That classification matters for your diagrams. The repository holding Terraform modules, Ansible playbooks, firewall policy templates or cloud security group definitions becomes part of the evidence that your network and data-flow diagrams describe reality, so it must be protected like any other configuration file and kept consistent with the active configuration.
For the diagrams, this means the network diagram required by Requirement 1.2.3 and the data-flow diagram required by Requirement 1.2.4 are easier to demonstrate as accurate when they are generated from, or reconciled against, the same repository that deploys the NSCs. A reviewer can then trace a connection on the diagram to a rule in code, to a change record and to the running firewall or cloud security group. Drift between the code and the live rulesets, such as a console change that never reached the repository or a backup restored with older rules, is the finding to hunt for before an assessor does. Confirm which tool is the authoritative source when the two disagree, and document how that conflict is resolved.
Before the assessment, ask your assessor how they want the repository presented: which branches and environments count as the active configuration, how far back the change history must go, how pull request approvals and merge rights are recorded, and who can push changes directly to production. Ask whether they will sample a live rule and trace it back through the code and history, and whether exported configuration snapshots are acceptable as evidence. Those answers determine how much of the diagram work can be automated and which access controls need to be visible in the evidence.
Which significant changes force a diagram and scope update
PCI SSC FAQ 1317 lists the kinds of significant change that send an entity back to its scope review. Each card below names one trigger, the diagram or inventory it touches, and who should approve the update before the change is treated as complete.
New CDE hardware or software
Adding a server, firewall, load balancer, application or library to the cardholder data environment changes the inventory and the network diagram at the same time. Under Requirement 12.5.1, each new in-scope component needs a recorded function or use, and Requirement 1.2.3 expects the network diagram to show its connections to the CDE. Update both documents before go-live, and confirm the security team signs off on the change record. Ask whether a new component was added to the diagram, not only to the change ticket.
Changes to data flows or storage
A new payment integration, a new reporting export or a new location where account data is written all alter the data-flow diagram required by Requirement 1.2.4. Storage changes also affect the account data location list that Requirement 12.5.2 asks the entity to confirm. The payment or compliance owner should approve the revised flow, and the security lead should confirm where the data lands. Check logs, backups and analytics copies, since these are common gaps.
Changes to the CDE boundary
Moving a segmentation control, opening a route between a system and the CDE, or adding supporting infrastructure such as DNS, identity or monitoring can move the boundary. The network diagram must still show every connection into the CDE, and the scope confirmation must record the segmentation controls that now separate it. The network security owner should approve the boundary change, and an independent QSA should review it if the change is material to the assessment.
New cloud accounts, subnets or peering
Illustrative example: a team creates a new cloud account, adds a subnet to an existing virtual network, or sets up a peering link to a shared services account. Each of these can create a path into the CDE that the diagram does not show. Infrastructure as code can reflect the change, but the diagram, inventory and segmentation evidence must be updated to match the deployed state. The cloud platform owner should approve the change, and the compliance lead should confirm the scope.
Change of third party
Replacing a payment gateway, hosting provider, managed firewall operator or support vendor changes which connections and data flows are in scope. The new third party must appear on the diagram with its connection path, and the scope confirmation must identify it as a third-party connection. Confirm the contract and responsibility matrix are updated, and obtain sign-off from the vendor management owner. Ask the new provider what evidence it can supply for its own part of the environment.
How to produce and validate the diagrams before the assessment starts
This sequence turns scattered sources into one set of network and data-flow diagrams that match the live environment, pass a scope check, and carry an owner's approval and a version history an assessor can trace. Each step ends with a named artifact so the work can be reviewed before the assessment begins.
Gather the source records
The compliance lead and the platform team collect the system inventory, firewall and security group rulesets from every network security control, cloud network configuration exports, infrastructure as code repositories, lists of third-party connections, and notes from interviews with the owners of payment applications and integrations. Interviews should ask where account data enters, where it is stored, where it is transmitted and where it leaves. The output is a source register that lists each record, its owner, its export date and the environment it describes, so an assessor can see what each diagram was built from.
Draft the network diagram
A network engineer draws the network diagram from the source register. It should show every connection into and out of the cardholder data environment, the segmentation controls that separate it from other networks, the network security controls at each boundary, and the connections to third parties and to any other environment that can affect the CDE. The output is a labeled draft with a legend, the environment it covers and the date of the source exports it reflects.
Draft the data-flow diagram
The payment application owner draws the data-flow diagram from the interview notes and the draft network diagram. It should trace every flow of account data from the point of capture through processing, storage, transmission, backup and deletion, and name the channel, protocol and system at each hop. Where a flow touches a third party, the diagram names that party. The output is a draft that a second reviewer can follow from entry to exit without asking the author for context.
Reconcile against inventory and configuration
The reviewer compares both drafts with the system inventory and the exported rulesets, line by line. Every system on a diagram should appear in the inventory, every ruleset that permits a connection to the CDE should match a drawn connection, and every drawn connection should trace to a rule or to a documented third-party link. Infrastructure as code is compared with the live configuration, since a mismatch means the code no longer describes the environment. The output is a reconciliation log that lists each discrepancy, its resolution and the person who closed it.
Test segmentation through scope confirmation
The compliance lead uses the reconciled diagrams as the basis for the scope confirmation. The team checks whether each segmentation control works as the diagram claims, through documented tests or a segmentation test performed under the entity's own procedure, and confirms that no system outside the drawn boundary can reach the CDE. Any system found to have a path is added to the scope and the diagrams are corrected. The output is a signed scope confirmation that refers to the diagram versions it relied on and records the segmentation test results.
Obtain owner approval
The accountable owner of the cardholder data environment reviews the diagrams, the reconciliation log and the scope confirmation, then approves them in writing. Approval confirms that the owner accepts the diagrams as the authoritative description of the environment and understands the connections they show. The output is a dated approval record that names the approver, the diagram versions and any open items, so the assessor can see that a named person accepted responsibility for the content.
Version and store the diagrams
The team saves the approved diagrams in a controlled repository with a version number, change summary, author, approver and date for each release. Each change to the environment that affects a connection or data flow triggers a new draft that passes through the same reconciliation and approval steps. The output is a version history an assessor can read from the first release to the current one, showing when each diagram changed and why, and which diagram was in force at the time of any significant change.
What usually makes the diagrams fail assessment and how to avoid it
Most diagram findings come from drift, not from bad drawing skills. The diagrams fall behind the environment, miss connections that bypass the main path, and lack the approval trail an assessor needs to accept them. Each card below names one failure pattern and a step that prevents it.
Diagrams drawn once and not updated
A diagram that reflects the environment at the last audit will fail as soon as a new payment service, database or network segment is added. Requirements 1.2.3 and 1.2.4 expect the network and data-flow diagrams to be accurate, and PCI SSC FAQ 1317 lists new CDE hardware or software and changes to data flows as significant changes that trigger a scope review. Prevention: tie diagram review to your change process so every approved change ticket that touches the CDE names the diagram section it changes, and record the diagram version and date in that ticket.
Third-party and remote support connections missing
Vendor VPN tunnels, remote support sessions, managed monitoring agents and API integrations are often set up outside the normal change path and never added to the drawing. An assessor who finds a connection to the CDE that the diagram omits will question the accuracy of the whole document. Prevention: run a connection review that lists every inbound and outbound session to the CDE, including vendor accounts, and reconcile it against the diagram at each scope confirmation.
Ephemeral cloud resources left out
Autoscaled instances, containers, serverless functions and short-lived load balancers can appear and disappear between reviews, so a static drawing rarely captures them. Assessors will check whether the diagram reflects the components that actually process or connect to account data. Prevention: generate the cloud portion of the diagram from the live account or from infrastructure as code, and state in the document which resources are dynamic and how their connections are controlled.
Diagrams that disagree with firewall and cloud rules
When a diagram shows a segment isolated but the firewall or security group rules allow a broader path, the document and the configuration contradict each other. Requirement 1.2.8 treats infrastructure as code and automated settings that configure network security controls as configuration files that must match the active configuration. Prevention: pick a sample of rules for each boundary, trace each one to a line on the diagram, and flag any rule with no matching connection for review or removal.
Account data stores outside the main diagram
Backups, log stores, analytics exports, support ticket attachments and temporary files holding primary account numbers are frequently left off the data-flow diagram because they sit in another team's tooling. The data-flow diagram must show all account data flows, so these stores count even when they are secondary. Prevention: start the data-flow exercise from the data discovery results and backup catalogs, not from the application architecture, and confirm each store's location and retention with its owner.
No record of who approved the diagram
A diagram without an owner, a review date and an approval record gives an assessor no basis to accept it as the current state. Requirement 12.5.2 places the scope confirmation with the entity itself, and the reviewer needs evidence that the people accountable for the environment reviewed the diagram. Prevention: keep a version-controlled copy with the author, reviewer, approver, date and the change tickets that were reviewed, and confirm the approval process with your QSA before the assessment begins.
Questions buyers ask about PCI DSS diagram requirements
Can a PCI DSS network diagram be a generated export from infrastructure as code?
Yes, a generated export can serve as the diagram, provided it is accurate, shows every connection to the cardholder data environment (CDE) and is reviewed by a person who understands the environment. Requirements 1.2.3 and 1.2.4 call for an accurate network diagram and an accurate data-flow diagram, but they do not prescribe a drawing tool. The assessor will check that the output matches the live configuration, so the generator must read from the same code that deploys the environment. Infrastructure as code also counts as configuration under Requirement 1.2.8, so the code itself must be secured, version controlled and kept consistent with what is running. Confirm with your assessor how they want the generated output dated, approved and retained.
Does one PCI DSS diagram set satisfy both an SAQ and a ROC?
The same accurate diagrams can support both, but the assessment type determines how much detail the assessor expects and where the diagrams are cited. An SAQ is completed by the entity on the official templates, while a Report on Compliance is completed by a Qualified Security Assessor (QSA) who tests the diagrams against the live environment. Requirement 12.5.2 scope confirmation uses the same diagrams, so one maintained set usually serves both purposes. Before you decide, confirm with your acquirer or payment brand which validation type applies to you and which evidence they expect, because the brands decide who must validate.
Who must sign off the network and data-flow diagrams?
The organization owns the diagrams and must approve them, normally through a named role that understands both the network and the payment flows. The standard does not name a specific job title, so you should assign accountability to a person who can answer assessor questions about each connection. Technical owners such as network and cloud engineers should prepare and check the content, and the same accountable role should confirm the annual scope review under Requirement 12.5.2. Record the approver, date and version of each diagram so the assessor can see who reviewed the current state. An outside partner or assessor cannot approve the organization's own diagrams on its behalf.
How much effort does a diagram project usually take, and what drives it?
No supplied figure exists for typical effort, so treat any duration as something to request in a written scope rather than assume. The main drivers are the number of in-scope systems, the number of cloud accounts and network segments, the number of third-party connections, and how often the environment changes. A small estate with one account and few integrations is far quicker to document than a multi-account cloud platform with many vendor links. Ask any provider to break the estimate into discovery, drawing or generation, validation against live configuration, and the process for keeping diagrams current after changes.
What does the internal team need to provide for diagram work?
The internal team must supply accurate knowledge of the environment, because no drawing is accurate without it. Typically this means access to network configuration, cloud account structures, firewall rule sets, data stores and their locations, and a list of third parties that connect to the CDE. Someone must also explain how card data enters, moves through and leaves the environment, since the data-flow diagram depends on that business process. Plan time for an engineer to review each draft and confirm that the connections shown are the ones that actually exist.
Can an outside partner produce the PCI DSS diagrams for us?
An implementation partner can prepare the diagrams, the infrastructure as code output and the supporting configuration evidence, provided the written scope says so. DeployOpen prepares systems, controls and evidence for compliance assessments, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. The partner should document the environment as it is, flag gaps and keep the organization in control of approval. Partner work should not be presented as an independent review, so keep the consultant and the assessor roles separate in your planning.
Can the partner issue the PCI DSS report or confirm our diagrams are compliant?
No. Only an independent assessor, such as a Qualified Security Assessor for a Report on Compliance, can issue the report, and the organization completes the Self-Assessment Questionnaire and its Attestation of Compliance. DeployOpen prepares systems and evidence but does not issue audit reports, attestations or certifications. PCI DSS validation is documented on official PCI SSC templates, and certificates are not recognized as validation. Ask your assessor early which diagram formats and evidence they will accept, so the partner prepares material that the assessor can test.
How DeployOpen prepares diagrams and evidence ahead of your assessment
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, and prepares the network and data-flow diagrams, scope evidence and inventory an assessor will check. We prepare systems and evidence only. Your organization owns its controls, and an independent QSA or assessor issues the assessment.
How we scope
- Written, fixed scope listing the environments, accounts and segments whose diagrams we will produce and verify.
- Agreed boundaries for which connections to the CDE and which account data flows are included.
- Named deliverables and timelines agreed in writing before any diagram or configuration work starts.
How we build
- Network diagram built from the live configuration of your network security controls and cloud accounts.
- Data-flow diagram traced from card data entry through storage, processing and transmission points.
- Infrastructure as code and NSC configuration files stored under version control and kept consistent with active settings.
How we hand over
- Diagrams delivered with version history, owner, review date and a record of the sources used to produce them.
- Scope confirmation evidence and system inventory cross-referenced to the diagrams for your assessor.
- Documented change triggers so your team knows when significant change requires an updated diagram and scope review.
How we support
- Ongoing support and diagram updates available as a retainer after handover, for changes in your environment.
- Continuous testing of the segmentation boundary shown in the diagrams, available under a separate agreed scope.
- Review sessions with your team to walk through diagrams before your QSA reviews them, with questions confirmed with your assessor.
