PCI DSS Compliance Checklist (Free Excel, 2026)

What the PCI DSS v4.0.1 Requirements Checklist covers

The file is a single Excel workbook with 70 rows, grouped under the 12 requirements of PCI DSS v4.0.1. Those 12 requirements sit under 6 security goals: building and maintaining a secure network, protecting stored account data, running a vulnerability management program, enforcing strong access control, monitoring and testing systems, and keeping an information security policy that ties it together.

Each row gives you:

• Requirement reference so every item maps back to the official numbering.
• Control description in plain language, not standard-speak.
• Status (not started, in progress, met, or not applicable) so you can measure readiness at a glance.
• Evidence and owner columns to record who is accountable and where the proof lives.
• Notes for scoping decisions, compensating controls, and assessor questions.

The items that became mandatory in March 2025 are flagged so they do not slip through as "future" work. That flag alone is the reason to retire an older checklist.

PCI DSS the honest way: what actually matters

PCI DSS v4.0.1 is 12 requirements across 6 goals, and the hardest part is almost never the individual controls. It is scope. The requirements apply to every system, process, and third party that stores, processes, or transmits cardholder data. Define that boundary too widely and you drown in work; define it too narrowly and your assessment fails. Settle scope before you touch a single control.

How you validate depends on how you handle card data. Merchants confirm compliance through a Self-Assessment Questionnaire, and the SAQ type follows your setup: fully outsourced e-commerce sellers often use SAQ A, while organisations that store or process card data directly move up toward SAQ D. Higher-volume merchants validate through a Report on Compliance instead. Choosing the wrong route changes which requirements apply, so decide early. If you are unsure, our guide on who must comply and which SAQ applies walks through the common scenarios.

Two operational facts catch teams out. First, the controls future-dated in v4.0 became mandatory in March 2025, so anything you once parked as "later" now counts against you. Second, many merchants must run quarterly external vulnerability scans by an Approved Scanning Vendor (ASV).

Be clear on one boundary: no GRC or compliance-automation platform is an ASV or a QSA. The quarterly scan and the formal assessment are separate contracts with accredited providers. Any software, including ours, helps you organise requirements and evidence; it does not scan your perimeter for PCI purposes and it does not sign your assessment. Treat any vendor who blurs that line with suspicion.

How to use the PCI DSS v4.0.1 Requirements Checklist

1. Fix your scope first. List every system, process, and third party that touches cardholder data. Only what is in scope needs to be assessed.
2. Confirm your validation route. Work out which SAQ applies, or whether your volume requires a Report on Compliance, before you start marking items.
3. Assign an owner to each of the 70 items. An item without a name attached does not get done.
4. Attach evidence, not opinions. Record the config export, policy link, or ticket that proves each control operates, in the evidence column.
5. Check the March 2025 controls are live. Confirm they are actually operating, not just planned, then set your status honestly.
6. Book your ASV scan separately and review the checklist monthly, so nothing drifts between now and your assessment date.

Do this automatically in Venvera

A spreadsheet is a good starting point, but it goes stale the moment you close it. In Venvera, the same 70 items live on the PCI DSS framework as continuously tracked controls: owners, due dates, and evidence stay attached, status updates as your environment changes, and one piece of evidence can satisfy the equivalent control in other frameworks you run, so you are not re-collecting the same proof for every audit. Plans start from EUR 399/month, and you can weigh the options on our PCI DSS compliance software page. The caveat still holds: Venvera keeps your program organised and audit-ready, but your ASV scan and QSA assessment remain separate, accredited engagements.

Frequently Asked Questions

Is a PCI DSS compliance checklist enough to make us compliant?

No. A checklist organises the work and builds your evidence trail, but validation still runs through a Self-Assessment Questionnaire or a Report on Compliance, and many merchants also need quarterly external scans by an Approved Scanning Vendor. No GRC or compliance-automation platform is an ASV or a QSA, so scanning and formal assessment are separate contracts. The checklist gets you ready; it does not sign you off.

Which SAQ should we use?

It depends on how you handle card data. Fully outsourced e-commerce merchants often use SAQ A, while organisations that store or process card data directly move up toward SAQ D. Getting this wrong changes which of the 12 requirements apply to you, so confirm it early. Our guide on who must comply and which SAQ applies covers the common merchant setups.

What changed in PCI DSS v4.0.1 for 2025?

v4.0.1 keeps the same 12 requirements across 6 security goals. The change that matters is timing: a set of controls that were future-dated in v4.0 became mandatory in March 2025. If your last review treated them as optional, they now count, which is why this checklist flags them explicitly.

Do we still need external scans if we use compliance software?

Yes, if your validation type calls for them. Quarterly external vulnerability scans by an Approved Scanning Vendor are required for many merchants, and that is a distinct service from any compliance platform. Software helps you track requirements and reuse evidence; it does not replace an ASV scan or a QSA assessment.