What PCI DSS is
PCI DSS stands for Payment Card Industry Data Security Standard. It's the security standard every organization that stores, processes, or transmits cardholder data must follow. It's maintained by the PCI Security Standards Council (a body run by Visa, Mastercard, Amex, Discover, and JCB) and enforced by the card brands plus your acquiring bank.
The current version is PCI DSS 4.0 (released March 2022). Some new requirements were "future-dated" — informational from 4.0's release until March 31, 2025, then fully mandatory. As of 2026 you should be operating against 4.0 in full.
Who's regulated: if you accept credit or debit cards in any form, PCI DSS applies. Even if you outsource everything to Stripe Checkout, you're still in scope — just at the lowest tier (SAQ A).
The 12 core requirements
PCI DSS organizes its hundreds of sub-requirements under 12 top-level numbered requirements:
- Install and maintain network security controls. Firewalls, segmentation between the cardholder data environment (CDE) and the rest of your network.
- Apply secure configurations to all system components. No vendor defaults; documented baseline configs.
- Protect stored account data. Encryption at rest, key management, data retention/disposal policies. (Don't store more than you have to.)
- Protect cardholder data with strong cryptography during transmission over open public networks. TLS 1.2+, validated cipher suites.
- Protect all systems and networks from malicious software. Anti-malware on systems "commonly affected" by malware, plus continuous monitoring on others.
- Develop and maintain secure systems and software. Secure SDLC, vulnerability management, code review, patch cadences.
- Restrict access to system components and cardholder data by business need-to-know.
- Identify users and authenticate access to system components. MFA on all access to the CDE, strong password requirements.
- Restrict physical access to cardholder data. Badges, visitor logs, secure media handling.
- Log and monitor all access to system components and cardholder data. Daily log review for the CDE.
- Test security of systems and networks regularly. Quarterly external ASV scans, annual penetration tests, quarterly internal scans.
- Support information security with organizational policies and programs. The "everything else" requirement — written policies, training, incident response, vendor management.
The 4 merchant levels
| Level | Visa transactions/year | Validation |
|---|---|---|
| Level 1 | 6M+ (any channel) — or any merchant the card brand designates | Annual Report on Compliance (ROC) by a Qualified Security Assessor (QSA), plus quarterly ASV scan |
| Level 2 | 1M – 6M | Annual Self-Assessment Questionnaire (SAQ); some acquirers require ROC |
| Level 3 | 20K – 1M e-commerce | Annual SAQ + quarterly ASV scan |
| Level 4 | < 20K e-commerce or < 1M total | Annual SAQ; ASV scan if e-commerce |
Your acquiring bank assigns your level. Each card brand has its own thresholds — Mastercard and Visa differ slightly. The numbers above are Visa's; Mastercard is similar; Amex and Discover have their own programs.
Which SAQ applies to you
For Levels 2-4 (and Level 1 for service providers), you self-assess via a Self-Assessment Questionnaire. There are 9 SAQ types — the right one depends on how you handle card data:
- SAQ A — e-commerce that fully outsources card handling to a validated third-party (e.g. Stripe Checkout, Braintree hosted). ~22 questions.
- SAQ A-EP — e-commerce where your website touches card data even briefly (e.g. Stripe Elements, where your page contains the iframe). ~191 questions.
- SAQ B — imprint machines or stand-alone dial-up terminals only.
- SAQ B-IP — stand-alone IP-connected terminals.
- SAQ C — POS systems connected to the internet.
- SAQ C-VT — virtual terminals (web-based, single transaction at a time).
- SAQ D — anyone who stores card data, or doesn't fit above. ~370 questions. The default for software companies.
- SAQ P2PE — validated point-to-point encryption deployments.
- SAQ A-PCI Tap on Mobile — newer SAQ for tap-to-pay on mobile devices.
SaaS rule of thumb: if you use Stripe Checkout / Braintree hosted / similar full-redirect, you're SAQ A. If you embed Stripe Elements or any iframe on your own page, you jump to SAQ A-EP. If you ever see raw card data — even briefly — you're SAQ D.
What's new in PCI DSS 4.0
Versus 3.2.1 (the previous version), 4.0 introduces:
- Customized implementation. You can meet a requirement an alternative way if you document a targeted risk analysis showing equivalent security. Adds flexibility but also more documentation work.
- Phishing-resistant MFA on all access to the CDE (FIDO2 / hardware tokens preferred over SMS or TOTP).
- Stronger password requirements. Minimum 12 characters (up from 7), or use MFA + behavioral controls.
- Continuous monitoring of payment-page scripts. Catches Magecart-style client-side skimming attacks.
- Targeted risk analyses required for several requirements that previously had fixed timeframes (e.g. log review cadence, scan cadence).
- More granular network segmentation documentation requirements.
PCI DSS vs other frameworks
| Framework | Scope | Style | Audit |
|---|---|---|---|
| PCI DSS 4.0 | Cardholder data only | Prescriptive | QSA ROC or SAQ |
| SOC 2 | Anything you scope | Principles-based | CPA attestation |
| ISO 27001 | Whole ISMS | Risk-based | External certification body |
| HIPAA | ePHI only | Required + addressable | HHS audit on request |
How to get to PCI DSS compliance
- Determine your level + SAQ type. Talk to your acquirer. Get this wrong and the rest of the work is misdirected.
- Scope your CDE. Map every system, network, and person that touches cardholder data. Aggressively segment what's NOT in scope — that's where most overspend comes from.
- Run a gap assessment against the SAQ or full DSS as applicable.
- Remediate over a defined timeline. Quarterly ASV scans start now so you have clean reports by audit time.
- Submit the SAQ (or get the ROC done) and the Attestation of Compliance (AoC). File annually.