PCI DSS, the Payment Card Industry Data Security Standard, is the global security standard for any organization that stores, processes or transmits payment card data. It is maintained by the PCI Security Standards Council, founded by the major card brands, and enforced through contracts between card brands, acquiring banks and merchants. In e-commerce payment security, PCI DSS defines the minimum technical and organizational controls that protect cardholder data from theft.
PCI DSS is not a law in most countries, but compliance is a contractual obligation for card acceptance. Non-compliance can lead to fines passed on by the acquirer, higher fees, liability for fraud losses after a breach and, in serious cases, the loss of the ability to accept cards.
What PCI DSS protects and how its scope is defined
PCI DSS protects account data, which consists of cardholder data and sensitive authentication data. The distinction matters because the rules differ: some data may be stored with protection, while other data must never be stored after authorization, even in encrypted form.
| Data element | Category | Storage after authorization |
|---|---|---|
| Primary account number (PAN) | Cardholder data | Allowed only if rendered unreadable |
| Cardholder name and expiry date | Cardholder data | Allowed with protection when stored with the PAN |
| Card verification code (CVV, CVC) | Sensitive authentication data | Not allowed |
| Full magnetic stripe or chip data | Sensitive authentication data | Not allowed |
| PIN and PIN block | Sensitive authentication data | Not allowed |
The cardholder data environment (CDE) includes every system that handles account data and every system connected to it. Reducing scope is therefore the most effective compliance strategy: the fewer systems touch card data, the fewer systems must meet the full set of controls.
The twelve PCI DSS requirements
PCI DSS is organized into six goals and twelve principal requirements, each broken down into detailed sub-requirements and testing procedures. The current version is PCI DSS 4.0.1; version 4.0 replaced 3.2.1, which was retired in 2024, and several new requirements became mandatory in 2025.
| Goal | Requirements |
|---|---|
| Secure networks and systems | 1. Network security controls; 2. Secure configurations |
| Protect account data | 3. Protect stored account data; 4. Strong cryptography in transmission |
| Vulnerability management | 5. Protection from malicious software; 6. Secure systems and software |
| Strong access control | 7. Restrict access by need to know; 8. Identify and authenticate users; 9. Restrict physical access |
| Monitoring and testing | 10. Log and monitor all access; 11. Test security regularly |
| Information security policy | 12. Policies and programs supporting security |
Version 4.0 introduced a customized approach, which lets mature organizations meet a requirement’s objective with alternative controls, and it strengthened requirements such as multi-factor authentication for access to the CDE. For online stores, two requirements are especially relevant: authorization of payment page scripts and detection of unauthorized changes to those pages, both aimed at e-skimming attacks.
Merchant levels and validation methods
Every merchant must comply with PCI DSS, but how compliance is validated depends on transaction volume and the card brand’s program. The levels below follow the widely used Visa and Mastercard model; exact thresholds are set by each brand and acquirer.
| Level | Annual card transactions | Usual validation |
|---|---|---|
| Level 1 | Over 6 million | Report on Compliance by a Qualified Security Assessor |
| Level 2 | 1 to 6 million | Self-Assessment Questionnaire, sometimes assessor-led |
| Level 3 | 20,000 to 1 million e-commerce | Self-Assessment Questionnaire |
| Level 4 | Fewer than 20,000 e-commerce | Self-Assessment Questionnaire |
Smaller merchants use a Self-Assessment Questionnaire (SAQ) that matches how they accept cards. The integration method determines which SAQ applies and therefore how much work compliance requires.
| Integration | Card data path | Typical SAQ |
|---|---|---|
| Redirect or iframe to a compliant provider | Card data entered only on provider pages | SAQ A |
| Direct post or JavaScript-built payment form | Merchant page affects card data capture | SAQ A-EP |
| Card data handled on merchant servers | Merchant systems receive the PAN | SAQ D |
PCI DSS compared with related payment security measures
PCI DSS is often mentioned together with other payment security concepts, but each solves a different problem. Compliance does not prevent fraud by itself, and fraud tools do not provide compliance.
| Concept | Purpose | Relation to PCI DSS |
|---|---|---|
| Tokenization | Replaces the PAN with a non-sensitive token | Reduces CDE scope |
| 3D Secure | Authenticates the cardholder during payment | Fraud and liability tool, not compliance |
| Fraud screening | Scores transactions for fraud risk | Separate from data protection |
| Chargeback management | Handles disputed transactions | Affected by breaches, not by the standard |
Common PCI DSS misconceptions
- Using a payment provider means no obligations: even SAQ A merchants must secure their site and validate compliance.
- Compliance is a yearly event: controls must work every day; the annual assessment only checks them.
- Encryption removes scope: systems that can decrypt card data remain in scope.
- Storing CVV for repeat purchases is fine if encrypted: it is never allowed after authorization.
- Small stores are not targeted: automated attacks on outdated store software affect merchants of every size.
A non-technical view
PCI DSS is the rulebook that card companies require from anyone who accepts card payments. It explains how card numbers must be protected, who may see them and how systems must be checked.
A good way to think of it is the safety code for a building. The safest approach for most online shops is to let a specialist payment provider handle the card details, so the shop itself has far less to protect.
A concrete example
A mid-sized online cosmetics store processes about 50,000 card transactions a year, which places it at Level 3. Its old checkout collected card numbers in a form on its own server, which put the web server, database and network in scope and required the extensive SAQ D.
The store moves to hosted payment fields from its payment provider, so card numbers are entered only on the provider’s systems and returned as tokens. It also inventories all scripts on the checkout page and sets up alerts for unauthorized changes. Its validation drops to a much shorter SAQ, and the risk of a card data breach on its own servers is largely removed.