What Is PCI DSS? Requirements and Compliance Explained

When customers pay with a card, their account information may pass through websites, terminals, networks, and payment providers. Each system that handles the information introduces responsibilities for keeping it secure. PCI DSS establishes a common baseline for protecting that data.

The PCI Security Standards Council (PCI SSC) develops and maintains the standard, with payment brands and acquiring banks setting compliance and reporting obligations through their respective programs. PCI DSS isn’t, by itself, a government law.

The requirements help organizations address several common risks:

• Unauthorized access: Limiting who can view cardholder data and administer payment systems.
• Data exposure: Protecting information while it’s stored or transmitted.
• Security weaknesses: Identifying vulnerable systems, unsafe configurations, and malicious software.
• Limited visibility: Recording activity so teams can investigate suspicious access.

These measures are part of broader data security, and meeting PCI DSS requirements supports stronger safeguards, although compliance alone can’t guarantee that a breach won’t occur.

How PCI DSS compliance works

PCI DSS applies to entities that store, process, or transmit cardholder data or sensitive authentication data, as well as organizations that could affect the security of that information. This can include merchants, payment processors, and service providers. Requirements depend on each organization's environment and responsibilities.

Determine what’s in scope

Organizations first identify how account data moves and where it’s handled. The cardholder data environment (CDE) includes people, processes, and technologies that store, process, or transmit cardholder data, along with relevant connected or security-impacting systems.

A useful starting point is to map payment flows, identify connected systems, and document third-party relationships. Outsourcing payments may reduce applicable technical requirements, but it doesn’t automatically eliminate compliance obligations.

Implement and validate the controls

Organizations then assess applicable requirements, address gaps, collect evidence, and maintain controls over time. Depending on their payment brand's or acquirer's rules, validation may involve:

• Self-Assessment Questionnaire (SAQ): An assessment form for eligible organizations.
• Report on Compliance (ROC): A more detailed assessment report, often prepared with a Qualified Security Assessor (QSA).
• Attestation of Compliance (AOC): An official document summarizing assessment results.

The appropriate route depends on factors such as business role, payment environment, and the applicable compliance program. PCI DSS is one of several compliance and regulatory frameworks that organizations may need to address.

The 12 PCI DSS requirements

PCI DSS v4.0.1 organizes its 12 principal requirements under six security objectives. Together, they cover the technical controls and organizational practices needed to protect payment account data. Note that not every requirement applies in the same way to every organization.

Build and maintain secure networks and systems

1. Install and maintain network security controls. Manage traffic between trusted and untrusted networks.
2. Apply secure configurations to all system components. Replace insecure defaults and maintain approved settings.

Protect account data

1. Protect stored account data. Limit retention and use appropriate protections for stored information.
2. Protect cardholder data with strong cryptography during transmission over open, public networks. Use strong cryptography across open, public networks.

Practices such as data encryption help organizations put these protections into effect.

Maintain a vulnerability management program

1. Protect systems and networks from malicious software. Use appropriate anti-malware measures.
2. Develop and maintain secure systems and software. Address vulnerabilities and build security into development and maintenance.

Implement strong access control measures

1. Restrict access to system components and cardholder data by business need-to-know. Give personnel only the access required for their work.
2. Identify users and authenticate access to system components. Use unique identities and appropriate authentication controls.
3. Restrict physical access to cardholder data. Protect facilities, devices, and physical records.

Regularly monitor and test networks

1. Log and monitor all access to system components and cardholder data. Keep relevant records of activity involving systems and cardholder data.
2. Test security of systems and networks regularly. Perform required testing to find weaknesses and confirm safeguards remain effective.

Maintain an information security policy

1. Support information security with organizational policies and programs. Set responsibilities, train personnel, manage third parties, and maintain an incident response plan.

PCI DSS examples and use cases

The requirements look different depending on how an organization accepts payments and which systems it controls.

E-commerce retailer

An online store may redirect customers to a hosted payment page. That can reduce the retailer's exposure to account data, but it still needs to understand its website's role, confirm the provider's responsibilities, and follow the validation method applicable to its setup.

In-store merchant

A business using payment terminals needs to consider device security, physical access, network connections, and any systems that can affect the cardholder data environment. Its scope may differ from that of an online retailer.

Payment service provider

A provider that processes transactions for many merchants may manage systems containing cardholder data. It must understand its own applicable requirements and clearly explain which security responsibilities it handles for customers.

Across these scenarios, scope determines the relevant controls. Organizations should confirm their obligations with the payment brand, acquirer, or other entity managing their compliance program.

How PCI DSS fits into security operations

PCI DSS isn’t a separate activity that security teams complete once a year. Many requirements depend on everyday processes that keep protections working between assessments.

For example, security teams can use vulnerability management (VM) to identify weaknesses, prioritize remediation, and track progress. Penetration testing can help test whether certain weaknesses could be exploited. Neither activity replaces the other required PCI DSS controls or assessment procedures.

Other ongoing responsibilities include reviewing access privileges, checking logs, maintaining secure configurations, and preparing for incident response (IR). Those practices also help teams discover problems that a point-in-time assessment might miss.

For organizations exploring how security capabilities relate to specific obligations, PCI DSS compliance guidance can provide additional context. The underlying responsibility remains the same: Keep applicable controls functioning and retain evidence that they work.