PCI DSS v4.0.1 · QSA-accredited since 2014

PCI Compliance Checklist, in the order that reduces risk fastest

Most teams start a PCI DSS programme at Requirement 1 and work down the list. That is the wrong order. This pre-audit checklist follows the six risk-based milestones the PCI Security Standards Council uses in its Prioritized Approach, so the controls that close off the worst outcomes come first. Answer honestly and you will finish with a ranked view of what to fix before an assessor walks in.

6 risk milestones 68 evidence questions 250 mapped sub-requirements Rated critical to low Nothing stored, nothing sent
Official PCI SSC Register Cianaa Technologies is a Qualified Security Assessor company listed with the PCI Security Standards Council since 2014. Ask us for our listing.
0%evidenced
Start with Milestone 1
How to use this

Answer as an assessor would read it

For each item, ask whether you could put evidence in front of someone today. Not whether you believe it is happening, and not whether it is written in a policy somewhere. A control you cannot evidence is a finding waiting to be written. Mark Partial where something exists but is incomplete, inconsistent across the environment, or undocumented.

1. CriticalData you should not be holding, and scope you cannot prove.
2. Very highThe perimeter, access and hardening controls attackers meet first.
3. HighApplication and patching weaknesses that bypass the perimeter.
4. MediumAccess control and logging. Detection and reconstruction.
5. Medium-lowProtecting stored data and the keys that guard it.
6. LowGovernance, policy, people and third parties.
Severity here means how urgently a gap should be closed, not how easily it can be ignored. A Low rating does not make a control optional. Every item on this page is a PCI DSS requirement, and a Milestone 6 failure will end an assessment just as firmly as a Milestone 1 failure. The ordering tells you what to do on Monday morning, not what you can leave undone.
This is a pre-audit tool, not an assessment. The full standard runs to more than 300 sub-requirements. These 68 questions cover the ground that decides most outcomes, weighted toward the earlier milestones because that is where risk concentrates. Your validation route and reporting obligations are set by your acquirer or payment brand, not by this page.

Milestone 1. Stop holding what you cannot defend

Critical risk

Sensitive authentication data, retention limits and knowing your true scope. The cheapest breach is the one where there was nothing worth taking.

0%
A current network diagram showing every connection into and out of the cardholder data environment, including wireless.
1.2.3
A data-flow diagram tracing account data across every system that stores, processes or transmits it, updated whenever the environment changes.
1.2.4
A written retention schedule naming each location account data is held, for how long, and the legal or business reason.
3.2.1
Evidence that data past its retention date is actually deleted, with that check run at least once every three months.
3.2.1
Confirmation that full track data from the magnetic stripe or chip is never retained once authorisation completes.
3.3.13.3.1.1
Confirmation that the card verification code is never retained once authorisation completes.
3.3.1.2
Confirmation that PINs and PIN blocks are never retained once authorisation completes.
3.3.1.3
Where sensitive authentication data is held electronically before authorisation finishes, evidence it is encrypted with strong cryptography.
3.3.2
If you issue cards or support issuing, a documented business justification and protection for any sensitive authentication data you store.
3.3.3
Documented destruction of paper records containing cardholder data once they are no longer needed.
9.4.6
Documented destruction or sanitisation of electronic media once the cardholder data on it is no longer needed.
9.4.7
Scope confirmed in writing within the last twelve months, and again after any significant change to the environment.
12.5.212.5.2.1

Milestone 2. Protect the systems and networks around the data

Very high risk

The largest milestone by far, and where most assessment findings land. These are the controls that stop an attacker reaching the environment in the first place.

0%
Network security control rulesets built and maintained against a documented configuration standard.
1.2.1
Inbound and outbound traffic to the cardholder data environment restricted to what is necessary, with everything else denied by default.
1.3.11.3.2
Wireless networks separated from the cardholder data environment by network security controls, with wireless traffic denied unless there is an authorised business purpose.
1.3.3
Anti-spoofing controls in place to detect and block forged source addresses at the trusted boundary.
1.4.3
No system component storing cardholder data reachable directly from an untrusted network.
1.4.4
Hardening standards applied to every system type in scope, aligned to a recognised industry benchmark and updated as new issues emerge.
2.2.1
Vendor default accounts and passwords changed, removed or disabled before a system reaches production.
2.2.2
All administrative access over non-console channels encrypted with strong cryptography.
2.2.7
Cardholder data encrypted in transit across open or public networks, with an inventory of the trusted keys and certificates in use.
4.2.14.2.1.1
Anti-malware protection deployed where the standard requires it, kept current, actively running, and not disableable by users.
5.2.15.3.15.3.5
Technical controls in place to detect and protect personnel against phishing attacks.
5.4.1
An inventory of every script running on payment pages, each one authorised and integrity-checked, with tamper detection alerting on change.
6.4.311.6.1
A unique named account for every individual, with shared, generic or group credentials eliminated from the environment.
8.2.18.2.2
Multi-factor authentication enforced on all remote access and on all access into the cardholder data environment.
8.4.28.4.38.5.1
Internal and external vulnerability scans running to schedule, with rescans performed until a passing result is achieved.
11.3.111.3.2
Physical access to sensitive areas controlled and logged, and card-reading devices inspected periodically for tampering or substitution.
9.2.19.5.1

Milestone 3. Secure the applications that touch payments

High risk

Application weaknesses are the most reliable route into an otherwise well-defended environment. This milestone is narrow but unforgiving.

0%
Every system component patched, with critical and high-severity patches applied within one month of release.
6.3.3
A process for identifying newly disclosed vulnerabilities relevant to the software you use, with a risk ranking applied.
6.3.1
Bespoke and custom software developed against documented secure coding practice, with developers trained at least annually.
6.2.16.2.2
Code reviewed before release by someone other than the author, with findings corrected and the review recorded.
6.2.36.2.3.1
Public-facing web applications protected by an automated technical solution that detects and blocks attacks, or reviewed by an equivalent method.
6.4.16.4.2
Development and test environments kept separate from production, with separation of duties between them.
6.5.36.5.4
Live primary account numbers never used for testing or development.
6.5.5
Test data and test accounts removed from system components before they go live.
6.5.6

Milestone 4. Know who did what, and when

Medium risk

Access control and logging. This is what turns an incident from an unknown into something you can reconstruct, scope and defend.

0%
Access granted on least privilege and least access, justified by documented business need.
7.2.17.2.2
All user accounts and their entitlements reviewed at least once every six months, with inappropriate access corrected.
7.2.4
Application and system accounts managed and their access reviewed, rather than left standing indefinitely.
7.2.57.2.5.1
Audit logs capturing every individual user access to cardholder data.
10.2.1.1
Audit logs capturing all actions taken by administrative or privileged accounts.
10.2.1.2
Each log entry recording the user, event type, date and time, success or failure, origin and the data or resource affected.
10.2.2
Logs protected from alteration and deletion, and readable only by those with a job-related need.
10.3.110.3.2
System clocks synchronised from an agreed time source across the environment.
10.6.110.6.2
Logs from the highest-risk sources reviewed daily, using automated mechanisms rather than by eye alone.
10.4.110.4.1.1
Twelve months of log history retained, with the most recent three months immediately available for analysis.
10.5.1
Failures of critical security controls detected, alerted on, and responded to under a documented process.
10.7.210.7.3
Intrusion detection or prevention monitoring traffic at the perimeter of the cardholder data environment and alerting on suspicious activity.
11.5.1

Milestone 5. Protect the data you have decided to keep

Medium-low risk

For everything that survived Milestone 1. Storage protection and key management is where the standard is least forgiving of good intentions.

0%
Primary account numbers rendered unreadable everywhere they are stored, by an approach the standard accepts.
3.5.1
Primary account numbers masked when displayed, so only those with a documented business need see more than the first six and last four digits.
3.4.1
Controls preventing the copying or relocation of primary account numbers when using remote access technologies.
3.4.2
Where hashing is used to protect stored account data, keyed cryptographic hashes with the key protected separately.
3.5.1.1
Disk-level or partition-level encryption not relied on by itself to protect stored account data on system components.
3.5.1.23.5.1.3
Cryptographic keys protected against disclosure and misuse, with access restricted to the fewest custodians necessary.
3.6.13.7.5
Documented key management covering generation, secure distribution, secure storage, and scheduled or forced key changes.
3.7.13.7.23.7.33.7.4
Key custodians formally acknowledging in writing that they understand and accept their responsibilities.
3.7.9
Media containing cardholder data physically secured, classified by sensitivity, and controlled whenever it is moved.
9.4.19.4.29.4.3
Visitors to sensitive areas identified, authorised, escorted where required, and logged with a retained record.
9.3.29.3.39.3.4

Milestone 6. Close the loop and make it hold

Low risk

Policy, governance, people and third parties. Historically treated as paperwork, and now among the most commonly failed areas at assessment.

0%
An information security policy that is current, formally approved, published, and reviewed at least once every twelve months.
12.1.112.1.2
Security roles and responsibilities documented, formally assigned, and understood by the people holding them.
12.1.312.1.4
A documented targeted risk analysis supporting the frequency of every control where the standard lets you choose that frequency.
12.3.1
Cryptographic suites and protocols in use inventoried and monitored for continued fitness against emerging weaknesses.
12.3.3
Hardware and software inventoried, with end-of-life status tracked and a plan for anything approaching it.
12.3.412.5.1
Security awareness training delivered to all personnel on joining and at least annually, covering current threats including phishing.
12.6.112.6.3
Personnel screened before hire, to the extent local law permits.
12.7.1
Third-party service providers inventoried, with written agreements and a documented split of which PCI DSS responsibilities sit with whom.
12.8.112.8.212.8.5
Third-party compliance status monitored at least once every twelve months rather than assumed.
12.8.4
An incident response plan that names roles, covers containment and notification, and is tested at least annually.
12.10.112.10.2
Your position

Answer the questions above to see where you stand

Your score updates as you go. Nothing you enter leaves your browser.

Fix these first

    Gaps will be listed here in priority order, earliest milestone first.

    Questions

    Frequently asked questions about the PCI compliance checklist

    Is this checklist suitable for all PCI merchant levels?
    Yes. All 12 PCI DSS requirements apply to every merchant regardless of level. What differs between levels is the validation method (SAQ vs. QSA audit) and the specific sub-requirements that apply based on your payment acceptance method. A Level 4 merchant using a fully hosted payment page will have far fewer applicable controls than a Level 1 merchant storing cardholder data, but both must demonstrate compliance with the applicable requirements.
    How often should I review this checklist?
    PCI DSS requires annual validation, but compliance is a continuous programme. You should review your control status quarterly, aligned with your ASV scan cycle, and any time there is a significant change to your environment, such as a new payment system, infrastructure migration, or significant organisational change. Some controls (like log reviews and patch management) must be verified daily or monthly.
    What is the difference between this checklist and the SAQ?
    This checklist is a pre-audit and gap identification tool. It helps you understand your current posture and what you need to fix before formal validation. The Self-Assessment Questionnaire (SAQ) is the official PCI SSC validation document you complete to formally attest your compliance to your acquiring bank. There are nine different SAQ types depending on how you accept payments, each containing different subsets of PCI DSS requirements.
    What are the most commonly failed checklist items?
    Based on our QSA experience, the most commonly failed areas are: Requirement 8 (weak or shared passwords, missing MFA), Requirement 6 (missing security patches, no WAF, unmanaged web scripts), Requirement 10 (insufficient log retention or review processes), Requirement 12 (incomplete policies, untested incident response plan), and Requirement 3 (unnecessary storage of sensitive cardholder data).
    Can a QSA help me work through this checklist?
    Absolutely. Our certified QSAs can conduct a structured gap assessment using the full PCI DSS v4.0.1 requirements, going far beyond this summary checklist to assess every sub-requirement against documented evidence. The output is a detailed gap report with a prioritised remediation plan, realistic effort estimates, and clear guidance on what to do next. This is the most efficient way to prepare for formal PCI certification.

    Continue your PCI journey

    All PCI services
    Guide

    What is PCI Compliance?

    The complete business guide to PCI DSS: what it is, what is required, and how to get there.

    Read the guide
    Service

    PCI Compliance Assistance

    QSA-led, end-to-end PCI compliance assistance, from gap assessment to certified AOC.

    View service
    Free tool

    SAQ Selector

    Find the right SAQ for your business in under 60 seconds. Nine outcomes, no signup.

    Open the selector
    Free tool

    Pre-Audit Maturity Assessment

    Rate 24 practices across 8 domains and see whether your compliance will hold between assessments.

    Start the assessment
    Get a second opinion

    Have a QSA check your answers

    Thirty minutes with a practising Qualified Security Assessor who will tell you which of your gaps actually matter for your validation route, and what an assessor will ask for.

    Book a QSA review

    About this checklist. The six-milestone risk ordering is the structure published by the PCI Security Standards Council in The Prioritized Approach to Pursue PCI DSS Compliance for PCI DSS v4.0.1. The requirement numbers cited are references to that standard. All question wording on this page is Cianaa’s own, written as evidence questions rather than restatements of the standard, and no text from PCI SSC documents is reproduced here.

    PCI DSS and the Prioritized Approach are published by the PCI Security Standards Council LLC, which is not affiliated with Cianaa Technologies and does not endorse this checklist. Always work from the current standard, including its Applicability Notes, which change how individual requirements are interpreted.

    Cianaa Technologies is an independent certification and assessment body headquartered in Auckland. We have been a PCI Qualified Security Assessor on the PCI Security Standards Council register since 2014 and are a PCI 3DS Assessor.