PCI DSS 4.0 Requirements Checklist for 2026

Here on the Ignyte blog, we talk a lot about general information security frameworks like ISO 27001 and government frameworks like CMMC and FedRAMP. But that doesn’t mean that’s all we understand.

One of the most broadly used security standards in the world is PCI DSS. The Payment Card Industry Data Security Standard is the standard that must be upheld by any and all entities that handle, process, or store cardholder data and authentication data for payments. Every merchant, every service provider, every bank; if payment information is involved, it needs to be handled at PCI DSS standards of security.

As you know, the larger and more commonly used the security framework, the greater the threat surface. With millions of entities required to use PCI DSS, there are just as many malicious actors trying to poke holes in it.

That’s why the PCI DSS framework undergoes continual improvement, with new versions and standards published routinely. The 1.0 version of the framework was released in 2004, the 4.0 version was released in 2022, and the 4.0.1 iteration was released in 2024. With the slow but steady rollout of these improvements, 4.0’s new requirements are now mandatory as of March 2025, when the previous major version is retired.

Now, nearly a year later, existing entities should be in compliance, and newcomers need to implement their own procedures to ensure compliance. With over 500 requirements across 12 domains, this isn’t a simple task. The full document outlining all of them (linked above) is nearly 400 pages long.

And with good reason. With billions of people around the world affected by data breaches, this information needs to be kept secure, and security must be taken seriously.

What do you need to know to successfully implement PCI DSS 4.0.1 in 2026? We’ve put together this checklist to help ensure as smooth a process as possible.

Who Must Comply and Penalties for Failure

First, who is this resource for? The fact is, any entity that accepts or handles credit cards needs to comply. That holds true no matter what kind of business, what industry, or even where in the world you are. It’s true whether you retain card information for ongoing subscriptions or just handle it once and purge it from your records.

It even holds true if you use a third-party payment processor to handle it all; you’re still responsible for making sure your implementation is compliant. Scope is more limited when you’re offloading most of the security to a third party, but you still have some requirements to meet.

This requirement is not enforced by a government or law enforcement agency; rather, it’s enforced by agreement between the payment processors themselves.

Noncompliance is not an option. The penalties are steep and severe, fitting for the risk involved. PCI DSS is about trust, and if customers can’t trust that their information will be secure, payment processors don’t want them doing business with you.

Penalties vary based on the scope of the violation or breach, and can range from $5,000 per month in fines, up to $100,000 per month in fines, or more. Beyond that, any data breach can result in compensation costs, and customers can take legal action. Brand reputation damage, loss of revenue, and closed businesses are common results.

How PCI DSS Compliance Works

PCI DSS is not a certification, and it’s not a one-and-done static position. It’s a continuous, ongoing process, with three sequential steps.

1. Assess. Take inventory of assets and processes handling cardholder data, and analyze them for potential vulnerabilities or violations of PCI DSS standards.
2. Repair. If vulnerabilities are found, fix them and ensure security and compliance.
3. Report. Document the results of the assessment process, record any remediation necessary, and share those reports (PCI Compliance Reports) with payment processors you work with.

This is done in a variety of ways and on a variety of schedules. Compliance must be validated annually, and you must perform quarterly scans. Continuous monitoring is also an ongoing requirement, with real-time monitoring part and parcel of PCI DSS 4.0. Testing and validation must also be done after significant changes to the environment, and there must be routine penetration testing as well. Self-assessment questionnaires are also common.

The PCI Security Standards Council, the organization maintaining PCI DSS, also certifies its own version of 3PAOs called QSAs: Qualified Security Assessors. Annual assessments and other reviews may need to be conducted or validated by a QSA, so finding one from the 400+ available is critical.

2026 PCI DSS Compliance Checklist

For obvious reasons, we’re not going to reproduce a 400-page document in a checklist format here. Instead, this checklist serves as a summary and general representation of the tasks and requirements you’ll need to handle across the 12 domains of PCI DSS. There are many more specific resources provided in the PCI document library, so find the one that suits your needs as necessary to follow along.

1: Install and Maintain Network Security Controls

Domain one is network security. This domain requires you to implement security controls that prevent unauthorized access to systems that handle, store, or process cardholder data. When you analyze your own systems, you must map how cardholder data flows and what systems it touches, and ensure all of them are secure. All of this must be explicit, planned, documented, and enforced.

Actionable Steps:

• Install firewalls and network security controls at all network borders.
• Segment any environments that handle cardholder data away from both public networks and non-secure corporate environments.
• Control and document inbound and outbound traffic and the rules that govern them.
• Regularly review, test, and validate firewall rules and segmentation implementation.
• Actively monitor, in real time, all network traffic for instances of unauthorized connections.

All network traffic that has the potential to touch PCI-controlled systems must be authorized only, monitored, and audited for security purposes.

2: Apply Secure Configurations to All System Components

Doing business in the modern era is not a matter of bespoke engineering, but more often the use of out-of-the-box apps and software meant to handle payments for you, host your storefront, and otherwise manage commerce.

These systems ship with default configurations, and those configurations may seem to be “good enough”, but the fact of the matter is, there’s no such thing as a one-size-fits-all solution. Section two of PCI DSS is all about ensuring that those configurations are set up correctly for your specific institution and your specific systems. Anything left running unnecessarily, or disabled when it shouldn’t be, is a potential threat vector.

Actionable Steps:

• Review your system components and disable unnecessary services, protocols, and ports.
• Remove default accounts, or secure their credentials.
• Define the baseline minimum configuration standards for all systems.
• Review configurations after any system or infrastructure changes.
• Use an automatic configuration management tool to detect changes and drift from standards.

When even a single misconfigured setting can let a malicious attacker compromise your payment systems, it’s paramount to have all of this done properly.

3: Protect Stored Account Data

PCI DSS has strict rules about what cardholder data you can store, how it must be stored, and how long you can retain the information. Any stored cardholder data must be secure against unauthorized access. It must be encrypted and rendered unreadable before storing it, no matter how it is stored.

If your organization does not store cardholder data at all, at any point, then you can skip this section. However, if you do store it, even if it’s only temporarily stored for a matter of minutes, hours, or days, you must comply.

Actionable Steps:

• Ensure that you do not store authentication data after authorization.
• Ensure cardholder data is encrypted using the strongest reasonably available cryptographic standards.
• When displayed, mask primary account numbers.
• Maintain an accurate and updated inventory of any system that stores data.
• Ensure secure deletion of data when it exceeds retention limits.

Industry-standard encryption changes from time to time, so make sure you’re using strong, non-compromised encryption standards.

4: Protect Cardholder Data in Transit

Part and parcel of doing business digitally is the transmission of cardholder data from the cardholder’s network to yours. You need to receive the information somehow, and that means the information travels over public, unsecured networks. Thus, you need to protect it while it’s in transit.

Actionable Steps:

• Ensure strong encryption for data in transmission, such as TLS.
• Disable cipher suites and insecure encryption protocols you don’t use.
• Ensure secure management of encryption certificates, keys, and other elements of the system.
• Maintain defined schedules for rotating certificates, security keys, and other frequent targets.
• Actively monitor network traffic for signs of unauthorized data transfers.

In the event that a man-in-the-middle attacker has compromised a system outside of your environment, any data they gather from you should be unreadable.

5: Protect All Systems and Networks from Malware

Malicious software takes many forms, and your systems need to be protected against them all.

Actionable Steps:

• Use relevant anti-malware and antivirus software on secure systems.
• Keep virus definitions and malware signature libraries up to date.
• Routinely scan systems for signs of malware.
• Actively monitor traffic for signs of malware behavior.
• Promptly isolate and remediate systems compromised by malware.

All of this has been standard in computer security for decades, so it’s nothing new.

6: Develop and Maintain Secure Systems

Any applications, system components, and other elements of your environment must be maintained in terms of security. Moreover, when possible, they should be designed with that security in mind from the ground up.

This is another potentially-skippable section if your organization does not do any custom development. However, if any system is customized, security must be kept at the forefront of the design.

Actionable Steps:

• Adhere to secure coding standards when developing new components.
• Routinely perform security-focused code reviews.
• Continually scan applications and systems for vulnerabilities.
• Ensure timely application of security patches and updates.
• Regularly test systems for signs of newly developed (zero-day) weaknesses.

Generally speaking, the fewer customized components you use, the lower your maintenance burden.

7: Restrict Access to Cardholder Data System Components

Any system that touches, handles, stores, or otherwise deals with cardholder data must operate under the principle of least privilege. Restrict access to only those who need to know, for as little time as is necessary, and monitor that access for signs of abuse. Only the bare minimum of people and accounts should have access, and access should be removed promptly when it’s no longer necessary.

Actionable Steps:

• Define roles and accounts for who needs access to sensitive data.
• Enforce the principle of least privilege across secure systems.
• Review user access rights routinely and remove unnecessary access.
• Promptly remove access when user roles change or employees leave.
• Document all approvals and changes to authorization and access.

Any account with access it doesn’t need is a liability that must be addressed.

8: Identify and Authenticate User Access to Systems

Most data breaches come from the inside, when employee access is compromised. Ensure that each individual with access to your systems has their own unique ID, which can be traced and monitored. Further, ensure that all access is secured, and violations are tracked and handled accordingly.

Actionable Steps:

• Define unique user IDs for all users.
• Prohibit, and monitor for, account sharing.
• Never use generic, multi-person-access accounts.
• Use Mult-Factor Authentication where possible.
• Log all user authentication events and activity.
• Proactively disable accounts when access is no longer required.

Compromised user accounts are one of the biggest threats, so ensure that they have as little access as possible.

9: Restrict Physical Access to Cardholder Data

If your business stores cardholder data at all, any physical location where that data is stored (including company servers) must be secured. Additionally, any systems that can access stored data must also be secured. Access must be monitored and reviewed routinely.

Actionable Steps:

• Restrict facility access behind badging systems and access controls.
• Ensure sensitive systems are in locked rooms or server cabinets.
• Maintain visitor logs for all visitors, contractors, or VIPs, and ensure they have escorts when in sensitive areas.
• Monitor facilities with surveillance, like CCTV, where necessary.
• Routinely review physical access logs for signs of suspicious activity.

The “man with a clipboard” social engineering attack is common, so take physical security seriously if it’s under your purview.

10: Monitor and Log All Access to Sensitive Systems

Many of the previous steps include a line like “monitor and log activity.” Section 10 is the specific monitoring requirements and access logging requirements.

Actionable Steps:

• Log all systems access.
• Protect log data from alteration or deletion.
• Retain logs as long as required by regulation.
• Review logs for signs of abnormalities.
• Use automation to review logs in a timely manner.

Logging and log reviews are a key part of maintaining and validating PCI DSS security.

11: Test Security

All elements of PCI DSS security must be tested and validated on a regular basis. For some components, this may mean ongoing, daily vulnerability scanning or malware detection. For others, it might mean weekly, monthly, quarterly, bi-annual, or annual testing. In all cases, any significant change to systems or architecture must trigger testing and validation.

Actionable Steps:

• Conduct vulnerability scans on a regular basis.
• Perform penetration testing as required on a schedule.
• Review security configurations routinely.
• Validate remediation of detected issues and document corrective actions.

PCI DSS security is a moving target, and continual testing is required to maintain compliance.

12: Maintain Security with Organizational Policies

All of this security should not just be something imposed on your organization by PCI DSS and the payment processors you use; it should be supported by internal policies and procedures. This encompasses company policies, employee training policies, documentation policies, and more.

Actionable Steps:

• Define and document your institutional information security policies.
• Assign roles and responsibilities for maintaining security and documentation.
• Train employees on their responsibilities and company policy rules.
• Retain evidence of training and policy acknowledgement.
• Review and routinely update policies as necessary.

Documentation across the board is required.

Keeping Tabs on PCI DSS Compliance Efforts

Keeping track of all of this, across 500+ security controls, is a huge task. That’s why we offer the Ignyte Assurance Platform. Our platform was designed for government-level information security and can easily encompass everything involved in PCI DSS compliance.

From monitoring implementation to storing logs and evidence, our platform can ensure your compliance process is as smooth as possible. To see how, simply book a demo today, and we’ll show you.