Short answer
PCI compliance means meeting the Payment Card Industry Data Security Standard (PCI DSS), the security rules for any business that stores, processes, or transmits card data. Version 4.0.1 is the only active version. Most small merchants prove compliance once a year with a self-assessment questionnaire, and some also need a passing external scan from an approved scanning vendor every three months.
What is PCI compliance? It means following the Payment Card Industry Data Security Standard (PCI DSS), the security rulebook for every business that stores, processes, or transmits card data. The PCI Security Standards Council (PCI SSC) describes the standard as a set of baseline technical and operational requirements designed to protect payment account data, and it applies whether you run one food truck or fifty stores.
The good news: for most small merchants, staying compliant comes down to one questionnaire a year, sometimes a scan every quarter, and a setup that keeps card numbers off your own systems. Below: the current version, how to pick your self-assessment questionnaire (SAQ), the yearly to-do list, what skipping it costs, and how to shrink the work. Everything is dated as of October 2026.
Who sets the PCI rules, and who enforces them?
PCI SSC writes and maintains the standard, but it doesn't police anyone. Its own About Us page answers the question "Does the PCI Security Standards Council enforce compliance?" with a flat "No," and says whether you must comply or validate is up to the organizations that run compliance programs, such as the payment brands and your acquirer.
The card brands run those programs: PCI SSC notes that American Express, Discover, JCB International, Mastercard, and Visa each have their own. Visa puts it plainly: PCI SSC owns and manages the standard, but Visa manages all data security compliance enforcement and validation initiatives for its network.
In day-to-day terms, your acquirer, the bank behind your merchant account, is the one Visa holds responsible for ensuring the PCI DSS compliance of its service providers and merchants, so it's the one that asks you for proof. And no, being small doesn't exempt you. PCI SSC says the standard is intended for all merchants regardless of size or transaction volume, and that whether a small merchant has to formally validate is decided by the individual payment brands.
What is the current version of PCI DSS?
As of October 2026, PCI DSS v4.0.1 is the only active version. Here's how it got there.
| Date | What changed |
|---|---|
| March 2022 | PCI DSS v4.0 published, with many new requirements marked as best practices until 2025 |
| March 31, 2024 | v3.2.1 retired; v4.0 became the only active version |
| June 2024 | v4.0.1 released as a limited revision with no added or deleted requirements |
| October 15, 2024 | SAQs for v4.0.1 published |
| December 31, 2024 | v4.0 retired; v4.0.1 became the only active version |
| March 31, 2025 | 51 future-dated requirements became mandatory, and a revised SAQ A took effect |
| June 3 to July 20, 2026 | PCI SSC collected industry comments on v4.0.1 to start the next version |
Sources: PCI SSC on the best-practice period, the v4.0 transition, v4.0.1, future-dated requirements, the v4.0.1 SAQs, the SAQ A update, and the 2026 comments.
That 2026 comment period, which PCI SSC framed as the start of the next version, changes nothing you do today. When a new version arrives, expect overlap: PCI SSC says all new versions come with a period when both the current and updated versions are active.
The 12 PCI DSS requirements at a glance
PCI DSS v4.x has 12 principal requirements under six goals, listed here as PCI SSC publishes them, with names lightly shortened.
| Goal | Requirements |
|---|---|
| Build and maintain a secure network and systems | 1. Install and maintain network security controls. 2. Apply secure configurations to all system components. |
| Protect account data | 3. Protect stored account data. 4. Protect cardholder data with strong cryptography during transmission over open, public networks. |
| Maintain a vulnerability management program | 5. Protect all systems and networks from malicious software. 6. Develop and maintain secure systems and software. |
| Implement strong access control measures | 7. Restrict access by business need to know. 8. Identify users and authenticate access. 9. Restrict physical access to cardholder data. |
| Regularly monitor and test networks | 10. Log and monitor all access. 11. Test security of systems and networks regularly. |
| Maintain an information security policy | 12. Support information security with organizational policies and programs. |
Nobody expects a corner store to build all of that from scratch. Most SAQs include only the requirements that apply to their type of setup; SAQ B-IP, for example, includes only those PCI DSS requirements applicable to merchants that use standalone, PCI-listed terminals. Pick the right SAQ and the list gets much shorter.
Which SAQ applies to your business?
An SAQ is the yearly form most small merchants use to validate. Which one you file depends on how card data reaches you, not on your industry. Here is the current lineup in plain English.
| SAQ | Fits merchants who | Typical small-business example |
|---|---|---|
| A | Accept only card-not-present payments (online, mail, or phone) and fully outsource card handling to a PCI DSS compliant provider | Online store using a hosted checkout page or emailed payment links |
| A-EP | Sell online with a website that doesn't receive card data but controls how it reaches the processor | Custom checkout whose form posts card data straight to the processor |
| B | Use only imprint machines or standalone dial-out terminals | Older terminal on a phone line |
| B-IP | Use only standalone, PCI-listed terminals with an IP connection, kept apart from other systems | Countertop terminal on its own network |
| C-VT | Key one transaction at a time into a third-party virtual terminal on an isolated computer | Office staff keying phone orders |
| C | Run payment application systems connected to the internet, with no electronic card data storage | Integrated POS system |
| P2PE | Use only terminals from a validated, PCI-listed point-to-point encryption solution | Store counter with P2PE terminals |
| SPoC | Use a phone or tablet with a secure card reader in a validated SPoC solution | Mobile reader that takes PIN entry on a phone |
| D | Don't fit any of the above | Anyone storing card numbers electronically |
Sources: PCI SSC's SAQ A update, the v4.0.1 A-EP, B-IP, C-VT and P2PE forms, the v4.0 B and C forms, and its SAQ overview. If you use SPoC, note that PCI SSC set a sunset period for the SPoC standard from May 1 to October 31, 2026; ask your provider what you'll file next year.
A quick way to narrow it down:
- If you store card numbers electronically anywhere (a spreadsheet, a database, an email inbox), start from SAQ D. The other SAQs are written for merchants with no electronic card data storage.
- If you sell only online through a hosted page, a redirect, an embedded payment frame, or emailed payment links, look at SAQ A.
- If your own website builds the payment form or loads scripts into it, you're likely in SAQ A-EP.
- If you key phone orders into a virtual terminal on one dedicated computer with no card reader attached, look at SAQ C-VT.
- If you take cards in person on standalone terminals, look at B-IP, or P2PE if the terminals belong to a validated P2PE solution.
Take a Denver coffee shop with two countertop terminals on their own network and an online gift card page built on its processor's hosted checkout. The counter points toward SAQ B-IP and the website toward SAQ A, so it should ask how its acquirer wants both channels reported. PCI SSC points questions about validation and reporting to the acquirer or the payment brands, so confirm the SAQ with them.
What do you have to do every year?
It's a yearly cycle, not a certificate you frame:
- Confirm your merchant level. In Visa's validation table, Level 1 (over 6 million Visa transactions a year) files a Report on Compliance by a Qualified Security Assessor plus an Attestation of Compliance every year. Level 2 (1 to 6 million) and Level 3 (under 1 million) complete an SAQ every year. Mastercard, American Express, and Discover use their own tables, compared in our guide to PCI compliance levels.
- Map every way card data enters your business, including phone orders someone writes on a notepad.
- Choose your SAQ, answer it honestly, and sign the Attestation of Compliance that comes with it.
- If your SAQ includes Requirement 11.3.2, get passing external scans from a PCI Approved Scanning Vendor (ASV) at least once every three months. Our ASV scan guide covers what passes.
- If your checkout embeds a provider's payment form, confirm your site isn't open to script attacks, either with your own controls or with written confirmation from your payment provider.
- Submit what your acquirer asks for, keep copies, and put next year's date on the calendar.
Two details trip people up. Visa merged its old Levels 3 and 4 into one Level 3 on April 25, 2024, without changing anyone's compliance requirements. And for v4.x, PCI SSC added ASV scans to SAQ A: they cover the system hosting a page that redirects to a payment provider or embeds its payment form.
Step 5 comes from the SAQ A revision that took effect March 31, 2025, which dropped Requirements 6.4.3 and 11.6.1 and added this eligibility check. Per PCI SSC's FAQ, it applies to sites that embed a payment form (an iframe), not to redirects or emailed payment links.
What happens if you're not PCI compliant?
There are two kinds of cost. The small, steady kind shows up on your statement: if your processor charges a PCI non-compliance fee, it appears as a line item until you validate. Our guides to hidden processing fees and reading your merchant statement show where to look.
The large kind starts with a breach. Visa's What To Do If Compromised rules set tight clocks:
- Report the incident to Visa and your acquirer within three calendar days, using Visa's incident report.
- If Visa requires a PCI Forensic Investigator (PFI), sign a contract with one within five business days.
- Get the PFI's preliminary report to Visa within five business days of hiring them, and the final report within ten business days after the investigation ends.
- Deliver all potentially compromised account numbers within ten business days, per Visa's guidance for merchants.
Then come the assessments. Visa says that if a merchant doesn't comply with PCI DSS or fails to fix a security issue, it may assess a non-compliance assessment to the acquirer, which pays it. Visa's compromise rules also list tiered assessments for Level 3 merchants, effective February 9, 2025: $5,000 for merchants with up to 100,000 annual transactions and $10,000 for those with 100,000 to 500,000. Read your merchant agreement to see how costs like these can be passed on to you.
One line in Visa's rules matters more than any fee. Visa says assessments may be waived if a forensic investigation finds no evidence of PCI DSS non-compliance before and at the time of the breach. Being current when something goes wrong is your best defense, which is a better reason to do the paperwork than avoiding a monthly fee.
How do tokenization, P2PE, and hosted checkout shrink your PCI scope?
Scope is the set of systems and processes that PCI DSS applies to in your business. The less card data you touch, the smaller it gets, and the shorter your SAQ.
Hosted checkout is the biggest lever for online sellers. When every element of the payment page comes from a PCI DSS compliant provider, through a redirect, an embedded frame, or a payment link, you can qualify for SAQ A. PCI SSC's e-commerce guidance described the iframe approach as eligible for the smallest possible subset of PCI DSS requirements, because the provider handles most of the work. Clearo's online payments include hosted checkout.
Tokenization matters if you keep cards on file for repeat or recurring charges. PCI SSC's tokenization guidelines recommend minimizing the number of system components that store, process, or transmit card numbers, and storing tokens instead does exactly that. You still validate your environment every year; tokens shrink the job rather than end it.
Point-to-point encryption (P2PE) does the same for in-person sales. Merchants on a PCI-listed P2PE solution have fewer PCI DSS requirements to meet, according to PCI SSC. The word "validated" matters: PCI SSC's merchant FAQ says encryption alone is generally insufficient to take card data out of scope. A terminal that merely "encrypts" isn't the same as a PCI-listed P2PE solution.
Visa adds a carrot. Its Technology Innovation Program removes the annual validation requirement for eligible merchants when at least 75% of yearly transactions run through EMV chip terminals, a validated P2PE solution, or EMVCo-standard tokenization. In the US, the terminals must accept both contact chip and contactless. Ask your acquirer whether you qualify before you skip anything. Our POS terminals take chip and tap, and is tap to pay safer? explains why both protect card data better than a swipe.
Common PCI mistakes that break compliance
The mistakes below are habits, not hacks, which means you can fix most of them this week:
- Keeping the security code. PCI DSS treats card verification codes as sensitive authentication data, and storing them after authorization is prohibited, even if encrypted. That includes the sticky note from a phone order.
- Letting card numbers land in email or text messages. That's electronic storage, which pushes you toward SAQ D.
- Picking SAQ A when your developer added scripts to the checkout page. A Chicago online retailer that swaps its hosted page for a custom form has likely moved into SAQ A-EP, or SAQ D if card data now passes through its own server.
- Assuming a compliant provider makes you compliant. You still attest to your own setup each year.
- Skipping a quarterly scan. Requirement 11.3.2 calls for a passing scan at least once every three months, so a missed quarter is a gap.
- Leaving default passwords on terminals and routers. Requirement 2 is literally about secure configurations.
If you take orders by phone, the cleanest habit is keying them straight into a virtual terminal while the customer is on the line, then shredding nothing because you wrote nothing down. Our guide to card-not-present transactions covers the other risks of phone and online sales.
Is a full PCI assessment worth it for a small business?
Usually not. Visa's table puts merchants under 1 million Visa transactions a year on an annual SAQ, not an on-site audit by a Qualified Security Assessor. Paying for a full assessment makes sense mainly if your acquirer requires one or your setup is complex, for example if you store card data or run your own payment page.
For most small merchants, the money is better spent shrinking scope: move to hosted checkout online, use validated P2PE or chip terminals in store, and stop storing anything you don't need. A shorter SAQ is easier to complete honestly, and an honest SAQ is the one that protects you after a breach. PCI requirements come from the card industry, so they work the same way across the United States; state rules on topics like surcharging are a separate layer.
Next step
If you're not sure which SAQ fits your setup, or there's a PCI line on your statement you can't explain, send us a recent statement for a free statement review. We'll point out PCI-related charges and tell you what your payment setup likely requires. Clearo also offers PCI compliance support, and if you'd rather talk it through first, contact us.
About this guide
Written by the Clearo Payments team. Clearo provides interchange-plus payment processing to merchants in the US and Canada, with no long-term contracts and no cancellation fees. Card network rules and laws change, so check the sources below before you act on anything here. Our editorial standards explain how we source and update guides. Questions about your own setup? Ask our team.
Sources
Official and primary sources we checked while writing this guide.
- Merchant Resources - PCI Security Standards Council (pcisecuritystandards.org)
- About Us - PCI Security Standards Council (pcisecuritystandards.org)
- Maintaining Payment Security - PCI Security Standards Council (pcisecuritystandards.org)
- Just Published: PCI DSS v4.0.1 (blog.pcisecuritystandards.org)
- Now is the Time for Organizations to Adopt the Future-Dated Requirements of PCI DSS v4.x (blog.pcisecuritystandards.org)
- Countdown to PCI DSS v4.0 (blog.pcisecuritystandards.org)
- Important Updates Announced for Merchants Validating to Self-Assessment Questionnaire A (blog.pcisecuritystandards.org)
- FAQ Clarifies New SAQ A Eligibility Criteria for E-Commerce Merchants (blog.pcisecuritystandards.org)
- Resource Guide: Vulnerability Scans and Approved Scanning Vendors (blog.pcisecuritystandards.org)
- Request for Comments: PCI Data Security Standard (PCI DSS) v4.0.1 (blog.pcisecuritystandards.org)
- Point-to-Point Encryption (P2PE) Standard - PCI SSC (pcisecuritystandards.org)
- FAQ: Are merchants allowed to request card verification codes/values from cardholders? - PCI SSC (pcisecuritystandards.org)
- PCI DSS v4.0.1 Self-Assessment Questionnaire P2PE - PCI SSC (docs-prv.pcisecuritystandards.org)
- PCI DSS v4.0 Self-Assessment Questionnaire B - PCI SSC (listings.pcisecuritystandards.org)
- PCI DSS v4.0 Self-Assessment Questionnaire C - PCI SSC (listings.pcisecuritystandards.org)
- Information Supplement: PCI DSS Tokenization Guidelines (listings.pcisecuritystandards.org)
- Account Information Security (AIS) Program and PCI | Visa (corporate.visa.com)
- What To Do If Compromised - Visa Supplemental Requirements (usa.visa.com)
- Protecting Your Business - Data Security - Visa (usa.visa.com)
- Merchant qualifications | Visa (corporate.visa.com)
- Coffee with the Council Podcast: Guidance for PCI DSS E-commerce Requirements Effective After 31 March 2025 (blog.pcisecuritystandards.org)
- PCI DSS v4.0: What's New with Self-Assessment Questionnaires (blog.pcisecuritystandards.org)
- SAQs for PCI DSS v4.0.1 Bulletin - PCI SSC (pcisecuritystandards.org)
- PCI DSS v4.0.1 SAQ A-EP - PCI SSC (docs-prv.pcisecuritystandards.org)
- PCI DSS v4.0.1 SAQ B-IP - PCI SSC (docs-prv.pcisecuritystandards.org)
- PCI DSS v4.0.1 SAQ C-VT - PCI SSC (docs-prv.pcisecuritystandards.org)
- Software-Based PIN Entry on COTS (SPoC) - PCI SSC (pcisecuritystandards.org)
- Information Supplement: Best Practices for Securing E-commerce - PCI SSC (listings.pcisecuritystandards.org)