Any organization that stores, processes, or transmits payment card data answers to a security standard most owners have heard of but few have read in full. The Payment Card Industry Data Security Standard (PCI DSS) provides a baseline of technical and operational requirements designed to protect account data. This article covers the 12 core requirements at a summary level and flags the version 4.0 changes that now carry real assessment consequences.
The standard matters beyond retail checkout counters. SaaS platforms that bill customers directly, healthcare organizations with patient payment portals, and technology vendors processing card payments on behalf of clients all fall under its scope. Understanding the structure of PCI DSS, and tracking what the 4.0 revision changed, helps a compliance or security team plan remediation work before an assessor finds the gaps first.
What Is PCI DSS?
PCI DSS is a global data security standard maintained by the PCI Security Standards Council. The standard applies to merchants, service providers, and any other entity that handles cardholder data. It defines a common set of controls across network security, access management, monitoring, and governance.
The requirements are organized into 12 principal categories grouped under six broader control objectives: building a secure network, protecting account data, maintaining a vulnerability management program, implementing strong access controls, monitoring and testing networks, and maintaining an information security policy.
What Are the 12 PCI DSS Requirements?
The 12 core requirements of PCI DSS have remained consistent across versions, including the current v4.0.1 release. At a summary level, the requirements break down as follows.
- Requirement 1: Install and Maintain Network Security Controls. Firewalls and segmentation rules block unauthorized access into the cardholder data environment, keeping attackers out of critical systems.
- Requirement 2: Apply Secure Configurations to All System Components. Default passwords and security settings from vendors are widely known and frequently exploited, so organizations must change all default credentials and maintain secure configurations.
- Requirement 3: Protect Stored Account Data. Stored cardholder data must be minimized, encrypted, and retained only for legitimate business needs.
- Requirement 4: Protect Cardholder Data With Strong Cryptography During Transmission Over Open, Public Networks. Encryption protects card data as it moves across the internet or other public networks.
- Requirement 5: Protect All Systems and Networks From Malicious Software. Anti-malware tools, deployed and kept current, protect the cardholder data environment from malicious software.
- Requirement 6: Develop and Maintain Secure Systems and Software. Secure coding practices, patch management, and change control reduce exploitable vulnerabilities in applications touching card data.
- Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know. Access gets limited to what a given role actually requires.
- Requirement 8: Identify Users and Authenticate Access to System Components. Unique IDs, strong authentication, and multi-factor authentication for administrative and remote access confirm who touches sensitive systems.
- Requirement 9: Restrict Physical Access to Cardholder Data. Physical security controls prevent unauthorized access to cardholder data stored on premises, including access controls to sensitive areas and secure destruction of media.
- Requirement 10: Log and Monitor All Access to System Components and Cardholder Data. Tracking and reviewing access to systems and data helps detect suspicious activity.
- Requirement 11: Test Security of Systems and Networks Regularly. Vulnerability scans, penetration testing, and control testing validate security effectiveness on an ongoing basis.
- Requirement 12: Support Information Security With Organizational Policies and Programs. Documented security policies, assigned responsibilities, and trained personnel tie the other 11 requirements together.
What Is PCI DSS 4.0?
The PCI Security Standards Council announced Version 4.0 of the standard in March 2022. Version 3.2.1 officially retired two years later, making 4.0 the sole active standard from that point forward.
Version 4.0 introduced 64 new or updated requirements, with 51 designated as "future-dated" and 13 effective immediately upon rollout. A limited revision followed soon after: PCI DSS v4.0.1 was published in mid-2024, with no new or deleted requirements, only corrections and clarifications. Version 4.0 itself retired at the end of 2024, so v4.0.1 became the only active version for every assessment conducted from 2025 onward.
Several immediate changes shifted how organizations document compliance. A new requirement, 12.3.2, calls for documenting each customized approach a business uses to meet a control and performing a targeted risk analysis to justify it. Another immediate requirement, 12.5.2, calls for documenting and confirming PCI DSS scope, including the cardholder data environment and everything that stores, processes, or transmits card data, at least once every 12 months.
Which PCI DSS 4.0 Requirements Became Mandatory in 2025?
As of March 31, 2025, every future-dated requirement is mandatory, with no additional grace period. Qualified Security Assessors now evaluate these requirements during every assessment. For a business still treating these items as optional, that window has closed.
Three areas carry the most practical weight for small and mid-sized businesses.
- Expanded multi-factor authentication. Requirement 8.4.2, one of the future-dated controls effective March 31, 2025, broadens where multi-factor authentication applies beyond remote access alone.
- Stronger password requirements. Password policy moved toward a 12-character minimum as part of the authentication control set.
- Authenticated internal vulnerability scanning and payment page monitoring. Requirement 6 clarified applicability notes for managing payment page scripts, a direct response to web-skimming attacks against checkout pages.
For organizations whose last assessment predated the deadline, 2026 marks the first full calendar year in which every PCI DSS assessment occurs after the cutoff, meaning some of these controls may be tested as mandatory for the first time.
Why PCI DSS 4.0 Compliance Carries More Weight Now
An assessment under the current standard no longer treats the future-dated controls as aspirational. A Qualified Security Assessor reviews them with the same rigor applied to any other requirement. A gap in multi-factor authentication coverage, password strength, or payment page monitoring now produces a documented finding rather than a note for next year. Noncompliance can also trigger escalating fines from card networks, levied through the merchant's acquiring bank, along with exposure to fraud liability if a breach involving card data follows.
For a SaaS company billing customers directly or a healthcare provider running a patient payment portal, the stakes extend past the card brands. A breach touching payment data frequently triggers state breach notification obligations and customer trust damage that outlasts any processor penalty.
How to Prepare for a PCI DSS 4.0.1 Assessment
A practical path toward readiness follows a few consistent steps regardless of company size.
- Define the cardholder data environment precisely, mapping every system that stores, processes, or transmits card data.
- Run a gap assessment against the current 12 requirements, with particular attention to the formerly future-dated controls.
- Remediate access control, authentication, and logging gaps before engaging an assessor or completing a self-assessment questionnaire.
- Decide between a self-assessment questionnaire and a formal Report on Compliance based on transaction volume and processor requirements.
- Build the annual scope confirmation and targeted risk analysis documentation into a recurring calendar item rather than a one-time project.
Moving Forward With PCI DSS 4.0.1
PCI DSS was never a one-time checklist, and the 4.0.1 revision makes that clear. The 12 requirements still provide the structural map, but the controls once labeled as future best practices now carry full assessment weight. Businesses handling card data gain the most by treating compliance as a continuous program rather than an annual scramble, and by closing gaps in authentication, logging, and payment page security before an assessor identifies them.
Planet 9 is a Bay Area cybersecurity consulting firm specializing in PCI DSS readiness for SMBs in retail, e-commerce, and payments. Our vCISOs and compliance managers help organizations choose the right approach, configure GRC tools if needed, and get audit-ready without wasted time.
