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. How you prove compliance depends on your size and how you handle cards: smaller players self-attest with a Self-Assessment Questionnaire, the largest get a full Report on Compliance from a Qualified Security Assessor, and both end in a signed Attestation of Compliance. Validation is annual, with quarterly external scans on top, and the obligation runs every day in between.
Most teams meet PCI DSS the same way. A customer or a partner sends a security questionnaire, and a line item asks for the Attestation of Compliance. The card brands do not knock on the door. The pressure comes through contracts, through the acquiring bank, and through the partners who will not move forward without proof. By the time that line item arrives, the work behind it has either been done or it has not.
This guide walks through the standard the way a practitioner reads it: who it covers, what the cardholder data environment is and why scope decides how much work you face, the 12 requirements grouped under their 6 control objectives, how merchant levels and validation paths work, what a QSA does, and the cadence you live with after the 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 not a law. It is a contractual requirement that flows down through the payment brands and the acquiring banks to everyone who touches a card.
That reach is wide. It includes:
- 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 all of this, and both are worth getting right:
- 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 are the plain-language goals. The requirements are how you get there.
| 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. If your program still names v4.0 as current, the substance is close, but the version label is two years stale.
The more consequential date is March 31, 2025. Of the requirements introduced in v4.x, 51 were designated best practice until that date and became mandatory on it. If your last assessment treated them as future-dated, they are now in force, and an assessor will expect 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. What follows is the requirement level, the structure most teams reason in.
| 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 what you store, 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; confirm the specifics with your acquirer, since they own the program you report 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 do the work of proving compliance, and they are easy to confuse.
| 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 distinction that matters in practice: the SAQ and ROC are the assessment, and the AOC is the proof you hand to someone else. When a partner asks for your PCI compliance, they almost always mean 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 QSA assesses the program. The ASV scans the perimeter. They are different qualifications doing different jobs.
Validation cadence
PCI DSS is validated on a yearly rhythm, but it is not a once-a-year project. The controls are meant to operate continuously, and the annual report is a point-in-time confirmation that they already do.
- Annual. Complete the applicable SAQ or ROC and sign the AOC. This is the headline obligation that satisfies 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. Treat the requirement text as the source for each interval.
- Continuously. Monitoring, access management, patching, and change control run every day. A control that only works the week before the assessment is a control that does not work.
A readiness checklist
Run this before you start an assessment cycle. It will not make you compliant, but it tells you whether the scope is honest and the evidence exists.
- You have 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.
- You know your merchant or service provider level and the validation path your acquirer requires.
- You have selected the correct SAQ type, or confirmed that a ROC is 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 you can produce on request.
- Third parties in your CDE have their own AOCs on file and the responsibility split is written down.
- An incident response plan exists, names owners, and has been exercised.
PCI DSS asks for the same discipline good compliance has always asked for. Know exactly where the regulated data lives, shrink that footprint until it is small enough to defend, and keep evidence that the controls run every day rather than the week of the assessment. The annual report is the easy part once that holds.