Opens in a new tab
A digital screen displaying PCI Compliance key concepts and a checklist for secure card data protection, with icons and brief descriptions for each compliance requirement.

PCI Compliance Requirements for Businesses That Take Cards

By Jason Russell · September 21, 2026

Ask a small business owner about PCI compliance and you will usually get one of two answers. Either a blank look, or a sigh and a reference to “that form the processor sends.”

I have spent more than twenty five years in network security and the last fifteen running a managed IT company. In that time one conversation has repeated itself more than almost any other, and it starts the same way every time: an owner gets a form from their payment processor and has no idea what to do with it.

The form is a Self Assessment Questionnaire. Depending on which one you were sent, it runs somewhere between thirty and three hundred questions, and it uses phrases like “cardholder data environment” and “non console access.” Most owners read the first page, conclude it was written for a company with a full security department, and either click through it or hand it to whoever looks least busy that week.

I understand the instinct completely. I also want to be direct about what that decision actually is. An SAQ is an attestation. You are telling your acquiring bank, in writing and under your own signature, that a specific set of controls exists inside your business. If a card compromise happens later and a forensic investigator finds those controls were never there, that signed attestation becomes the most expensive piece of paper in your filing cabinet.

This article walks all twelve PCI DSS requirements and translates each one into what it means for a company with twenty five people, one server closet, a couple of card terminals and a website. Not what it means for a retail chain with a security operations center.

Who writes these rules, and who actually enforces them

PCI DSS is published by the PCI Security Standards Council, which was founded by the major card brands. It is not a law and there is no PCI police. The Council itself is unusually blunt about this. In its own words, it does not define compliance requirements for any organization or set compliance validation responsibilities. Those are set by what it calls compliance enforcing entities: the card brands, your acquiring bank, and your payment facilitator.

That distinction matters more than most owners realize. Your actual obligation lives in your merchant agreement. The contract you signed with your processor is what makes PCI DSS binding on you, and it also determines what your processor can charge back to you if things go wrong. If you have never read that section, it is a better use of the next thirty minutes than the rest of this article.

The current version is PCI DSS v4.0.1, the only active version since December 31, 2024. More importantly, the fifty one requirements that version 4.0 originally labeled “future dated best practices” stopped being optional on March 31, 2025. So when someone in your office says “we passed our PCI last time,” the follow up question is which version and which year. A clean 2024 attestation does not mean you would pass today.

Your merchant level, and why it matters less than you think

Merchant levels are set by transaction volume and are assigned by your acquirer, not by you. The traditional framing is four levels: above six million annual transactions, one to six million, twenty thousand to one million e-commerce, and everything below that.

Two things about that framing are worth correcting, because most articles on this topic have not caught up. First, Visa consolidated merchant Levels 3 and 4 into a single Level 3 effective April 25, 2024. Visa now treats one to one million annual transactions as a single tier. Mastercard still uses four levels. You can be Visa Level 3 and Mastercard Level 4 at the same time, with different validation expectations attached to each. Second, a breach can move you up a level regardless of volume.

Here is the part owners most often get wrong: your level changes how you validate, not what you are required to do. All twelve requirements apply at every level. Being small does not shrink the standard. It only shrinks the paperwork you have to file about the standard.

Choosing the right SAQ, which is where most small businesses go wrong

There are nine self assessment questionnaires plus one for service providers, and the right one depends entirely on how card data moves through your business. SAQ A is the shortest. SAQ D for merchants runs past three hundred questions. Landing on the wrong one is the most common and most expensive mistake I see.

The most frequent version of that mistake sounds reasonable: “we use a hosted checkout, so we are SAQ A.” SAQ A eligibility is narrower than that. It requires that every element of the payment page delivered to the customer browser originates only and directly from a PCI DSS compliant third party. A single analytics tag, chat widget or retargeting pixel loading from your own domain on that page can push you into SAQ A-EP, which is a substantially larger questionnaire.

The Council did make life easier for genuine SAQ A merchants in January 2025 by removing Requirements 6.4.3, 11.6.1 and 12.3.1 from that questionnaire and adding an eligibility criterion instead. But read what the Council said alongside that change, because it is easy to misread as a reprieve: those modifications affect how merchants report on those requirements, and they do not remove or diminish the underlying requirements within PCI DSS.

One more trap for mixed environments: swiping a card at a countertop terminal and keying one into a browser based virtual terminal are different acceptance channels with different questionnaires behind them. Plenty of offices do both and validate only the one they think of first.

The twelve requirements, translated

What follows is the plain English version of each requirement, and what it typically looks like when a twenty five person business has to satisfy it.

1. Install and maintain network security controls

In practice: a business grade firewall with a documented rule set that somebody actually reviews. The router your internet provider dropped off does not qualify. The honest version of this requirement in most small businesses is that firewall rules have accumulated over eight years from three different vendors and nobody currently knows what half of them permit. That is the real work item. Know what your firewall allows and why. We made the same argument at length in Nobody Budgets for the Firewall Until It Fails.

2. Apply secure configurations to all system components

Change the defaults, on everything. Terminals, wireless access points, switches, the network printer, the security cameras, the point of sale software. Vendor default credentials are published on the internet, and attackers check them first because it costs them nothing to try.

3. Protect stored account data

The most valuable sentence in this entire article: the best way to satisfy Requirement 3 is to not store card data at all. No spreadsheet of card numbers for recurring clients. No scanned authorization forms sitting in a shared folder. No card numbers typed into the notes field of your CRM or practice management system. No card numbers in email. If you store nothing, most of Requirement 3 becomes not applicable, and a meaningful share of your total PCI burden disappears with it. This is the single highest leverage decision an owner can make here.

4. Protect cardholder data with strong cryptography during transmission

Card data moving across any open or public network has to be encrypted in transit. The part small businesses miss is the human side: do not accept card numbers by email or text message, ever. When a customer sends one anyway, and they will, delete it, tell them why, and give them a safe alternative. Set that expectation in writing before it happens.

5. Protect all systems and networks from malicious software

Managed endpoint protection on every machine that touches the environment, kept current, with someone watching the alerts. Version 4 also added a requirement for mechanisms that detect and protect personnel against phishing, which goes well beyond traditional antivirus and is not satisfied by whatever shipped free with the laptop. More on why the watching matters more than the product in Managed Endpoint Antivirus.

6. Develop and maintain secure systems and software

Patching, on a defined schedule, with evidence that it happened. If you run e-commerce, this is also where payment page script controls live under Requirement 6.4.3: scripts on your payment page must be inventoried, justified and authorized. Most small merchants have never taken that inventory and would be surprised by what is on the page. We covered the discipline side of this in Patch Management.

7. Restrict access to system components and cardholder data by business need to know

The front desk does not need accounting. The bookkeeper does not need the server console. In a small office this is less about buying technology than about admitting everyone was given everything because it was easier during the last staffing crunch. Review access when people change roles, not only when they leave.

8. Identify users and authenticate access to system components

No shared logins. This is the requirement that gets the most pushback in small offices, because one shared front desk account is genuinely convenient. It is also the reason a lot of breach investigations end with nobody able to say who did what.

Two specifics became mandatory on March 31, 2025. If a password is used as an authentication factor, it must be at least twelve characters and contain both numeric and alphabetic characters. And multi factor authentication is now required for all access into the cardholder data environment, for every role, from any location. It previously applied mainly to administrators and remote access. Now an employee connecting from inside your own office is covered too. If twelve character unique passwords sound impossible for your staff, that is the problem password management exists to solve.

9. Restrict physical access to cardholder data

Locked storage for any paper that carries card data, controls on who can reach your network gear, and regular physical inspection of your terminals for tampering or skimming overlays. Terminal skimming is a current attack, not a historical one, and the countermeasure is unglamorous: somebody looks at the devices on a documented schedule and initials a sheet.

10. Log and monitor all access to system components and cardholder data

Logs that exist, are retained, and are actually reviewed. “We have logs” is not what the requirement says. Somebody or something reviews them, and there is a record that the review happened. For a business your size that almost always means buying monitoring rather than building it, because the alternative is asking an office manager to read firewall logs. That is the case we laid out in What Happens at 2 a.m..

11. Test security of systems and networks regularly

Quarterly external vulnerability scans by an Approved Scanning Vendor, internal scanning, wireless detection and penetration testing scaled to your environment. The quarterly ASV scan is the item small merchants skip most often, and it is also the easiest for an acquirer to notice is missing, because those results are filed externally.

12. Support information security with organizational policies and programs

Written policies, annual security awareness training that now has to cover phishing and social engineering specifically, an annual confirmation of what is in scope, a documented incident response plan, and a maintained list of your third party service providers with written acknowledgment of what each is responsible for.

Requirement 12 is where most of the real hours go, and it is the one owners most reliably assume is a formality. It is not. When something goes wrong, Requirement 12 artifacts are the first thing anyone asks for. The training piece is covered in Does Employee Cybersecurity Training Actually Work, and the vendor inventory piece in The Vendor Nobody Owns.

What getting this wrong actually costs

There is a lot of loose talk in this industry about PCI fines, usually framed as “up to five hundred thousand dollars per month.” I do not use numbers I cannot trace to a source document, so here is what Visa publishes in What To Do If Compromised, version 10.0, effective June 25, 2026.

If you suspect or confirm a compromise, notification to Visa is required within three calendar days. If Visa requires a PCI Forensic Investigation and it is not completed within four full calendar months, investigation fees apply: a flat USD 3,000 for Level 3 merchants, or USD 10,000 per month for Level 1 and Level 2 merchants, processors and members.

Separately, Visa moved to a tiered non compliance assessment structure for Level 3 merchants effective February 9, 2025:

Entity Annual transactions Non compliance assessment
Level 3 merchant 1 to 100,000 USD 5,000
Level 3 merchant 100,000 to 500,000 USD 10,000
Level 3 merchant 500,000 to 1,000,000 USD 25,000
Level 2 merchant 1,000,001 to 6,000,000 USD 100,000
Level 1 merchant More than 6,000,000 USD 100,000

Visa also reserves discretion to raise a Level 3 assessment to the USD 100,000 threshold if the facts of the case warrant it.

The nuance that matters to you: these assessments are levied against Visa members, which means your acquiring bank, not directly against you. They reach you through your merchant agreement. So the operative question is not what Visa’s published schedule says. It is what your processor’s contract says it is entitled to pass through to you, on top of card reissuance costs, forensic fees and any fraud losses. If you carry a cyber policy, this is also the moment to find out what it actually covers, a question we took apart in Are You Wasting Money on Cyber Insurance.

One more clause deserves attention from anyone who uses an outside IT provider. A PCI Forensic Investigator cannot be a firm that has provided you with assessment, advisory, consulting, monitoring or network security support within the past three years. Read that again. Your managed service provider is disqualified from investigating your own breach. That is by design, and it is correct, but it means you should know who your forensics firm would be before you need one, not during the worst week of your year.

And in Florida, a second clock is running

The card brands are not the only party with a deadline. Under the Florida Information Protection Act, Florida Statutes section 501.171, a covered entity has no later than thirty days after determining a breach occurred to notify affected individuals. If five hundred or more Florida residents are affected, the Department of Legal Affairs must be notified as well. Civil penalties for failure to notify run to a maximum of five hundred thousand dollars, assessed per breach rather than per individual. A credit card number combined with the security code needed to use it is explicitly covered personal information under that statute.

That obligation exists independently of PCI DSS and of your processor, and thirty days sounds generous until you have lived it.

What PCI compliance does not do for you

I would rather you hear the limits from me than find them later.

  • PCI DSS is scoped to payment card data and nothing else. It has essentially nothing to say about your client files, your patient records, or the business email compromise that redirects a wire transfer. Those are real risks and a clean SAQ does not touch them.
  • A passing attestation is a snapshot. Version 4 is deliberately pushing merchants toward continuous evidence rather than an annual scramble, which is the right direction, but an attestation still describes a moment. Environments drift within weeks.
  • Compliance is not security. I have seen compliant environments get breached and well secured environments fail a questionnaire on documentation gaps. Treating the SAQ as your security program is a category error.
  • Scope reduction has genuine tradeoffs. Validated point to point encryption terminals and fully hosted payment pages usually cost more per transaction or constrain how your checkout looks. The cheaper, more flexible integration is almost always the one that enlarges your scope.
  • Some requirements do not fit a twenty five person company gracefully. Segmentation penetration testing is a fair example. The customized approach exists for cases like that, but it requires a qualified assessor and is not a savings.

Where my own interest lies in all this

Harmony MSP sells managed IT and security services, and I am not going to pretend otherwise while handing you a list of controls. Requirements 1, 2, 5, 6, 7, 8, 10 and 11 map almost directly onto work we bill for. When I say your firewall rules need documenting and somebody needs to be reading your logs, I am describing services we sell.

So here is what we are not. We are not a Qualified Security Assessor and not an Approved Scanning Vendor. We cannot sign your Report on Compliance or run your quarterly ASV scan, and per the three year rule above we could not investigate a breach at a client we support. Any provider telling a small business it handles all of PCI under one roof is either confused about the program or counting on you being confused about it.

And the self interested reason we push scope reduction first: a smaller cardholder data environment is easier for us to secure, easier to keep passing, and generates fewer emergency calls. It also lowers what you spend with us on compliance work. Both are true at once, and I would rather say so plainly than dress it up as principle.

A reasonable first thirty days

If you take nothing else from this, take the sequence. Order matters more than speed.

  1. Pull your merchant agreement and find the PCI clause. Understand what your acquirer is contractually entitled to pass through to you.
  2. Ask your acquirer, in writing, what merchant level they have assigned you and which SAQ they expect. Do not guess, and do not let a sales rep answer it verbally.
  3. Map every path a card takes into your business. Countertop terminal, website checkout, phone orders, mailed forms, mobile readers, recurring billing stored in a scheduling or practice management system. Nearly every owner who does this finds a path they had forgotten.
  4. Find and eliminate stored card data. Search your shared drives, CRM note fields, scanned document folders and email. It is tedious, and it is the highest return hour you will spend.
  5. Then, and only then, open the SAQ.

Doing steps three and four before step five routinely changes which questionnaire applies, and that changes the size of the entire job. I have watched a business go from a three hundred question SAQ D to a short SAQ by deleting one spreadsheet and changing one phone intake habit.

If you are looking at one of these questionnaires right now

If you are a Central Florida business owner staring at an SAQ and you are not sure whether the answers you are about to sign are true, that is a good instinct and it is worth an hour before you submit anything. I am happy to walk through your card acceptance paths and tell you honestly where you stand, including the parts that are not work for us. Call us at (407) 720-6540. No charge for the conversation and no obligation on the other side of it.

Frequently asked questions

What are the PCI compliance requirements for a small business?

All twelve PCI DSS requirements apply to every merchant that stores, processes or transmits cardholder data, regardless of size. They cover network security controls, secure configurations, protecting stored account data, encrypting data in transit, anti malware and anti phishing protections, secure systems and patching, need to know access, unique user authentication with multi factor authentication, physical access controls, logging and monitoring, regular vulnerability scanning and testing, and written policies with training and incident response. Your merchant level changes how you validate compliance, not which requirements apply.

Is PCI compliance required by law?

No. PCI DSS is a contractual obligation rather than a federal law. It becomes binding on you through your merchant agreement with your acquiring bank, and the card brands and your acquirer enforce it. Some state laws reference payment card security separately, and state breach notification statutes such as Florida Statutes section 501.171 apply independently of PCI DSS.

What is the difference between SAQ A and SAQ A-EP?

SAQ A is for merchants who have fully outsourced all payment processing, where every element of the payment page delivered to the customer browser comes only and directly from a PCI DSS compliant third party. SAQ A-EP applies when your own website or server can affect the payment transaction even though it does not store card data, which includes payment pages that load scripts from your own domain. A single analytics tag or chat widget on a checkout page can be the difference.

What happens if you are not PCI compliant?

Nothing, until something goes wrong. Then non compliance affects what your acquirer can assess and pass through to you. Visa’s published non compliance assessments start at USD 5,000 for smaller Level 3 merchants and reach USD 100,000 for Level 1 and Level 2 merchants, with forensic investigation fees on top. Those are levied against your acquiring bank, which recovers them from you under your merchant agreement. Card reissuance costs, fraud losses and state breach notification obligations are separate.

How often do you need to validate PCI compliance?

Annually for the SAQ or Report on Compliance, and quarterly for external vulnerability scans by an Approved Scanning Vendor where applicable. Since PCI DSS v4.0.1 the practical expectation has shifted toward continuous evidence that controls were operating throughout the year, not a single point in time snapshot taken the week the form is due.

Sources

A note on figures: investigation fees and non compliance assessment amounts come directly from Visa’s What To Do If Compromised version 10.0 and are subject to change at Visa’s discretion. Validation requirements are set by your acquirer and payment brands, not by the PCI Security Standards Council. This article is general information about payment card security requirements and is not legal advice.

Our latest posts