PCI DSS Compliance Checklist

If your business stores, processes, or transmits cardholder data, PCI DSS applies to you, and an auditor or acquiring bank will eventually ask you to prove it. The standard is large, but it is not mysterious. This checklist walks through what compliance actually requires under PCI DSS v4.0.1, the current version, so you can see where you stand before an assessment rather than during one.

Treat each item as a question to answer honestly. “Mostly” is not a passing answer for a control that protects payment data.

First: scope your cardholder data environment

Everything in PCI starts with scope. The cardholder data environment (CDE) is every system that stores, processes, or transmits cardholder data, plus anything connected to it.

• Map where card data lives. Every database, application, log, and backup that touches a card number.
• Map how it flows. From capture through processing to storage and disposal.
• Segment aggressively. The smaller and more isolated your CDE, the smaller your compliance burden. Segmentation is the single biggest lever on PCI cost and effort.
• Confirm what is out of scope, and be ready to prove that isolation holds. This is exactly what network segmentation testing validates.

Pick your validation route: SAQ or ROC

Your merchant level is set by each card brand from your transaction volume over a 12-month period, and it decides how you validate: a Self-Assessment Questionnaire (SAQ) for smaller merchants, or a Report on Compliance (ROC) for the largest. Your acquirer tells you which applies. If you self-assess, the SAQ type follows from how you take payments, and it decides which parts of Requirement 11, the penetration test included, you have to answer. Our guide to PCI compliance levels and SAQ types has each brand’s thresholds and the scanning and testing every SAQ includes.

Hotels and restaurant groups usually take cards through several channels at once, from front desk and bar terminals to a booking engine or online ordering, so they may need more than one SAQ, or SAQ D for the whole environment. Our page on hotel and restaurant PCI compliance goes through what each requirement means on property.

The 12 PCI DSS requirements

PCI DSS organizes its controls into six goals and twelve requirements. Here is the working checklist.

Build and maintain a secure network

1. Install and maintain network security controls. Firewalls and equivalent controls between the CDE and everything else, with documented, justified rules.
2. Apply secure configurations to all system components. No vendor defaults, no unnecessary services, hardened baselines everywhere.

Protect account data

3. Protect stored account data. Minimize what you store, encrypt what you must keep, and never store sensitive authentication data after authorization.
4. Encrypt cardholder data in transit across open and public networks with strong, current cryptography.

Maintain a vulnerability management program

5. Protect against malware on all systems commonly affected, kept current and actively running.
6. Develop and maintain secure systems and software. Patch promptly, follow secure development practices, and manage vulnerabilities as they emerge. For e-commerce, 6.4.3 adds an inventory of every script on your payment pages, each authorized and checked for integrity.

Implement strong access control

7. Restrict access to cardholder data by business need to know. Least privilege, enforced by default deny.
8. Identify users and authenticate access. Unique IDs, strong authentication, and multi-factor authentication for all non-console access into the CDE (8.4.2).
9. Restrict physical access to cardholder data, including media, devices, and facilities.

Regularly monitor and test networks

10. Log and monitor all access to system components and cardholder data, with reviewable, tamper-resistant audit trails.
11. Test security of systems and networks regularly. This is where scanning (11.3), penetration testing (11.4) and payment-page tamper detection (11.6.1) live, covered in detail below.
12. Support information security with organizational policies and programs. A maintained security policy, risk assessment, and staff awareness.

What became mandatory on 31 March 2025

PCI DSS v4.0 added 64 new requirements, and 51 of them were future-dated: best practice until 31 March 2025, mandatory since. (PCI Security Standards Council) If your last assessment ran before that date, check these first:

• Payment-page scripts (6.4.3). Keep an inventory of every script that loads in the customer’s browser on your payment pages, with a written reason for each, and confirm each is authorized and has not been altered.
• Change and tamper detection (11.6.1). Alert your team when the security-relevant HTTP headers or the script contents of your payment pages change without authorization.
• MFA for all non-console access into the CDE (8.4.2). Not just administrators and not just remote access.

These are the controls that stop e-skimming, which is why a checkout test should now check them. SAQ A merchants are the exception: the SAQ A revision that took effect on 31 March 2025 removed 6.4.3 and 11.6.1 from that questionnaire, and merchants with embedded payment forms instead confirm that their site is not susceptible to script attacks.

The testing PCI actually requires (Requirement 11)

Requirement 11 is where most teams need outside help, and where a real assessment separates paper compliance from actual security:

• Internal and external penetration testing at least annually (11.4.2 and 11.4.3) and after any significant change to the CDE.
• Segmentation testing (11.4.5) to confirm that the controls isolating your CDE from the rest of the network actually work, every six months for service providers (11.4.6). If segmentation fails, your entire network is in scope.
• Quarterly vulnerability assessment and scanning: internal scans under 11.3.1, and external scans by an Approved Scanning Vendor (ASV) under 11.3.2.
• Wireless access point checks (11.2.1) at least every three months, to detect authorized and unauthorized access points, even if you do not use Wi-Fi in the CDE. An on-site wireless penetration testing engagement includes a rogue access point sweep and also tests whether your Wi-Fi reaches the CDE.
• Remediation and retest of findings (11.4.4), so your report shows issues closed rather than merely identified.

Scanning (11.3) and penetration testing (11.4) are separate requirements with separate evidence. Our guide to the ASV scan vs penetration test explains why neither replaces the other, and the Requirement 11.4 penetration testing requirements guide goes through every sub-requirement.

A penetration test for PCI is not a checkbox scan. It has to be scoped to your CDE, performed to the standard your QSA expects, and delivered as evidence they will accept. See what that looks like on our sample report page, and see what PCI penetration testing costs component by component: external from $4,200 and internal with segmentation from $6,000, each with a free retest.

Before your assessment

• Complete the right validation type. The SAQ or ROC your merchant level and payment setup call for.
• Gather evidence continuously, not the week before. Policies, scan reports, penetration test reports, and access reviews.
• Fix findings and retest so nothing critical is open at assessment time.
• Re-scope after changes. New systems, new integrations, or new data flows can pull things back into scope.

The short version

PCI compliance is scope discipline plus twelve requirements plus proof that your controls work. Get the scope small, keep evidence current, check the requirements that became mandatory in March 2025, and treat Requirement 11 testing as a real security exercise rather than a formality. Do that and the assessment becomes a confirmation, not a scramble.

If you need the penetration testing and segmentation testing PCI requires, delivered as evidence your QSA will accept, scope a PCI engagement and we will build it around your cardholder data environment. Our full approach is on the PCI DSS penetration testing page.