A vendor questionnaire asks whether you meet "all 12 PCI DSS requirements." You know the standard exists. What you actually want right now is something to work through, item by item, not another explainer.
A PCI DSS compliance checklist breaks the standard's 12 requirements, covering network security, cardholder data protection, vulnerability management, access control, monitoring, and policy, into concrete action items you can work through and verify one at a time, before completing a Self-Assessment Questionnaire or Report on Compliance. It applies the same way to a five-person startup and a national retailer. Only the validation method changes.
By the end of this, you'll have a working checklist for all 12 requirements, know exactly which version of the standard you're being held to, and understand which SAQ and merchant level actually apply to you.
Here's what's ahead:
- What this checklist covers, and what it deliberately doesn't
- Why a PCI DSS compliance checklist matters in practice, not just on paper
- Which PCI DSS version this checklist follows
- All 12 requirements, formatted as an actual checklist
- The steps that wrap around the 12 requirements themselves
- SAQ types and merchant levels, explained plainly
- Common mistakes teams make working through a checklist like this
Why a PCI DSS Compliance Checklist Matters
Most businesses that fail a PCI assessment didn't skip a requirement outright. 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, a password policy got relaxed for a new hire and never revisited.
That's the real argument for a pci compliance checklist over a one-time compliance project. A checklist gets re-run. A project gets finished and forgotten.
A checklist you complete once and file away isn't a PCI DSS checklist, it's a snapshot of a moment that's already over. The 12 requirements describe what continuous should look like. Re-running this list quarterly catches the drift before an assessor does. — Upendra Varma, CTO at ComplyJet
The stakes are concrete, not abstract. Non-compliance can mean fines from your acquiring bank, increased transaction fees, or in serious cases, losing the ability to process cards at all. A breach involving unprotected cardholder data adds forensic costs, notification obligations, and reputational damage on top of whatever the card networks levy directly.
It's worth being precise about where that enforcement actually comes from. PCI DSS isn't a government law, it's a contractual standard set by the major card networks, enforced through your merchant agreement with your acquiring bank.
That distinction matters in practice. There's no regulator to file a complaint with, but your ability to keep accepting cards runs directly through that agreement, which is exactly why the consequences of falling behind on this checklist land quickly, and land on revenue, not just on paper.
PCI DSS 4.0 Compliance Checklist: Which Version This Follows
Here's the part a lot of checklists skip: which version of PCI DSS they're actually built against.
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 (Source: Wikipedia, Payment Card Industry Data Security Standard). A pci dss 4.0 compliance checklist and a v4.0.1 checklist are effectively the same thing: 4.0.1 is a clarifying update to 4.0, not a new numbered requirement set, and the same 12 requirements sit underneath both.
Here's how the three versions line up:
The 12 requirements haven't changed in number under 4.0.1. What changed is guidance underneath a few of them: Requirement 8's multi-factor authentication expectations expanded beyond remote access alone, and Requirement 11 picked up new guidance on monitoring scripts on payment pages, a direct response to how card-skimming attacks work today. Both are called out in the checklist below.
If your last gap assessment was run against 3.2.1-era language, the fix usually isn't starting over. It's a targeted review of Requirements 7, 8, and 11, the three that picked up real new depth on the way to 4.0.1.
The PCI DSS Compliance Checklist — 12 PCI DSS Requirements to Work Through
These 12 pci dss requirements are the same list whether you're reading them here as a checklist or in full depth in the requirements guide. This pci dss requirements checklist groups every item under the same 6 goals the standard itself uses, so nothing sits in isolation from why it exists.
Work through each group in order. Each row is one thing to actually do, not just a concept to understand.
Build and Maintain a Secure Network and Systems (Requirements 1-2)
| Do this | What it means |
|---|---|
| Install and maintain network security controls | Firewalls or equivalent technology separating your cardholder data environment from every network segment that doesn't need access to it |
| Remove vendor-default settings everywhere | No default passwords, default accounts, or default configurations on any firewall, server, or point-of-sale terminal |
A tightly scoped network here does more than satisfy an assessor. It shrinks how much of your infrastructure the rest of this checklist even applies to, which shrinks the audit itself.
Protect Cardholder Data (Requirements 3-4)
| Do this | What it means |
|---|---|
| Protect 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 |
| Encrypt cardholder data in transit | Strong, current protocols (TLS 1.2 or higher) across any open or public network, never legacy SSL or early TLS |
Encryption and tokenization solve different problems, and it's worth keeping them distinct on your checklist. Encryption protects data that still needs to be recoverable. Tokenization replaces the real card number with a substitute that's useless outside the system that issued it.
Maintain a Vulnerability Management Program (Requirements 5-6)
| Do this | What it means |
|---|---|
| Protect systems against malware | Anti-malware deployed on every applicable system, kept current, and actively logging what it catches |
| Develop and maintain secure systems and software | A defined patch-management cadence plus secure coding practices for anything built in-house |
Requirement 5 is old by PCI DSS standards and still one of the most commonly under-maintained, which is exactly why it's worth its own callout below.
Implement Strong Access Control Measures (Requirements 7-9)
| Do this | What it means |
|---|---|
| Restrict access by need-to-know | Role-based access with documented privilege levels that match what a person's job actually requires |
| Identify and authenticate every user | Unique IDs, no shared credentials, and multi-factor authentication, expanded under 4.0 beyond remote access alone |
| Restrict physical access | Locked facilities, visitor logging, and secure destruction of any media that held cardholder data |
If your MFA rollout only covers VPN or remote access, that satisfied an older version's scope, not the current one. 4.0.1 expects it across a broader slice of access into the cardholder data environment.
Regularly Monitor and Test Networks (Requirements 10-11)
| Do this | What it means |
|---|---|
| Log and monitor all access | Audit trails covering the cardholder data environment, retained long enough to actually investigate an incident |
| Test security systems and processes regularly | Quarterly external scans by an Approved Scanning Vendor, internal scans, and periodic penetration testing, each on its own cadence |
Requirement 11 is also where 4.0.1 added real new weight: tighter guidance on monitoring scripts running on payment pages, closing a gap card-skimming attacks have exploited.
Maintain an Information Security Policy (Requirement 12)
| Do this | What it means |
|---|---|
| Maintain a written information security policy | Annual review, documented risk assessments, staff security training, and a tested incident response plan |
Every other item on this checklist eventually traces back to this one. It's the requirement that makes the rest auditable rather than assumed.
PCI Compliance Steps — How to Work Through This Checklist
The real pci compliance steps aren't just the 12 requirements in isolation. They're a sequence:
- Determine your merchant level and SAQ type. This decides which validation path you're working toward before you start gathering evidence.
- Scope your cardholder data environment. Know exactly which systems store, process, or transmit card data, and which ones don't.
- Work through the 12 requirements above. Gather evidence for each one as you go, not after the fact.
- Run the required scans and tests. Quarterly ASV scans, and annual penetration testing at minimum.
- Complete your SAQ, or engage a QSA for a full Report on Compliance. Which one depends on your level, covered below.
- File the Attestation of Compliance. The formal sign-off that closes out the cycle, until it's time to run the whole thing again.
The same sequence, as a quick visual reference:
Most checklist-style pages list the 12 items without ever sequencing the process around them. The sequence matters as much as the list itself.
The PCI Compliance Questionnaire (SAQ) — Types Explained
The pci compliance questionnaire isn't one form. Which SAQ type applies depends on how your business actually touches cardholder data, not just its size.
| SAQ type | Who it's for |
|---|---|
| SAQ A | Card-not-present merchants that fully outsource all cardholder data handling to validated third parties, with no data touching your own systems |
| SAQ A-EP | E-commerce merchants that partially outsource payment processing, but whose website can still affect the security of the transaction |
| SAQ B | Merchants using only imprint machines or standalone, dial-out payment terminals with no electronic cardholder data storage |
| SAQ B-IP | Merchants using standalone, PTS-approved terminals connected via IP, with no electronic storage |
| SAQ C | Merchants with payment application systems connected to the internet, with no electronic cardholder data storage |
| SAQ C-VT | Merchants that manually key in transactions through an isolated virtual terminal, with no electronic storage |
| SAQ D (merchants) | Every merchant that doesn't fit one of the categories above, including anyone storing cardholder data directly |
| SAQ D (service providers) | All service providers eligible to self-assess rather than undergo a full QSA-led assessment |
Each SAQ type has specific eligibility conditions attached to it. If your business doesn't cleanly meet every condition for a shorter SAQ, the correct move is the next, more comprehensive one, not a best guess at the shorter form. P2PE-validated point-of-sale solutions carry their own dedicated SAQ as well, worth checking with your provider if that's how you process cards today.
PCI DSS Compliance Levels
| Level | Annual transaction volume | Validation path |
|---|---|---|
| Level 1 | Over 6 million | Full, independent audit by a Qualified Security Assessor (Report on Compliance) |
| Level 2 | 1 to 6 million | Self-Assessment Questionnaire |
| Level 3 | 20,000 to 1 million, and all e-commerce merchants | Self-Assessment Questionnaire |
| Level 4 | Under 20,000 | Self-Assessment Questionnaire |
These thresholds aren't identical across every card brand. Visa, for instance, works from three merchant levels rather than four, and exact volume cutoffs can vary by brand. Check with your acquiring bank or payment processor for the specific thresholds that apply to your business.
The 12 requirements themselves don't change by level. Only the validation path does. A full breakdown of how levels are assigned and what triggers a jump between them is its own topic ComplyJet is still building a dedicated guide for. This section deliberately stays at the "which path applies" depth rather than duplicating that guide's job.
Your PCI Audit Checklist — Preparing for the Assessment
A pci audit checklist is distinct from the 12-requirement checklist above. It's what gets you ready for the assessment itself, once the underlying controls are in place.
- Engage a QSA or ISA early, not the week before your validation window opens.
- Schedule ASV scans well ahead of the assessment, so there's time to remediate anything a scan flags.
- Assemble evidence per requirement as you go, not retroactively, so nothing gets reconstructed from memory.
- Confirm your SAQ type or ROC scope in writing with whoever is validating you, before the assessment starts, not during it.
- Review documentation gaps specifically, since incomplete paperwork is a more common delay than a missing technical control.
- Line up compensating controls in advance if something can't be fixed before the window closes. A documented compensating control, reviewed and approved by your assessor, can cover a genuine gap that can't be remediated in time. Discovering this option exists mid-assessment, instead of ahead of it, wastes time you don't have.
Of everything on that list, one pattern shows up more than the rest:
Common PCI Checklist Mistakes to Avoid
- Scoping the cardholder data environment too loosely. Every system left in scope that doesn't actually need to touch cardholder data is one more system every item on this checklist applies to.
- Treating the checklist as a one-time exercise. Controls drift. A checklist run once, right before an assessment, misses exactly the drift it exists to catch.
- Picking the wrong SAQ type. Guessing at the shorter, easier form instead of confirming eligibility against the actual criteria creates a gap that surfaces later, not now.
- Skipping the annual policy review. Requirement 12 expects the policy actively maintained, not filed away after it's first written.
- Letting quarterly ASV scans slip. Compressing testing into the week before validation tends to miss exactly the issues it exists to catch.
- Under-documenting evidence retention. Logs that exist but were never reviewed, or retained for less time than the requirement expects, satisfy the letter of the item and miss the point.
- Confusing "compliant" with "certified." Most merchant levels validate through self-assessment or a Report on Compliance, not a certificate. Know which term actually applies to your situation before you use it in a customer conversation.
How ComplyJet Helps With PCI DSS Compliance
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. Working through this checklist in practice means ongoing evidence collection, not a once-a-year document push, and that's what ComplyJet's guided support is built around: mapping each requirement to the controls in your actual environment, tracking them continuously, and getting you ready for whichever validation path your level requires.
That matters most for a small team without a dedicated security hire, where a checklist like this one would otherwise compete with everything else on someone's plate.
FAQs
What is a PCI DSS compliance checklist?
A PCI DSS compliance checklist breaks the standard's 12 requirements into concrete action items you can work through and verify, one at a time, before completing your SAQ or Report on Compliance. It covers the same ground as the requirements themselves, formatted to actually be used rather than just read.
What are the 12 items on a PCI DSS compliance checklist?
Network security controls, no vendor defaults, protecting stored cardholder data, encrypting data in transit, anti-malware, secure systems and software, restricted access, unique authenticated user IDs, physical access controls, logging and monitoring, regular security testing, and a maintained information security policy.
What's the difference between this checklist and the PCI DSS compliance requirements?
The requirements guide explains what each of the 12 requirements means and why it exists, in real sub-control depth. This checklist takes the same 12 items and formats them as something to actually work through in order.
What PCI DSS version should this checklist follow?
Version 4.0.1, released June 2024. It's the current, sole active version of the standard. Version 3.2.1 was retired March 31, 2024, and 4.0.1 itself is a clarifying update to version 4.0, not a new requirement set.
How many PCI DSS compliance levels are there?
Four, based on annual transaction volume, though exact thresholds vary somewhat by card brand. The 12 requirements stay the same at every level. Only the validation path changes, from a full QSA-led audit at Level 1 to a Self-Assessment Questionnaire at Levels 2 through 4.
How do I complete a PCI DSS Self-Assessment Questionnaire (SAQ)?
Start by confirming which SAQ type you're actually eligible for based on how your business handles cardholder data, not just its size. Work through the questionnaire's specific control questions, gather the supporting evidence for each answer, and sign the Attestation of Compliance once it's complete.
Is there a downloadable PCI DSS compliance checklist PDF or Excel version?
The PCI Security Standards Council publishes an official "Prioritized Approach Tool" as a spreadsheet, though it's currently still on the v3.2.1 edition. This article is built as a scannable, checklist-formatted page for the same purpose, kept current to the standard's actual version.
Related Reading
- PCI DSS Compliance: What It Is, Who Needs It, and How It Works, the broad overview this checklist deliberately doesn't re-cover.
- PCI DSS Compliance Requirements: All 12, Explained, the full explanation behind any item on this checklist.





