New: Citizen Developer Security | Let everyone develop. Securely.

See how

Blog

PCI DSS compliance requirements

12 MIN

PCI DSS Compliance Requirements blog cover

What is PCI DSS?

Any financial institution, proprietor, or other entity that handles sensitive information must adhere to adequate security standards. Payment security is essential for any entity that processes, transmits, or stores cardholder data. The Payment Card Industry Data Security Standard (PCI DSS) compliance requirements help guard the integrity of this card payment data by providing a rubric of operational and technical requirements for organizations accepting or processing payment transactions.

The PCI DSS is a strict compliance standard, especially with respect to penalties. The potential costs of a security breach include:

  • Fines from the card brands, typically passed on through your acquiring bank
  • Increased audit requirements
  • Cost of printing and postage for customer notification mailing
  • Cost of staff time during security recovery
  • Cost of lost business during register or store closures and processing time

In addition, organizations that do not adequately safeguard cardholder data risk decreased sales due to a marred public image and loss of customer confidence should data breaches occur. Organizations that still fail to enforce adequate security risk losing the privilege of accepting card payments.

Who Do PCI DSS Requirements Apply To?

PCI compliance requirements are overseen by the PCI Security Standards Council, an independent body that was created by the major payment card brands. PCI DSS stands for Payment Card Industry Data Security Standard. As defined, these standards apply to every organization that accepts, handles, or processes card payments.

12 PCI Compliance Requirements

Updated November 2026: the requirement names below follow PCI DSS v4.0.1, the current version of the standard.

  1. Install and maintain network security controls
  2. Apply secure configurations to all system components
  3. Protect stored account data
  4. Protect cardholder data with strong cryptography during transmission over open, public networks
  5. Protect all systems and networks from malicious software
  6. Develop and maintain secure systems and software
  7. Restrict access to system components and cardholder data by business need to know
  8. Identify users and authenticate access to system components
  9. Restrict physical access to cardholder data
  10. Log and monitor all access to system components and cardholder data
  11. Test security of systems and networks regularly
  12. Support information security with organizational policies and programs

PCI DSS Requirement 1: Install and maintain network security controls

This first requirement ensures merchants protect card data by creating a secure network through the proper configuration of a firewall. Firewalls restrict incoming and outgoing network traffic through rules and criteria configured by your organization, and thus are instrumental in implementing access control.

Organizations should establish firewalls and router standards, which allow for a standardized process for allowing or denying changes to access rules for the network. Configuration rules should be reviewed twice a year, including access controls.

PCI DSS Requirement 2: Apply secure configurations to all system components

Many operating systems and devices come with factory default settings such as usernames, passwords, and other configuration parameters. These parameters are insecure, easy to guess, and frequently posted on the internet. Nissan fell victim to a supply chain attack because of an unchanged, default password.

For this reason, using default passwords is forbidden. Organizations should maintain a list of all systems utilized and a standard set of security configuration procedures. These procedures should be followed each time a new system is added to prevent the risk of vulnerability due to the lack of a password change.

PCI DSS Requirement 3: Protect stored account data

This is the title track of the PCI album: Protecting cardholder data is the entire purpose of PCI DSS compliance requirements. In order to achieve this goal, merchants must document what data they want to store, where they want to store it, and how long they want to retain this data.

This requirement prescribes encryption using an industry-accepted algorithm, such as SHA-256, AES-256, or RSA 2048, to all cardholder data. Organizations should follow best practices surrounding encryption and ensure an effective encryption key management process is implemented. Organizations can use card data discovery tools to reveal instances where card data is fully displayed and interceptable, such as in log files, databases, spreadsheets, etc. Further, this requirement includes rules for how primary account numbers should be displayed, such as showing only the first six and last four digits with the rest redacted.

PCI DSS Requirement 4: Protect cardholder data with strong cryptography during transmission over open, public networks

Similarly to requirement 3, organizations must secure the card data when it is transmitted over an open or public network. This includes the internet, 802.11, Bluetooth, GSM, CDMA, and GPRS.

Organizations must map where card data is being sent to and from and should utilize a form of secure transmission protocol when transporting data over a public network. Using TLS, SSH, or another form of encrypted transmission helps reduce the likelihood of successful interception and compromise.

PCI DSS Requirement 5: Protect all systems and networks from malicious software

Organizations should protect against malware. All systems including the workstations, laptops, and mobile devices that employees may use to access the system both locally and remotely should have an anti-virus solution deployed on them.

To fulfill this requirement, merchants need to ensure that anti-virus or anti-malware programs are updated on a regular basis to detect known malware. They must also ensure those anti-virus mechanisms are always active, using the latest signatures, and generating auditable logs. Maintaining an up-to-date anti-malware program prevents known malware from infecting systems.

PCI DSS Requirement 6: Develop and maintain secure systems and software

Fun fact: over 70% of breaches could have been prevented by keeping dependencies updated–regular updates cannot be ignored. Organizations must limit the potential for exploits by deploying vulnerability patches in a timely manner. Organizations must ensure all systems in the card data environment remain up to date, including:

  • Operating systems
  • Firewalls, routers, switches
  • Application software
  • Databases
  • POS terminals

In addition, organizations should define and implement a development process that enforces security requirements in all phases of development.

PCI DSS Requirement 7: Restrict access to system components and cardholder data by business need to know

Need to Know is a fundamental concept for implementing strong access control measures; this idea is synonymous with the principle of least privilege. To support security, organizations must be able to allow or deny access to the cardholder data system based on the specific individual.

Role-based access control (RBAC) is key to granting access to card data and systems involved in handling sensitive data.

PCI DSS Requirement 8: Identify users and authenticate access to system components

Shared passwords are never appropriate. Each authorized user and service with access to the card data system should have a unique identifier with an appropriately complex password.

IAM offers an elegant solution for identity management and further supports the earlier requirement of RBAC. In addition, 2FA or multi factor authentication is required to be implemented to help control remote access.

PCI DSS Requirement 9: Restrict physical access to cardholder data

Without physical access controls, unauthorized persons could gain access to the facility holding sensitive data to steal, disable, interrupt, or destroy critical systems and cardholder data. For this reason, physical access controls are necessary.

Organizations should:

  • Use video cameras and electronic access control to monitor entry and exit doors of physical locations such as data centers.
  • Retain the recordings or access logs of personnel movement for a minimum of 90 days.
  • Implement an access process that allows distinguishing between authorized visitors and employees.
  • All removable or portable media containing the cardholder data must be physically protected.
  • All media must be destroyed when the business no longer needs it.
  • Physical security must be in place, otherwise, this undermines cyber security.

PCI DSS Requirement 10: Log and monitor all access to system components and cardholder data

All the systems must have the correct audit policy set and send the logs to a centralized log management server. These logs must be reviewed at least daily to look for anomalies and suspicious activities.

PCI DSS states that audit trail records meet a certain standard in terms of the content of the information. Time synchronization is required. Audit data must be secured, and this data must be maintained for a period no shorter than a year.

PCI DSS Requirement 11: Test security of systems and networks regularly

New vulnerabilities are discovered every day by security researchers and hackers. All systems and processes must be tested on a frequent basis to ensure that security is maintained.

Regular security testing activities are required:

  • Wireless analyzer scan to detect and identify all authorized and unauthorized wireless access points on a quarterly basis.
  • All external IPs and domains exposed in the cardholder data environment are required to be scanned by a PCI Approved Scanning Vendor (ASV) at least quarterly.
  • Internal vulnerability scans must be conducted at least quarterly.
  • All external IPs and domains must go through an application and network penetration test at least yearly, or after any significant change.
  • File monitoring is a necessity, too. The system should perform file comparisons each week to detect changes that may have otherwise gone unnoticed.

PCI DSS Requirement 12: Support information security with organizational policies and programs

Educating personnel on security best practices is a powerful way to improve an organization’s security posture. The information security policy must be annually reviewed and disseminated to all the employees, vendors, and contractors–these individuals must read and acknowledge the policy.

This requirement also requires you to perform:

  • An annual, formal risk assessment that identifies critical assets, threats, and vulnerabilities.
  • User awareness training
  • Employee background checks
  • Incident management
  • All these requirements are reviewed by a quality assurance assessor and verified that they are adequately implemented.
Shift to AI podcast hosted by Roland Cloutier. Listen nowShift to AI podcast hosted by Roland Cloutier. Listen nowShift to AI podcast hosted by Roland Cloutier. Listen now

PCI DSS Audit

Determining Scope

Before implementing compliance measures for PCI DSS, organizations should determine the scope of the compliance requirements applicable to their organization. Determining the appropriate scope is key to balancing compliance costs, operations costs, and risks associated with interacting with payment card data.

PCI DSS Levels

All financial entities that handle payment card data fall onto one of 4 PCI compliance levels. This concept of different tiers of cybersecurity is not new – Google SLSA and the NIST Cybersecurity Framework both utilize this tier system when categorizing security rigor. Similar to levels within SLSA, these 4 levels pertain to the validation stringency prescribed to the organization; unlike SLSA, lower levels indicate a higher validation level. A merchant’s validation level is determined based on the transaction volume it handles per year, though they may be forced to conform to higher levels if they suffer a breach.

The levels as defined by Mastercard and Visa, two of the creators of PCI DSS, are as follows:

Level Mastercard Criteria Visa Criteria Requirements
1 > 6M Mastercard + Maestro transactions

Any merchant that has suffered a hack or an attack that resulted in an Account Data Compromise (ADC) Event

Any merchant that Mastercard, in its sole discretion, determines should meet the Level 1 merchant requirements to minimize risk to the system

> 6M Visa transactions annually

Any merchant that has suffered a hack or an attack that resulted in an Account Data Compromise (ADC) Event

Any merchant that Visa, in its sole discretion, determines should meet the Level 1 merchant requirements to minimize risk to the system

Annual PCI DSS assessment resulting in the completion of a Report on Compliance

Penetration test at least annually

Quarterly network scan by Approved Scanning Vendor

Submission of an Attestation of Compliance Form

2 6M – 1M Mastercard + Maestro transactions 6M – 1M Visa transactions annually Annual Self-Assessment Questionnaire

Penetration test at least annually

Quarterly network scan by Approved Scanning Vendor

Submission of an Attestation of Compliance Form

3 1M – 20,000 Mastercard + Maestro transactions 1M – 20,000 Visa e-commerce transactions annually Annual Self-Assessment Questionnaire

Quarterly network scan by Approved Scanning Vendor

Submission of an Attestation of Compliance Form

4 All other merchants < 20,000 Visa e-commerce transactions annually

< 1,000,000 Visa transactions per year, regardless of acceptance channel

Annual Self-Assessment Questionnaire

Quarterly network scan by Approved Scanning Vendor

Submission of an Attestation of Compliance Form

The measure of transaction volume is based on the aggregate number of transactions from a merchant Doing Business As (‘DBA’) or unique identity. If an organization has multiple DBAs and shares cardholder data between them this measure will aggregate all DBAs transactions under a corporation together. Otherwise, auditors may consider the individual DBA transaction volume to determine the appropriate validation level.

How Cycode Can Help Satisfy PCI DSS Requirements

PCI DSS compliance is difficult, however, the security benefits of implementation are massive for companies. Because of the mandatory nature of this framework, organizations don’t have a choice in the matter.

PCI DSS allows organizations to choose which tools to use to help comply with security requirements. Cycode greatly improves an organization’s ability to enforce the provisions required by PCI DSS.

Cycode enables security teams to view security insights from every SCM, build system, and cloud environment in a single place, including a list of security policy violations. These security violations are displayed in a traceable manner to make remediation much simpler.

For example, PCI requirement 3 requires tracking of data provenance. Cycode provides a solution by enabling users to view the state of security policy related to encryption of data-at-rest. From here, we can confirm whether violations exist and if this policy is being applied across all components. This provides audit provenance for PCI requirement 3, which can be directly shared with auditors.

Cycode includes workflows that help ensure adherence to best practices, such as the principle of least privilege. Cycode’s Agentic Workflows can be used to send alerts, create tickets, and automatically remediate cases where the configurations violate security controls as outlined in PCI. For example, workflows may prescribe remediating action when Cycode detects unused access to a repository that violates need-to-know as described in requirement 7.

Although PCI DSS compliance is difficult, Cycode gives you the visibility, policies, and tools to make adhering to these standards much easier and more cost effective for your organization. Security, development, and devops personnel all benefit from the effective use of security tools.

Want to Learn More?

Schedule a demo to learn how Cycode can help secure your software supply chain.

See Cycode in action. Book a demoSee Cycode in action. Book a demoSee Cycode in action. Book a demo

FAQ

Frequently asked questions

What is PCI DSS?

The Payment Card Industry Data Security Standard (PCI DSS) is a set of security requirements for any organization that stores, processes, or transmits payment card data. It is maintained by the PCI Security Standards Council, founded by the major card brands, and enforced through the card brands and acquiring banks rather than by law.

What is the current version of PCI DSS?

The current version is PCI DSS v4.0.1, a limited revision of v4.0 published in June 2024. Version 3.2.1 was retired on March 31, 2024, and the new requirements that v4.0 introduced as future-dated became mandatory on March 31, 2025. Read why ASPM is essential for PCI DSS 4.0.

What are the 12 PCI DSS requirements in version 4.0?

1. Install and maintain network security controls. 2. Apply secure configurations to all system components. 3. Protect stored account data. 4. Protect cardholder data with strong cryptography during transmission over open, public networks. 5. Protect all systems and networks from malicious software. 6. Develop and maintain secure systems and software. 7. Restrict access to system components and cardholder data by business need to know. 8. Identify users and authenticate access to system components. 9. Restrict physical access to cardholder data. 10. Log and monitor all access to system components and cardholder data. 11. Test security of systems and networks regularly. 12. Support information security with organizational policies and programs.

Who has to comply with PCI DSS?

Every merchant and service provider that stores, processes, or transmits cardholder data, or that can affect the security of that data, regardless of size. That includes payment processors, hosting providers, and software providers whose systems touch the cardholder data environment. Using a third-party payment provider can shrink your scope, but it does not remove your obligations entirely.

What is the difference between a ROC and an SAQ?

A Report on Compliance (ROC) is a full assessment carried out by a Qualified Security Assessor, generally required for Level 1 merchants and service providers. A Self-Assessment Questionnaire (SAQ) is a self-evaluation that smaller merchants complete themselves, with different SAQ types depending on how they accept card payments. Both are usually accompanied by an Attestation of Compliance (AOC).

How does PCI DSS apply to application security?

Requirement 6 covers secure software: training developers, reviewing custom code for vulnerabilities before release, keeping an inventory of custom and third-party software components, and managing vulnerabilities in them. Teams typically meet these with SAST for custom code, SCA and a software bill of materials for third-party components, and secrets detection to keep credentials out of code. Cycode's Agentic Code Scanning runs deterministic SAST and agentic analysis as one system, including on code written by AI coding assistants.

How often do you need to test for PCI DSS?

Compliance is validated annually, but several controls run more often. External vulnerability scans by an Approved Scanning Vendor and internal scans are required at least quarterly and after significant changes, and penetration testing is required at least once a year and after significant changes. Continuous scanning in the development pipeline helps keep these results clean between assessments.

Can a security tool satisfy PCI DSS on its own?

No. Meeting PCI DSS depends on your controls, processes, and assessment, not on a single product. Tools help you implement the requirements and produce evidence for assessors. Cycode's ASPM platform helps teams find and fix risk across code, dependencies, secrets, and pipelines, and report on it against frameworks such as PCI DSS. See our overview of security frameworks and standards.

How can AI help security teams keep up with PCI DSS requirements?

AI can take on the repetitive work between assessments: triaging findings, prioritizing by exploitability, routing each issue to its owner, and proposing fixes. Cycode AI does this with Maestro, Cycode's agentic orchestration engine, and Agentic Workflows that act automatically when risk appears, inside boundaries the security team sets and with an audit trail assessors can review.