Framework Guide

PCI DSS Guide

PCI DSS is contractual rather than legal — enforced through your acquirer and the card brands — but its teeth are real: non-compliance fees, higher processing rates, and in breach scenarios, liability that has ended companies. It is also the most prescriptive mainstream framework, which makes scoping decisions disproportionately valuable.

Scope is the whole game

Every PCI requirement applies to the cardholder data environment: systems that store, process, or transmit card data, plus anything connected to them. Shrinking that boundary — through tokenization, outsourced payment flows, and network segmentation — shrinks the compliance burden more than any tooling decision. The most cost-effective hour in PCI is the one spent on the data-flow diagram.

Validation paths

Smaller merchants and service providers self-assess through SAQs; higher transaction volumes or partner demands trigger an on-site assessment by a Qualified Security Assessor producing a Report on Compliance. Both paths require quarterly external scans by an approved vendor — a cadence obligation that catches teams who treat PCI as annual.

Go Deeper

PCI DSS Checklist — A PCI DSS v4 checklist that starts where the money is — scope reduction — then walks the 12 requirements, SAQ selection, and evidence. Full list on-page.

Frequently Asked
What SAQ type do we need?

It depends on how card data flows through your environment. Fully outsourced e-commerce typically qualifies for SAQ A; redirect and iframe integrations may qualify for SAQ A or A-EP depending on implementation; anything that touches cardholder data directly moves toward SAQ D. Data-flow mapping settles the question definitively.

What did PCI DSS 4.0 change?

The 4.0 requirements that became mandatory in 2025 expanded MFA coverage, added targeted risk analyses, introduced e-commerce payment-page script controls, and made logging more prescriptive. Programs built on 3.2.1 assumptions commonly show gaps in exactly these areas.