What Is PCI DSS? Payment Card Data Security, Explained

The Payment Card Industry Data Security Standard (PCI DSS) is a set of technical and operational requirements that any organization storing, processing, or transmitting cardholder data must follow. It isn’t a law — it’s a contractual standard maintained by the PCI Security Standards Council, an industry body founded by the major card networks (Visa, Mastercard, American Express, Discover, and JCB). Compliance is enforced through the contracts merchants sign with their payment processors and acquiring banks, not through government regulation.

Who has to comply

Any entity that touches primary account numbers (PANs) — the 16-digit number on a payment card — is in scope, regardless of size. That includes:

• Merchants, from a single-location retailer to a large e-commerce platform.
• Payment processors and gateways that route transactions between merchants and banks.
• Service providers that store or transmit card data on a merchant’s behalf, including many SaaS platforms and hosting providers.

The scope and rigor of compliance scale with transaction volume. The PCI Council defines four merchant levels based on annual card transactions, with Level 1 (the highest volume) requiring an annual on-site audit by a Qualified Security Assessor, while lower levels can typically self-assess with a Self-Assessment Questionnaire (SAQ).

Many merchants reduce their own scope by never touching raw card numbers at all — routing payment forms through a processor’s hosted fields or redirect flow (Stripe Checkout and similar products work this way) so the card number never passes through the merchant’s own servers. This meaningfully shrinks what needs to be audited.

The 12 requirements

PCI DSS organizes its controls into six goals, broken into 12 requirements:

1. Install and maintain network security controls — firewalls and network segmentation between the cardholder data environment and the rest of the network.
2. Apply secure configurations to all system components — no vendor default passwords or unnecessary services.
3. Protect stored account data — encrypt or tokenize stored PANs; never store full track data, CVV, or PIN data after authorization.
4. Protect cardholder data in transit with strong cryptography — TLS, not plaintext, across open networks.
5. Protect systems from malware with anti-malware controls, kept current.
6. Develop and maintain secure systems and software — patch management and secure development practices, informed by lists like the OWASP Top 10.
7. Restrict access to cardholder data by business need-to-know — the principle of least privilege applied to a specific dataset.
8. Identify users and authenticate access — unique IDs per user and multi-factor authentication for administrative and remote access.
9. Restrict physical access to cardholder data and the systems that process it.
10. Log and monitor all access to network resources and cardholder data, with logs retained and reviewed.
11. Test security of systems and networks regularly — vulnerability scans and penetration testing on a defined cadence.
12. Support information security with organizational policies — a documented security policy, incident response plan, and staff training.

Tokenization: the common way to shrink scope

Most of the operational burden of PCI DSS comes from requirement 3 — protecting stored account data. The standard practice for avoiding that burden is not storing the PAN at all: a payment processor tokenizes the card number at the point of capture and hands the merchant an opaque token that can be used for refunds or recurring billing but is useless if stolen. This is conceptually the same trade a hashed password makes — the sensitive value never sits in the merchant’s database in a usable form. Systems that never store, process, or transmit the actual PAN can often be excluded from PCI scope entirely, which is why most small and mid-size merchants integrate a hosted payment page rather than building their own card form.

PCI DSS compared to other compliance frameworks

	PCI DSS	SOC 2	ISO 27001
Governing body	PCI Security Standards Council (industry)	AICPA (US)	ISO (international)
Scope	Cardholder data specifically	Any service organization’s controls	Any organization’s information security management
Enforcement	Contractual, via payment processors	Contractual, via customer requirements	Voluntary certification
Format	Prescriptive — 12 fixed requirements	Flexible — auditor tests against chosen trust principles	Flexible — risk-based management system

PCI DSS is notably more prescriptive than SOC 2 or ISO 27001: where those frameworks let an organization define its own control objectives and have an auditor test against them, PCI DSS specifies the controls directly. A company handling payments frequently needs more than one of these — PCI DSS for the cardholder data environment, plus SOC 2 or ISO 27001 to satisfy enterprise customers asking about security posture more broadly.

The takeaway

PCI DSS is the standard that makes card payments trustworthy at scale: 12 fixed requirements covering network security, access control, monitoring, and how cardholder data is stored and transmitted, enforced through the contracts merchants and processors sign rather than by statute. The most effective compliance strategy for most businesses isn’t building elaborate controls around stored card data — it’s avoiding storing that data in the first place, by routing payments through a processor that handles tokenization and absorbs most of the compliance scope.