PCI DSS Architecture Diagrams: Cardholder Data Environment & Network Segmentation (2026)

How to create PCI DSS 4.0.1 architecture diagrams for companies handling cardholder data. Covers CDE scoping, network segmentation, tokenization, SAQ types, and cardholder data flow documentation — with AI prompt templates.

Ryan·Senior AI Engineer

·Last updated July 12, 2026

PCI DSS architecture diagrams occupy a unique place among compliance documentation: they aren't just supporting evidence, they're a literal audit deliverable. PCI DSS 4.0.1 Requirements 1 and 12 explicitly mandate that every entity storing, processing, or transmitting cardholder data maintain a current network diagram and a current cardholder data flow diagram, reviewed at least annually and whenever the environment changes. A Qualified Security Assessor (QSA) or your acquiring bank will ask to see both before looking at anything else. This guide covers what belongs on each diagram, how the Cardholder Data Environment (CDE) boundary drives your audit scope, and how to use AI to generate accurate, assessor-ready diagrams.

The two diagrams PCI DSS 4.0.1 requires

Network diagram (Requirement 1.2.4): Shows all connections between the CDE and other networks, including any wireless networks. Must identify all network devices (firewalls, routers, switches), all segmentation boundaries, and the connections between the CDE, the corporate network, and the internet. This is the diagram assessors use to verify your segmentation actually isolates the CDE — if a connection exists on your network but not on the diagram, that's a finding.
Cardholder data flow diagram (Requirement 1.2.4 / 12.5.2): Traces account data — Primary Account Number (PAN), cardholder name, expiration date, service code, and any Sensitive Authentication Data (SAD) if temporarily retained — from the point of capture through every system that stores, processes, or transmits it, to eventual disposal. Every arrow on this diagram represents a system that's in-scope for the assessment.

Both diagrams must be kept current (Requirement 12.5.2 requires a review at least once every 12 months and upon significant change) and must match what your assessor finds when they validate the environment. A diagram that's stale or that omits a connection is one of the most common sources of PCI findings.

The Cardholder Data Environment (CDE) boundary

The CDE is the set of people, processes, and technology that store, process, or transmit cardholder data or sensitive authentication data, plus any system component that is connected to or could impact the security of that data. Everything inside the CDE boundary is subject to the full PCI DSS control set — over 300 individual requirements in v4.0.1. Everything properly segmented outside the CDE is out of scope. This is why the CDE boundary line is the single most important thing on a PCI diagram: draw it too loosely and you've pulled your entire corporate network into scope; draw it without adequate segmentation evidence and your assessor will draw it for you, usually larger.

Network segmentation — firewalls, VLANs, or a dedicated cloud VPC with explicit allow-listed ports and protocols only — is how you shrink the CDE. A flat network with no segmentation controls means the entire network is in-scope by default. A properly segmented CDE isolated from the corporate LAN, with only the specific ports needed (e.g., 443 for API calls, nothing else) allowed across the boundary, is what lets you scope an assessment down to a handful of systems instead of your whole company.

Components to include on the diagram

Payment capture points: In-store POS terminals, e-commerce checkout pages, mobile payment SDKs. Show exactly where card data first enters your systems (or, in the scope-reducing pattern below, where it bypasses your systems entirely).
Payment gateway / processor: Stripe, Adyen, Braintree, or similar. In 2026, the dominant pattern for SaaS and e-commerce is tokenization at the edge — the processor's hosted fields or SDK capture the PAN directly, and your servers only ever see a token. Label this connection clearly, since it determines whether raw PAN ever touches your infrastructure.
Tokenization vault: If you self-manage tokenization (rather than relying on the processor's vault) for recurring billing or stored payment methods, this vault and its network segment are fully in-scope and must be diagrammed as its own isolated zone.
Network segmentation controls: Firewalls and VLANs isolating the CDE from the corporate network and the internet, with the specific allow-listed ports/protocols annotated on each boundary — not just “firewall present.”
DMZ: For any public-facing component that touches payment data or sits in front of the CDE, show its placement in a DMZ separate from both the internet and the internal CDE segment.
Encryption: TLS 1.2+ for all cardholder data in transit, and strong cryptography (AES-256 or equivalent) plus key management details for anything stored at rest.
Logging / SIEM: Centralized logging for all CDE access, with the log destination and retention period noted — Requirement 10 audit trail evidence.
Third-party service providers: Any vendor with a connection into the CDE should be labeled with a reference to their own PCI Attestation of Compliance (AOC), so an assessor can see at a glance which parties are covered by their own assessment.

Scope reduction: hosted fields and tokenization

The single biggest lever for shrinking a PCI assessment is ensuring raw PAN never touches your own servers. Using a hosted payment page, an iframe, or a redirect — Stripe Checkout, Stripe Elements, Braintree Drop-in — means the cardholder's browser or app submits card data directly to the processor's domain. Your infrastructure only ever handles an opaque token or a payment confirmation. This is the difference between qualifying for the lightweight SAQ A (roughly 20-odd requirements) versus SAQ D (the full control set, 300+ requirements) for merchants who touch raw PAN directly on their own servers. Your architecture diagram is the evidence an assessor uses to confirm which pattern you actually implemented — a diagram showing card data flowing from the client directly to the processor, with no PAN-bearing arrow into your backend, substantiates an SAQ A claim.

Prompt examples for PCI DSS architecture diagrams

SaaS checkout with tokenization (SAQ A pattern)

"PCI DSS network diagram for a SaaS e-commerce checkout using Stripe Elements. Customer browser loads our checkout page (served from our web app, hosted on Vercel) but the card input fields are Stripe-hosted iframes injected directly into the page — raw PAN is entered by the customer and submitted by their browser straight to Stripe's domain over TLS 1.3, never touching our servers. Our backend only receives a Stripe payment token and a charge confirmation via webhook (HMAC-signed, verified server-side). Show the browser-to-Stripe connection as a separate, dashed line outside our network boundary, and our backend as receiving only tokenized data. Annotate: 'No PAN transmitted to or stored by merchant systems — SAQ A eligible.' Include Stripe's AOC reference as a third-party attestation note."

CDE network segmentation from corporate network

"PCI DSS network segmentation diagram for a retail payment platform. Cardholder Data Environment is a dedicated VPC (10.20.0.0/16) fully isolated from the corporate network (10.10.0.0/16) — the only connection between them is through a next-gen firewall with an explicit allow-list: port 443 (HTTPS API calls) and port 22 (SSH, jump-host only, MFA-required). All other ports denied by default. Within the CDE VPC: public subnet contains only a load balancer behind a WAF; private subnet contains the payment processing service and tokenization vault; no direct internet route from the private subnet (egress via NAT gateway to the processor's API only, IP allow-listed). Corporate network (employee laptops, internal tools, email) has zero direct route into the CDE VPC — support staff access via a bastion with just-in-time access and full session recording. Draw the CDE boundary as a heavy dashed line and label every crossing connection with its allowed port/protocol."

Cardholder data flow diagram (capture to processor, no storage)

"PCI DSS cardholder data flow diagram for an in-store retail POS system. Flow: chip/tap card presented at POS terminal → terminal performs point-to-point encryption (P2PE) at the point of interaction, PAN is encrypted in hardware before it ever leaves the terminal → encrypted payload sent over TLS 1.2+ via the store's network to the payment processor's gateway → processor decrypts using the P2PE key it manages, authorizes the transaction, returns an approval code → POS terminal stores only the approval code, last-4 digits, and transaction ID locally for the receipt — no PAN, no full track data, no CVV is ever stored, logged, or written to disk at any point in the flow. Mark every arrow with its encryption method (P2PE hardware encryption, then TLS in transit) and mark the terminal and processor gateway as the only two points that ever handle unencrypted-equivalent cardholder data, both outside our direct control after P2PE. Add disposal note: no retention means no disposal step required for PAN."

Recurring billing with self-managed tokenization vault

"PCI DSS architecture diagram for a subscription billing platform that stores tokenized PAN for recurring charges. Initial card capture via Stripe Elements (tokenized at the browser, as above). For recurring billing we need our own reference beyond Stripe's token, so a nightly batch job calls Stripe's API to retrieve a vaulted, non-reversible token and stores it in a dedicated tokenization vault — an isolated database in its own network segment (10.30.5.0/28), reachable only from the billing service via mTLS, with no direct internet exposure and no developer access without a break-glass approval. The vault segment sits inside the CDE boundary; the rest of the billing service (invoice generation, dunning emails, usage metering) sits outside the CDE and only ever references an internal customer ID, never the token itself. Show the CDE boundary drawn tightly around just the vault and its access path, with the wider billing service diagrammed outside it and connected through a narrow, logged API call."

SAQ types and how they change diagram scope

SAQ type	When it applies	Diagram / scope implication
SAQ A	Fully outsourced card capture via hosted fields, iframe, or redirect — merchant never receives or stores PAN electronically	CDE is essentially empty; diagram should show card data flowing browser-to-processor only, bypassing merchant servers entirely
SAQ A-EP	E-commerce site doesn't receive PAN but does control or influence how the payment page is delivered (e.g., site script assembles the checkout page that embeds the processor's iframe)	Diagram must include the web server that serves/controls the payment page, even though it never touches PAN — that server is in-scope
SAQ B	Standalone, dial-out terminals or imprint machines only — no electronic cardholder data storage, no connection to other systems	Diagram is minimal: isolated terminal(s) with a direct connection to the processor, explicitly disconnected from any other network
SAQ D	Merchant or service provider stores, processes, or transmits PAN directly on its own systems (e.g., self-managed tokenization vault, in-house payment processing)	Full network and data flow diagrams required, covering every in-scope system — the heaviest documentation burden of the four

What to annotate on a PCI DSS architecture diagram

CDE boundary line: A clearly drawn boundary (heavy or dashed line) separating in-scope systems from everything else. This is the first thing an assessor looks for.
Data flow direction with encryption noted: Every arrow carrying cardholder data should show direction and the encryption method in use (TLS version, P2PE, tokenization) — never leave an unlabeled arrow crossing the CDE boundary.
Firewall / segmentation rules: Label each boundary crossing with the specific allowed ports and protocols, not just “firewall.” Assessors validate these against actual firewall rulesets.
Third-party AOC references: Note which connected vendors (processor, gateway, hosting provider) have their own current PCI Attestation of Compliance, and which responsibilities they cover per their responsibility matrix.
Retention and disposal points: Mark anywhere cardholder data is stored, even temporarily, with its retention period and the secure disposal or purge mechanism.
Wireless access points: PCI DSS specifically calls out wireless networks — if any wireless network exists anywhere near the CDE, it must appear on the diagram even if it's logically isolated.
Diagram version and review date: Requirement 12.5.2 requires an annual review — include a version number and last-reviewed date so an assessor can confirm currency at a glance.

Ready to try it yourself?

Start Creating - Free