The Payment Card Industry Data Security Standard (PCI DSS) - V4.0.1 Compliance report
The Payment Card Industry Data Security Standard (PCI DSS) compliance report helps you assess your application's security against the requirements designed to protect cardholder account data.
About the PCI DSS V4.0.1
The Payment Card Industry Data Security Standard (PCI DSS) was developed to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally. PCI DSS provides a baseline of technical and operational requirements designed to protect account data.
PCI DSS comprises a minimum set of requirements for protecting cardholder data and can be enhanced by additional controls and practices to further mitigate risks, as well as local, regional, and sector laws and regulations. Additionally, legislation or regulatory requirements might require specific protection of personal information or other data elements (for example, cardholder name). PCI DSS does not supersede local or regional laws, government regulations, or other legal requirements.
The PCI DSS security requirements apply to all system components included in or connected to the cardholder data environment (CDE). The CDE is comprised of people, processes, and technologies that store, process, or transmit cardholder data or sensitive authentication data.
"System components" include network devices, servers, computing devices, and applications. Examples of system components include, but are not limited to, the following:
- Systems that provide security services (for example, authentication servers), facilitate segmentation (for example, internal firewalls), or might impact the security of the CDE (for example, name resolution or web redirection servers).
- Virtualization components such as virtual machines, virtual switches/routers, virtual appliances, virtual applications/desktops, and hypervisors.
- Network components including but not limited to firewalls, switches, routers, wireless access points, network appliances, and other security appliances.
- Server types including but not limited to web, application, database, authentication, mail, proxy, Network Time Protocol (NTP), and Domain Name System (DNS).
- Applications including all purchased and custom applications, including internal and external (for example, Internet) applications.
- Any other component or device located within or connected to the CDE.
Covered entities
PCI DSS applies to all entities involved in payment card processing—including merchants, processors, acquirers, issuers, and service providers, as well as all other entities that store, process, or transmit cardholder data (CHD) and/or sensitive authentication data (SAD).
PCI DSS requirements apply to organizations and environments where account data (cardholder data and/or sensitive authentication data) is stored, processed, or transmitted. Some PCI DSS requirements might also be applicable to organizations that have outsourced their payment operations or management of their CDE. Additionally, organizations that outsource their CDE or payment operations to third parties are responsible for ensuring that the account data is protected by the third party per the applicable PCI DSS requirements.
Compliance penalties
If a merchant or service provider does not comply with the security requirements or fails to rectify a security issue, the card companies might fine the acquiring member, or impose restrictions on the merchant or its agent.
Compliance required by
PCI DSS version 4.0.1 has replaced PCI DSS version 4.0 and is effective as of January 1, 2025. The PCI DSS version 4.0 cannot be used for PCI DSS compliance after December 31, 2024.
Regulators
The PCI Security Standards Council, and its founding members including American Express, Discover Financial Services, JCB, MasterCard Worldwide, and Visa International.
PCI DSS V4.0.1 report vulnerabilities
The following table lists the specific PCI DSS V4.0.1 requirements that are evaluated. Vulnerabilities found in your application are mapped to these requirements.
| ID | Name |
|---|---|
| Requirement 2 | Apply secure configurations to all system components |
| Requirement 2.2.2 | If the vendor default account(s) will be used, the default password is changed per Requirement 8.3.6. If the vendor default account(s) will not be used, the account is removed or disabled. |
| Requirement 2.2.4 | Only necessary services, protocols, daemons, and functions are enabled, and all unnecessary functionality is removed or disabled. |
| Requirement 2.2.6 | System security parameters are configured to prevent misuse. |
| Requirement 4 | Protect cardholder data with strong cryptography during transmission over open, public networks |
| Requirement 5 | Protect all systems and networks from malicious software |
| Requirement 6 | Develop and maintain secure systems and applications. |
| Requirement 6.2.1 | Bespoke and custom software are developed securely |
| Requirement 6.2.4.1 | Software engineering techniques or other methods are defined and in use by software development personnel to prevent or mitigate common software attacks and related vulnerabilities in bespoke and custom software, including but not limited to injection attacks, including SQL, LDAP, XPath, or other command, parameter, object, fault, or injection-type flaws. |
| Requirement 6.2.4.2 | Software engineering techniques or other methods are defined and in use by software development personnel to prevent or mitigate common software attacks and related vulnerabilities in bespoke and custom software, including but not limited to attacks on data and data structures, including attempts to manipulate buffers, pointers, input data, or shared data. |
| Requirement 6.2.4.3 | Software engineering techniques or other methods are defined and in use by software development personnel to prevent or mitigate common software attacks and related vulnerabilities in bespoke and custom software, including but not limited to attacks on cryptography usage, including attempts to exploit weak, insecure, or inappropriate cryptographic implementations, algorithms, cipher suites, or modes of operation. |
| Requirement 6.2.4.4 | Software engineering techniques or other methods are defined and in use by software development personnel to prevent or mitigate common software attacks and related vulnerabilities in bespoke and custom software, including but not limited to attacks on business logic, including attempts to abuse or bypass application features and functionalities through the manipulation of APIs, communication protocols and channels, client-side functionality, or other system/application functions and resources. This includes cross-site scripting (XSS) and cross-site request forgery (CSRF). |
| Requirement 6.2.4.5 | Software engineering techniques or other methods are defined and in use by software development personnel to prevent or mitigate common software attacks and related vulnerabilities in bespoke and custom software, including but not limited to Attacks on access control mechanisms, including attempts to bypass or abuse identification, authentication, or authorization mechanisms, or attempts to exploit weaknesses in the implementation of such mechanisms. |
| Requirement 6.3 | Security vulnerabilities are identified and addressed |
| Requirement 6.3.2 | An inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software is maintained to facilitate vulnerability and patch management. |
| Requirement 6.3.3 | All system components are protected from known vulnerabilities by installing applicable security patches/updates. |
| Requirement 6.4 | Public-facing web applications are protected against attacks. |
| Requirement 6.5.6 | Test data and test accounts are removed from system components before the system goes into production. |
| Requirement 7 | Restrict access to system components and cardholder data by business need to know. |
| Requirement 7.1 | Limit access to system components and cardholder data to only those individuals whose job requires such access. |
| Requirement 7.2.2 | Access is assigned to users, including privileged users, based on: Job classification and function and least privileges necessary to perform job responsibilities. |
| Requirement 7.2.6 | All user access to query repositories of stored cardholder data is restricted as follows: Via applications or other programmatic methods, with access and allowed actions based on user roles and least privileges. Only the responsible administrator(s) can directly access or query repositories of stored CHD. |
| Requirement 8.2.8 | If a user session has been idle for more than 15 minutes, the user is required to re-authenticate to re-activate the terminal or session. |
| Requirement 8.3.1 | All user access to system components for users and administrators is authenticated via at least one of the following authentication factors: Something you know, such as a password or passphrase. Something you have, such as a token device or smart card. Something you are, such as a biometric element |
| Requirement 8.3.2 | Strong cryptography is used to render all authentication factors unreadable during transmission and storage on all system components. |
| Requirement 8.6.2 | Passwords/passphrases for any application and system accounts that can be used for interactive login are not hard coded in scripts, configuration/property files, or bespoke and custom source code. |
| Requirement 11.4 | External and internal penetration testing is regularly performed, and exploitable vulnerabilities and security weaknesses are corrected. |