PCI Compliance Checklist: All 12 PCI DSS Requirements (2026)

Last updated July 2026. PCI compliance means meeting all 12 requirements of the PCI Data Security Standard for any system that stores, processes or transmits cardholder data. The current standard is PCI DSS v4.0.1, which replaced v4.0 on 31 December 2024, and the 51 future-dated requirements that were optional best practices became mandatory on 31 March 2025. Your validation path depends on how you accept payments and how many transactions you run, which determines whether you file a self-assessment questionnaire or hire a QSA.

This checklist walks all 12 requirements in order, tells you which SAQ you probably need, and lists the evidence an assessor asks for first. It is written for US businesses that take card payments and need to satisfy their acquiring bank or a customer, not for QSAs.

Before the checklist: scope, level and SAQ

Step 1: define your cardholder data environment

Scope is the single biggest lever on PCI cost, and most companies scope too widely by accident. Your cardholder data environment (CDE) is every system that stores, processes or transmits cardholder data, plus every system connected to those. Map the actual flow: where card data enters, what touches it, where it rests, where it leaves. Then reduce it. Tokenization, a hosted payment page, and a redirect to your processor can move most of your infrastructure out of scope entirely, which is worth more than any control you will implement afterward.

Step 2: find your merchant level

Level	Annual card transactions	Typical validation
Level 1	Over 6 million (any brand), or any merchant after a breach	Annual Report on Compliance by a QSA or an internal auditor, plus quarterly ASV scans
Level 2	1 million to 6 million	Annual SAQ, plus quarterly ASV scans
Level 3	20,000 to 1 million e-commerce	Annual SAQ, plus quarterly ASV scans
Level 4	Under 20,000 e-commerce, or under 1 million total	Annual SAQ, scans as required by your acquirer

Thresholds are set per card brand and your acquiring bank has the final word, so confirm your level with them rather than assuming. Service providers follow a separate two-level scheme.

Step 3: pick the right SAQ

Choosing the wrong self-assessment questionnaire is the most common early mistake, and it usually means answering hundreds of questions you did not need to. SAQ A covers fully outsourced e-commerce where you never touch card data. SAQ A-EP covers e-commerce sites that do not receive card data but can affect the payment page. SAQ B covers imprint machines and standalone dial-out terminals; B-IP covers standalone IP terminals. SAQ C covers payment applications connected to the internet; C-VT covers web-based virtual terminals. SAQ P2PE covers validated point-to-point encryption terminals. SAQ D is everything else and every service provider, and it is by far the longest.

The PCI DSS checklist: all 12 requirements

Requirement 1: install and maintain network security controls

Document the CDE network with a current diagram showing every connection and card-data flow. Restrict inbound and outbound traffic to what is explicitly needed and deny everything else. Review rule sets at least every six months and keep the review records. Segment the CDE from the rest of your network, because segmentation is what keeps scope small.

Requirement 2: apply secure configurations to all system components

Change every vendor default before a system goes live: passwords, SNMP community strings, wireless keys, sample accounts. Maintain hardening standards per system type based on recognized benchmarks, and keep an inventory of components in scope. Under v4.x you also need documented roles and responsibilities for these activities, which auditors now test explicitly.

Requirement 3: protect stored account data

Do not store what you do not need. Sensitive authentication data (the full track, CVV and PIN) must never be retained after authorization, full stop. Where you do store the primary account number, render it unreadable using strong cryptography, and mask it so only the first six and last four digits show to anyone without a business need. Document your retention period and prove you actually delete data at the end of it.

Requirement 4: protect cardholder data with strong cryptography during transmission

Encrypt account data with strong cryptography over open, public networks. Keep an inventory of trusted keys and certificates. Never send unprotected PANs by email, chat or ticketing systems, which is the failure that shows up most often in real assessments because a support agent pasted a card number into a ticket.

Requirement 5: protect all systems against malicious software

Deploy anti-malware on systems commonly affected by it, keep it current, and run periodic scans with logs retained. For systems not commonly affected, document the periodic evaluation that justifies that conclusion. Anti-phishing controls became explicit under v4.x.

Requirement 6: develop and maintain secure systems and software

Patch critical vulnerabilities within one month of release. Follow a documented secure development lifecycle with code review for bespoke software, and train developers annually. Public-facing web applications need either an automated technical solution such as a WAF or an annual manual review. The v4.x payment-page script requirement, which asks you to manage and justify every script on a page that takes card data, is a genuine implementation lift for e-commerce teams and it is now in force.

Requirement 7: restrict access by business need to know

Define access based on job function, default to deny, and document who approved each grant. Review all user accounts and access privileges at least every six months and keep the review evidence, including what you changed as a result.

Requirement 8: identify users and authenticate access

Every user gets a unique ID. No shared accounts. Multi-factor authentication is now required for all access into the CDE and for all remote network access, not just administrative access, which was one of the most significant future-dated changes to take effect. Passwords must be at least 12 characters where the system supports it. Application and system accounts need documented management and their credentials rotated on a defined basis.

Requirement 9: restrict physical access to cardholder data

Control entry to facilities and areas holding card data, distinguish personnel from visitors, log visitor access and retain those logs for at least three months. Secure and inventory media containing card data, destroy it when it is no longer needed, and periodically inspect point-of-interaction devices for tampering and skimming.

Requirement 10: log and monitor all access

Log access to system components and cardholder data with enough detail to reconstruct events, including user, event type, timestamp, success or failure, and affected resource. Protect logs from alteration, synchronize clocks with a reliable time source, and retain audit history for at least 12 months with the last 3 months immediately available. Failures of critical security control systems must be detected, alerted on and responded to promptly, which under v4.x means automated log review rather than someone reading logs manually.

Requirement 11: test security of systems and networks regularly

Run internal vulnerability scans quarterly and after significant changes, and external scans quarterly through an Approved Scanning Vendor with passing results. Perform external and internal penetration testing at least annually and after significant infrastructure changes, and remediate what it finds. Test for unauthorized wireless access points quarterly. E-commerce sites must also detect unauthorized changes to payment page scripts.

Requirement 12: support information security with organizational policies

Maintain a written information security policy reviewed at least annually. Run a formal risk analysis for the elements v4.x requires it for. Deliver security awareness training at hire and annually. Maintain an incident response plan and test it annually. Keep a list of third-party service providers with card-data access, run due diligence before engagement, monitor their compliance status annually, and hold written agreements acknowledging their responsibility for the data.

What evidence will an assessor actually ask for?

The controls are the easy part to describe and the hard part to prove. Assemble these before the assessment rather than during it:

• Current network and card-data-flow diagrams, dated and matching reality
• Firewall and router rule sets plus the last two six-month review records
• System inventory with configuration standards per component type
• Quarterly ASV scan reports showing passing results, plus internal scan output
• The most recent penetration test report and remediation evidence
• User access listings with the last two access review records and approvals
• MFA configuration screenshots covering CDE and remote access
• Patch records demonstrating the one-month critical patch window
• Log samples, retention configuration and evidence of automated review
• Security awareness training completion records
• The incident response plan and evidence of the annual test
• Service provider list, due diligence records and written agreements

Notice how many of those are point-in-time artifacts that go stale. That is the practical case for continuous compliance monitoring: an access review from eleven months ago proves nothing about today, and reconstructing a year of evidence in assessment week is where PCI programs burn most of their hours.

How much does PCI compliance cost?

For a small Level 4 merchant on SAQ A with fully outsourced payments, the direct cost can be close to nothing beyond an annual scan fee. For a Level 1 merchant, a QSA-led Report on Compliance typically runs from the high tens of thousands into six figures depending on scope, with ASV scanning, penetration testing and remediation on top. The variable that moves this number most is scope, which is why the hours you spend reducing your CDE before you start pay back more than anything else in this checklist.

How often do you need to be PCI compliant?

PCI DSS is a continuous obligation validated annually. You complete an SAQ or Report on Compliance every 12 months, run ASV scans quarterly, and are expected to maintain the controls in between. In practice most breached merchants were validated at some point and non-compliant at the time of the breach, which is the gap the standard's continuous language in v4.x is trying to close.

Does PCI DSS apply if we use Stripe or Square?

Yes, PCI still applies to you, but a processor can dramatically shrink what you must do. If you use a hosted payment page or a fully outsourced iframe and card data never touches your systems, you may qualify for SAQ A, the shortest questionnaire. If you use a JavaScript integration where your page can affect how card data is collected, you fall into SAQ A-EP and carry considerably more requirements including the v4.x payment page script controls. Read your integration type carefully, because teams routinely assume SAQ A while running an A-EP integration. Note also that reconciling processor settlements is a separate exercise: the payouts that land in your bank rarely map one to one to orders, and finance teams usually end up converting statement files into a workable spreadsheet format to match deposits against transaction batches.

What happens if you fail PCI compliance?

There is no government fine for PCI non-compliance because it is a contractual standard, not a law. The consequences flow through your acquiring bank: monthly non-compliance fees, higher transaction rates, and in serious cases termination of your ability to accept cards. After a breach involving card data, the card brands can assess penalties running into the hundreds of thousands, you are typically forced to a Level 1 validation with a QSA regardless of your volume, and you fund the forensic investigation. State breach notification laws and the FTC apply independently.

Where to start this week

Draw the card-data flow first. Everything else follows from an accurate picture of what is in scope, and most teams find at least one system holding card data that nobody remembered. Then confirm your level and SAQ with your acquirer before you answer a single question, reduce scope wherever tokenization or a hosted page can do it, and only then start working the 12 requirements. If you carry other frameworks, map as you go: PCI requirements 7, 8, 10 and 12 overlap heavily with SOC 2 and ISO 27001, so evidence collected once should serve all three. That crosswalk is exactly what PCI compliance software is for, and it is the difference between PCI being a project and PCI being a byproduct of controls you already run.