Knowledge Article

The 12 PCI DSS Requirements (v4.0): Compliance Checklist for 2026

What Is PCI DSS?

The Payment Card Industry Data Security Standard (PCI DSS) is a global set of data security security requirements designed to ensure that all organizations handling payment card information maintain a secure environment. Compliance is  a contractual obligation enforced by the payment brands and acquiring banks. 

The PCI DSS requirements are 12 core rules for securing cardholder data, grouped under six objectives: build secure networks, protect data, manage vulnerabilities, control access, monitor, and maintain a security policy. The 12 requirements in the latest version of PCI DSS (v4.0) can be summarized as follows:

Build and maintain a secure network and systems

1. Install & maintain network security controls: Use firewalls to protect cardholder data.

2. Apply secure configurations: Harden systems by changing default passwords and securing system settings.

 Protect account data

3. Protect stored account data: Encrypt stored cardholder data and only keep what’s necessary.

4. Protect data in transit: Encrypt cardholder data during transmission over open, public networks.

Maintain a vulnerability management program

5. Protect against malware: Use and regularly update anti-virus/anti-malware software.

6. Develop secure systems: Keep systems and applications patched and secure.

Implement strong access control measures

7. Restrict access: Limit access to cardholder data to “need-to-know” basis.

8. Identify users: Assign unique IDs and authenticate all users.

9. Restrict physical access: Control physical access to cardholder data.

Regularly monitor and test networks

10. Monitor & log access: Track and monitor all access to network resources and cardholder data.

11. Test security systems: Regularly test security systems and processes.

Maintain an information security policy

12. Maintain a policy: Have a policy for information security, including training for all staff.

This is part of a series of articles about PCI DSS compliance

Achieve PCI DSS Compliance on Unmanaged Laptops

Learn how to keep sensitive data secure and PCI DSS compliant when contractors and remote workers use personal laptops.

PCI DSS: Who Must Comply and How the Standard Is Enforced 

Any entity that stores, processes, or transmits cardholder data must comply with PCI DSS, regardless of its size or transaction volume. This includes retailers, e-commerce sites, payment processors, financial institutions, and third-party service providers. The standard groups organizations into levels based on annual transaction volume, with different reporting and validation requirements for each level. 

For example, large merchants typically require an annual on-site assessment by a Qualified Security Assessor (QSA), while smaller entities may be allowed to complete a self-assessment questionnaire.

Enforcement of PCI DSS is managed by the payment card brands, often through the acquiring banks. These banks are responsible for ensuring that their merchants comply, and may impose fines, heightened scrutiny, or even terminate the ability to accept card payments for entities that fail to meet requirements. 

In the event of a data breach, non-compliant organizations risk hefty penalties, reputational damage, and the obligation to notify affected individuals and mount expensive remediation efforts.

PCI DSS 4.0: The 12 Requirements in Detail

1. Install and Maintain Network Security Controls

Organizations must implement network security controls that prevent unauthorized access to systems that store, process, or transmit cardholder data. These controls define how traffic enters, exits, and moves within the environment, with a clear separation between the cardholder data environment and other networks. Controls must be explicitly designed, documented, and enforced to limit exposure paths. Poorly defined or misconfigured controls often leave unintended access routes that attackers can exploit.

Practical steps:

  • Deploy firewalls or equivalent network security controls at all network boundaries
  • Segment the cardholder data environment from corporate and public networks
  • Document allowed inbound and outbound traffic rules
  • Review and validate firewall rules and segmentation regularly
  • Monitor network traffic for unauthorized connections

2. Apply Secure Configurations

System components frequently ship with default settings that prioritize usability over security. PCI DSS requires organizations to harden systems so that only required services, protocols, and functions are enabled. Secure configurations reduce the attack surface and create consistency across environments. Configuration standards must be maintained over time as systems are updated or replaced.

Practical steps:

  • Disable unnecessary services, protocols, and ports
  • Remove or secure default accounts and credentials
  • Define baseline configuration standards for all system types
  • Use configuration management tools to detect drift
  • Review configurations after system or infrastructure changes

3. Protect Stored Account Data

Cardholder data stored at rest must be protected to prevent disclosure in the event of unauthorized access. PCI DSS strictly limits what data may be stored and how long it may be retained. Any stored cardholder data must be unreadable without proper authorization. Organizations must also be able to account for where data is stored across all systems.

Practical steps:

  • Do not store sensitive authentication data after authorization
  • Encrypt stored cardholder data using strong cryptography
  • Mask primary account numbers when displayed
  • Maintain an inventory of all data storage locations
  • Securely delete data that exceeds retention requirements

4. Protect Data in Transit

Cardholder data transmitted across open or untrusted networks must be protected against interception and modification. Encryption ensures confidentiality and integrity during transmission. Cryptographic mechanisms must be correctly implemented and maintained. Weak protocols or expired certificates undermine transport security and introduce compliance gaps.

Practical steps:

  • Use strong encryption such as TLS for data transmissions
  • Disable insecure protocols and cipher suites
  • Manage encryption keys and certificates securely
  • Rotate certificates and keys according to defined schedules
  • Monitor network traffic for unauthorized data transfers

5. Protect Against Malware

Malware presents a direct risk to systems that handle payment data by enabling data theft, remote control, or lateral movement. PCI DSS requires controls that detect, prevent, and respond to malware infections. These controls must apply to all relevant systems, including endpoints and servers. Detection capabilities must remain effective as threats evolve.

Practical steps:

  • Deploy anti-malware solutions on applicable systems
  • Keep malware signatures and engines up to date
  • Perform regular malware scans
  • Monitor systems for suspicious behavior
  • Isolate and remediate infected systems promptly

6. Develop Secure Systems

Applications and system components must be built and maintained with security in mind to reduce the introduction of vulnerabilities. PCI DSS requires security to be integrated into development and maintenance processes. Vulnerabilities introduced during development or left unpatched in production increase exposure to exploitation. Secure development practices reduce long-term operational risk.

Practical steps:

  • Follow secure coding standards during development
  • Perform code reviews focused on security issues
  • Scan applications and components for vulnerabilities
  • Apply security patches in a timely manner
  • Test systems regularly for newly discovered weaknesses

7. Restrict Access

Access to cardholder data must be limited to individuals whose job responsibilities require it. Broad or unmanaged access increases the impact of compromised credentials or insider misuse. PCI DSS enforces least privilege and requires periodic validation of access rights. Access controls must remain accurate as roles and personnel change.

Practical steps:

  • Define roles and associated access requirements
  • Enforce least privilege across systems and applications
  • Review user access rights regularly
  • Remove access promptly when roles change or employment ends
  • Document access approvals and changes

8. Identify Users

Every individual accessing systems in scope must be uniquely identifiable. Shared accounts prevent accountability and weaken audit trails. Strong authentication ensures that access is tied to a verified identity. User activity must be traceable to support investigations and compliance validation.

Practical steps:

  • Assign unique user IDs to all users
  • Prohibit shared or generic accounts
  • Implement multi-factor authentication where required
  • Log user authentication and activity events
  • Disable accounts when no longer needed

9. Restrict Physical Access

Physical access to systems that store or process cardholder data must be controlled and monitored. Unauthorized physical access can bypass logical security measures. PCI DSS requires physical safeguards that prevent tampering, theft, or unauthorized system interaction. Controls must apply to facilities, devices, and media.

Practical steps:

  • Restrict facility access using badges or access controls
  • Secure systems in locked rooms or cabinets
  • Maintain visitor logs and escort procedures
  • Monitor facilities using surveillance where appropriate
  • Review physical access records periodically

10. Monitor and Log Access

Logging and monitoring provide visibility into system activity and enable detection of suspicious behavior. PCI DSS requires comprehensive logging of access to systems and cardholder data. Logs must be protected to preserve their integrity. Regular review ensures that incidents are identified in a timely manner.

Practical steps:

  • Log access to systems and cardholder data
  • Protect logs from alteration or deletion
  • Retain logs according to defined retention requirements
  • Review logs regularly for anomalies
  • Use automated tools to support log analysis

11. Test Security Systems

Security controls must be validated through regular testing to confirm that they function as intended. Testing identifies weaknesses that may not be visible during normal operations. PCI DSS requires both automated and manual testing activities. Findings must be tracked until remediation is complete.

Practical steps:

  • Conduct regular vulnerability scans
  • Perform penetration testing on a defined schedule
  • Review firewall and security control configurations
  • Validate remediation of identified issues
  • Document testing results and corrective actions

12. Maintain a Policy

A formal information security policy establishes expectations and responsibilities across the organization. PCI DSS requires policies that address all aspects of protecting cardholder data. Policies must remain current and reflect actual practices. Awareness and enforcement are necessary for policies to be effective.

Practical steps:

  • Define and document an information security policy
  • Assign roles and responsibilities for security activities
  • Review and update policies regularly
  • Train personnel on policy requirements
  • Retain evidence of policy acknowledgment and training

Best Practices for Complying with PCI DSS Requirements 

Here are some of the ways that organizations can ensure they comply with the 12 PCI DSS requirements.

1. Leverage Secure Remote Access Solutions 

Remote workers and contractors often use personal or unmanaged devices, introducing significant compliance risks for PCI DSS environments. Traditional approaches like virtual desktop infrastructure (VDI) or issuing corporate hardware are expensive and complex to manage at scale. To address this, organizations can adopt secure remote access solutions that isolate business activity locally on user-owned devices without taking control of the whole system.

Solutions like Venn’s Blue Border create a company-controlled secure enclave on the user’s PC or Mac, where all work data is encrypted and access is strictly managed. Business applications run natively within this isolated environment, keeping them visually and functionally separate from personal activity. This approach enforces data loss prevention policies and standardized compliance checks, while allowing employees and contractors to work with their preferred local apps.

2. Adopt Zero Trust Network Access and Microsegmentation

Zero trust network access (ZTNA) assumes that no user or device is trusted by default, even if located within the corporate network. Organizations should implement identity-aware proxies, continuous authentication, and segmentation of workloads to prevent unauthorized lateral movement within the cardholder data environment. Microsegmentation further limits access by separating applications and services at a granular level.

Adopting these measures limits the blast radius of any breached account or system. Continuous validation of user and device trust, along with dynamic policy enforcement, aligns with PCI DSS goals of minimizing risk and controlling access to sensitive data. Microsegmentation also simplifies compliance by reducing PCI DSS scope for individual system segments.

3. Automate Controls in CI/CD with Policy-as-Code

Integrating PCI security controls into CI/CD pipelines ensures that compliance is embedded into the software development lifecycle. Policy-as-code solutions enable automated enforcement of security standards, such as secure configurations, vulnerability scanning, and authentication requirements. This reduces manual effort and errors, while maintaining a high velocity of software delivery.

Automated controls can detect, block, and remediate non-compliant changes before they reach production. Maintaining compliance artifacts such as code scan results and configuration reports helps demonstrate alignment with PCI DSS during audits. Policy-as-code also supports ongoing compliance by continuously verifying that standards are met with each code change.

4. Use Immutable Logging and Centralized Time via PTP/NTP

Immutable logging, with logs written to write-once storage or using tamper-evident mechanisms, preserves the integrity of forensic data required by PCI DSS. Centralized, synchronized time via PTP (Precision Time Protocol) or NTP (Network Time Protocol) ensures all logs across systems have accurate, consistent timestamps, which is critical for incident investigation and audit trails.

By aggregating and protecting logs, organizations can efficiently monitor, detect, and respond to anomalies or breaches. Centralized log management solutions also support compliance by simplifying log retention, searching, and reporting. Immutable and time-synchronized logs reduce the risk of undetected tampering and help satisfy audit and investigation requirements.

5. Integrate EDR, IDS/IPS, and WAF Telemetry for Correlated Detection

Aggregating telemetry from endpoint detection and response (EDR), intrusion detection/prevention systems (IDS/IPS), and web application firewalls (WAF) allows organizations to correlate data from multiple layers of defense. This integration provides a richer context for identifying attacks targeting payment environments and supports faster, more accurate incident response.

Correlated detection reduces blind spots, flags advanced threats, and enables automated or orchestrated response actions. Centralizing and normalizing this telemetry supports compliance reporting by demonstrating end-to-end visibility and continuous monitoring, as required by PCI DSS. Regular reviews of alerts and tuning detection rules further improve the effectiveness of these controls.

6. Rotate Keys and Secrets via Automation with Short TTLs

Automated management of cryptographic keys, API tokens, and secrets is critical for securing payment environments. Implementing frequent rotation, ideally with short time-to-live (TTL) settings, limits the window of opportunity for attackers to exploit compromised credentials. Secrets management platforms and orchestration tools can automate the process, reducing manual errors and oversight.

Regular rotation must be paired with strong access controls and tracking to ensure that only authorized processes can access sensitive secrets. Expiring credentials rapidly also aligns with PCI DSS guidance on limiting data exposure. Automation simplifies compliance, while enhancing overall security posture against credential-based attacks.

7. Continuously Scan and Pen Test Cloud Assets and Serverless

PCI DSS requires organizations to identify and mitigate vulnerabilities across their entire environment, including cloud and serverless assets. Automated vulnerability scanning and regular penetration testing detect misconfigurations, missing patches, and weaknesses in cloud-native services. Coverage should include infrastructure-as-code (IaC) templates, APIs, and ephemeral resources that may be overlooked in traditional assessments.

Continuous testing helps organizations keep pace with the rapid deployment cycles typical of cloud and serverless environments. Remediation efforts should be tracked and documented to demonstrate compliance. Coordinating scans and pen tests across all technical stacks ensures comprehensive visibility and early detection of potential compliance gaps.

8. Run Quarterly Tabletop Exercises for Payment Incidents

Quarterly tabletop exercises simulate realistic payment security incidents, testing the effectiveness of incident response plans in line with PCI DSS requirements. By involving key stakeholders, these exercises reveal gaps, clarify roles, and validate communication protocols. Scenarios should include data breaches, ransomware, and third-party compromises.

Such exercises improve organizational preparedness and reinforce the importance of payment security across teams. Lessons learned should be incorporated into updated incident response plans. Regular practice boosts confidence, speeds up actual incident response, and provides evidence of compliance activities during assessments.

9. Perform Third-Party Risk Reviews Before Onboarding Vendors

Vendors and service providers often have direct or indirect access to cardholder data environments, increasing the risk of third-party breaches. PCI DSS requires due diligence before onboarding new partners. This includes assessing their security posture, validating compliance certifications, and reviewing contractual requirements for data protection.

Continuous monitoring of third-party risk (through audits, questionnaires, and performance metrics) reduces exposure to supply chain attacks. Organizations should maintain updated inventories of service providers and their access rights. Proactive risk reviews demonstrate compliance with PCI DSS requirements and reduce the likelihood of incidents originating from external parties.

Supporting PCI DSS Compliance with Venn’s Blue Border™

Venn’s Blue Border™ helps organizations comply with PCI DSS by providing a secure, segregated, and encrypted environment for accessing cardholder data, ensuring that robust authentication, continuous monitoring, encryption, and secure access controls are in place. Venn’s technology helps mitigate risks associated with remote work on personal or unmanaged devices, supporting the enhanced security measures required by PCI DSS.

Venn is similar to an MDM solution, but for laptops. With Venn, work lives in a company-controlled Secure Enclave installed on the user’s PC or Mac, where all data is encrypted and access is managed. Work applications run locally within the Enclave – visually indicated by Venn’s Blue Border™ – protecting and isolating business activity while ensuring end-user privacy.

If you want to learn more about how Venn can help you meet PCI DSS with your users’ personal or unmanaged devices, feel free to book some time and we can connect you with an expert.