A working PCI DSS compliance checklist runs in five phases, in this order: confirm the cardholder data environment scope, fix your validation route with the acquirer, implement and evidence the twelve requirements, complete the scanning and testing cycle, then assemble the report and sign the attestation. Phases two through five all depend on phase one being right, which is why scope is the item teams most often get wrong and the item an assessor challenges first.
The current version is PCI DSS v4.0.1, and the future-dated v4.0 requirements became mandatory on 31 March 2025. If your last assessment predates that, the checklist below is not a refresh — it is a new programme with a different evidence burden.
What follows is sequenced so you can work down it. Each item names what you produce, who owns it, and what an assessor will ask for.
What a PCI DSS Compliance Checklist Has to Cover
A PCI DSS compliance checklist has to cover three kinds of work, and most published checklists only cover one. Scoping work, which is architectural. Control implementation across the requirements, which is engineering and policy. And validation work — scans, tests, documentation, attestation — which is project management with a deadline attached.
Flat 12-bullet checklists skip the first and third. They hand you "encrypt cardholder data" as a line item and leave you to discover six weeks later that nobody agreed which systems were in scope, so the encryption work covered the wrong half of the estate.
The PCI DSS organises its 12 requirements under 6 control objectives. Those requirements are the middle of the programme, not the whole of it.
The Five Phases at a Glance
The five phases below each have a single owner and a single output, and nothing in a later phase is worth starting until the earlier one has produced its artefact.
| Phase | Output | Typical owner |
|---|---|---|
| 1. Scope confirmation | Data-flow diagrams, network diagrams, a signed scope statement listing in-scope systems | Security lead with an engineering owner per system |
| 2. Validation route | Written confirmation of SAQ type or ROC from your acquirer or card brand | Finance or payments owner, with the security lead |
| 3. Control implementation | Control-by-control status against all twelve requirements, with owners and gaps | Engineering leads per requirement |
| 4. Scanning and testing | ASV scan reports, internal scan results, penetration test report, remediation records | Security engineering |
| 5. Assessment and attestation | Completed SAQ or ROC plus a signed Attestation of Compliance | Executive sponsor signs; security lead assembles |
Give every row a named person. "Security" is not an owner, and an assessor who asks who owns Requirement 10 will not accept a team name.
Phase One: Confirm the Cardholder Data Environment Scope
Cardholder data environment scope is the first and highest-leverage item on the checklist. The cardholder data environment — the CDE — is every system that stores, processes or transmits account data, plus connected systems and systems that could impact the security of the CDE. That third category is the one that catches people: a jump host, a directory service, a monitoring agent or a CI runner with reach into the CDE is in scope even though no card data ever touches it.
Work these items in order:
- Inventory every payment flow. Card-present, e-commerce, phone orders, refunds, recurring billing, chargeback handling. For each, document where account data enters, goes and stops. Output: one data-flow diagram per flow. The assessor will compare these to what they see in the network.
- Produce a current network diagram showing CDE boundaries, segmentation points and every connection crossing them. Output: a dated diagram with the segmentation controls marked. Owner: network or platform engineering.
- List connected and security-impacting systems explicitly, with a one-line reason each is in scope. Output: a scope register — the document that prevents an argument in week 10.
- Find the account data nobody declared. Search logs, backups, support-ticket attachments, analytics pipelines, email archives and developer laptops. Output: a discovery report plus a remediation ticket per hit. Undeclared storage is the most common source of a late finding.
- Sign the scope statement. Output: a scope document someone senior has accepted. An annual scope confirmation is expected, so date it and diarise the next one.
Phase 1 is also where the biggest cost decisions get made, because every system you legitimately remove from scope disappears from phases 3, 4 and 5. Tokenisation, a hosted payment page, and segmentation that is actually enforced are the 3 levers worth evaluating before you implement a single control — see reducing PCI DSS scope for how far each one goes.
Not sure your CDE scope would survive an assessor's first question?
Share your work email and we'll walk your payment flows against the scoping rules and mark the connected and security-impacting systems that are usually missed.
Phase Two: Fix the Validation Route Before You Build Anything
Your validation route determines how much evidence you need, so fix it before you build anything. Validation produces either a Self-Assessment Questionnaire or a Report on Compliance completed with a Qualified Security Assessor, and each is accompanied by an Attestation of Compliance. You do not choose between them unilaterally — the acquirer or the card brand decides which applies to you.
- Ask your acquirer, in writing, what they require. Output: an email or portal record naming the SAQ type or confirming a ROC is expected. Owner: whoever holds the merchant or processor relationship. Do this in week 1; the answer changes the plan.
- Confirm which SAQ applies if you are self-assessing. The SAQ types differ sharply in length and in which requirements they invoke; picking the wrong one wastes months. The SAQ types and what each covers walks the distinctions, and merchant and service provider levels explains what drives the acquirer's answer.
- Engage a QSA early if a ROC is in play. Output: a signed engagement with agreed timelines for the readiness review and the assessment itself. QSA calendars are the usual constraint on an annual cycle.
- Record the applicable requirement set. Output: a note stating which of the 12 requirements apply, which do not, and why. Not-applicable determinations need a reason the assessor can test.
Phase Three: Work the Twelve Requirements as a Control Checklist
The twelve requirements are the control checklist proper, and the discipline that makes this phase tractable is one named owner and one evidence artefact per requirement. Refer to them by number — Requirements 1 through 12 — and keep a single status table that engineering updates, rather than a slide that security maintains separately.
Two items in this phase carry more risk than the rest, so handle them first:
- Sensitive authentication data must not be stored after authorisation. Verification and verification-code data, full track data, and PINs have no post-authorisation storage case. Output: evidence that your systems, logs and third-party integrations do not retain them, plus the search that proves it. This is the finding that most often stops an assessment outright.
- Stored primary account numbers must be rendered unreadable. Output: a record of the method in use everywhere a PAN is stored, including backups and non-production copies, with key management documented. Owner: platform engineering.
The rest run across network security controls, secure configuration, encryption in transit, anti-malware, secure development, access control, authentication, physical access, logging and monitoring, security testing, and the governing information security policy. The twelve PCI DSS requirements explained covers each in turn.
Your status table needs four columns an assessor can read: requirement number, named owner, the control as actually implemented, and the evidence artefact with a date. Anything with no dated artefact is a gap, whatever the policy says. If your v4 work is still in progress, what changed in PCI DSS v4 confirms which items are new since your last cycle.
Free workbook
The PCI DSS Scope & Evidence Workbook
The status table described above, already built: a worked scope decision across fourteen systems including the connected-to ones teams miss, an SAQ selection guide, and an evidence row for every one of the twelve requirements with the named artefact, owning role and cadence. Enter your work email and we'll send it.
Phase Four: Build the Scanning and Testing Record
The scanning and testing record is a cadence, not a task, and it is the phase most likely to delay an attestation because missing quarters cannot be manufactured retrospectively.
- Quarterly external vulnerability scans by an Approved Scanning Vendor, where your SAQ or ROC calls for them. Output: 4 passing ASV scan reports covering the assessment period, plus rescans showing remediation. Start the cadence early — a programme that begins scanning in month 10 has no quarterly history to show.
- Internal vulnerability scanning on its own schedule, with results and remediation tracked. Output: scan reports and closed tickets. Owner: security engineering.
- Penetration testing at least annually and after any significant change. Output: a scoped test report covering the CDE boundary and segmentation, with retest evidence. Define "significant change" in writing so the trigger is auditable rather than a judgement made after the fact.
- Segmentation testing where you rely on segmentation to keep systems out of scope. Output: evidence that the boundary holds. If it fails, your phase-1 scope was wrong and phases 3 onward need revisiting.
Book the penetration test after remediating the scan findings, not before, or you pay for a report that documents issues you already knew about.
Phase Five: PCI DSS Audit Preparation and Attestation of Compliance
PCI DSS audit preparation is assembly, not discovery. If you reach this phase and are still finding out what your controls do, the earlier phases were not finished.
- Assemble the evidence pack against the applicable requirement set: policies with review dates, configuration standards, access reviews, logs and log-review records, training records, service-provider documentation, scan and test reports. Output: an indexed pack mapped requirement by requirement.
- Complete the SAQ or support the ROC. Output: the completed questionnaire, or the QSA's report with your responses to every information request. Expect sampling — a control picked at random and three instances requested across the period, not one.
- Resolve findings and document compensating controls where a requirement cannot be met as written. Output: a documented rationale and the compensating control itself, tested.
- Sign the Attestation of Compliance. Output: an executed AOC alongside the SAQ or ROC, submitted to whoever asked for it. The attestation is a statement by your organisation, so the signatory should have seen the evidence, not just the summary.
Teams comparing this with a SOC 2 programme often assume the evidence overlaps cleanly; PCI DSS versus SOC 2 sets out where it does and does not.
Where This Checklist Usually Breaks Down
This checklist breaks down in 4 recognisable ways, and each one traces back to an earlier phase that was signed off too quickly.
- Scope settled by assumption. Nobody ran the discovery search, so account data in logs or a support queue surfaces during the assessment.
- Evidence generated at the end. Access reviews backdated into a spreadsheet, log reviews with no record, training with no completion data. Sampling across the period finds this immediately.
- Scanning started late. Quarterly means four quarters. There is no way to recover a missed one.
- Policies that describe a different company. Templates inherited and never reviewed, describing controls the team does not operate. Policy diverging from practice is a finding in its own right.
Running the Checklist Every Year, Not Once
Running the checklist every year is the normal state, not an exception, because PCI DSS operates as an annual compliance cycle: scope confirmation, evidence refresh, scanning cadence, testing, then attestation. Year 2 is cheaper than year 1 only if the evidence kept accumulating in between.
Build the cycle into the calendar rather than the project plan. Scope confirmation at a fixed point each year. Scans booked for all 4 quarters at once. Penetration testing scheduled annually with an additional trigger written into your change process. Access reviews and log reviews on a cadence that produces a dated record each time.
The authoritative source for the standard, the SAQ documents and the AOC templates is the PCI Security Standards Council at pcisecuritystandards.org. Pull the documents from there rather than from a consultancy summary, and check the version before you start.
PCI DSS Checklist Questions Teams Ask
These 5 PCI DSS checklist questions are the ones teams ask most often once they start sequencing the work rather than reading a flat list of 12 requirements.
Scope, before anything else. The cardholder data environment is every system that stores, processes or transmits account data plus connected and security-impacting systems, and until that boundary is documented and signed off you cannot size the control work, choose a validation route or scope a penetration test. Scoping is the step that most often goes wrong, and an annual scope confirmation is expected, so treat it as a recurring artefact.
Your acquirer or the card brand decides, so ask them in writing before planning the programme. A Self-Assessment Questionnaire is completed by you; a Report on Compliance is completed with a Qualified Security Assessor. Both are accompanied by an Attestation of Compliance. The two routes differ substantially in evidence burden and timeline, which is why confirming the route early is worth more than any amount of early control work.
Less than the full standard, usually, but never none of it. A processor or hosted payment page can move most account data outside your systems and shorten the applicable requirement set, which is reflected in the SAQ your acquirer specifies. What remains is still yours: the systems that connect to the payment flow, the people with access, your policies, and evidence that the integration works as you claim.
Sensitive authentication data must not be stored after authorisation at all — encryption creates no exception for verification codes, full track data or PINs. The primary account number may be stored where there is a documented business need, and must be rendered unreadable wherever it is stored. Backups, non-production environments and log pipelines count as storage, and they are where undeclared copies turn up.
It depends almost entirely on phases 1 and 4. A narrow scope with a short SAQ can move quickly; a broad CDE needing a ROC will not. The hard constraint is the scanning cadence, because quarterly external scanning where it applies cannot be compressed. Starting the scan cadence and the penetration test scheduling in month 1 is the most effective way to avoid a delayed attestation.
Keep a PCI DSS checklist current between assessments
Book a demo and we'll show how Konfirmity holds scope, control ownership, scan cadence and evidence in one place so the annual cycle starts from a live record rather than a rebuild.
Book a demo
Start With Scope, Finish With the Attestation
Starting with scope and finishing with the attestation is what makes this checklist usable across all 5 phases. Confirm scope and get it signed. Fix the validation route with your acquirer. Assign every requirement an owner and an evidence artefact. Start the scanning and testing cadence in month 1, not month 10. Then assemble, assess and attest.
Teams that work the phases in sequence spend their effort on controls. Teams that start with the 12 requirements spend it on rework, because a scope change invalidates control decisions already made and evidence already gathered.
If you do one thing on Monday, run the discovery search for undeclared account data across logs, backups and support queues. It takes a day and it is the most common cause of a late finding. Then book the scanning cadence — how ASV scanning works covers what a passing report requires, and PCI DSS penetration testing covers the scope and triggers you will need to define.
