PCI DSS Quick-Start

A beginner-friendly walk of PCI DSS — the six goal families that organize the twelve requirements, the four SAQ levels and merchant-vs-service-provider tiering that decide which report you actually file, v4.0 in 2024–2025 with the future-dated controls now mandatory, scope-reduction patterns (segmentation, processor tokenization, the CDE-on-a-VLAN shape), and two real analyst briefs that show the AOC firing in a vendor intake and a redirect-to-tokenized-checkout migration.

Last updated: 2026-07-31

Pair this primer with the full course: Full /courses/pci-dss walk →

The six goal families and the twelve requirements

Goal 1 — Build and Maintain a Secure Network: Req 1 (install and maintain network security controls to protect cardholder data) and Req 2 (apply secure configurations to all system components). The pair that defines the CDE boundary and the firewalls that defend it.
Goal 2 — Protect Account Data: Req 3 (protect stored account data) and Req 4 (protect cardholder data with strong cryptography during transmission over open, public networks). The pair that defines what you keep, how you keep it, and how it crosses the wire.
Goal 3 — Maintain a Vulnerability Management Program: Req 5 (protect all systems and networks from malicious software) and Req 6 (develop and maintain secure systems and software). The pair that protects the runtime — patching, anti-malware, and the SDLC.
Goal 4 — Implement Strong Access Control Measures: Req 7 (restrict access to cardholder data by business need-to-know), Req 8 (identify users and authenticate access to system components), and Req 9 (restrict physical access to cardholder data). The pair's odd-one-out: 'need-to-know' is the gate the rest of PCI leans on.
Goal 5 — Regularly Monitor and Test Networks: Req 10 (log and monitor all access to system components and cardholder data) and Req 11 (test security of systems and networks regularly). The pair that proves the controls are running — both via logs and via active testing (penetration tests, ASV scans, IDS/IPS).
Goal 6 — Maintain an Information Security Policy: Req 12 (support information security with organizational policies and programs). The policy umbrella: a written, maintained, communicated information-security policy is the document the assessor opens with and the document the org fails on when it is absent.

SAQ levels and the merchant-vs-service-provider split

PCI DSS compliance is not one artifact — it is a tiered set, and the artifact you file is decided by who actually stores, processes, or transmits cardholder data (CHD), and how. Merchants are tiered by Visa/Mastercard into Level 1 (more than 6M transactions/year — full Report on Compliance by a QSA), Level 2 (1M–6M — SAQ plus Attestation of Compliance), Level 3 (20K–1M e-commerce or 1M total — SAQ plus AOC), and Level 4 (below the Level 3 thresholds — SAQ plus AOC, with compliance enforcement typically delegated to the acquiring bank). Service providers have their own two-tier split: Level 1 (more than 300K transactions/year — full ROC by a QSA) and Level 2 (below — SAQ-D for Service Providers plus AOC).

The 'SAQ' the analyst files is itself a family, not a single form. Eight named SAQ documents sit across four SAQ families (sometimes called four SAQ 'levels' in shorthand): SAQ A (card-not-present merchants that fully outsource all cardholder data functions to a PCI-DSS-compliant processor — the cleanest case), SAQ A-EP (e-commerce merchants that outsource processing but retain a page that touches the consumer's browser), SAQ B (standalone dial-out or IP-terminal merchants with no cardholder data storage — now retired for most modern use cases), SAQ B-IP (standalone POI-terminal merchants that connect via IP, no cardholder data storage), SAQ C-VT (virtual-terminal merchants, one transaction at a time, no cardholder data storage), SAQ C (merchants with a payment application system connected to the internet, no cardholder data storage), and SAQ D (the catch-all — all other merchants and most service providers). The framework language you will see quoted is 'four SAQ levels'; that is the four SAQ families (A, A-EP, B/B-IP, C-VT/C, D), with the variously retired or split subforms collapsed inside each family.

The gate that decides which SAQ you file is concrete: who holds the PAN at rest, who transmits the PAN, and who has the keys. A D2C merchant that redirects consumers to a PCI-DSS-compliant tokenized checkout (Stripe Checkout, Braintree Hosted Fields, Adyen Drop-in) is SAQ-A territory — the merchant never sees the PAN and the tokenized integration is the one the processor attests on. The same merchant touching a customer-data field on its own server (a saved-card flow on the merchant's backend, a custom checkout page that POSTs to its own API) is SAQ-D: full twelve-requirements territory, with the auditor on the hook for everything below.

PCI DSS v4.0 and the ROC vs SAQ + AOC flavor

PCI DSS v3.2.1 retired on 2024-03-31 and PCI DSS v4.0 is the current standard as of 2024–2025. The v4.0 future-dated requirements — the additional requirements the PCI Security Standards Council deferred to give organizations an adoption runway — became mandatory on 2025-03-31. Any scope or report dated after that point is read against v4.0 with the future-dated controls in force; treat the 2025-03-31 cutoff as the date by which v4.0 alignment on the future-dated controls must be visible in the assessment evidence.

The certification flavor follows the tiering. Level 1 merchants and Level 1 service providers file a Report on Compliance (ROC) produced by a Qualified Security Assessor (QSA): the QSA walks the twelve requirements, samples controls, tests operating effectiveness, and writes the ROC document itself. Merchants and service providers below Level 1 file a Self-Assessment Questionnaire (the SAQ document chosen above) plus an Attestation of Compliance (AOC) — the AOC is the short, signed document that summarizes the SAQ and is the artifact that gets shared with acquiring banks, partners, and customers. The AOC is what the buyer on the other side of a vendor questionnaire actually asks for; the ROC is what a customer or partner reviewing a Level 1 service provider (a Stripe, Adyen, Braintree) is reviewing.

The practical gate: confirm the version your assessor (internal or external) is reading against, confirm the date window your report covers, and confirm whether the report you are signing is an SAQ + AOC or a full ROC. The ROC vs SAQ distinction is not a paperwork preference — it is the difference between a QSA having attested your controls under their credential and you having self-attested against the twelve requirements yourself.

Scope-reduction patterns

PCI scope is what your assessor walks. Every system that stores, processes, or transmits cardholder data (the Cardholder Data Environment, CDE), and every system that connects to it, is in scope. The first move is segmentation: isolate the CDE on its own network with documented ingress and egress, so that an unrelated business system connecting to the CDE does not pull itself into scope by virtue of the connection.

The second move is tokenization via a payment processor. When the merchant replaces its own card-data capture with a hosted tokenized checkout (Stripe Checkout, Stripe Elements with tokenization on the client, Braintree Hosted Fields, Adyen Drop-in, Checkout.com Frames), the PAN never reaches the merchant's server — only a token does, and the PCI control on that token is the processor's, not the merchant's. A clean redirect-to-processor integration is the path from SAQ-D territory to SAQ-A territory, and it is the path most D2C and SaaS merchants actually take.

The third shape, less common but real, is the 'CDE on a VLAN with tight ingress/egress' pattern: a single, well-instrumented network segment that contains all PAN handling, with documented allow-listing for every other system that needs to reach it (a billing reporter, a fraud-scoring service, an audit log shipper). This still leaves the CDE in PCI scope — no tokens here — but it dramatically narrows what the assessor must read. Each pattern reduces different things: segmentation reduces which systems the assessor walks, tokenization reduces whether the merchant is in scope at all, and the VLAN-with-egress shape reduces the size of the audit surface in scope.

Two beginner briefs — redirect-to-tokenized checkout and processor AOC review

WovenCart (D2C apparel on Shopify Plus, PCI scope on the marketing tooling that touches cardholder data) handling a redirect-to-tokenized-checkout migration: the marketing analytics stack currently sees PAN data via a saved-customer feature on the merchant's checkout page, which is SAQ-D territory and is the reason the prospective enterprise customer paused the contract. The analyst's job is to map every flow that currently sees the PAN (checkout page, post-purchase receipt, abandoned-cart email builder, customer-support refund tool) onto a tokenized alternative (Stripe Checkout for the public flow, Stripe Billing for the post-purchase, a refund-via-dashboard API for support), produce the network diagram showing the CDE shrinking to just the processor's hosted page, and walk the resulting SAQ type from D down to A. The concrete artifact is the redirect-to-tokenized-checkout architecture diagram, the before-and-after SAQ-A eligibility memo, and the AOC (from the processor) that the QSA will request to validate SAQ-A status.
Atlas Health Partners (regional integrated delivery network, post-merger HITRUST journey, evaluating a new third-party payment processor for patient-billing integration) handling a processor AOC review: procurement sends the processor vendor-risk packet ahead of a pilot. The analyst's job is to intake the processor's current AOC and ROC, confirm the AOC is current (dated within the last twelve months, signed by a QSA for Level 1 service providers), map the processor controls onto Atlas's CDE boundary to confirm the patient-billing flow inherits the processor's scope, and flag any carve-outs the processor proposes (a sub-processor list that introduces an entity outside the ROC, a clarified-scope definition that excludes a transaction volume the patient-billing flow will hit). The concrete artifact is the vendor-risk memo mapping the processor controls onto the CDE boundary, the sub-processor inventory accepted by Atlas, and a one-page memo on the SLAs Atlas has to enforce on its side because they are not covered by the processor's AOC.

Next steps

Once you can name which PCI requirement a brief opens first — and which SAQ family the resulting scope-reduction pattern is targeting — you are no longer reading PCI DSS as a twelve-requirements wall; you are reading it as a tiered framework with a clear scope-reduction path. The next concrete move is to score a real environment against the twelve requirements on a 0–3 maturity scale so the Gap Report you hand leadership lines up cleanly against the SAQ type the org actually files.

When you are ready to read the matching course, the full /courses/pci-dss walk covers requirement-by-requirement evidence and the QSA sampling logic for a Level 1 ROC. The Gap Analysis lab below accepts PCI DSS directly on its free sub-form, so a free visitor can run the lab against the twelve requirements and read the gap scoring with no payment required. Until then, the laminate for PCI is: name the requirement, name the SAQ, name the next concrete artifact.

Next: try the Gap Analysis lab

Score a real environment against the PCI DSS twelve requirements on a 0–3 maturity scale and print a Gap Report (per-requirement current vs target, average maturity, and a remediation list sorted lowest first). PCI DSS is selectable directly from the lab's free sub-form — no payment required to walk the twelve requirements and read the gap scoring.

Open the Gap Analysis lab →