PCI DSS
Also known as: Payment Card Industry Data Security Standard, PCI, PCI compliance
PCI DSS (the Payment Card Industry Data Security Standard) is a set of 12 security requirements created by the major card networks (Visa, Mastercard, Amex, Discover) to protect credit and debit card data from theft and fraud.
Any business that stores, processes, or transmits card numbers must comply, regardless of size. Non-compliance can result in fines from your bank, loss of card acceptance, and legal liability after a breach.
PCI DSS, explained at three levels
At home
If you have ever bought something online with a card, PCI DSS is the reason your card details are supposed to be protected. Any shop, restaurant, or website that takes card payments must follow these security rules: things like using encryption, keeping software up to date, and limiting who can see card numbers. Think of it as a safety inspection every card-accepting business must pass.
At work
PCI DSS is a set of security requirements your organization must meet if it accepts, processes, or stores credit or debit card payments. It is organized into 12 requirements covering firewalls, encryption, access control, monitoring, and security testing. Compliance is validated annually, and failing can lead to fines from your acquiring bank, suspension of card acceptance, and increased legal exposure after a breach.
At home
PCI DSS groups its 12 requirements into six goals: build a secure network, protect cardholder data, manage vulnerabilities, implement strong access control, monitor and test networks, and maintain an information security policy. Your validation method depends on transaction volume: small merchants can self-assess using a Self-Assessment Questionnaire (SAQ); larger merchants and service providers need an external Qualified Security Assessor (QSA) to produce a Report on Compliance (ROC).
At work
Scoping is the most important first step: every system that stores, processes, or transmits cardholder data (or is connected to those systems) is in scope. Network segmentation is the primary tool for reducing scope. By isolating the cardholder data environment (CDE) on a dedicated network segment, an organization can shrink its PCI footprint dramatically. SAQ type varies by how a merchant accepts cards: SAQ A covers fully outsourced e-commerce; SAQ D is for merchants with the largest in-scope environments.
At home
PCI DSS v4.0 introduced a customized approach as an alternative to the traditional prescriptive approach, letting mature security programs demonstrate how they meet stated objectives using their own controls. Key v4.0 additions include MFA for all CDE access (not just remote), enhanced phishing-resistant authentication, a targeted risk analysis requirement for flexible controls, and new requirements around payment page script integrity (6.4.3) targeting client-side skimming attacks like Magecart. Tokenization and point-to-point encryption (P2PE) remain the most effective scope-reduction techniques.
At work
From a practitioner standpoint, the v4.0 customized approach changes the QSA assessment model: instead of verifying a prescribed control exists, the QSA validates that the control meets the stated objective and is tested regularly. Requirements 6.4.3 and 11.6.1 directly address client-side skimming by mandating script inventory, authorization, and tamper detection for payment pages. Mapping PCI DSS controls to ISO 27001 Annex A or NIST CSF avoids duplicated effort: organizations running one security program can satisfy multiple frameworks simultaneously.
Real-world examples
At home
Nadia runs an online bakery and uses Shopify Payments to take orders. Because Shopify handles all card processing and never passes raw card numbers to Nadia's server, her compliance burden is minimal: she completes a short SAQ A each year confirming she has not stored card data herself.
At work
The security team at Meridian Retail Corp completed an annual scoping exercise and discovered their payment terminals were on the same network as their office PCs. After segmenting the terminals onto an isolated VLAN, the number of in-scope systems dropped from 200 to 14, cutting their Level 1 ROC effort by more than half.
How it compares
| Feature | PCI DSS | ISO 27001 | SOC 2 |
|---|---|---|---|
| Who sets it | PCI Security Standards Council (card networks) | International Organization for Standardization | AICPA (US accounting body) |
| Who must comply | Any org accepting card payments | Any org: voluntary certification | Service providers: voluntary but customer-driven |
| Primary focus | Payment card data protection | Broad information security management | Security, availability, confidentiality, privacy |
| Audit output | SAQ or Report on Compliance (ROC) | ISO 27001 certificate | SOC 2 Type I or Type II report |
| Mandatory? | Yes, for card payment acceptance | No: voluntary | No: voluntary |
PCI DSS is the only one of the three that is commercially mandatory: if you accept card payments, you must comply. ISO 27001 and SOC 2 are voluntary but increasingly required by enterprise customers and procurement teams.
For analysts
PCI DSS requirements appear in BA artefacts as non-functional requirements and acceptance criteria for any feature that touches payment data. When documenting requirements, specify which SAQ type applies and whether network segmentation is in scope for the proposed design. A common mistake is treating PCI DSS as a one-off IT project rather than an ongoing organizational program: requirements must address people (training), processes (procedures), and technology. Useful acceptance criterion: 'The payment system must not retain CVV data after authorization, verified during the annual PCI DSS assessment.'
History & origin
PCI DSS was created in 2004 when Visa, Mastercard, American Express, Discover, and JCB merged their separate card security programs into a single standard administered by the newly formed PCI Security Standards Council. Before that, each network ran its own program (Visa had CISP, Mastercard had SDP) leaving merchants to satisfy multiple overlapping requirements. Version 1.0 launched in December 2004. Major milestones include v3.2 (2016), which required multi-factor authentication for all administrative access to the cardholder data environment, and v4.0 (2022), which extended MFA to all access into that environment and introduced a customized approach allowing organizations to demonstrate security outcomes rather than just checking prescribed controls. Version 4.0.1 (2024) is the current release, and v4.0's future-dated requirements became mandatory in March 2025.