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, 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 segmentation testing validates.

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.

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 access into the CDE.
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 penetration testing lives, covered in detail below.
12. Support information security with organizational policies and programs. A maintained security policy, risk assessment, and staff awareness.

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 and after any significant change to the CDE.
• Segmentation testing to confirm that the controls isolating your CDE from the rest of the network actually work. If they do not, your entire network is in scope.
• Quarterly vulnerability scanning, with external scans by an Approved Scanning Vendor (ASV).
• Remediation and retest of findings, so your report shows issues closed rather than merely identified.

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.

Before your assessment

• Complete the right validation type. A Self-Assessment Questionnaire (SAQ) for smaller merchants, or a Report on Compliance (ROC) with a QSA for larger ones. Confirm which applies to your merchant level.
• 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, 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.