Most PCI checklists are the twelve requirements retyped with tick boxes next to them. You can tick every box on one of those and still fail, because the assessor is not asking whether you did it. They are asking you to prove it.
A PCI compliance checklist is only worth the paper it is on if it is organized the way an assessment actually runs. This article sets out that order: scope first, evidence second, requirements third. It also covers the five items that fail most often, and the one deadline inside your evidence that nobody plans for.
- Scope is not the first item on the list. It is the thing that decides what the rest of the list says.
- All 51 future-dated requirements of PCI DSS v4.x stopped being best practice on 31 March 2025. There is no grace period left.
- A QSA samples. The question is never “do you have a policy”, it is “show me these nine systems”.
- Evidence has a shelf life. Start collecting three months before the assessment and you will be short of the twelve-month history for half of it.
- The customized approach is not a shortcut. It is more work, and it is unavailable if you validate with an SAQ.
Why most PCI compliance checklists fail
They are written from the standard instead of from the assessment. The standard is a list of controls. An assessment is a conversation in which somebody asks you for artifacts, picks a sample, and checks whether the artifacts match reality.
So a checklist that says “implement MFA for all access into the CDE” is accurate and useless. The one that survives says this instead. List every path into the cardholder data environment, name the MFA mechanism on each, and produce an authentication log for three named accounts over the sampling period. That is the actual unit of work.
Start with scope, because everything else is downstream
Scope is the single biggest variable in cost, effort and outcome. Get it wrong and every other line of the checklist is answering the wrong question.
- 1 Find the data. Not where you think it is. Where it actually is, including the places it was never meant to be: support tickets, call recordings, log files, test databases, a spreadsheet on somebody’s desktop.
- 2 Draw the flows. Every path account data takes from capture to deletion, with the systems it touches on the way.
- 3 Mark connected systems. Anything that can reach the cardholder data environment, or that affects its security, is in scope. Directory services, jump hosts, monitoring agents, backup infrastructure.
- 4 Prove the segmentation. If you say a network is out of scope, you need a test that shows it, not a diagram that claims it.
- 5 Write the scope down and date it. Scope is confirmed at least every 12 months, and the confirmation is itself an artifact.
The fastest way to shrink a PCI project is to take data out of scope rather than to secure more of it. Tokenization and redirecting the payment page both do this. Neither is free, and both are cheaper than assessing a flat network.
The twelve requirements, and what the assessor asks for
Here is the list in the order the standard numbers them, with the artifact that actually gets requested next to each.
- 1. Network security controls. Current ruleset exports, the business justification for each allowed service, and evidence the ruleset was reviewed in the last six months.
- 2. Secure configurations. Your hardening standard, and three systems picked by the assessor compared against it. Vendor defaults are the classic finding here.
- 3. Protect stored account data. Where it is stored, how it is rendered unreadable, the key inventory, and proof that sensitive authentication data is not retained after authorization.
- 4. Protect data in transit. TLS configuration on every public-facing endpoint, and the inventory of trusted keys and certificates.
- 5. Malicious software. Coverage reports, not license counts. Which systems are protected, which are deemed not at risk, and the periodic evaluation behind that decision.
- 6. Secure systems and software. Patch records with dates, the secure development process, and for e-commerce the payment page script inventory and authorization under 6.4.3.
- 7. Restrict access by need to know. The access model, and a sample of accounts with the approval record for each.
- 8. Identify and authenticate. Unique IDs, no shared accounts, and MFA on every access into the CDE under 8.4.2, which is the one that catches people out.
- 9. Physical access. Visitor logs, media handling, device inspection records for point-of-interaction terminals.
- 10. Log and monitor. Twelve months of log retention with three months immediately available, plus the automated review mechanism under 10.4.1.1.
- 11. Test security regularly. Four passing quarterly ASV scans, internal scans, the penetration test, and the segmentation test.
- 12. Policies and programs. The information security policy, the risk analyzes under 12.3.1, training records, and the incident response plan with evidence it was tested.
The five items that fail most often
These are not the hard requirements. They are the ones that get missed because they look administrative, so they drop off a PCI compliance checklist written from the standard.
- 1 Targeted risk analyzes (12.3.1). Every control where you choose the frequency needs a documented analysis justifying that frequency. Most organizations have the control and not the analysis.
- 2 MFA into the CDE (8.4.2). People implement it for remote and administrative access, then discover that console access from inside the office also counts.
- 3 Payment page scripts (6.4.3 and 11.6.1). An inventory with a written justification per script, plus tamper detection on the page. Marketing tags are usually the gap.
- 4 Four passing ASV scans. Not four scans. Four passing ones, spread across the year, from a listed vendor. A failed scan in Q2 that was never rescanned clean is a finding in Q4.
- 5 Testing the incident response plan. Requirement 12.10 asks for a plan that has been exercised. A document nobody has rehearsed fails on the evidence, not on the content.
Evidence has a date, and that is the trap
No PCI compliance checklist warns you about this one, and it turns a comfortable project into a scramble. A good deal of the evidence an assessor needs is historical, so it cannot be produced retrospectively.
You cannot generate last quarter’s passing ASV scan in the week before the assessment. You cannot produce six months of firewall review records from a review you never ran.
Quarterly items need four instances. Six-monthly items need two. Annual items need one that falls inside the period. Count backwards from your assessment date and you will usually find that the real start date for the project was nine to twelve months earlier. If that date has passed, the honest move is to pick a later assessment date rather than to arrive short.
The customized approach, and when not to use it
PCI DSS v4 lets you meet the objective of a requirement by a different means than the one written down. That is the customized approach, and it is frequently misunderstood as a way around a control you do not want to implement.
It is the opposite. It requires you to document the objective, design the control, perform a targeted risk analysis, and then produce evidence that your alternative meets the objective at least as well. Your assessor has to derive and execute the testing for it. In practice it is more work than the defined approach, and it earns its place only where a defined requirement genuinely does not fit your architecture.
Two limits worth knowing before you plan around it. Some requirements are not eligible for it at all. And if you validate with a self-assessment questionnaire rather than a full assessment, it is not available to you.
What a checklist cannot tell you
A PCI compliance checklist cannot tell you which validation path you are on. That is set by your level and your acquirer, and it changes how much of the above you actually have to document. A merchant filing a short questionnaire and a merchant producing a Report on Compliance are doing very different amounts of work against the same twelve requirements.
So before you work through any PCI compliance checklist, settle two things: which merchant level you are and who decided it, and which questionnaire you qualify for. Both answers come from outside the standard, and both change the size of the job.
Where we fit
The quarterly external scan under Requirement 11.3.2 can only be attested by an Approved Scanning Vendor listed with the Council. Nordstern holds that listing with global scope, certificate 50955001-01. The scan has its own pass criteria, and failing it is the most common way a quarter gets lost.
For the rest of it, the work that pays off is the scoping exercise at the start and the evidence calendar that follows. That is what our PCI DSS consulting work is built around, inside the wider PCI DSS practice. The scanning cadence behind Requirement 11 sits with vulnerability and exposure management. Talk to the team if you want the scope settled before the clock starts.
Sources
- PCI Security Standards Council, document library: PCI DSS v4.0.1, published 11 June 2024, and the Summary of Changes.
- PCI Security Standards Council, guidance for the e-commerce requirements effective after 31 March 2025.
