Payment card data remains a valuable target for cybercriminals, making strong security controls essential for any organization that accepts, processes, stores, or transmits payment card information. The Payment Card Industry Data Security Standard (PCI DSS) establishes a common set of security requirements designed to protect payment card account data and the systems that handle it.
PCI DSS compliance requires more than preparing for an annual assessment. Organizations need to understand where payment data resides, maintain appropriate security controls, manage vulnerabilities, monitor third-party service providers, and continually validate that their controls remain effective as technology and threats change.
What is PCI DSS?
The Payment Card Industry Data Security Standard (PCI DSS) is a global information security standard designed to protect payment card account data. The PCI Security Standards Council (PCI SSC) maintains the standard, while payment brands and acquiring banks manage their respective compliance programs.
PCI DSS applies to entities that store, process, or transmit cardholder data and to systems that could affect the security of the cardholder data environment (CDE). This can include merchants, payment processors, service providers, cloud providers, and other organizations involved in payment processing.
PCI DSS v4.0.1 is the current active version of the standard. PCI DSS v4.0 retired on December 31, 2024, and requirements previously designated as future-dated became effective March 31, 2025. PCI DSS v4.0.1 did not introduce or remove requirements from v4.0; it provided clarifications and corrections to support implementation.
Who needs to comply with PCI DSS?
PCI DSS applies broadly to organizations involved in payment card processing. Applicability can include:
- Merchants accepting card payments
- Payment processors and gateways
- Acquirers and issuers
- E-commerce organizations
- Service providers that store, process, or transmit payment card data
- Third parties that manage systems within the CDE or can affect its security
Company size alone does not determine whether PCI DSS applies. Smaller businesses may have different validation obligations based on factors such as transaction volume and payment environment, but they can still have PCI DSS responsibilities.
Outsourcing payment processing also does not automatically eliminate PCI DSS obligations. Organizations must understand which responsibilities they retain and which are managed by third-party service providers.
What data does PCI DSS protect?
PCI DSS distinguishes between cardholder data and sensitive authentication data.
Data type | Examples | PCI DSS consideration |
Cardholder data | Primary account number (PAN), cardholder name, expiration date, service code | Must be appropriately protected when stored, processed, or transmitted |
Sensitive authentication data | Full track data, card verification codes, PINs and PIN blocks | Subject to strict protections and post-authorization storage restrictions |
Primary account number | Payment card account number | A central factor in determining applicability of PCI DSS requirements |
Understanding where this information travels is fundamental to defining PCI DSS scope.
What is the cardholder data environment?
The cardholder data environment, or CDE, includes the people, processes, and technologies that store, process, or transmit payment card account data, as well as system components that can affect the security of the CDE.
Organizations should document payment data flows and maintain an accurate inventory of relevant systems. Network segmentation, tokenization, validated point-to-point encryption, outsourcing, and eliminating unnecessary cardholder data storage can potentially help reduce scope when implemented appropriately.
However, organizations should not assume a security technology automatically removes an environment from scope. Scoping depends on the architecture, data flows, connectivity, and implementation of applicable controls.
What are the 12 PCI DSS requirements?
PCI DSS organizes its controls into 12 principal requirements covering network security, data protection, vulnerability management, access control, monitoring, testing, and security governance.
PCI DSS requirement | Primary objective |
1. Install and maintain network security controls | Control network traffic and protect the CDE |
2. Apply secure configurations to all system components | Reduce exposure created by insecure configurations and unnecessary functionality |
3. Protect stored account data | Minimize stored data and protect account data that must be retained |
4. Protect cardholder data with strong cryptography during transmission | Protect payment data traveling over open, public networks |
5. Protect systems and networks from malicious software | Prevent, detect, and address malware |
6. Develop and maintain secure systems and software | Identify vulnerabilities, securely develop software, and maintain systems |
7. Restrict access by business need to know | Apply least privilege to systems and account data |
8. Identify users and authenticate access | Establish strong identity and authentication controls |
9. Restrict physical access to cardholder data | Prevent unauthorized physical access |
10. Log and monitor access | Maintain visibility into activity affecting systems and account data |
11. Test security systems and processes regularly | Identify vulnerabilities and validate security controls |
12. Support information security with organizational policies and programs | Establish security governance, responsibilities, and risk management processes |
Together, these requirements establish a defense-in-depth approach to payment security. For cybersecurity teams, Requirements 5, 6, 10, and 11 are particularly relevant to malware protection, vulnerability management, monitoring, and security testing. GRC and third-party risk teams also play an important role in Requirement 12, including managing relationships with third-party service providers.
PCI DSS v4.0.1 strengthens protections for e-commerce payment pages. Requirements 6.4.3 and 11.6.1 address risks associated with payment-page scripts and unauthorized changes to payment-page content, helping organizations reduce exposure to e-skimming attacks. While these requirements do not apply to merchants validating compliance through SAQ A, eligible merchants must still meet SAQ A's payment-page script-attack eligibility criteria, including confirming that their payment pages are protected against script-based attacks. Depending on their environment and applicable requirements, merchants may also need to complete external vulnerability scans through an Approved Scanning Vendor (ASV).
PCI DSS compliance checklist
Achieving PCI DSS compliance starts with understanding your environment and continues through ongoing monitoring, testing, documentation, and remediation. Use this checklist to organize key activities.
PCI DSS checklist item | Action | Evidence to maintain |
Define PCI DSS scope | Identify systems, processes, people, and technologies that store, process, transmit, or affect the security of account data | CDE inventory, network diagrams, data-flow diagrams |
Inventory in-scope assets | Maintain an accurate inventory of applicable systems and components | Asset inventory and ownership records |
Secure network configurations | Restrict unnecessary connectivity and maintain network security controls | Configuration standards, network rules, change records |
Protect stored account data | Minimize storage and apply appropriate protection | Retention policies, encryption and key-management records |
Protect data in transit | Use strong cryptography over open, public networks | Encryption and certificate configurations |
Maintain secure systems | Apply secure configurations, identify vulnerabilities, and install applicable patches | Patch records, vulnerability findings |
Control access | Restrict access according to business need and least privilege | Access policies and review records |
Strengthen authentication | Maintain unique identities and required MFA | Authentication policies and access records |
Monitor activity | Log and monitor access to systems and account data | Security logs, alerts, and review records |
Test security controls | Conduct required scans, penetration tests, and other security testing | ASV reports, scan results, penetration test reports |
Manage third parties | Identify relevant providers and document responsibilities | Provider inventory, agreements, AOCs, responsibility records |
Maintain governance | Maintain policies, training, risk analyses, and incident-response procedures | Policies, training records, risk assessments, test results |
Maintain an accurate attack surface
Asset inventories can quickly become outdated as organizations adopt cloud infrastructure, launch new applications, change payment technologies, and add third parties.
Continuous asset discovery can complement PCI DSS scoping processes by helping security teams identify internet-facing infrastructure and unexpected changes in the external attack surface. Bitsight Security Posture Management, for example, provides an external view of assets and exposures that organizations can use to identify and prioritize attacker-relevant exposure.
Establish vulnerability management processes
PCI DSS requires organizations to identify and address security vulnerabilities, conduct applicable vulnerability scanning, and regularly test security systems and processes.
Vulnerability management should also account for changing threat conditions. A critical severity score provides one signal, but it does not necessarily indicate whether attackers are actively targeting a vulnerability.
Bitsight Cyber Threat Intelligence adds real-world threat context to vulnerability management. Dynamic Vulnerability Exploitability (DVE) scoring, for example, helps teams assess exploitation likelihood based on threat intelligence so they can prioritize remediation alongside factors such as asset importance and business impact.
Monitor third-party service providers
Third parties can store or process account data, manage components within the CDE, or otherwise affect its security. Organizations therefore need to understand the services providers perform and clearly document PCI DSS responsibilities.
PCI SSC expects third-party service providers to provide appropriate evidence when their services meet customers' PCI DSS requirements or can affect the security of cardholder data. Where applicable, this can include an Attestation of Compliance or other evidence demonstrating that relevant requirements were assessed.
Point-in-time documentation alone may not reveal how a provider's security posture changes between assessments. Bitsight Continuous Monitoring provides objective, evidence-based security information across third-party ecosystems to help organizations identify changes in vendor risk and prioritize follow-up.
