What is PCI DSS?
The Payment Card Industry Data Security Standard (PCI DSS) is a set of security requirements for protecting payment card data. It is maintained by the PCI Security Standards Council (PCI SSC), which the major card brands founded, and it applies to merchants, payment processors, service providers and any other organization that stores, processes or transmits cardholder data or can affect the security of that data.
PCI DSS is not a law. It is enforced through contracts: the card brands require it of acquiring banks, and acquirers require it of merchants in their merchant agreements. Version 4.0.1, published in 2024, is the current version, and the requirements that version 4.0 introduced as future-dated became mandatory on March 31, 2025.
What PCI DSS protects
The standard calls the protected data account data, which has two parts:
- Cardholder data: the primary account number (PAN), cardholder name, expiration date and service code. The PAN is the defining element; if it is not stored, processed or transmitted, PCI DSS generally does not apply.
- Sensitive authentication data: full track data from the magnetic stripe or chip, the card verification code, and PINs or PIN blocks. Merchants must not store it after a payment is authorized, even in encrypted form.
A stored PAN must be rendered unreadable, for example with strong encryption, truncation, keyed cryptographic hashing or tokenization. When displayed to people who do not need the full number, it is masked, commonly to the last four digits.
The 12 requirements
The standard's 12 principal requirements are grouped under six goals:
| # | Requirement area |
|---|---|
| 1 | Network security controls, such as firewalls, around the cardholder data environment |
| 2 | Secure configurations for all system components |
| 3 | Protection of stored account data |
| 4 | Strong cryptography for card data sent over open, public networks |
| 5 | Protection against malware |
| 6 | Secure systems and software |
| 7 | Access restricted by business need to know |
| 8 | User identification and authentication, including MFA |
| 9 | Physical access restrictions |
| 10 | Logging and monitoring of all access |
| 11 | Regular security testing |
| 12 | Organizational policies and programs |
Testing and validation
Requirement 11 sets the testing cadence: internal and external vulnerability scans at least once every three months, with external scans performed by an Approved Scanning Vendor (ASV), and internal and external penetration tests at least every 12 months and after significant changes. Requirement 10 calls for keeping audit log history for at least 12 months, with the most recent three months immediately available.
How an organization proves compliance depends on its size and role, as set by the card brands and acquirers. Large merchants and service providers typically undergo an annual assessment by a Qualified Security Assessor (QSA), documented in a Report on Compliance (ROC). Smaller merchants usually complete a Self-Assessment Questionnaire (SAQ). Either way, the result is summarized in an Attestation of Compliance (AOC), which customers often request during vendor due diligence.
Reducing PCI DSS scope
PCI DSS applies to the cardholder data environment (CDE) and to systems connected to it or able to affect its security, so shrinking that environment shrinks the work. Common methods are network segmentation that isolates the CDE, tokenization that replaces PANs with tokens in order, CRM and analytics systems, and hosted payment pages or point-to-point encryption that keep readable card numbers off the merchant's own systems. The organization must confirm its scope at least once every 12 months, the assessor validates it, and segmentation used to reduce scope must be penetration tested to prove it works.
PCI DSS on the CompTIA Security+ exam
PCI DSS appears under SY0-801 objective 5.5 as the main example of an industry-based standard, and under objective 5.4 in the context of compliance obligations and the cost of failing them. A scenario that mentions cardholder data, credit card transactions, a merchant agreement or an acquiring bank points at PCI DSS. Know that it is contractual rather than a law, that non-compliance can bring fines passed down through the acquiring bank and, in the worst case, loss of the ability to accept cards, and that tokenization and segmentation reduce scope. Distractors include GDPR, which is a law covering personal data broadly, HIPAA for health information, ISO/IEC 27001 and the NIST Cybersecurity Framework. PCI DSS also appears in A+ Core 2 (220-1202) objective 4.6, which covers regulated data such as payment card information.