PCI DSS Compliance Checklist: The 12 Requirements Under v4.0.1

What's New in PCI DSS v4.0.1?

PCI DSS v4.0 rebuilt the standard around how modern businesses operate and how attackers behave, asking organizations to prove that their security controls actually work, not just that they exist on paper. Version 4.0.1 refines that foundation rather than replacing it.

Released in mid-2024, v4.0.1 is a limited revision. It corrects formatting and typographical errors and clarifies the intent of certain requirements and guidance. Critically, there are no new or deleted requirements, so if you built your program around v4.0, you don't need to rescope it. The clarifications include:

• Requirement 3 (protect stored account data): Clarified applicability notes for issuers, plus a customized-approach objective for organizations using keyed cryptographic hashes to render PANs unreadable.

• Requirement 6 (secure systems and software): Reverted to v3.2.1 language so that installing patches within 30 days applies only to critical vulnerabilities, and added guidance on managing payment page scripts.

• Requirement 8 (identify and authenticate access): Clarified that multi-factor authentication for non-administrative access into the cardholder data environment does not apply to accounts authenticated only with phishing-resistant factors.

• Requirement 12 (organizational policies): Clarified the relationship between customers and third-party service providers (TPSPs).

• Appendices: Moved the customized-approach sample templates to the PCI SSC website and added definitions for "legal exception," "phishing-resistant authentication," and "visitor."

Two dates matter. PCI DSS v4.0 was retired on December 31, 2024, which means v4.0.1 is now the only active version supported by the PCI SSC. And the future-dated requirements became mandatory on March 31, 2025; v4.0.1 did not change that deadline. If your compliance program hasn't closed the gap on things like risk-based access controls, targeted risk analyses, and updated authentication practices, you're already behind.

Where to Start: Scope Your Cardholder Data Environment (CDE)

Before you touch the 12 requirements, define your scope. Identify every system, tool, process, and person that handles or could impact cardholder data. This collective footprint is your cardholder data environment (CDE), and it sets the boundaries of your compliance obligations.

Scoping also shapes how you validate compliance, whether you complete a Self-Assessment Questionnaire (SAQ) or undergo a full Report on Compliance (ROC). Systems generally fall into three buckets:

• In-scope: Systems that store, process, transmit, or could affect the security of cardholder data

• Connected: Systems not directly involved in processing cardholder data but connected to your CDE

• Out-of-scope: Systems that don't interact with or connect to your CDE

Under v4.0.1, scope must be documented and confirmed at least once every 12 months (every six months for service providers) and after any significant change. Startups often discover they're accidentally pulling unrelated systems into scope, like CI/CD pipelines, support tooling, and staging environments. The earlier you define and enforce boundaries, the smaller and cheaper your assessment becomes.

The 12 PCI DSS v4.0.1 Requirements

PCI DSS organizes its 12 requirements under six control objectives:

1. Build and maintain a secure network and systems

2. Protect account data

3. Maintain a vulnerability management program

4. Implement strong access control measures

5. Regularly monitor and test networks

6. Maintain an information security policy

Below is how to approach each requirement.

1. Install and Maintain Network Security Controls

Every system that stores or processes cardholder data is a potential target. PCI DSS requires organizations to limit exposure by controlling how data moves across their networks and preventing unauthorized traffic from reaching the CDE.

Firewalls are a major part of that defense, but v4.0 broadened the language from "firewalls and routers" to "network security controls" to reflect virtual devices, routing rules, cloud-native access controls, and software-defined networking. Whatever the form, you're expected to configure it, document it, and maintain it, enforcing segmentation between the CDE and everything else. Misconfigurations, like a permissive default rule or an overlooked open port, are among the most common and preventable sources of PCI violations.

Pro-tip: Drata connects directly to your cloud provider to monitor firewall rules and segmentation controls in real time. It flags gaps, tracks changes, and helps your team maintain secure boundaries without relying on manual reviews.

2. Apply Secure Configurations to All System Components

Out-of-the-box settings aren't built for security. Vendors ship products with default credentials, open ports, and permissive access controls. Every in-scope system, operating systems, network devices, cloud instances, application frameworks, and third-party software, must be securely configured before deployment and reviewed regularly after.

You're expected to remove or disable insecure features, replace default passwords, close unused ports, and document configuration standards for every system type. Applying secure configurations isn't a one-time task; it's a repeatable baseline enforced at scale and tracked across updates.

Pro-tip: Drata monitors your cloud assets, flags configuration drift, and checks for default settings across systems, helping teams enforce hardening standards automatically and surface exceptions before they become audit issues.

3. Protect Stored Account Data

Cardholder data is only as secure as its environment. Stored account data, such as the PAN, must be protected with strong cryptography so it stays unreadable even if an attacker gains access. Encryption keys must be protected, rotated, and managed with the same level of care.

It's easy to underestimate how many places cardholder data ends up: databases, backups, logs, and test environments. Without controls to detect and restrict data sprawl, sensitive information surfaces in unexpected places, expanding your PCI scope. (Under v4.0.1, organizations using keyed cryptographic hashes to render PANs unreadable should review the clarified applicability notes.)

Pro-tip: Drata monitors your storage configurations and validates that encryption is enabled where required, so you can track systems that store cardholder data, surface exposure points, and keep key management aligned with PCI requirements.

4. Protect Cardholder Data With Strong Cryptography During Transmission

Cardholder data needs protection at rest and in motion. Whenever it travels across open, public networks, encrypt it using strong cryptography like TLS 1.2 or higher. Outdated protocols like SSL and early TLS are no longer acceptable.

This covers transmissions between your systems and customers, payment processors, APIs, and internal tools running over cloud or hybrid networks. Encryption should be enforced, not optional, and misconfigurations like weak cipher suites or expired certificates can quietly open the door to interception.

Pro-tip: Drata scans your environment for weak or missing encryption settings, catching unsupported protocols, exposed endpoints, and insecure configurations before they create audit issues, or worse, breaches.

5. Protect All Systems and Networks From Malicious Software

Malware, including viruses, worms, ransomware, spyware, and malicious scripts, doesn't need a complex exploit to cause damage. One unmonitored endpoint, an outdated dependency, or an overlooked phishing email is enough. PCI DSS expects organizations to actively detect, prevent, and respond to malicious software across every environment where it's a risk.

Traditional antivirus for workstations falls under that umbrella, and so do behavior-based tools for servers, cloud workloads, and developer machines. Automated scans, threat detection, and alerting are part of the equation, but so is having an incident response plan for when something gets through.

Pro-tip: Drata keeps tabs on malware defenses across your environment, flags gaps in coverage, and confirms that protections stay active and up to date.

6. Develop and Maintain Secure Systems and Software

Every new feature, update, or third-party tool introduces potential risk. PCI DSS calls for building security into your systems from day one and maintaining it throughout their lifecycle. Code should be reviewed, systems patched, and known vulnerabilities addressed quickly.

Outdated software is a common entry point. Under v4.0.1, patches for critical vulnerabilities must be installed within 30 days. Your team needs a clear process for applying security updates, decommissioning outdated components, and vetting new tools before deployment.

Pro-tip: Drata continuously monitors your assets and dependencies, alerting you to missing patches and outdated systems so nothing quietly drifts out of compliance.

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

Not everyone needs access to cardholder data, and the more people who have it, the more you're exposed. PCI DSS expects access to be limited to those whose roles genuinely require it, applying "need to know" to both systems and people.

Access controls should be role-based, reviewed regularly, and enforced through least privilege. When someone changes teams or leaves, their access should change too. Shared accounts, overly broad permissions, and access granted "just in case" are all red flags during an audit.

Pro-tip: Drata continuously monitors access levels, flags excessive permissions, and helps enforce least privilege. It also makes it easy to review and revoke access when roles change or employees are offboarded.

8. Identify Users and Authenticate Access to System Components

You can't control what you can't trace. PCI DSS requires that every user accessing in-scope systems be uniquely identified and authenticated: no shared logins, no mystery accounts.

Every user should have a unique ID, and access should require more than just a password. Multi-factor authentication (MFA) is expected, especially for administrative and remote access. Under v4.0.1, MFA for non-administrative CDE access doesn't apply to accounts that already use phishing-resistant authentication factors.

Pro-tip: Drata integrates with your identity provider to track who has access to what, confirms MFA is enforced, and flags shared or orphaned accounts before they create risk.

9. Restrict Physical Access to Cardholder Data

Not all threats come through a network. Offices, server rooms, and data centers where cardholder data is stored or accessed must be protected from unauthorized entry.

Only approved personnel should have access, and that access needs to be logged, reviewed, and revoked when no longer needed. Paper records, removable media, and exposed terminals can all pull environments into scope if they aren't properly secured.

Pro-tip: Drata helps track which personnel have access to physical systems tied to the CDE and assists in documenting controls and maintaining audit-ready records for site security, visitor logs, and hardware access.

10. Log and Monitor All Access to System Components and Cardholder Data

When something goes wrong, logs are often the only evidence of what happened. PCI DSS calls for detailed audit trails tracking who accessed what, when, and from where. That data helps detect suspicious behavior and supports investigations.

With thousands of events flowing through your systems every hour, manual log review isn't practical, which is why automated monitoring is essential. Well-tuned alerts can surface unusual activity before it becomes a breach.

Pro-tip: Drata connects with your logging tools to confirm key events are captured, stored securely, and retained as required, and validates that alerting is in place so your team stays ahead of emerging threats.

11. Test Security of Systems and Networks Regularly

Security controls degrade over time. Software changes, new threats emerge, and yesterday's configuration might not hold up tomorrow. You're expected to test your defenses on a regular schedule, not just during audit season.

This includes vulnerability scans, configuration reviews, and penetration tests. Under v4.0.1, penetration testing must happen at least every 12 months and after any significant change, covering segmentation controls where segmentation is used. Service providers must validate their segmentation controls every six months. External vulnerability scans must be performed by an Approved Scanning Vendor (ASV).

Pro-tip: Drata tracks the cadence of vulnerability scans and penetration tests, documents results, assigns remediation tasks, and verifies findings are resolved. Note that Drata is not an ASV, so you'll still engage an ASV for the required external scans.

12. Support Information Security With Organizational Policies and Programs

Security is a business-wide commitment, so your organization should back its controls with policies, defined responsibilities, and ongoing education. Engineers secure systems, HR manages onboarding and offboarding, and employees handle data every day. A strong program gives each team the guidance they need and holds them accountable.

Pro-tip: Drata provides a library of PCI DSS v4.0.1–aligned policy templates, tracks employee acknowledgments, and helps manage security awareness training. It also links policies directly to controls, so your documentation stays aligned with how the business operates.

What to Avoid as You Work Through Your PCI DSS Checklist

As you implement your PCI DSS checklist, avoid these common mistakes that slow teams down or put audits at risk:

1. Treating compliance like an IT project. PCI DSS cuts across teams. Engineering may own infrastructure, but HR manages onboarding, Finance stores payment data, and Legal defines vendor agreements. If compliance lives in a silo, it breaks. Build governance early and make it a company-wide initiative.

2. Skipping a proper scoping process. Everything hinges on scope. If you don't define which systems and workflows touch cardholder data, you'll either miss requirements or over-engineer your entire environment.

3. Choosing the wrong SAQ. There are 10 SAQ types, each covering a different subset of requirements. Using the wrong one, out of convenience or guesswork, can result in noncompliance.

4. Treating vulnerability scans as a final stamp of approval. Passing a scan doesn't mean you're PCI compliant. It's one requirement among many; some vendors overstate its significance with "compliance badges."

5. Ignoring third-party exposure. If a vendor handles card data on your behalf, you're still accountable for ensuring proper controls are in place.

6. Waiting until a customer asks for a report. By the time a deal depends on PCI compliance, you're already behind. Treat it as part of your go-to-market readiness.

Get PCI DSS Compliant Without Slowing Down

PCI DSS v4.0.1 raised the bar, and for good reason. Customers, partners, and regulators expect payment data to be protected with intention, not just checklists. Still, compliance doesn't have to come at the cost of speed or focus.

Drata helps you implement, monitor, and maintain PCI controls with pre-mapped controls, policy templates, and automated evidence collection, plus the ability to filter requirements in and out of scope based on your SAQ type. From mapping your scope to preparing for your QSA, you'll have a clear path forward and fewer hours sunk into spreadsheets and screenshots.

Book a demo to see how Drata simplifies PCI compliance and gets you audit-ready faster.

PCI DSS Compliance Checklist FAQs