Skip the reading? Connect your stack and get a readiness score today. Plans from $79 a month, prices published.
A PCI DSS compliance checklist has two halves, and almost everyone starts with the wrong one. First you determine scope and pick the right Self-Assessment Questionnaire, because that decides how many of the 12 requirements you actually answer. Then you work the requirements that apply, collect evidence, and complete an annual SAQ and attestation of compliance. The current version is PCI DSS v4.0.1, after the Council retired v4.0 on December 31, 2024 and the future-dated requirements became mandatory on March 31, 2025.
The reason order matters is money. A SaaS company that runs payments through a hosted Stripe page and a company that stores card numbers in its own database are both "PCI compliant" when they are done, but one of them answered a short questionnaire about its payment page and its vendors, and the other spent a year on network segmentation and quarterly scanning. Same standard, wildly different projects. If you print the 12 requirements and start at the top, you will do work nobody was going to ask you for.
What is required for PCI DSS compliance?
PCI DSS applies to any organization that stores, processes, or transmits cardholder data, and it is enforced by your acquiring bank or payment processor under your merchant agreement rather than by a government regulator. That distinction shapes everything: your acquirer decides what validation they will accept from you, so they are the authority to ask when the answer is ambiguous.
The obligations come down to four things. Know your scope, which means knowing every system that touches card data and every third party you have outsourced it to. Meet the requirements that apply to that scope. Keep evidence that the controls actually operate, not just that they exist. Then validate annually, either with a Self-Assessment Questionnaire and an attestation of compliance, or, at higher transaction volumes, with a Report on Compliance signed by a Qualified Security Assessor.
Your merchant level determines which of those two routes you are on. Levels are set by the individual card brands rather than by the PCI Security Standards Council, and the thresholds differ between Visa, Mastercard, American Express, and Discover, so there is no single table that answers it for every business. Volume per brand is the main driver, and a previous breach can move you up a level. Ask your acquirer which level they have you at instead of guessing from a blog post.
Which PCI DSS SAQ do you need?
This is the highest-leverage question on the whole checklist. The SAQ you are eligible for is determined by how card data flows through your business, not by your headcount or revenue. Confirm your choice with your acquirer before you start filling anything in.
| SAQ | Who it is for | Typical situation |
|---|---|---|
| SAQ A | Card-not-present merchants who have fully outsourced all account data handling to a compliant third-party provider | E-commerce or mail order using a hosted payment page or iframe, where card data never reaches your servers |
| SAQ A-EP | E-commerce merchants whose site does not receive account data but does control how the customer is redirected to the processor | Your own checkout page posts directly to the processor, or you script the redirect yourself |
| SAQ B | Merchants using imprint machines or standalone dial-out terminals | A small retailer with a phone-line card terminal and no e-commerce |
| SAQ B-IP | Merchants using standalone PCI-approved point-of-interaction devices with an IP connection, not connected to other devices in the same network zone | An IP terminal on its own isolated network segment |
| SAQ C | Merchants with a payment application connected to the internet, on a system that is not shared with other systems | A point-of-sale application on a dedicated machine with an internet connection |
| SAQ C-VT | Merchants who key transactions into a web-based virtual terminal on a standalone computer | Back-office staff typing card numbers into a processor's web portal |
| SAQ P2PE | Merchants using a validated PCI-listed point-to-point encryption solution, where the only systems touching account data are those terminals | Retail using a validated P2PE terminal fleet |
| SAQ D for Merchants | Merchants eligible to self-assess who do not fit any other SAQ | You store card data yourself, or your environment spans several of the cases above |
| SAQ D for Service Providers | The only SAQ available to SAQ-eligible service providers | You process or store card data on behalf of your own customers |
The practical read: if you can honestly get to SAQ A, the architecture decision that keeps card data off your systems has just saved you more compliance work than any tool ever will. If you are on the fence between SAQ A and SAQ A-EP, the question is whether your page merely loads someone else's payment form or whether your code controls the redirect. That distinction is worth getting right, because A-EP is a substantially longer questionnaire.
The PCI DSS compliance checklist: the 12 requirements
These are the 12 requirements of PCI DSS v4.0.1, grouped as the standard groups them. How many of these you answer depends entirely on the SAQ you landed on above. A SAQ A merchant will find large parts of this table marked not applicable, and that is the correct outcome, not a shortcut.
| Req. | What it asks for | What auditors and acquirers actually look at |
|---|---|---|
| 1 | Install and maintain network security controls | Firewall and security group rules with a documented business justification, reviewed on a stated cadence |
| 2 | Apply secure configurations to all system components | Vendor defaults changed, hardening standards written down, and configuration drift caught |
| 3 | Protect stored account data | Whether you store it at all, retention and deletion schedules, and encryption or truncation where you do |
| 4 | Protect cardholder data with strong cryptography during transmission | TLS configuration on every path that carries card data, including internal hops |
| 5 | Protect all systems and networks from malicious software | Anti-malware coverage and update frequency, or a documented rationale where systems are not at risk |
| 6 | Develop and maintain secure systems and software | Patch timelines for critical vulnerabilities, secure development practice, and change control records |
| 7 | Restrict access to system components and cardholder data by business need to know | Role definitions, least privilege, and evidence that access reviews happened |
| 8 | Identify users and authenticate access to system components | Unique IDs, no shared accounts, and multi-factor authentication into the cardholder data environment |
| 9 | Restrict physical access to cardholder data | Facility controls and media handling, or your cloud provider's attestation where you have no data center |
| 10 | Log and monitor all access to system components and cardholder data | Logging switched on, retained, and reviewed, with proof that someone looks at it |
| 11 | Test security of systems and networks regularly | Quarterly external scans by an Approved Scanning Vendor, internal scans, and penetration testing |
| 12 | Support information security with organizational policies and programs | A maintained security policy, annual risk assessment, training, incident response, and a service provider list |
Requirement 6 is where a lot of engineering teams lose evidence rather than lose control. Change control is usually happening already, but it lives in pull requests and deploy logs that nobody has ever exported. It is far easier to answer at assessment time when your deployment pipeline keeps a durable record of what shipped, when, and who approved it, because that record is the evidence rather than a reconstruction of it.
What changed in PCI DSS v4.0.1?
Version 4.0.1 is a limited revision of 4.0 rather than a new standard, and the timeline is the part worth memorizing. PCI DSS v4.0 was retired on December 31, 2024, so v4.0.1 is the only active version. The requirements that had been future-dated, meaning best practice until a stated date, became mandatory on March 31, 2025. If your last assessment predates that, your checklist is out of date.
For e-commerce merchants the two that changed the most are both about the payment page. Requirement 6.4.3 wants every script on a payment page authorized, inventoried, and integrity checked, with a written justification for why each one is there. Requirement 11.6.1 wants a change and tamper detection mechanism that alerts someone when the payment page or its HTTP headers are modified. Both exist because of e-skimming attacks, where an attacker injects a script that quietly copies card numbers as customers type them.
Did the PCI SSC remove requirements from SAQ A?
Yes, and this is the detail most checklists on the internet still have wrong. After industry feedback, the PCI Security Standards Council removed Requirement 6.4.3, Requirement 11.6.1, and the Requirement 12.3.1 targeted risk analysis that supported 11.6.1 from SAQ A, effective March 31, 2025. In their place it added an eligibility criterion: the merchant confirms that its site is not susceptible to attacks from scripts that could affect its e-commerce systems.
The nuance matters. Those requirements were removed from the questionnaire, not from PCI DSS. If you validate on SAQ A-EP or SAQ D, 6.4.3 and 11.6.1 apply in full. And SAQ A merchants did not get a free pass either, because the new eligibility criterion is a statement you are making about your own site. If a third-party script on your checkout page could reach your payment flow, you have to deal with that before you can claim SAQ A eligibility at all.
How often do you have to do PCI compliance?
Continuously, with two visible checkpoints. The SAQ and attestation of compliance are annual. External vulnerability scans under Requirement 11 are quarterly and have to come from an Approved Scanning Vendor on the PCI SSC list, with any failing scan re-scanned until it passes. Several other items carry their own cadence: access reviews, policy reviews, risk assessment, and security awareness training are all at least annual, and log review is expected far more often than that.
The failure mode at small companies is almost never a technical control. It is that the annual cycle has no owner, so the SAQ gets remembered when an acquirer sends a chasing email, and a year of evidence has to be reconstructed from memory in a fortnight. A compliance calendar with named owners fixes more PCI problems than any scanner.
What compliance software can and cannot do for PCI
Software is genuinely useful for the tracking half of this: working out which SAQ applies, turning the applicable requirements into obligations with owners and dates, pulling evidence such as MFA enforcement and logging configuration from AWS or Okta on a schedule, and keeping the annual cycle visible. That is what PCI compliance software is for, and it is where most of the manual effort actually goes.
Be clear about the other half. No compliance platform is an Approved Scanning Vendor, so it cannot perform your quarterly external scans, and none of them is a Qualified Security Assessor, so none can sign a Report on Compliance. Any vendor blurring that line is describing a product that does not exist. Complies does not ship cardholder data discovery or network scanning, and it says so rather than implying coverage it does not have.
The other thing worth knowing before you buy: if SOC 2 is also on your roadmap, most of Requirements 7, 8, 10, 11, and 12 is the same evidence. Requirement 7 and 8 access control line up with SOC 2 CC6.1 and CC6.2, Requirement 10 logging with CC7.2, and Requirement 12 policy and vendor management with CC5.3 and CC9.2. A platform that cross-maps lets you satisfy a shared control once, which is why running SOC 2 and PCI DSS together costs far less than running them a year apart. It is also worth comparing what compliance software actually costs before you sit through a demo, because most vendors in this category will not publish a price.
Five mistakes worth avoiding
Scoping late. Teams pick a tool, import all 12 requirements, and discover in month three that they were SAQ A the whole time. Scope first, always.
Assuming your processor covers you. Stripe or Adyen being validated covers their environment. You still confirm your own eligibility, keep their attestation on file, maintain your policy, and attest annually.
Treating not applicable as a shortcut. Marking a requirement not applicable is a legitimate answer that needs a stated reason. Marking it not applicable because it was inconvenient is how an assessment falls apart.
Collecting evidence at the end. A screenshot taken the week before you attest proves the control existed that week. Evidence collected on a schedule proves it operated all year, which is what the requirement actually says.
Forgetting the service provider list. Requirement 12 expects you to maintain a list of the third parties in your payment flow and monitor their compliance status. That list is also the first thing an acquirer asks for when something goes wrong.
Work the checklist in that order, scope then requirements then evidence then attestation, and PCI stops being the vague dread it usually is and becomes a short list of dated tasks with names on them.
RUN IT, NOT JUST READ IT
Turn this into tracked rows with owners
Everything in this guide becomes obligations, controls, and evidence with owners and due dates inside Complies, with a live readiness score on top. Plans from $79 a month, prices published.