PCI DSS

What is PCI DSS?

The Payment Card Industry Data Security Standard is a set of security requirements to protect payment account data. It is maintained by the PCI Security Standards Council (PCI SSC), which was founded by the major payment card brands. The current version is PCI DSS v4.0.1, a limited revision of v4.0 published in June 2024 that clarified wording without adding or removing requirements.

Purpose and objectives

PCI DSS sets a common baseline of controls so that card data is protected consistently wherever it is handled: in shops, online, in call centres and across the service providers behind them. Version 4 emphasises security as a continuous process, flexibility in how objectives are met, and stronger authentication and monitoring.

Who does it apply to?

Any entity that stores, processes or transmits cardholder data or sensitive authentication data, or that could affect the security of the cardholder data environment (CDE). That includes:

• merchants of every size and channel;
• payment processors, acquirers and issuers;
• service providers such as hosting, managed security, call centres and payment page providers.

Key data definitions

Scoping the cardholder data environment

Scope is the single biggest driver of PCI DSS effort. The CDE comprises the people, processes and technology that store, process or transmit account data, plus connected system components. Network segmentation can reduce scope if it is effective and validated. Requirement 12 now requires entities to confirm their scope at least annually, and service providers more often.

The 12 requirements

Defined and customized approaches

In the defined approach, the entity implements the requirement as written and the assessor follows the testing procedures. In the customized approach, the entity designs its own control to meet the requirement’s stated objective, documents a targeted risk analysis and a controls matrix, and the assessor derives tests. Many requirements also let the entity set frequencies through a targeted risk analysis.

Validation and reporting

The payment brands and acquirers decide how an entity must validate compliance, usually based on transaction volume and role.

• Report on Compliance (ROC): a detailed assessment, typically performed by a Qualified Security Assessor (QSA) or an Internal Security Assessor.
• Self-Assessment Questionnaire (SAQ): for eligible entities. Its type depends on the payment channel. Examples include SAQ A for fully outsourced e-commerce, SAQ B for imprint or standalone dial-out terminals, and SAQ D for everyone else.
• Attestation of Compliance (AOC): the formal declaration accompanying either.
• Approved Scanning Vendor (ASV) external vulnerability scans, generally quarterly, where required.

Requirements that became mandatory in 2025

Several v4.0 requirements were “best practice until 31 March 2025” and are now mandatory, including:

• multi-factor authentication for all access into the CDE;
• longer minimum password lengths where passwords are used;
• managing and authorising scripts on payment pages, and detecting unauthorised changes to payment page content;
• authenticated internal vulnerability scanning;
• anti-phishing mechanisms;
• targeted risk analyses supporting flexible control frequencies.

Implementation lifecycle

1. Understand how you accept payments. Map every channel and data flow.
2. Minimise and scope. Remove unnecessary card data, use tokenisation or validated point-to-point encryption (P2PE), outsource where sensible, and segment.
3. Gap assessment against the applicable requirements or SAQ.
4. Remediate.
5. Manage service providers. Keep a list, track their compliance status, and maintain a responsibility matrix.
6. Validate. ROC or SAQ, ASV scans and penetration tests as required.
7. Business as usual. Continuous monitoring, annual scope confirmation and re-validation.

Evidence and documentation

Assessors expect network and data-flow diagrams, scope confirmation records, configuration standards, key-management procedures, vulnerability scan and penetration test reports, access reviews, logs and log-review evidence, training records, incident response plan testing, service provider AOCs and responsibility matrices, and targeted risk analyses.

Common misconceptions and pitfalls

• “PCI certified.” PCI SSC does not certify merchants. Entities validate compliance through a ROC or SAQ, and the AOC confirms it at a point in time.
• “Tokenisation means we’re out of scope.” It reduces scope, but systems that can de-tokenise or affect the CDE stay in scope.
• Choosing the wrong SAQ. Eligibility criteria are specific. A misfiled SAQ gives false assurance.
• Scope creep through flat networks, shared admin credentials or unmanaged third-party scripts.

Relationship with other frameworks