PCI DSS compliance is the set of security controls every business that accepts, processes, stores, or transmits payment card data must meet under the Payment Card Industry Data Security Standard. The standard is written and maintained by the PCI Security Standards Council, founded in 2004 by Visa, Mastercard, American Express, Discover, and JCB. It currently sits at version 4.0.1, and as of March 31, 2025, every requirement in that version is fully enforceable.
Complying means two things at once: actually meeting the twelve requirement groups in the standard, and proving you meet them through whatever validation method your acquiring bank assigns based on how many card transactions you handle each year.
Who Has to Comply
The standard applies to merchants and to service providers. A merchant is any business that accepts payment cards carrying one of the five major brand logos. A service provider is any organization (other than a card brand) that handles cardholder data for another business or whose services could affect the security of that data. Payment gateways, managed hosting companies, and payment processors are all service providers.
Transaction volume does not decide whether the rules apply to you. A sole proprietor running a few card sales a month has the same underlying obligation as a national chain. Volume decides only how rigorously you have to prove compliance.
Outsourcing payments to a third party does not transfer your responsibility. You stay accountable for confirming that every partner in the transaction chain maintains its own compliance. The Council’s third-party guidance requires merchants to keep a monitoring program that tracks each provider’s status, reviews it at least once a year, and documents what happens if a provider falls out of compliance.1PCI Security Standards Council. Third-Party Security Assurance Information Supplement Contracts should spell out which party owns each security obligation.
The Twelve Requirements
PCI DSS organizes its controls under six goals, each containing specific numbered requirements. The goals build on each other: secure the network, protect the data, defend against vulnerabilities, control access, watch what happens, and hold it all together with policy.
Build and Maintain a Secure Network
Requirement 1 calls for network security controls (firewalls, access control lists, and similar mechanisms) that restrict traffic between the cardholder data environment and everything else. Requirement 2 prohibits default passwords and factory security settings on any system component. Every device needs unique, strong credentials before it touches production traffic.
Protect Cardholder Data
Requirement 3 covers stored data. If you keep card numbers, they must be rendered unreadable through encryption, truncation, hashing, or tokenization. Requirement 4 covers data in transit: any time cardholder data crosses a public network, it must be encrypted.
Maintain a Vulnerability Management Program
Requirement 5 mandates anti-malware protection on systems commonly targeted by malicious software, with regular updates. Requirement 6 requires secure development practices and timely patching. When a vendor releases a critical security patch, you cannot afford to sit on it for months.
Implement Strong Access Controls
Requirement 7 limits data access to people whose jobs genuinely require it. Requirement 8 assigns a unique ID to every user with system access so every action can be traced to a specific person. Requirement 9 addresses physical security: server rooms, data centers, and any location where cardholder data exists must be protected against unauthorized physical entry.
Monitor and Test Networks
Requirement 10 demands logging and monitoring of all access to network resources and cardholder data. Requirement 11 requires regular testing through vulnerability scans and penetration tests. This is where you find problems before an attacker does.
Maintain an Information Security Policy
Requirement 12 ties everything together with a formal security policy that applies to all personnel. Third-party monitoring, incident response planning, and security awareness training all live under this requirement.
Merchant Levels and How You Prove Compliance
Card brands sort merchants into four levels based on annual transaction volume. The thresholds below reflect Visa’s definitions, which are the ones most commonly referenced; other brands use similar ranges with small variations. Your acquiring bank (the bank that processes your card transactions) ultimately determines your level and tells you which validation method to use.
- Level 1: more than 6 million transactions per year. These merchants get the most rigorous treatment: an annual onsite assessment by a Qualified Security Assessor (QSA), a formal Report on Compliance (ROC), and quarterly external network scans by an Approved Scanning Vendor (ASV).2Mastercard. Revised PCI DSS Compliance Requirements for L2 Merchants
- Level 2: 1 million to 6 million transactions per year. Level 2 merchants typically validate through a Self-Assessment Questionnaire (SAQ) and quarterly ASV scans, though some card brands may require a QSA assessment.2Mastercard. Revised PCI DSS Compliance Requirements for L2 Merchants
- Level 3: 20,000 to 1 million e-commerce transactions per year.3Visa. Validation of Compliance – Information Security
- Level 4: fewer than 20,000 e-commerce transactions, or up to 1 million total transactions of any type per year. Levels 3 and 4 generally validate with an SAQ and quarterly ASV scans.3Visa. Validation of Compliance – Information Security
A merchant that suffers a data breach is almost always elevated to Level 1 regardless of transaction volume.
Every merchant, regardless of level, also completes an Attestation of Compliance (AOC): a signed declaration summarizing the assessment results. The AOC plus supporting documentation (SAQ or ROC, plus ASV scan reports) gets submitted to your acquiring bank.4PCI Security Standards Council. Attestation of Compliance – Merchants The acquirer confirms whether validation succeeded.5Visa. Account Information Security (AIS) Program and PCI
ASV scans are a separate, ongoing obligation. You need four passing quarterly scans a year. A scan that flags a high-severity vulnerability fails, and you have to remediate and rescan before the quarter closes. Keep every submission, scan report, and piece of acquirer correspondence; compliance is annual, and clean prior-year records make each cycle faster.
A QSA-led ROC assessment for a Level 1 merchant typically runs from $30,000 to over $200,000, depending on how sprawling the environment is.
Service Provider Levels
Service providers use a separate two-level system based on the number of card transactions they store, process, or transmit each year:
- Level 1: more than 300,000 transactions annually. Requires an annual ROC by a QSA, quarterly ASV scans, penetration testing, and internal scanning.
- Level 2: fewer than 300,000 transactions annually. Validates with SAQ D, quarterly ASV scans, penetration testing, and internal scanning.
Verify a provider’s compliance level and current status before you sign anything. A provider’s breach becomes your problem.
Choosing the Right Self-Assessment Questionnaire
The SAQ is the primary validation tool for merchants below Level 1. Several versions exist, each written for a specific payment environment:6PCI Security Standards Council. SAQs for PCI DSS v4.0.1 Now Available
- SAQ A is for merchants that have fully outsourced all cardholder data functions to validated third parties. No card data touches the merchant’s own systems. This is the shortest questionnaire.
- SAQ A-EP is for e-commerce merchants that partially outsource payment processing but maintain a website that could affect transaction security (for example, a site that redirects customers to a payment page hosted elsewhere).
- SAQ B is for merchants using only imprint machines or standalone dial-out terminals with no electronic cardholder data storage.
- SAQ C is for merchants with internet-connected payment application systems but no electronic cardholder data storage.
- SAQ P2PE is for merchants using a validated point-to-point encryption solution with no electronic cardholder data storage.
- SAQ D is the catch-all. If your environment fits none of the categories above, you complete SAQ D, which covers the full set of PCI DSS requirements.
Picking the wrong SAQ wastes time and can get your submission rejected by the acquirer. If you’re not sure which applies, map exactly how card data enters, moves through, and leaves your environment first. That data flow diagram usually makes the right SAQ obvious.
What Version 4.0.1 Changed
PCI DSS v3.2.1 was retired on March 31, 2024. Version 4.0 replaced it, and v4.0.1 followed as a minor clarification release that did not change substance or push back deadlines.7PCI Security Standards Council. Just Published: PCI DSS v4.0.1 Version 4.0 introduced 64 new requirements; 51 were future-dated to give organizations time to implement. That grace period ended on March 31, 2025, so every requirement is now fully enforceable.8PCI Security Standards Council. Now is the Time for Organizations to Adopt the Future-Dated Requirements of PCI DSS v4.x
Three shifts in v4.0 touch nearly every organization. First, multi-factor authentication now applies to all access into the cardholder data environment, including local and administrative access; under v3.2.1 it was only required for remote access. Second, the standard now allows targeted risk analysis: rather than prescribing fixed frequencies for certain activities, organizations can set their own schedules provided they document a formal risk analysis justifying the choice.9PCI Security Standards Council. Just Published: PCI DSS v4.x Targeted Risk Analysis Guidance Third, organizations can choose between the traditional defined approach (meeting each requirement exactly as written) and a new customized approach that satisfies a requirement’s objective through alternative controls. The customized approach demands rigorous documentation and suits organizations with mature security programs. Compensating controls still exist under the defined approach for legitimate technical constraints, but they cannot be used retroactively to cover a control that was simply missed.10PCI Security Standards Council. PCI DSS v4.0: Compensating Controls vs Customized Approach
The Council frames v4.0 as a move away from snapshot-in-time compliance toward continuous security. Organizations that maintain their controls year-round avoid the expensive cycle of scrambling before each annual assessment.11PCI Security Standards Council. Eight Steps to Take Toward PCI DSS v4.0
Cutting Scope to Cut Cost
The fewer systems that touch cardholder data, the fewer systems you have to protect, test, and document. Scope reduction is the most cost-effective compliance strategy for most businesses, and three techniques do most of the work.
Network Segmentation
Segmentation isolates systems that handle cardholder data from the rest of your network using firewalls, VLANs, access control lists, or a combination. The Council is explicit that segmentation is not itself a PCI DSS requirement, but it sharply reduces the number of systems subject to PCI controls. For a system to qualify as out of scope, it must not store, process, or transmit cardholder data, must sit on a separate network segment, and must have no connectivity path to the cardholder data environment.12PCI Security Standards Council. Guidance for PCI DSS Scoping and Network Segmentation Segmentation controls must be penetration tested at least annually to confirm they’re actually working.
Point-to-Point Encryption
A PCI-listed P2PE solution encrypts card data at the payment terminal and keeps it encrypted until it reaches a secure decryption environment run by the solution provider. Because readable card data is never available inside your network, the number of PCI DSS requirements that apply drops significantly. Merchants using a validated P2PE solution can often qualify for SAQ P2PE, which is far shorter than SAQ D.13PCI Security Standards Council. AT A GLANCE: P2PE v3
Tokenization
Tokenization replaces a card number with a substitute value that has no exploitable meaning if stolen. The actual card data lives in a secure token vault run by the tokenization provider. If your systems only see tokens and never the underlying card numbers, those systems can potentially fall out of PCI DSS scope entirely, provided the isolation is strict: the token cannot be reversed to recover the card number, and the systems handling tokens have no connection to the vault or the cardholder data environment.14PCI Security Standards Council. Information Supplement – PCI DSS Tokenization Guidelines
Many businesses combine all three. A retailer might use P2PE at point-of-sale terminals, tokenization for stored transaction records, and network segmentation to isolate whatever systems remain in scope. Each layer compounds the reduction.
Monitoring Third-Party Service Providers
Outsourcing shrinks your technical burden and creates a management burden. Requirement 12.8 obliges you to maintain an inventory of every service provider that handles or could affect cardholder data, and a documented monitoring program to go with it.1PCI Security Standards Council. Third-Party Security Assurance Information Supplement That program should cover onboarding new providers, recording what services each one delivers and where data lives, and reviewing compliance status at least annually. The contract should require the provider to notify you of any compliance changes or security incidents.
When a provider loses compliance, goes silent, or refuses to share documentation, the Council recommends documenting your attempts to obtain information, raising the provider’s risk level in your records, and contacting the provider’s acquiring bank or the card brands if needed. In a worst case where a provider will not validate, you may need to fold their systems into your own PCI DSS assessment, which is expensive and disruptive.
What Non-Compliance and Breaches Cost
PCI DSS is not a law. It’s a contractual obligation enforced through the agreements between card brands, acquiring banks, and merchants. That distinction matters less than it sounds like it should, because the financial consequences can be severe either way.
Card brands can impose monthly penalties ranging from $5,000 to $100,000 on acquiring banks for harboring non-compliant merchants. Those penalties flow downhill: your acquirer passes them through to you. Sustained non-compliance can also produce higher transaction fees or, ultimately, loss of the ability to accept card payments at all.
A confirmed breach escalates costs sharply. Card brands typically require the compromised merchant to hire a PCI Forensic Investigator (PFI) to determine the scope and cause. That requirement comes from individual card brand programs rather than the Council, and each brand sets its own timeline for when the investigation must start.15PCI Security Standards Council. PFI Program Guide On top of the investigation itself, the merchant typically absorbs card reissuing charges from issuing banks, brand-level fines, legal fees, customer notification expenses, and reputational damage. Post-breach fines alone can reach into the millions.
Businesses that were demonstrably non-compliant at the time of a breach face substantially higher penalties than those that can show they had controls in place and were validated. Compliance is not a guarantee against breaches, but it is the difference between a defensible position and a catastrophic one. Many cyber insurance policies now require PCI DSS compliance as a precondition for coverage, and a lapsed compliance status can give an insurer grounds to deny a claim when you need it most.