PCI DSS Compliance: 12 Requirements, Levels and SAQs
PCI DSS is twelve requirements written in plain language, wrapped in machinery that almost nobody explains: four merchant levels, ten questionnaires named after letters and acronyms, and an enforcement chain that runs through your bank rather than through Visa.
The email that starts this comes from the acquiring bank and runs four sentences. Complete your annual PCI validation by the end of the month. Here is a portal link. Here is a questionnaire named after a letter. Nothing in it says which letter applies to you, why that one, or what happens if you answer honestly and several of the answers are no.
The standard is not the hard part. It is twelve requirements in ordinary English, and a business that already patches its servers and controls who can log in has most of them running. What trips people up is the machinery around it: four merchant levels set by the card brands rather than by the standard, questionnaires that differ by how you take payments, three documents that all sound like proof and are not interchangeable, and a fine that never arrives from the company you think is fining you.
What Is PCI DSS Compliance?
PCI DSS is the Payment Card Industry Data Security Standard, written and maintained by the PCI Security Standards Council, a body founded in 2006 by American Express, Discover, JCB International, Mastercard and Visa. The Council's own description is that PCI DSS is a set of baseline technical and operational requirements designed to protect payment account data, intended for all entities that store, process or transmit cardholder data or sensitive authentication data.
Two of those terms are defined precisely, and the difference decides most of your obligations. The Council's glossary says cardholder data consists at a minimum of the full primary account number, and may also include the cardholder name, expiration date and service code. Sensitive authentication data is a separate category: card verification codes, full track data, PINs and PIN blocks. Cardholder data may be stored under conditions. Sensitive authentication data may not be stored at all once a transaction is authorized, encrypted or not.
The requirements apply inside the cardholder data environment, which the same glossary defines as the systems, people and processes handling that data, plus any system with unrestricted connectivity to them. That last clause quietly swallows networks. A file server on the same flat network as your point of sale terminals is in scope even though no card number ever touches it.
"Compliance" is therefore two things on different clocks. Meeting the requirements is continuous: the controls are on every day of the year. Proving it is periodic: once a year for the paperwork, once every three months for the external scan. An entity that becomes compliant in the four weeks before its filing date is not compliant, it is prepared.
Who Needs PCI DSS Certification?
Nobody. There is no such thing as PCI DSS certification for a merchant or a service provider, and the words are not interchangeable even though every vendor page treats them as though they were.
The Council qualifies assessors: its glossary says QSA companies are qualified by PCI SSC to validate an entity's adherence to PCI DSS requirements. The assessor, or you on your own behalf, performs an assessment and documents the result in a Report on Compliance or a Self-Assessment Questionnaire. Then you attest, on the Council's Attestation of Compliance form. So the assessor is certified, the assessment is a validation, and the output is an attestation. A company describing itself as "PCI certified" is telling you it has not read its own paperwork.
Who has to do it is broader than most small businesses assume. The Council is explicit that PCI DSS is intended for all entities involved in payment processing, including merchants, regardless of their size or transaction volume. A merchant is any entity accepting cards bearing a participating brand's logo as payment for goods or services. Volume changes how you prove compliance, never whether the requirements apply.
Service providers are the other half: anyone storing, processing or transmitting cardholder data for someone else, or running something that could affect its security. Hosting companies, gateways, call centers and anyone who touches a checkout page land here, and their customers ask for the attestation before they sign.
What Are the 12 Requirements of PCI DSS Compliance?
The twelve have been renamed. Version 4 rewrote most of the titles to describe outcomes rather than products, and the old wording is still what most articles reproduce: requirement 1 no longer says "install a firewall", requirement 5 no longer says "use antivirus software". The titles below come from the Council's SAQ D for Merchants, whose requirements mirror the standard.
| # | Requirement | What it asks for in practice |
|---|---|---|
| 1 | Install and Maintain Network Security Controls | Network security controls between the cardholder data environment and everything else, with rules that are documented and reviewed rather than inherited |
| 2 | Apply Secure Configurations to All System Components | No vendor default passwords or settings anywhere, and a hardening standard you can show |
| 3 | Protect Stored Account Data | Store as little as possible, for as short a time as possible, and render the account number unreadable wherever it is kept |
| 4 | Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks | Encryption in transit whenever card data crosses the internet or a wireless network |
| 5 | Protect All Systems and Networks from Malicious Software | Anti-malware that is current, running and logging, with periodic review of systems you decided did not need it |
| 6 | Develop and Maintain Secure Systems and Software | Risk-ranked patching, code review, and change management a Friday hotfix cannot bypass |
| 7 | Restrict Access to System Components and Cardholder Data by Business Need to Know | Least privilege, defined by role, denied by default |
| 8 | Identify Users and Authenticate Access to System Components | Unique IDs, no shared accounts, and multi-factor authentication into the cardholder data environment and for all remote access |
| 9 | Restrict Physical Access to Cardholder Data | Locked rooms, visitor records, media handling, and terminal inspection for skimmers |
| 10 | Log and Monitor All Access to System Components and Cardholder Data | Centralized logging with daily review of security events and twelve months of retention |
| 11 | Test Security of Systems and Networks Regularly | Quarterly internal and external scans, annual penetration testing, wireless detection, payment page tamper detection |
| 12 | Support Information Security with Organizational Policies and Programs | The written program: policies, risk analyses, training, a service provider inventory and a tested incident response plan |
Requirement 3 is where most of the expensive mistakes live, and it contains the one rule that has no exceptions.
They are not equally weighted. Requirements 1, 2, 5, 6 and 9 fall out of ordinary operational hygiene. Requirements 3, 10, 11 and 12 are where an assessment stalls, because they demand records that only exist if somebody was already producing them: a data flow diagram that matches reality, twelve months of logs, four quarters of passing scans, and a tested incident response plan.
What Are the 6 Major Principles of PCI DSS?
The twelve requirements are grouped under six goals, printed at the top of each section of the standard and of every SAQ. The grouping is the fastest way to hold the standard in your head.
"Maintain an information security policy" sounds like the throwaway goal until you notice that requirement 12 carries the risk analyses, the training program, the service provider inventory and the incident response plan. It is the goal that turns twelve technical controls into something an organization is still running in three years.
PCI DSS Compliance Levels for Merchants
The levels are not in PCI DSS. The standard applies the same twelve requirements to everyone; the levels decide only how you prove it. Each brand sets its own, which is why "what level am I?" depends on which brand you ask and, in the end, on what your bank says. Visa puts the split plainly: the Council owns, maintains and manages PCI DSS, but Visa manages all data security compliance enforcement and validation initiatives. Your level comes from total Visa transaction volume over a rolling twelve months, counted across credit, debit and prepaid, in one country or with one acquirer.
| Level | Annual Visa transaction volume | Minimum validation |
|---|---|---|
| 1 | 6 million or more, all channels | Report on Compliance by a QSA, or by internal resources if signed by a company officer, plus an Attestation of Compliance |
| 2 | 1 million to 6 million, all channels | Self-Assessment Questionnaire plus an Attestation of Compliance |
| 3 | 20,000 to 999,999 e-commerce transactions | Self-Assessment Questionnaire plus an Attestation of Compliance |
| 4 | Under 20,000 e-commerce, and all other merchants under 1 million | Self-Assessment Questionnaire, or alternative validation as defined by your acquirer |
Those thresholds and the validation column come from Visa's published PCI DSS validation requirements, which sets the service provider levels far lower: Level 1 above 300,000 Visa transactions a year, Level 2 below. A service provider that wants a place on Visa's Global Registry has to file a full Report on Compliance with a QSA regardless of level, which is why so many small gateways carry a QSA-signed report they would not otherwise need.
There is also a route out of validation that almost nobody uses. Visa's Technology Innovation Program removes the requirement to validate compliance for eligible merchants when at least 75 percent of yearly transactions originate through EMV chip-enabled terminals, a validated point-to-point encryption solution or an integrated industry-standard tokenization solution. The requirements still apply. The annual paperwork does not.
How to Validate PCI DSS Compliance
Three documents do three different jobs, and merchants routinely send the wrong one to a customer who asked for the other.
The third document is the one that actually gets sent. The Attestation of Compliance is the Council's official form on which you attest to the results, whether they came from an SAQ or a ROC, and the Council's FAQ confirms it is intended to be shared externally to requesting entities under the payment brand rules. When a customer asks for "your PCI certificate", the AOC is what they want.
Two pieces of testing sit alongside the paperwork and cannot be self-declared. Requirement 11.3.2 calls for external vulnerability scans at least once every three months by a PCI SSC Approved Scanning Vendor, with vulnerabilities resolved and rescans run until the scan passes. That is a different exercise from the internal vulnerability scanning you run for your own purposes, because only an ASV's report counts and only a passing one. Requirement 11.4 adds penetration testing at least annually and after any significant change.
Which PCI DSS Self-Assessment Questionnaire Do You Need?
Each questionnaire covers only the requirements that apply to one kind of payment environment, and each carries eligibility criteria you have to meet before you may use it. Get this wrong and the attestation is worthless, because you answered the wrong set of requirements.
| Questionnaire | Who it is for |
|---|---|
| SAQ A | Card-not-present merchants with account data functions completely outsourced to validated third parties, keeping only paper reports or receipts |
| SAQ A-EP | E-commerce merchants whose website does not itself receive account data but does affect the security of the transaction or the integrity of the payment page |
| SAQ B | Merchants processing only via imprint machines or standalone dial-out terminals, with no electronic storage of account data |
| SAQ B-IP | Merchants processing only via standalone, PCI-listed PTS point-of-interaction devices with an IP connection to the processor |
| SAQ C | Merchants with payment application systems, such as a point of sale, connected to the internet, storing no electronic account data |
| SAQ C-VT | Merchants keying transactions one at a time into a third-party virtual terminal on an isolated computer |
| SAQ P2PE | Merchants processing only through a validated, PCI-listed point-to-point encryption solution |
| SAQ SPoC | Merchants taking card-present payments on a commercial off-the-shelf mobile device with a secure card reader that is part of a PCI SSC-listed SPoC solution |
| SAQ D for Merchants | Every merchant not eligible for one of the above |
| SAQ D for Service Providers | The only questionnaire available to service providers |
The eligibility text is stricter than those summaries. SAQ A is limited to merchants that do not store, process or transmit any account data in electronic format on their systems or premises, and it does not apply to face-to-face channels or to service providers at all. Most companies that believe they qualify for SAQ A qualify for SAQ A-EP instead, because their own checkout page is doing something. The determination belongs to your acquirer or the payment brand, in the same conversation where you confirm your level.
How to Reduce PCI DSS Scope
Scope is the only real lever. Every requirement applies to the cardholder data environment, so the cheapest program is the one with the smallest environment. Three moves do almost all of the work.
Stop the data reaching you. A hosted payment page or an iframe served by your processor sends card numbers from the customer's browser straight to the processor. That is the difference between SAQ A and SAQ D, which is the difference between a questionnaire that reaches seven of the twelve requirements and one that reaches all twelve.
Tokenize what you keep. If recurring billing needs a stored payment method, store the processor's token rather than the number. A token is useless outside your processor account, so a stolen table of tokens is not a stolen table of cards.
Encrypt at the terminal. For card-present businesses, a validated point-to-point encryption solution encrypts the card inside the reader, so the point of sale, the network and the back office never see readable data.
What Changed in PCI DSS Version 4.0.1
Version 4.0.1 is the current standard. The Council's document library lists it alongside a Summary of Changes from v4.0, and the Council describes 4.0.1 as a limited revision that corrects formatting and typographical errors and clarifies the focus and intent of some requirements, with no requirements added or deleted.
The substantive change happened before it. Version 4 introduced a long list of requirements marked as best practice until 31 March 2025, after which the SAQ text says they are required and must be fully considered during an assessment. That date has passed, so requirements that were optional at your previous filing are now scored.
Version 4 also formalized the customized approach, which lets an entity meet a requirement's stated objective through a different control, provided it documents a targeted risk analysis and an assessor validates the design and effectiveness. It is not a shortcut: it is more work to evidence than the defined approach it replaces.
Is PCI DSS Compliance Mandatory?
Not as a matter of federal law. No US statute requires PCI DSS, no federal regulator issues it, and the Council has no power to fine anyone. It is mandatory in the way that matters commercially, because your merchant agreement says so and your ability to accept cards depends on it.
Enforcement sits with the brands. The Council's own FAQ states that each payment brand, American Express, Discover, JCB International, Mastercard, UnionPay and Visa, runs its own PCI compliance program for its affiliated account data, and directs entities to the brands themselves for information about those programs and their reporting requirements. That is why there is no single authority to appeal to and why two acquirers can ask the same merchant for different paperwork.
State law reaches parts of it. Minnesota's Access Devices; Breach of Security statute makes it unlawful for a business in the state to retain the card security code, the PIN verification code number or the full contents of any magnetic stripe track after authorization, with a 48 hour allowance for PIN debit. That is requirement 3.3.1 written into law, and it carries a liability the standard does not: an entity that retained the data and then suffers a breach must reimburse the issuing bank for canceling and reissuing cards, closing and reopening accounts, blocking transactions, refunding cardholders and notifying them.
The comparison people reach for is SOC 2, and the two are different in shape. SOC 2 is an auditor's opinion against criteria you help shape, requested by customers. PCI DSS is a prescriptive control set imposed by the contract you signed to take payments at all.
What Happens If You Are Not PCI Compliant?
The commonly quoted figure, five thousand to a hundred thousand dollars a month, appears on page after page and is sourced on almost none of them.
Visa's published position is that where a merchant or service provider does not comply, or fails to fix a security issue, Visa may assess a non-compliance assessment to the issuer or acquirer, that the issuer or acquirer pays it, and that they must not represent that Visa imposed it on the merchant. The brand bills your bank, and your bank recovers the money under your merchant agreement. The other consequences follow the same path: higher processing fees, a forensic investigation after an incident, forced migration to Level 1 validation, and eventually termination of your ability to accept that brand. Under a statute like Minnesota's, an entity that retained prohibited data before a breach also owes the issuing banks the cost of reissuing every affected card.
The one thing worth having in place first is the plan required by requirement 12.10. A tested incident response plan turns the first day of a card compromise from improvisation into procedure, and what you do in the hours after a breach decides how much of the rest you control.
How to Become PCI DSS Compliant
The order matters more than the effort. Most failed first attempts are companies that started answering a questionnaire before they knew where their card data was.
Key takeaways
- PCI DSS is a contractual standard, not a law. The Council writes it, the card brands enforce it, and your acquiring bank is the party that asks you for anything.
- There is no PCI certification for merchants. Assessors are qualified, assessments are validations, and the document you send a customer is an Attestation of Compliance.
- Version 4 rewrote the twelve requirements to describe outcomes rather than products. Requirement 1 is network security controls, not "a firewall".
- Sensitive authentication data, meaning the verification code, full track data and PINs, may never be stored after authorization, encrypted or not.
- Merchant levels come from your annual volume with each brand and decide only how you prove compliance, never which requirements apply.
- Which questionnaire you file follows from how you take payments, and the eligibility criteria are stricter than the one-line summaries suggest.
- The requirements that were best practice under version 4 became mandatory on 31 March 2025, including the payment page script controls in 6.4.3 and 11.6.1.
- Published fine schedules do not exist. Non-compliance assessments are billed to your acquirer and reach you through your merchant agreement.
Common questions
What are the 12 requirements of PCI DSS compliance?
Install and maintain network security controls; apply secure configurations to all system components; protect stored account data; protect cardholder data with strong cryptography during transmission over open, public networks; protect all systems and networks from malicious software; develop and maintain secure systems and software; restrict access by business need to know; identify users and authenticate access; restrict physical access to cardholder data; log and monitor all access; test security regularly; and support information security with organizational policies and programs.
Who needs PCI DSS certification?
Nobody, because merchant certification does not exist. What exists is validation and attestation, required of every entity that stores, processes or transmits cardholder data or sensitive authentication data, regardless of size or transaction volume. That covers merchants at every level and any service provider whose systems could affect the security of someone else's card data.
What are the 6 major principles of PCI DSS?
Build and maintain a secure network and systems; protect account data; maintain a vulnerability management program; implement strong access control measures; regularly monitor and test networks; and maintain an information security policy. The twelve requirements sit under those six goals, with requirement 12 carrying the whole of the last one.
Is PCI DSS compliance mandatory?
Yes contractually, no legally. No federal statute requires it, but your merchant agreement does, and losing compliance eventually means losing the ability to accept cards. Several states, Minnesota among them, have written parts of the standard into law with liability for issuer reissuance costs attached.
What is the difference between PCI DSS validation and attestation?
Validation is the assessment: testing controls against the requirements and recording what was found, in a Self-Assessment Questionnaire or a Report on Compliance. Attestation is the signed statement of what that assessment concluded, on the Council's Attestation of Compliance form. The AOC is what customers and acquirers ask to see.
What are the PCI DSS merchant levels?
Four, set by each card brand from your annual volume with that brand. For Visa, Level 1 is 6 million or more transactions across all channels, Level 2 is 1 million to 6 million, Level 3 is 20,000 to 999,999 e-commerce transactions, and Level 4 is under 20,000 e-commerce or under 1 million overall.
Which SAQ do I need?
It follows from how you accept payments, not from your size. Fully outsourced card-not-present merchants use SAQ A, e-commerce merchants whose own page affects the transaction use SAQ A-EP, standalone dial-out terminals use SAQ B, internet-connected point of sale systems use SAQ C, and anyone not eligible for a shorter one uses SAQ D. Your acquirer confirms it.
How often do you need to do a PCI DSS assessment?
The assessment and attestation are annual. External scanning by an Approved Scanning Vendor is required at least once every three months under requirement 11.3.2, penetration testing at least annually under 11.4, and payment page tamper detection at least once every seven days under 11.6.1, unless a targeted risk analysis sets a different frequency.
Does PCI DSS apply if I use Stripe, Square or PayPal?
Yes. A compliant processor reduces which requirements you answer, often to the shortest questionnaire, but you remain the entity accepting the cards and you still file and attest. Requirement 12.8 also makes you responsible for a written inventory of every service provider handling account data and the agreements covering them.
What is a QSA and do I need one?
A Qualified Security Assessor company is qualified by the PCI Security Standards Council to validate an entity's adherence to the requirements. You need one as a Level 1 merchant filing a Report on Compliance, or as a service provider seeking a place on a brand's registry. Below that a QSA is optional, and many companies hire one for readiness work instead.
What happens if you fail a PCI DSS assessment?
You do not fail so much as file with requirements not in place, alongside a remediation plan and dates. Your acquirer decides what follows, usually a deadline and sometimes higher fees. The serious version arrives when non-compliance meets an actual breach, because forensic costs, reissuance liability and non-compliance assessments then land together.
On this page
- What Is PCI DSS Compliance?
- Who Needs PCI DSS Certification?
- What Are the 12 Requirements of PCI DSS Compliance?
- What Are the 6 Major Principles of PCI DSS?
- PCI DSS Compliance Levels for Merchants
- How to Validate PCI DSS Compliance
- Which PCI DSS Self-Assessment Questionnaire Do You Need?
- How to Reduce PCI DSS Scope
- What Changed in PCI DSS Version 4.0.1
- Is PCI DSS Compliance Mandatory?
- What Happens If You Are Not PCI Compliant?
- How to Become PCI DSS Compliant
Daniel Reyes
Daniel Reyes is a CISSP who spent twelve years in security operations, most recently leading a detection and response team for a mid-sized healthcare group in Texas. He reviews every resource and breach report on Cyber Security Firms for technical accuracy before it publishes.
Most of the people he has trained arrived having been told too much: a dozen acronyms, six vendors, and no clear idea which risk was theirs. His approach is to explain what an attack actually does before naming the tool that stops it, on the basis that most breaches start with something a reader could have recognised.