A PCI DSS checklist is a practical tool for turning PCI DSS v4.0.1 requirements into assigned tasks, evidence, validation questions, and remediation actions. It can help if your organization stores, processes, or transmits cardholder data or sensitive authentication data, or if it can affect the security of a cardholder data environment. PCI SSC develops the standard, while payment brands, acquirers, and other compliance-program managers determine validation obligations and reporting routes (PCI SSC).
Use this checklist to organize readiness work. Do not treat it as proof of compliance, a complete substitute for PCI DSS testing procedures, or a replacement for guidance from your acquirer, payment brand, QSA, or PCI DSS adviser.
What Is a PCI DSS Checklist?
A PCI DSS checklist translates the 12 PCI DSS requirements into practical planning questions:
- What must we check?
- Who owns the work?
- What evidence may be needed?
- How often does the activity need to happen?
- What depends on scope, payment architecture, SAQ type, ROC/AOC requirements, or service-provider responsibilities?
- What still needs validation before we mark it complete?
PCI DSS v4.0.1 as the baseline for this article. The PCI SSC Document Library lists PCI DSS v4.0.1 as the published standard, dated June 2024, and is the source of truth for the formal requirement wording, testing procedures, SAQs, ROC templates, AOCs, and supporting documents (PCI SSC Document Library).
Before You Start: Confirm Scope and Validation Path
Do not start by assuming every checklist item applies to every system. PCI DSS work depends on scope, payment flows, outsourcing, segmentation, service-provider relationships, and the validation route required by the organization managing your compliance program—or, more precisely, by the organization that manages your compliance program.
PCI SSC guidance states that scope, applicable requirements, and reporting methods such as an SAQ or ROC should be confirmed with the organization that manages the compliance program, typically a payment brand or acquirer (PCI SSC FAQ 1473).
Use this worksheet before relying on the main checklist.
| Decision area | What to confirm | Evidence or output to collect | Who should confirm |
|---|---|---|---|
| Applicability | Do you store, process, or transmit cardholder data or sensitive authentication data, or affect the security of the cardholder data environment? | Payment-flow summary, data-flow diagrams, system inventory | Compliance lead, security, payments owner |
| Scope | Which systems, networks, applications, people, locations, and processes are in scope? | Cardholder data environment diagram, segmentation notes, asset inventory | Security, IT, engineering, QSA/adviser if engaged |
| Entity role | Are you a merchant, service provider, or both? | Contract review, customer/payment processing role summary | Compliance, legal/procurement, business owner |
| Validation route | Are you expected to complete an SAQ, ROC, AOC, or another package? | Written confirmation from acquirer, payment brand, customer, or compliance-program manager | Compliance lead, executive sponsor |
| SAQ direction | If using an SAQ, which SAQ applies to your environment? | Acquirer/payment-brand confirmation; payment architecture notes | Compliance lead, acquirer/payment brand |
| Service providers | Which vendors store, process, transmit, or affect cardholder data? | Vendor list, responsibility matrix, service-provider PCI evidence | Legal/procurement, security, compliance |
| Outsourcing | Have outsourced payment flows reduced your in-scope environment, and what responsibilities remain? | Shared-responsibility notes, provider attestations, merchant obligations | Compliance, security, acquirer/payment brand |
| External scanning | Does Requirement 11.3.2 apply, requiring external ASV scans? | ASV scan scope and reports, remediation records | Security, IT, compliance |
| E-commerce payment pages | Do requirements for payment-page scripts and tamper detection apply? | Script inventory, authorization records, change/tamper monitoring evidence | Engineering, security, compliance |
PCI SSC provides different SAQs for different merchant scenarios, and merchants should confirm with their acquirer or payment brand whether they are eligible or required to submit an SAQ and which one fits their environment. SAQ D for Service Providers is the only SAQ for SAQ-eligible service providers (PCI SSC FAQ 1133).
Outsourcing payment processing can reduce the requirements that apply directly to a merchant environment, but it does not remove the merchant’s responsibility to protect account data appropriately, understand shared responsibilities, and confirm validation obligations (PCI SSC FAQ).
PCI DSS 4.0.1 Checklist: Requirements, Tasks, Owners, and Evidence
The table below is a planning checklist, not the full PCI DSS standard. The requirement headings come from PCI DSS v4.0.1; the tasks, owners, evidence examples, cadence notes, and status fields are practical planning aids. Confirm applicability and testing expectations against the official PCI SSC documents and your validation route (PCI SSC Document Library).
| PCI DSS v4.0.1 requirement | Task/check | Likely owner | Cadence or timing | Evidence to collect | Validation notes | Status |
|---|---|---|---|---|---|---|
| 1. Install and Maintain Network Security Controls | Confirm network security controls are defined, implemented, reviewed, and aligned to the cardholder data environment. | Security, network/IT | At design, after material changes, and on a recurring review cycle | Network diagrams, data-flow diagrams, firewall/security-control configurations, rule review records | Scope and segmentation affect what must be tested. Confirm in-scope networks and any segmentation assumptions. | Complete / Incomplete / N/A / Needs validation |
| 2. Apply Secure Configurations to All System Components | Check that in-scope systems use secure configurations and that defaults, unnecessary services, and configuration drift are managed. | IT, engineering, security | During build, change, and recurring configuration review | Configuration standards, hardening records, system inventories, screenshots or exports, change tickets | Evidence depends on system types and validation path. Cloud, SaaS, and managed services may require shared-responsibility review. | Complete / Incomplete / N/A / Needs validation |
| 3. Protect Stored Account Data | Identify whether account data is stored, minimize storage where possible, and protect retained data. | Security, data/platform engineering, compliance | At architecture review, data-flow changes, and recurring data-discovery review | Data inventory, retention policy, encryption/key-management documentation, database/storage configuration evidence | Confirm whether storage is necessary and which data elements are in scope. Do not assume tokenization or outsourcing removes all responsibilities without validation. | Complete / Incomplete / N/A / Needs validation |
| 4. Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks | Verify that cardholder data transmission over open, public networks is protected with strong cryptography. | Engineering, IT, security | During implementation, certificate/key changes, and recurring review | TLS configuration evidence, architecture diagrams, certificate records, approved protocol settings | Confirm which transmission paths carry cardholder data and whether third-party integrations are in scope. | Complete / Incomplete / N/A / Needs validation |
| 5. Protect All Systems and Networks from Malicious Software | Confirm malware protection and anti-malware processes are appropriate for in-scope systems. | Security, IT, endpoint/platform teams | During system onboarding and recurring monitoring | Anti-malware configuration, coverage reports, alert records, exception documentation | Some system types may use alternative controls. Confirm applicability and evidence expectations for each platform. | Complete / Incomplete / N/A / Needs validation |
| 6. Develop and Maintain Secure Systems and Software | Check vulnerability management, patching, secure development, change control, and payment-page script controls where applicable. | Engineering, application security, security, DevOps | During development, release, change, vulnerability remediation, and recurring review | Change-management records, patch records, vulnerability remediation evidence, code review/security testing evidence, secure development procedures | For applicable e-commerce environments, requirements 6.4.3 and 11.6.1 address payment-page script authorization and integrity, and detection of unauthorized payment-page changes or tampering (PCI SSC). | Complete / Incomplete / N/A / Needs validation |
| 7. Restrict Access to System Components and Cardholder Data by Business Need to Know | Confirm access is limited by role, business need, and least privilege. | Security, IT, system owners, HR/people operations | At onboarding, role change, termination, and recurring access review | Access control matrix, user lists, approval records, access review evidence, privilege exception records | Confirm which systems store, process, transmit, or can affect cardholder data. Evidence may differ for internal systems and service-provider platforms. | Complete / Incomplete / N/A / Needs validation |
| 8. Identify Users and Authenticate Access to System Components | Verify unique user identification, authentication controls, MFA where applicable, and account lifecycle processes. | Security, IAM/IT, engineering | At onboarding, access changes, and recurring review | IAM configuration exports, MFA evidence, account lists, authentication policy, joiner/mover/leaver records | Confirm which users, administrators, service accounts, and third-party access paths are in scope. | Complete / Incomplete / N/A / Needs validation |
| 9. Restrict Physical Access to Cardholder Data | Check physical security for facilities, media, devices, and paper records that contain or affect cardholder data. | Facilities, operations, IT, security | At facility/process changes and recurring review | Badge/access logs, visitor logs, media handling records, device inventory, physical security procedures | This may be limited if infrastructure is fully outsourced, but vendor responsibility and evidence still need review. | Complete / Incomplete / N/A / Needs validation |
| 10. Log and Monitor All Access to System Components and Cardholder Data | Confirm logging, monitoring, alerting, and log retention are designed for in-scope systems. | Security operations, IT, engineering | Continuous monitoring with recurring review | Log source inventory, SIEM/logging configuration, alert records, review records, retention settings | Validate which systems must generate logs, who reviews them, and how retention aligns with applicable PCI DSS requirements. | Complete / Incomplete / N/A / Needs validation |
| 11. Test Security of Systems and Networks Regularly | Plan vulnerability scanning, external ASV scans where applicable, penetration testing, segmentation testing, and detection-control testing. | Security, IT, engineering, external testers where used | Based on requirement, validation route, and after relevant changes | Vulnerability scan reports, ASV reports, penetration test reports, segmentation test evidence, remediation records | Where Requirement 11.3.2 applies, passing external vulnerability scans by an Approved Scanning Vendor are required at least once every three months (PCI SSC). | Complete / Incomplete / N/A / Needs validation |
| 12. Support Information Security with Organizational Policies and Programs | Confirm policies, risk management, security awareness, incident response, service-provider management, and governance are maintained. | Compliance, security, legal/procurement, operations, executive sponsor | At policy updates, vendor changes, training cycles, incident exercises, and recurring governance review | Policies and procedures, risk assessment records, training records, incident response plan and test records, vendor review evidence, responsibility assignments | Requirement 12 often ties technical controls to accountable governance. Confirm service-provider responsibilities and assessment evidence. | Complete / Incomplete / N/A / Needs validation |
For each row, avoid marking “not applicable” casually, keep a short note explaining why it is out of scope, who confirmed that conclusion, and what evidence supports it.
Recurring PCI DSS Activities to Keep the Checklist Current
PCI DSS readiness degrades when the checklist is treated as a one-time spreadsheet. Keep a recurring operating rhythm for the activities that affect scope, evidence, and remediation.
| Activity | What to keep current | Cadence guidance |
|---|---|---|
| Vulnerability scanning | Internal and external scan scope, scan results, remediation records | Follow applicable PCI DSS requirements and validation route; ASV scans are at least every three months where Requirement 11.3.2 applies. |
| Penetration testing and security testing | Test scope, findings, remediation, retest evidence | Confirm required timing and scope against PCI DSS v4.0.1 and your assessor/acquirer guidance. |
| Patch and vulnerability management | Vulnerability intake, risk decisions, fixes, exceptions | Run as an operational process, not just before assessment. |
| Log review and retention | Log sources, alerts, review evidence, retention settings | Confirm applicable retention and review expectations for in-scope systems. |
| Access reviews | User access, privileged access, third-party access, service accounts | Tie reviews to onboarding, role changes, terminations, and recurring control review. |
| Security awareness and role-based training | Training completion, target audiences, content updates | Keep evidence aligned to PCI DSS applicability and internal roles. |
| Risk assessments | Risks to the cardholder data environment and supporting processes | Refresh when the environment changes and as required by your validation route. |
| Vendor and service-provider reviews | Provider scope, shared responsibilities, PCI evidence, contract obligations | Reassess when vendors change and during recurring third-party review. |
| Incident response readiness | Response plan, contact lists, tabletop/test records, lessons learned | Update when systems, teams, providers, or escalation paths change. |
| Scope monitoring | Payment-flow changes, new integrations, segmentation changes, new storage locations | Review before and after architecture or vendor changes. |
| Evidence refresh | Stale screenshots, expired attestations, old diagrams, unresolved exceptions | Track evidence age and ownership so assessment preparation is not a last-minute collection exercise. |
The point is to make PCI DSS part of normal security, engineering, IT, compliance, and operations workflows. A clean checklist with stale evidence may not be a reliable readiness position.
How to Turn the Checklist Into a Remediation Plan
After completing the checklist, convert each row into a tracked decision or work item for follow-up work.
Use four practical statuses:
- Complete: Evidence exists, owner is assigned, and validation questions are resolved.
- Incomplete: The control, process, evidence, or ownership is missing.
- Not applicable: The item is outside scope, with a documented rationale and confirmation path.
- Needs validation: The team cannot yet confirm applicability, evidence sufficiency, or reporting expectations.
Prioritize gaps using three lenses:
- Scope impact: Does the issue affect systems that store, process, transmit, or can affect cardholder data?
- Assessment impact: Is the item likely to affect the SAQ, ROC, AOC, ASV scan, customer request, or acquirer discussion?
- Operational risk: Could the gap increase exposure, delay remediation, or create repeated evidence failures?
Assign each remediation item an owner, due date, evidence target, and validation dependency. For example, “Engineering to produce payment-page script inventory and authorization records” is more useful than “Requirement 6 incomplete.”
If a compensating control may be relevant, document and review it using the applicable PCI SSC process and assessor/acquirer guidance. Do not treat compensating controls as a default workaround for incomplete remediation.
This is also where PCI DSS readiness becomes easier to manage as operational work. Teams such as Ciphrix can support scope review, gap assessment framing, evidence planning, remediation tracking, and preparation for assessment conversations without replacing PCI SSC guidance, your acquirer, or a QSA.
When to Get Expert Help
Consider expert support when:
- scope is unclear, messy, or disputed across teams
- multiple payment flows, business units, or service providers are involved
- you are unsure which SAQ or validation route applies
- evidence is scattered across engineering, IT, security, legal, and operations
- remediation requires coordinated technical and compliance work
- you are preparing for customer, acquirer, payment-brand, or formal assessment conversations
A useful PCI DSS checklist does not promise compliance. It gives your team a disciplined way to organize PCI DSS v4.0.1 tasks, owners, evidence, open questions, and remediation work—then confirm the formal path with the parties responsible for your validation obligations.