PCI DSS Compliance Checklist

If your organization stores, processes, or transmits payment card data, PCI DSS compliance is not optional. As of March 31, 2025, PCI DSS v4.0.1 is the only active version, and all 47 previously future-dated requirements are now mandatory. This checklist walks through every requirement with the implementation detail QSAs actually test against.

What Is PCI DSS and Who Needs to Comply

The Payment Card Industry Data Security Standard (PCI DSS) is a set of security controls developed by the PCI Security Standards Council (PCI SSC) to protect cardholder data. Any merchant, service provider, or technology vendor that touches card data falls under scope, regardless of transaction volume or company size.

Scope is the first thing a Qualified Security Assessor (QSA) examines. The cardholder data environment (CDE) includes every system that stores, processes, or transmits primary account numbers (PANs), plus any system that could affect the security of those systems. That definition frequently pulls in endpoints, administrative workstations, and remote access infrastructure that IT teams initially assume are out of scope.

The four PCI DSS merchant levels determine your validation requirements:

• Level 1: Over 6 million transactions annually. Requires an annual Report on Compliance (ROC) from a QSA.
• Level 2: 1 to 6 million transactions. Annual Self-Assessment Questionnaire (SAQ) plus quarterly network scans.
• Level 3: 20,000 to 1 million e-commerce transactions. Annual SAQ plus quarterly scans.
• Level 4: Under 20,000 e-commerce transactions. Annual SAQ recommended; requirements set by acquiring bank.

The 6 PCI DSS Control Objectives

The 12 PCI DSS requirements map to 6 control objectives. Understanding this structure helps you assign ownership across your security and IT teams before you start working through the individual checklist items.

1. Build and Maintain a Secure Network and Systems (Requirements 1-2)

2. Protect Account Data (Requirements 3-4)

3. Maintain a Vulnerability Management Program (Requirements 5-6)

4. Implement Strong Access Control Measures (Requirements 7-9)

5. Regularly Monitor and Test Networks (Requirements 10-11)

6. Maintain an Information Security Policy (Requirement 12)

PCI DSS Compliance Checklist: All 12 Requirements

The items below reflect PCI DSS v4.0.1. Each section flags the endpoint-level controls that appear most frequently in QSA testing, because that is where audits commonly find gaps.

Requirement 1: Install and Maintain Network Security Controls

Requirement 1 covers firewall and network segmentation controls. The goal is to isolate your CDE from untrusted networks and restrict traffic to only what is explicitly needed.

Checklist items:

• Document all network security controls and their configuration standards
• Maintain a current network diagram showing all CDE connections, including wireless
• Restrict inbound and outbound traffic to only what is necessary for the CDE
• Prohibit direct public access between the internet and any CDE component
• Review firewall rule sets at least every six months
• Ensure all connections to third-party networks are documented and authorized
• Apply network security controls on all endpoints that can reach CDE systems, not only perimeter firewalls

The last item is where endpoint teams get caught. A macOS workstation that can reach a payment processing server needs host-based firewall controls documented and tested, just like a network appliance.

Requirement 2: Apply Secure Configurations to All System Components

Default credentials and out-of-box configurations are a leading cause of breaches. Requirement 2 mandates that you harden every system component before it enters the CDE, and keep it hardened throughout its lifecycle.

Checklist items:

• Change all vendor-supplied default passwords before deployment
• Remove or disable unnecessary default accounts, services, and protocols
• Develop and maintain configuration standards for all system types (servers, endpoints, network devices, cloud instances)
• Align configuration standards with industry-accepted hardening guidance such as CIS Benchmarks or NIST guidelines
• Ensure configuration standards are applied consistently at provisioning, verified at least annually, and enforced through automated controls where possible
• Maintain an inventory of all in-scope system components

For endpoint-heavy environments, hardware inventory management is not just an IT operations task. A QSA will ask for a complete, current inventory of every device in scope. Gaps in your asset register become audit findings.

Requirement 3: Protect Stored Account Data

Requirement 3 governs what card data you store, where, and how it is protected. The default position should be: do not store PANs unless you have a specific, documented business reason.

Checklist items:

• Document the data retention policy for cardholder data and enforce deletion when data is no longer needed
• Do not store sensitive authentication data (SAD) after authorization, including full track data, CVV/CVC, and PINs
• Mask PANs when displayed (show only first six and last four digits maximum)
• Render PANs unreadable anywhere they are stored, using strong cryptography (AES-256, for example)
• Protect encryption keys with strict access controls and key custodian procedures
• Implement disk-level encryption on all endpoints and portable media that could contain cardholder data
• Maintain a data flow diagram showing where cardholder data exists at rest

Disk-level encryption is a direct QSA test point for endpoints. On macOS devices, FileVault must be enabled and the recovery key escrowed centrally so that key management is demonstrable. Devices without enforced encryption fail this requirement.

Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission

Any PAN transmitted over open, public networks must be encrypted. This applies to web traffic, API calls, email, and any other channel.

Checklist items:

• Use strong cryptography for all PAN transmission over open networks (TLS 1.2 minimum; TLS 1.3 preferred)
• Disable legacy protocols (SSL, TLS 1.0, TLS 1.1) across all in-scope systems
• Verify that only trusted certificates are accepted and that certificate validation is enforced
• Maintain an inventory of all trusted keys and certificates
• Ensure wireless networks transmitting cardholder data use strong encryption (WPA3 or WPA2-AES at minimum)
• Do not send unprotected PANs via end-user messaging technologies (email, SMS, chat)

Requirement 5: Protect All Systems and Networks from Malicious Software

Requirement 5 mandates anti-malware controls on all systems, with specific provisions around removable media and periodic evaluations for systems not typically targeted by malware.

Checklist items:

• Deploy anti-malware on all applicable system components
• Keep anti-malware signatures and software current with automatic updates
• Configure anti-malware to perform periodic scans or real-time scanning
• Enable anti-malware audit logs and retain them per your log retention policy
• Protect anti-malware from being disabled or altered by users (management-level controls required)
• Scan removable media for malware upon insertion and connection
• Conduct periodic evaluations of systems not commonly affected by malware (certain air-gapped or specialized systems) to confirm the risk assessment remains valid

For macOS environments, a common audit failure is relying on built-in XProtect as the sole anti-malware control without any centralized management, logging, or evidence of scan activity. QSAs require proof that the control is active, managed, and generating logs. Comparing EDR vs. antivirus capabilities matters here: endpoint detection and response tools typically produce richer audit logs and detection evidence than traditional signature-based AV, and that evidence quality shows in your audit.

Requirement 6: Develop and Maintain Secure Systems and Software

Requirement 6 covers patch management, vulnerability management, and secure development practices. The v4.0.1 updates tightened patch timelines significantly.

Checklist items:

• Establish a process to identify security vulnerabilities using reputable external sources (NVD, vendor advisories)
• Deploy critical and high-severity patches within one month of release
• Protect public-facing web applications against known attacks (OWASP Top 10 at minimum)
• Use a web application firewall (WAF) for public-facing applications
• Perform web application security assessments (penetration testing or automated scanning) at least annually and after significant changes
• Maintain an inventory of bespoke and custom software and their security review status
• For software developed in-house, follow a secure development lifecycle (SDLC) with documented security testing
• Address common vulnerabilities in code reviews before production deployment

For the patch timeline requirement, a 30-day window for critical patches is aggressive in large fleets. CVE prioritization and remediation processes need to be fast enough to meet that deadline consistently, not just in ideal conditions. Automated deployment pipelines that push patches to managed endpoints without waiting for user action are what make this requirement reliably achievable.

Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know

Requirement 7 enforces least-privilege access. Every user and system account should have only the access required for their specific job function.

Checklist items:

• Define access control policy based on least privilege and need to know
• Assign access based on job classification and function, not individual negotiation
• Review all user accounts and their access privileges at least every six months
• Restrict access to databases containing cardholder data; only database administrators should have direct query access
• Implement technical controls that enforce access restrictions (not just documented policies)
• Remove or disable accounts within 24 hours of a user's role change or termination

Requirement 8: Identify Users and Authenticate Access to System Components

Requirement 8 is one of the most demanding requirements in v4.0.1, particularly around multi-factor authentication (MFA). The expansion of MFA requirements is one of the most significant changes now mandatory as of March 2025.

Checklist items:

• Assign a unique ID to every user before granting access to system components
• Require MFA for all access into the CDE (this now explicitly includes administrative access from within the network, not only remote access)
• Require MFA for all remote network access originating from outside the entity's network
• Prohibit shared or group accounts for interactive logins
• Enforce minimum password complexity: at least 12 characters, including numeric and alphabetic characters
• Lock accounts after a maximum of 10 failed authentication attempts
• Set session idle timeout to 15 minutes or less
• Do not use vendor-supplied defaults for system and application passwords
• Manage service accounts with the same access control rigor as user accounts
• Invalidate authentication credentials immediately upon account termination
• Review all user IDs and authentication credentials at least every six months to confirm they are still needed

The MFA-for-all-CDE-access requirement catches many organizations off guard. If an administrator sits at a workstation on the internal network and connects to a payment server without MFA, that is a finding under v4.0.1. Device-level controls managing authentication state, screen lock enforcement, and session timeout are all part of satisfying this requirement at the endpoint.

Requirement 9: Restrict Physical Access to Cardholder Data

Requirement 9 covers the physical controls around your CDE, including data centers, server rooms, and physical point-of-sale systems.

Checklist items:

• Use physical access controls (badge readers, locks, CCTV) to restrict entry to CDE facilities
• Maintain physical access logs and review them at least quarterly
• Distinguish between on-site personnel and visitors; escort visitors at all times
• Protect physically any media that contains cardholder data
• Maintain an inventory of all media; conduct media inventories at least annually
• Destroy media securely when it is no longer needed (cross-cut shredding for paper; degaussing or physical destruction for electronic media)
• Protect point-of-sale devices from tampering; conduct periodic inspections
• Provide training to personnel who interact with payment terminals to detect skimming devices

Requirement 10: Log and Monitor All Access to System Components and Cardholder Data

Requirement 10 mandates audit logging for all in-scope systems. Logs must be generated automatically, protected from modification, and reviewed regularly. This is one of the heaviest evidence requirements in a PCI audit.

Checklist items:

• Enable audit logging on all in-scope system components
• Log all individual user access to cardholder data
• Log all actions taken by users with root or administrative privileges
• Log all access to audit trails themselves
• Log invalid logical access attempts
• Log use of and changes to identification and authentication mechanisms
• Log initialization, stopping, or pausing of audit logs
• Log creation and deletion of system-level objects
• Synchronize all system clocks to a reliable time source (NTP); document your time synchronization settings
• Protect audit logs from modification or deletion
• Retain audit logs for at least 12 months, with the most recent 3 months immediately available for analysis
• Review logs daily using automated tools or log management systems
• Investigate and remediate detected anomalies

Endpoint logs are frequently the weakest link in this requirement. Without centralized log collection from managed devices, IT teams cannot meet the daily review or 12-month retention requirements. Every in-scope endpoint must contribute logs to a centralized system, not store them locally where they can be lost or modified.

Requirement 11: Test Security of Systems and Networks Regularly

Requirement 11 mandates ongoing testing through vulnerability scans, penetration testing, and intrusion detection.

Checklist items:

• Maintain an inventory of authorized wireless access points; scan for unauthorized wireless access at least quarterly
• Run internal vulnerability scans at least quarterly and after significant changes; critical vulnerabilities must be remediated and rescanned
• Run external vulnerability scans quarterly using a PCI SSC-approved scanning vendor (ASV)
• Perform internal penetration testing at least annually and after significant infrastructure changes
• Perform external penetration testing at least annually
• Use a penetration testing methodology aligned with industry standards (PTES, OWASP, or NIST SP 800-115)
• Remediate exploitable vulnerabilities found during penetration testing; retest to verify
• Deploy an intrusion detection or intrusion prevention system (IDS/IPS) to monitor all CDE traffic
• Alert personnel to suspected compromises immediately
• Deploy a change-detection mechanism (file integrity monitoring) on critical files and configuration files

For vulnerability scanning to satisfy Requirement 11, you need both internal and external scans, on a defined schedule, with documented remediation timelines. Ad-hoc scanning does not meet the standard.

Requirement 12: Support Information Security with Organizational Policies and Programs

Requirement 12 covers the governance layer: policies, risk assessments, vendor management, and security awareness training.

Checklist items:

• Maintain a comprehensive information security policy; review and update it annually
• Develop and implement a risk assessment process; conduct a formal risk assessment at least annually
• Define acceptable use policies for end-user technologies
• Maintain and implement an incident response plan; test it at least annually
• Define roles and responsibilities for all PCI DSS activities
• Maintain a list of third-party service providers (TPSPs) with access to CDE or cardholder data
• Have a written agreement with each TSP acknowledging their responsibility to protect cardholder data
• Monitor TSP compliance status at least annually
• Conduct security awareness training for all personnel at hire and at least annually
• Train personnel with specific security responsibilities to maintain their skills
• Implement a policy to screen potential personnel prior to hire, consistent with local laws

PCI DSS v4.0.1: What Changed and What It Means for Endpoints

The transition from v3.2.1 to v4.0.1 introduced 64 new requirements. Of those, 47 were listed as future-dated and became mandatory on March 31, 2025. Organizations still operating on v3.2.1 controls are now out of compliance.

The changes most relevant to endpoint and device management teams:

MFA scope expansion (Requirement 8.4.2): MFA is now required for all access into the CDE, including access from trusted internal network segments. The v3.2.1 exception for on-site administrators is gone. Every privileged session into a CDE system requires a second factor.

Targeted risk analysis (Requirements 12.3.1 and 12.3.2): For controls where v4.0.1 allows flexible implementation frequency (such as log reviews and access reviews), organizations must document a targeted risk analysis that justifies the chosen frequency. This creates additional documentation work but also allows more defensible, risk-appropriate schedules.

Phishing-resistant authentication (Requirement 8.6.3): Payment page scripts must be authorized and their integrity verified. This requirement particularly affects e-commerce teams but has endpoint implications for developer workstations and build systems in scope.

Automated log review (Requirement 10.4.1.1): Daily log reviews must use automated mechanisms. Manual daily log review is no longer sufficient for systems that generate high log volumes.

E-commerce and client-side protection (Requirements 6.4.1 and 6.4.2): All scripts on public-facing payment pages must be inventoried, authorized, and have their integrity monitored. This is a significant new operational process for web teams.

Endpoint Security Controls That QSAs Actually Test

One of the most consistent gaps in PCI compliance programs is underestimating how much audit evidence comes from endpoint controls. A QSA testing a mid-market organization will typically request the following for every in-scope endpoint:

• Proof of encryption enforcement (FileVault enabled, key escrowed centrally)
• Anti-malware deployment and version currency evidence
• Patch status reports showing critical patches applied within 30 days
• Screen lock and session timeout configuration
• MFA enforcement records for CDE access
• Local firewall configuration
• Log forwarding configuration and confirmation that logs are reaching the SIEM

For macOS-heavy environments running tools like Slack, Salesforce, or internal admin consoles that touch payment workflows, every one of those machines can land in scope. A QSA who finds six unencrypted laptops and three machines with 90-day-old critical patches will issue findings against Requirements 3, 5, and 6 simultaneously.

How Iru Approaches PCI DSS Compliance

Most compliance platforms handle documentation. Most MDM platforms handle device configuration. PCI DSS requires both, and the evidence your QSA needs comes from the intersection. Iru addresses this by connecting enforcement at the device level to compliance evidence in a single workflow.

Iru Endpoint enforces the device-level controls that PCI DSS Requirements 2, 3, 5, 6, 8, and 10 depend on:

• FileVault encryption is enforced at provisioning with centralized key escrow, directly satisfying Requirement 3 for data-at-rest encryption on macOS endpoints. There is no manual step for end users.
• Configuration baselines aligned with CIS Benchmarks are deployed automatically at enrollment. Devices that drift from baseline trigger alerts rather than silently falling out of compliance.
• Critical patch deployment can be automated with defined deadline enforcement, putting 30-day remediation timelines within reach for fleets of hundreds or thousands of endpoints.
• Screen lock, session timeout, and passcode policies are enforced at the MDM profile level, not left to user discretion. This directly supports Requirement 8 session controls.
• Anti-malware deployment status, version currency, and scan logs are visible fleet-wide, providing the centralized evidence of active protection that QSAs require.
• Endpoint logs are forwarded to centralized logging infrastructure, supporting the Requirement 10 daily review and 12-month retention mandates.

Iru Compliance maps your organization's controls to PCI DSS requirements and automates evidence collection:

• Control mapping connects specific PCI DSS requirements to the technical and administrative controls in your environment, so you know which gaps need attention before your QSA arrives.
• Automated evidence collection pulls device compliance data, configuration reports, and patch status from Iru Endpoint, eliminating the manual evidence-gathering sprint before each audit.
• Continuous monitoring against PCI DSS controls surfaces drift in real time. You see a device fall out of compliance the day it happens, not three months later when your QSA asks for current status.
• Audit-ready reports package the evidence your QSA needs in the format they expect, reducing the back-and-forth that extends audit timelines.

For teams running compliance automation for the first time, the practical benefit is that the evidence your QSA requests for Requirement 2 (configuration standards), Requirement 5 (anti-malware), and Requirement 10 (logging) already exists in a structured, exportable form rather than being assembled from screenshots and spreadsheets the week before the audit.

Choosing the Right Path to PCI DSS Compliance

PCI DSS compliance is achievable for most organizations, but the path depends on where you are today. Start here:

1. Define your scope accurately. The most effective cost reduction in PCI compliance is reducing scope. Network segmentation, tokenization, and point-to-point encryption can remove systems from the CDE entirely. Get a QSA or Qualified Security Advisor (QSA) to review your scope before you start building controls.

2. Inventory everything in scope. You cannot secure what you cannot see. A complete, continuously updated inventory of in-scope devices, applications, and data flows is the foundation every other requirement builds on.

3. Automate enforcement before you automate evidence. Configuration drift and patch lag cause more audit failures than documentation gaps. Get your enforcement controls working first, then build the evidence layer on top.

4. Close the MFA gap for all CDE access. If you have not already extended MFA to all access paths into your CDE (including internal admin sessions), this is your highest-priority gap in v4.0.1. It is also one of the most common findings in audits conducted after March 2025.

5. Plan for quarterly and annual testing cycles. Vulnerability scans, penetration tests, access reviews, and log reviews all have defined frequencies. Build these into your operational calendar rather than treating them as one-time events.

PCI DSS compliance gets significantly more manageable when enforcement and evidence live in the same place. Iru Compliance maps controls and collects the audit evidence your QSA needs, while Iru Endpoint enforces those controls at the device level where most audit tests actually land. The two products work together or separately, depending on where your program is today.

Book a demo