PCI DSS
PCI DSS — the Payment Card Industry Data Security Standard — is the set of security requirements the card schemes impose on every organisation that stores, processes or transmits cardholder data: twelve requirements from firewalls and encryption to access control, logging and testing, enforced through acquirers' contracts. It is not law, but failing it brings fines, the loss of card acceptance and, after a breach, the fraud bill.
- Also known as
- Payment Card Industry Data Security Standard, PCI, PCI standard
- Used at
- every merchant, acquirer, processor, gateway, payment facilitator and any vendor whose systems touch card numbers; validated annually by audit or self-assessment according to the organisation's PCI compliance level
- Binding
- contractually — the schemes' rules flow through the acquirer's merchant agreement; version 4.0 (published 2022) became mandatory in 2024, with its future-dated requirements enforced from March 2025
- Typical requirements (the twelve)
- secure network and firewalls; secure configurations; protect stored account data; encrypt transmission over public networks; protect against malware; secure systems and software; restrict access by need to know; identify and authenticate users; restrict physical access; log and monitor access; test security regularly; maintain a security policy
- Typical cost of a breach
- forensic investigation, card reissuance costs charged back by the schemes, fines, and the fraud on the compromised cards — routinely millions, and the merchant is moved to Level 1 for life
- Parties
- the PCI Council, the schemes, acquirers, merchants and service providers, and the assessors (QSAs) and scanning vendors (ASVs) who validate
How PCI DSS works in practice
A payments company that handles card numbers must build its systems to the standard: card data stored only where necessary and encrypted; the systems that touch it segmented from the rest of the network; access to them limited, authenticated with multiple factors and logged; the logs kept and monitored; vulnerabilities scanned quarterly and penetration-tested annually; and a policy, training and incident plan behind it all. Each year a Qualified Security Assessor tests the controls against the several hundred sub-requirements and writes a Report on Compliance; the acquirer and the schemes receive an attestation.
The engineering choice most companies make is to shrink the scope. Every system that touches a card number is in scope; so the fewer that do, the cheaper compliance is and the smaller a breach can be. Tokenisation swaps the card number for a token after the first use; hosted pages and iframes capture it on the provider's domain; point-to-point encryption encrypts it in the terminal. A merchant that has done all three has a PCI scope of almost nothing and a self-assessment of a few pages; its payments provider has the scope instead, as a Level 1 service provider.
Version 4.0 raised the bar: multi-factor authentication for all access to the cardholder data environment, stronger encryption and key management, scripts on payment pages inventoried and monitored (the e-commerce skimming attacks of 2018–2020 written into the standard), and a customised approach that lets mature organisations meet the objective by other means.
Example
An online retailer stores card numbers for repeat purchases and validates as a Level 2 merchant by self-assessment. A skimming script injected through a third-party plugin harvests 180,000 card numbers over four months before the acquirer's fraud team notices the pattern. Costs: €350,000 of forensic investigation; €900,000 of card-reissuance charges levied by the schemes through the acquirer; €400,000 of fines; the fraud on the cards borne by the issuers and partly recharged; a mandatory move to Level 1 with a €300,000 annual audit for as long as it accepts cards; and eighteen months of remediation. Tokenisation and a hosted payment page would have cost €60,000 to implement and would have left nothing to skim. Its payments provider now sells that to every prospect with the retailer's story, unnamed.
Common mistakes
- Self-assessing against the wrong questionnaire, so the controls that matter are never checked. - Card data in places nobody mapped — logs, support tickets, a spreadsheet in finance. - Reading the annual attestation as security; the standard is a floor, and compliant companies are breached. - Payment-page scripts from third parties, unmonitored — the attack version 4.0 was written for. - Buyers of a payments company reading the certificate and not the last two years' findings and the incident log.