The Payment Card Industry Data Security Standard (PCI DSS) is a global security standard for protecting payment account data. It is maintained by the PCI Security Standards Council. PCI DSS is not a law, but it becomes binding through contracts and compliance programs operated by payment brands and acquirers. The current version is PCI DSS 4.0.1.
Who does PCI DSS apply to?
It applies to organizations that store, process or transmit cardholder data or sensitive authentication data, as well as service providers whose systems can affect the security of that environment. This includes merchants, processors, acquirers, issuers, hosting providers and certain software or managed-service providers. Transaction volume and type often determine the validation method, not whether the underlying requirements apply.
Which data and systems are in scope?
Cardholder data includes at least the primary account number (PAN) and may include the cardholder name, expiration date or service code. Sensitive authentication data includes full track data, card verification codes and PIN data. Certain authentication data must not be stored after authorization, even in encrypted form.
Scope covers the cardholder data environment (CDE), connected systems and components that can affect its security. An administration system, identity provider or logging service can therefore be relevant even if it stores no PAN. Data flow must be understood from collection through deletion.
What does PCI DSS require?
| Area | Examples |
|---|---|
| Networks and systems | Network security controls, secure configuration and malware protection. |
| Account data | Minimize storage, render PAN unreadable and protect transmission with strong cryptography. |
| Vulnerabilities | Secure development, patching, scans and penetration tests. |
| Access | Need-to-know, unique accounts, strong authentication and physical protection. |
| Monitoring | Logging, change detection and regular control testing. |
| Governance | Policies, roles, risk analysis, awareness and service-provider oversight. |
Version 4.x permits a customized approach for certain requirements in addition to the defined approach. This needs a documented control objective, targeted risk analysis and robust testing. It is not a blanket exception from the requirement.
How is compliance validated?
Depending on merchant or service-provider category, validation uses a Self-Assessment Questionnaire (SAQ) or a Report on Compliance (ROC), typically supported by a Qualified Security Assessor. An Attestation of Compliance summarizes the result. Where applicable, external vulnerability scans must be performed by an Approved Scanning Vendor. The relevant payment brand or acquirer determines the exact evidence required.
Compliance is not a once-a-year project. Inventory, control evidence, scans, access reviews, changes and service providers need attention throughout the year.
How can scope be reduced?
- Do not store card data, or retain it only as long as the business requires.
- Use hosted payment pages, tokenization or suitable payment terminals.
- Isolate the CDE with demonstrably effective network segmentation.
- Document data flows and dependencies and confirm scope regularly.
Outsourcing does not remove responsibility. The organization must select an appropriate provider, verify its PCI DSS status and responsibility split, and configure its own integration securely.
What is commonly misunderstood?
A passing scan is not PCI DSS compliance, and PCI DSS compliance does not guarantee that no breach will occur. Encryption does not automatically remove a system from scope if it manages keys or can decrypt data. A payment provider's compliance seal does not automatically cover the merchant either. Scope, assessment period and shared responsibilities must be established explicitly.
Thank you for your feedback! We will review it and optimize this content.