PCI DSS Compliance Requirements: All 12 Explained in Full Detail

A vendor security questionnaire lands in your inbox asking you to confirm you meet "all 12 PCI DSS requirements." You pull up a guide to check, and it's citing a version of the standard that got retired two years ago.

PCI DSS compliance requirements are the 12 specific controls the Payment Card Industry Data Security Standard mandates for any business that stores, processes, or transmits cardholder data, organized under 6 broader goals, and currently defined under PCI DSS version 4.0.1. They apply the same way to a five-person startup and a national retailer; only the validation method scales with size.

By the end of this, you'll know exactly what each of the 12 requirements demands, which version of the standard you should actually be reading against, and what changes (and doesn't) between merchant levels.

Here's what's ahead:

• What these 12 requirements actually are, and what this article deliberately isn't
• Why the version you're reading matters more than most guides let on
• Who these requirements apply to: merchants, processors, and online stores
• All 12 requirements, grouped by the 6 goals they serve
• Whether the requirements change by validation level
• Common mistakes teams make meeting them

A Quick PCI DSS Compliance Requirements Overview (and What These 12 Actually Cover)

The 12 requirements aren't 12 unrelated rules someone assembled into a checklist. They sit under 6 broader goals: build a secure network, protect cardholder data, manage vulnerabilities, control access, monitor and test continuously, and maintain a written security policy. Every one of the 12 exists to serve one of those six.

This article is not the general "what is PCI DSS compliance, who needs it, how does validation work" primer. ComplyJet's PCI DSS compliance guide covers that ground, along with the Self-Assessment Questionnaire, Report on Compliance, and Attestation of Compliance terminology. This piece has a narrower job: the 12 requirements themselves, in enough sub-control depth to actually be useful, not just a numbered list repeated back to you.

It's also not the step-by-step "how do I actually implement this" guide (in progress) or the full breakdown of how validation changes by merchant level (not yet started), both of which ComplyJet is building as separate, dedicated guides. Where this article touches either topic, it stays at overview depth and says so, rather than pretending to cover ground it doesn't.

A reader searching a bare pci dss compliance definition requirements phrasing usually wants exactly this: the requirements themselves, defined plainly, not the legal or enforcement backstory. That backstory (why it's contractual, not statutory, and who enforces it) lives in the pillar guide linked above.

PCI DSS Compliance Requirements 2026: Why the Version You're Reading Actually Matters

Here's the part most "12 requirements" guides skip entirely: which version of PCI DSS they're actually describing.

PCI DSS version 4.0.1, released June 2024, is the current and only active version of the standard. Version 3.2.1 was formally retired on March 31, 2024. Even the PCI Security Standards Council's own quick-reference guide for 3.2.1 is still indexed and findable online, describing a standard that no longer applies (Source: Wikipedia, Payment Card Industry Data Security Standard).

A search for pci dss 4.0 compliance requirements is usually really asking whether anything substantively changed under the new number. The honest answer: the requirement list itself didn't change, but several requirements picked up meaningfully expanded guidance on the way from 3.2.1 to 4.0, and a reader tracking pci dss compliance requirements 2026 should be reading against 4.0.1, full stop.

Two changes worth knowing before you get to the requirement-by-requirement breakdown below:

• Requirement 8: multi-factor authentication expectations expanded beyond remote access alone.
• Requirement 11: tighter guidance on monitoring and managing scripts on payment pages, closing a gap attackers have used for card-skimming injection.

Both are covered in more depth in their own requirement below.

Many of the pci dss 4.0 compliance requirements changes are additive guidance layered onto the existing 12, not a replacement set you need to learn from scratch. If your last gap assessment was run against 3.2.1 language, the fix is rarely "start over." It's closer to a targeted review of the handful of requirements that picked up real new depth, mainly 7, 8, and 11, against what 4.0.1 now expects.

PCI DSS Compliance Requirements for Merchants, Processors, and Online Stores

The 12 requirements don't change shape depending on who you are. What changes is scope: how many of your systems actually touch cardholder data, and which validation path you follow.

Merchants are the most common case: any business accepting card payments, in person or online. A five-person SaaS startup taking its first card payment and a national retailer processing millions of transactions a year both sit under the exact same 12 requirements, at very different validation levels.

Service providers and payment processors handle cardholder data on a merchant's behalf, and get their own separate validation scale based on transaction and account volume rather than a merchant-style level. A payment gateway processing on behalf of thousands of small merchants can land at a stricter validation tier than most of the individual merchants it serves, which surprises a lot of first-time service providers.

Issuers and processors are a distinct stakeholder group again, sitting on the card-issuing and transaction-routing side rather than the merchant side. An issuer processor pci dss compliance requirements search usually comes from exactly this persona, not a merchant at all, and it's worth naming that distinction directly rather than assuming every reader sits in the same seat.

Online stores have their own scoping wrinkle. An e-commerce checkout that's fully hosted by a PCI-compliant payment processor narrows which of the 12 requirements actually touch your own systems directly, since the processor absorbs a real share of the scope.

That narrowing isn't the same as an exemption, though. It doesn't remove your obligation to the requirements entirely; anything you touch directly, like a checkout page you control or card data that ever passes through your own servers, still counts.

A store's pci dss compliance ecommerce requirements picture, in practice, usually comes down to the requirements touching that hosted checkout and whatever sits around it, not all 12 at full force. That's a materially smaller scope than a business that stores cardholder data directly, but it's not zero.

The 12 Requirements for PCI DSS Compliance, Grouped by Goal

This is the part most generalist glossaries treat as a flat, evenly-shallow list. It shouldn't be. Some of these requirements deserve a paragraph; others deserve real sub-control detail, because that's genuinely what's being asked for.

Build and Maintain a Secure Network and Systems (Requirements 1-2)

Requirement 1 covers network security controls: firewalls and equivalent technology that separate your cardholder data environment from every network segment that doesn't need access to it. A well-scoped network here does more than satisfy an auditor; it shrinks how much of your infrastructure the rest of these 12 requirements even apply to, which shrinks the actual audit itself.

Requirement 2 is about not shipping with vendor defaults still active: default passwords, default accounts, default configurations on anything from a firewall to a point-of-sale terminal. Every default credential left in place is a documented, publicly known way in, which is exactly why attackers scan for them first.

Both requirements also expect an accurate, current inventory: which systems exist, which ones touch cardholder data, and which configuration standard each one is held to. Skipping the inventory step is a common shortcut that makes every later requirement harder to actually demonstrate.

Protect Cardholder Data (Requirements 3-4)

Requirement 3 governs stored cardholder data: strong encryption, masking so only the first and last four digits of a card number are ever displayed, and documented key management for whatever encryption keys protect that data. This is usually the most technically involved of the 12, and it's also where a business's actual risk concentrates, since stored data is what a breach ultimately exposes.

Requirement 4 covers cardholder data in transit, across any open or public network. Current guidance calls for strong, modern encryption such as TLS 1.2 or higher, not the older SSL and early-TLS protocols the standard has explicitly moved away from in recent versions. A checkout page that still negotiates a legacy protocol is a real, checkable gap, not a theoretical one.

Encryption and tokenization solve different problems here, and it's worth keeping them distinct. Encryption protects data that still needs to be recoverable in its original form; tokenization replaces the actual card number with a substitute value that's useless outside the system that issued it. Many businesses end up using both, encryption for data genuinely in transit or storage, tokenization to avoid holding the real number at all wherever possible.

Maintain a Vulnerability Management Program (Requirements 5-6)

Requirement 5 requires anti-malware protection on every system that's realistically at risk, kept current and actively logging what it catches. It's an old requirement by PCI DSS standards, and still one of the most commonly under-maintained: anti-malware that's deployed but never updated satisfies the letter of the requirement for about a week.

Requirement 6 is secure development and patch management: keeping systems and applications patched on a defined cadence, and building custom software with security considered from the start rather than bolted on afterward. This is also where Requirement 11's new payment-page-script guidance connects: insecure custom code on a checkout page is exactly the kind of gap that guidance targets.

Critical patches get the tightest expectations here, since an unpatched, publicly known vulnerability is the single easiest path into a cardholder data environment. A documented patch-management process, one that actually tracks which systems are current and which aren't, matters as much as the patching itself when it's time to demonstrate this requirement.

Implement Strong Access Control Measures (Requirements 7-9)

Requirement 7 restricts access to cardholder data on a documented need-to-know basis: role-based access, with privilege levels that map to what a person's job actually requires, not what's convenient to grant.

Requirement 8 covers identifying and authenticating every person with system access: unique IDs, no shared credentials, and multi-factor authentication. This is one of the two requirements that picked up real additional weight moving into version 4.0, expanding MFA expectations beyond remote access alone to cover a broader set of access into the cardholder data environment.

Requirement 9 is physical access: locked server rooms, visitor logging, and secure destruction of media that ever held cardholder data. Easy to underweight for a fully remote startup, but it still applies to wherever your infrastructure physically lives and to any hardware your team is issued.

For a fully cloud-hosted business, this requirement often shifts mostly onto the hosting provider's own physical security, but not entirely. A laptop that briefly held exported cardholder data before it was deleted still falls under secure-disposal expectations once that laptop is retired.

Regularly Monitor and Test Networks (Requirements 10-11)

Requirement 10 requires logging and monitoring of all access to cardholder data and the systems around it, with logs retained long enough to actually investigate an incident after the fact. Logging that exists but nobody reviews satisfies the storage half of this requirement and misses the point of the other half entirely.

Requirement 11 requires regular security testing: quarterly external vulnerability scans run by an Approved Scanning Vendor, internal scans, and periodic penetration testing, each distinct from the others and each required on its own cadence. This is also where the 4.0.1 update added real new weight, with tighter guidance on monitoring scripts running on payment pages specifically, a direct response to how card-skimming attacks actually work in practice today.

Maintain an Information Security Policy (Requirement 12)

Requirement 12 is the documentation requirement: a written, actively maintained information security policy, annual risk assessments, security awareness training for staff, and an incident response plan that's been tested, not just filed away. Every one of the other 11 requirements eventually traces back to a documented policy here; it's the requirement that makes the rest auditable rather than just assumed.

A policy that exists only as a document nobody's read since it was written doesn't satisfy this requirement in any real sense, even if it technically exists. Annual review is the minimum cadence, and a genuinely useful policy gets referenced and updated whenever something in the environment actually changes, not just on the anniversary of the last review.

Do PCI DSS Compliance Requirements Change by Validation Level?

No. All 4 merchant levels answer to the exact same 12 requirements. What changes is how you prove it.

Pci dss level 1 compliance requirements are not a separate, stricter rulebook sitting on top of the standard 12. Level 1 simply means the same 12 requirements get validated through a full QSA-led audit instead of a self-assessment, because the transaction volume at that level warrants independent verification. Are pci dss requirements the same for every business, regardless of level or business type? Yes, the requirement list itself never changes, only the depth of validation applied to it.

A full breakdown of how each level is defined, which SAQ type applies where, and what triggers a jump between levels is genuinely a separate topic, and ComplyJet is building a dedicated guide on PCI DSS compliance levels for exactly that. This section deliberately stays at the "does the list change" level rather than duplicating that guide's job.

Common Mistakes When Meeting PCI DSS Compliance Requirements

Most of these aren't exotic failures. They're the same handful of shortcuts showing up across businesses at every level, usually because a control that was solid at one point in time was never revisited after that.

• Treating "mostly compliant" as compliant. There's no partial credit across these 12. A gap in one requirement is a gap in your status, not a rounding error against the other 11, and an assessor will treat it that way even if the gap looks minor from the inside.
• Assuming a compliant payment processor covers everything. It reduces your scope. It doesn't erase your obligation to whatever you still touch directly, a hosted checkout page included, and finding that out during an assessment rather than beforehand is a rough way to learn it.
• Citing or building against a retired version of the standard. Building a control set against 3.2.1 in 2026 means building against a standard that's been superseded for two years, and it's a mistake that's genuinely easy to make when the guide you're reading never states its version.
• Deploying anti-malware once and never revisiting it. Requirement 5 expects it current and actively logging, not installed and forgotten during a busy quarter.
• Letting Requirement 11's testing cadence slip until an assessment is imminent. Quarterly scans and periodic penetration testing are meant to run on a schedule, not get compressed into the week before validation, where rushed testing tends to miss exactly the issues it exists to catch.
• Documenting a policy for Requirement 12 that doesn't match what the team actually does. An auditor testing that policy against real practice will find the gap; better to find it first, internally, than have it surface during the assessment itself.
• Ignoring the new payment-page-script guidance under Requirement 11 because it's easy to miss. It's a direct response to a real, current attack pattern, not a box-ticking addition, and skipping it leaves exactly the gap it was written to close.
• Scoping the cardholder data environment too loosely. Every system left inside scope that doesn't actually need to touch cardholder data is one more system every one of the 12 requirements now applies to, which makes the whole assessment bigger than it needs to be.

How ComplyJet Helps Meet PCI DSS Compliance Requirements

ComplyJet supports PCI DSS alongside SOC 1, SOC 2, ISO 27001, HIPAA, GDPR, and 25+ other frameworks, with flat per-company pricing rather than per-seat. Meeting these 12 requirements in practice means ongoing evidence collection and control monitoring, not a once-a-year document push, and that's the part ComplyJet's guided support is built around: mapping each requirement to the actual controls in your environment, tracking them continuously, and getting you ready for whichever validation path your level requires.

That guided model matters most for a small team without a dedicated security hire, where these 12 requirements would otherwise compete with everything else on someone's plate for attention.

That kind of continuous tracking is usually the difference between a control that's solid on paper and one that's actually solid in practice:

Most teams don't fail an assessment because they skipped a requirement outright. They fail because a control that was solid six months ago quietly drifted, a firewall rule got loosened for a deploy and never got tightened back, a scan got postponed twice. The 12 requirements are a snapshot of what continuous should look like, not a document you finish once. — Upendra Varma, CTO at ComplyJet

FAQs

What are the PCI DSS compliance requirements?

They're the 12 controls the Payment Card Industry Data Security Standard mandates for any business handling cardholder data, grouped under 6 goals covering network security, data protection, vulnerability management, access control, monitoring, and policy. All 12 apply under the current version, 4.0.1.

What are the 12 requirements for PCI DSS compliance?

Firewalls and network security, no vendor-default settings, protecting stored data, encrypting data in transit, anti-malware, secure development, restricted access, unique authenticated IDs, physical access controls, logging and monitoring, regular security testing, and a documented information security policy.

How many PCI DSS requirements are there?

12, organized under 6 broader goals. The number hasn't changed across recent versions of the standard; what's changed is the depth of guidance behind several of them.

What changed in the PCI DSS 4.0 requirements?

The 12 requirements themselves stayed the same. What expanded was guidance underneath a few of them, most notably wider multi-factor authentication expectations under Requirement 8 and new guidance on monitoring scripts on payment pages under Requirement 11. If your existing controls already satisfied the older version well, most of that work carries forward; it's a targeted update, not a rebuild.

Are PCI DSS requirements the same for every business?

Yes. The 12 requirements apply regardless of business type or size. What differs is scope, how many systems actually touch cardholder data, and validation method, which scales with transaction volume.

Do PCI DSS requirements differ by compliance level?

No, the requirements themselves don't change. Only the validation method does: Level 1 requires a full QSA-led audit, while Levels 2 through 4 validate through a Self-Assessment Questionnaire.

What is the current version of PCI DSS?

Version 4.0.1, released June 2024. It superseded version 4.0 with clarifying updates, and both came after version 3.2.1, which was formally retired on March 31, 2024. If a resource you're reading doesn't say which version it's describing, that's worth checking before you rely on it for anything specific.

Related Reading

• PCI DSS Compliance: What It Is, Who Needs It, and How It Works, the broader primer this article deliberately doesn't re-cover.
• Best PCI Compliance Software, for readers evaluating tools and platforms rather than reading the requirements themselves.
• PHI, PCI, and PII Compliance, for the healthcare-data crossover this guide doesn't cover.