The Payment Card Industry Data Security Standard, PCI DSS, applies to any entity that stores, processes, or transmits cardholder data. The current version is v4.0.1, released in June 2024. It organizes 12 requirements under 6 control objectives, all aimed at protecting the cardholder data environment, the systems where card data lives. The method of proving compliance depends on the entity's transaction volume and card-handling: lower-volume entities self-attest with a Self-Assessment Questionnaire, the highest-volume ones receive a full Report on Compliance from a Qualified Security Assessor, and both produce a signed Attestation of Compliance. Validation is annual, with quarterly external scans in addition, while the underlying control obligation is continuous.
PCI DSS is an information security standard maintained by the PCI Security Standards Council and imposed contractually rather than by statute. It reaches an organization through its acquiring bank, the payment brands, and commercial counterparties, which typically request the Attestation of Compliance as a line item in a security questionnaire or a contract.
This article covers the scope of the standard, the definition of the cardholder data environment and its effect on assessment burden, the 12 requirements grouped under their 6 control objectives, the merchant levels and validation paths, the role of the QSA, and the ongoing validation cadence after a first assessment.
Who must comply
PCI DSS applies to any organization that stores, processes, or transmits cardholder data, and to any organization whose systems can affect the security of that data. The standard is set and maintained by the PCI Security Standards Council, the body the major payment brands formed to own it. It is a contractual requirement rather than a law, and it flows down through the payment brands and the acquiring banks to every entity that handles card data.
The categories in scope include:
- Merchants of every size, from a single storefront to a global retailer, whether card data is keyed, swiped, dipped, tapped, or entered online.
- Service providers that store, process, or transmit card data on behalf of others, or that manage components inside a client's cardholder data environment, such as hosting providers, payment gateways, and managed security firms.
- Acquirers, processors, and issuers that sit in the authorization and settlement path.
Company size does not change whether the standard applies. A small business that handles a handful of card transactions a month is in scope. Size and card-handling change only how compliance gets validated.
The cardholder data environment and scope
Scope is the concept everything else in PCI DSS turns on, and scope is defined by the cardholder data environment, the CDE. The CDE is the people, processes, and technology that store, process, or transmit cardholder data or sensitive authentication data, together with any system component that connects to those systems or could affect their security. Everything inside the CDE is in scope for the assessment, and the standard's controls apply to all of it.
Two definitions underpin the scoping analysis:
- Cardholder data is the primary account number (the PAN), and where present alongside it, the cardholder name, expiration date, and service code.
- Sensitive authentication data is the full track data, the card verification value (the three or four digit code), and the PIN. This data must never be stored after authorization, even encrypted.
Because every in-scope system has to meet the requirements, the size of the CDE drives the cost and difficulty of the whole effort. This is why segmentation is the practitioner's main lever. Segmentation uses network controls to isolate the systems that handle card data from the rest of the environment, so the parts that do not touch card data fall outside scope. A flat network where any machine can reach the systems that process cards pulls the entire network into the CDE. A well-segmented one shrinks the assessment to the handful of systems that actually need it. The other lever is to stop handling card data at all, by outsourcing to a compliant provider or replacing the PAN with a token, so there is less data to protect.
The 6 control objectives
PCI DSS groups its 12 requirements under 6 control objectives. The objectives state the goals in plain language; the requirements state the controls that achieve them.
| Control objective | Requirements | What it covers |
|---|---|---|
| Build and maintain a secure network and systems | 1, 2 | Network security controls and secure configuration of all system components. |
| Protect account data | 3, 4 | Protecting stored cardholder data and encrypting it in transit across open, public networks. |
| Maintain a vulnerability management program | 5, 6 | Anti-malware defenses and secure development and patching of systems and software. |
| Implement strong access control measures | 7, 8, 9 | Restricting access by business need, authenticating every user, and controlling physical access. |
| Regularly monitor and test networks | 10, 11 | Logging and monitoring access, and testing the security of systems and networks. |
| Maintain an information security policy | 12 | The governing policies and programs that direct the people side of security. |
The current version and the 2025 mandatory requirements
The current standard is PCI DSS v4.0.1, released in June 2024. Versions 4.0 and 4.0.1 are the only active versions, referred to together as v4.x; the prior v3.2.1 was retired on March 31, 2024. A program that still names v4.0 as the current version is substantively close but carries an outdated version label.
A second date governs content. Of the requirements introduced in v4.x, 51 were designated best practice until March 31, 2025 and became mandatory on that date. An assessment that treated them as future-dated predates their effective date; they are now in force, and an assessor expects them implemented. They include expanded multi-factor authentication, the targeted risk analyses that set how often certain controls run, anti-phishing measures, and payment-page script integrity for e-commerce.
The 12 requirements
Each requirement contains many detailed sub-requirements, and v4.0 introduced a customized-approach option that lets an organization meet a stated security objective with controls of its own design, validated against the intent rather than the prescribed method. The table below states the requirement level, the structure at which most programs are organized.
| No. | Requirement | Plain language |
|---|---|---|
| 1 | Install and maintain network security controls | Control traffic into and out of the cardholder data environment with firewalls and equivalent controls. |
| 2 | Apply secure configurations to all system components | Change vendor defaults, remove unnecessary services, and harden every system before it goes live. |
| 3 | Protect stored account data | Minimize stored data, render the PAN unreadable where it is kept, and never store sensitive authentication data after authorization. |
| 4 | Protect cardholder data with strong cryptography during transmission | Encrypt cardholder data whenever it travels across open, public networks. |
| 5 | Protect all systems and networks from malicious software | Deploy and maintain anti-malware controls and keep them current. |
| 6 | Develop and maintain secure systems and software | Build software securely, manage vulnerabilities, and apply patches on a defined schedule. |
| 7 | Restrict access to system components and cardholder data by business need to know | Grant access only to those who need it for their role, and deny by default. |
| 8 | Identify users and authenticate access to system components | Give every user a unique ID, authenticate strongly, and apply multi-factor authentication where required. |
| 9 | Restrict physical access to cardholder data | Control physical entry to systems and media that hold card data, and manage that media through its lifecycle. |
| 10 | Log and monitor all access to system components and cardholder data | Record access to the CDE, protect those logs, and review them to detect anomalies. |
| 11 | Test security of systems and networks regularly | Run vulnerability scans and penetration tests, and watch for unauthorized changes. |
| 12 | Support information security with organizational policies and programs | Maintain the security policy, train staff, manage third parties, and keep an incident response plan ready. |
Merchant levels
Merchants are sorted into levels based mainly on annual transaction volume across a payment brand. The level determines the validation path. The exact thresholds and rules are set by each payment brand, so the program a given merchant follows depends on its acquirer and the brands it accepts. The pattern below is the widely-used four-level structure; the governing specifics sit with the acquirer, which owns the program the merchant reports into.
| Level | General profile | Typical validation |
|---|---|---|
| 1 | The highest transaction volumes, and any merchant that has suffered a breach. | Annual Report on Compliance by a QSA or Internal Security Assessor, plus quarterly scans. |
| 2 | Large transaction volumes below Level 1. | Annual Self-Assessment Questionnaire, plus quarterly scans. Some programs require an on-site review. |
| 3 | Moderate volumes, often concentrated in e-commerce. | Annual Self-Assessment Questionnaire, plus quarterly scans. |
| 4 | The smallest volumes. | Annual Self-Assessment Questionnaire, with scan requirements set by the acquirer. |
Service providers have their own level structure, generally split by whether they exceed a defined annual transaction count, with the larger tier validating through a Report on Compliance. Again, the governing thresholds belong to the payment brands.
SAQ, ROC, and AOC
Three documents carry the validation record, and they are frequently conflated.
| Document | What it is | Who uses it |
|---|---|---|
| SAQ (Self-Assessment Questionnaire) | A self-attested validation document. There are several SAQ types, each scoped to a specific way of handling cards, so an organization completes the one that matches how it accepts payments. | Eligible merchants and service providers with lower volumes or simpler card-handling. |
| ROC (Report on Compliance) | A full assessment of every applicable requirement, with evidence reviewed and controls tested by an assessor, documented in detail. | The highest-volume merchants and many service providers. |
| AOC (Attestation of Compliance) | The signed summary that states the validation result. It is the document shared with acquirers and partners as proof. | Everyone. Both an SAQ and a ROC produce an AOC. |
The operative distinction is that the SAQ and the ROC are the assessment, while the AOC is the document provided to an external party. A partner requesting evidence of PCI compliance is ordinarily requesting the AOC.
The role of the QSA
A Qualified Security Assessor, a QSA, is a firm and an individual the PCI Security Standards Council has certified to perform PCI DSS assessments and produce a Report on Compliance. The QSA examines evidence, tests controls, interviews the people who run them, and attests to whether each requirement is in place. A ROC is the QSA's professional judgment that the environment meets the standard, recorded in a form acquirers and brands accept.
Two related roles sit nearby. An Internal Security Assessor is an employee a company has trained and the Council has qualified to perform internal assessments, an option larger organizations use to build the capability in-house. An Approved Scanning Vendor, an ASV, is a separate Council-approved company that runs the required external vulnerability scans against internet-facing systems. The two are distinct qualifications with distinct functions: the QSA assesses the program, and the ASV scans the perimeter.
Validation cadence
PCI DSS is validated annually, while the controls it prescribes are required to operate continuously; the annual report is a point-in-time confirmation of controls already in operation.
- Annual. The applicable SAQ or ROC is completed and the AOC signed. This is the obligation reported to the acquirer.
- Quarterly. External vulnerability scans by an Approved Scanning Vendor against internet-facing systems, with passing results.
- On their own intervals. Several requirements carry their own testing and review cadences defined in the standard, such as penetration testing, log review, and policy review. The requirement text is the source for each interval.
- Continuously. Monitoring, access management, patching, and change control operate daily. A control exercised only in the period preceding an assessment does not satisfy the requirement it is mapped to.
A readiness checklist
The following conditions are verified before an assessment cycle begins. They do not establish compliance; they establish whether the scope is accurately drawn and the evidence exists.
- The organization maintains a current data flow and network diagram showing where cardholder data is stored, processed, and transmitted.
- The cardholder data environment is defined, and any segmentation that takes systems out of scope is documented and tested.
- The merchant or service provider level is established, along with the validation path the acquirer requires.
- The correct SAQ type is selected, or a ROC is confirmed as required.
- Sensitive authentication data is confirmed not to be stored after authorization anywhere in the environment.
- Stored PAN is rendered unreadable wherever it is kept, and storage is minimized.
- Quarterly ASV scans are scheduled and recent results pass.
- Every requirement maps to named evidence: a policy, a configuration, a log, or a test result producible on request.
- Third parties operating within the CDE have their own AOCs on file, and the responsibility split is documented.
- An incident response plan exists, names owners, and has been exercised.
The standard rests on three operating conditions: an accurate record of where regulated data resides, a cardholder data environment reduced to a defensible footprint, and evidence that the controls operate continuously rather than only in the assessment period. Where those conditions hold, the annual validation is a record of them.