PCI DSS 4.0: What Actually Changed for Small Merchants

The statement from your card processor has a new line on it, labeled something like a non-compliance fee or a PCI program fee. You call to ask and get told you never finished your annual questionnaire. There is a portal you have never logged into, a password reset that goes to an email address from two employees ago, and about ninety questions written in a language that is technically English.

You are not being singled out. The card industry rewrote its security standard, the deadlines already landed, and a lot of small merchants found out when the fee showed up. Here is what actually changed, what applies to a business your size, and what does not.

Quick note first. This is general information, not legal, tax, or insurance advice. Your obligations come from your merchant agreement, and those vary. Talk to your own attorney or your processor about your contract.

What PCI DSS Is, and Who Is Making You Do It

PCI DSS stands for Payment Card Industry Data Security Standard, written and maintained by the PCI Security Standards Council, an organization founded by the major card brands. Here is the part that trips people up: it is not a law. It is a contract term. When you signed your merchant agreement to accept cards, you agreed to follow it.

That is why enforcement arrives as a fee on your statement rather than a letter from a regulator. Your processor holds you to it because the card brands hold your processor to it.

The Version Situation, Cleared Up

Version 4.0 came out in March 2022. The Council published version 4.0.1 on June 11, 2024, describing it as a limited revision with no additional or deleted requirements, just corrections and clarifications. Version 4.0 retired on December 31, 2024, so 4.0.1 is the only active version now.

The date that matters: according to the PCI Security Standards Council, version 4 introduced 64 new requirements, and 51 of them were future-dated and became effective on March 31, 2025. If a vendor is calling about an upcoming PCI deadline, the deadline already passed. Not a reason to panic, but a reason to stop treating this as next year’s problem.

The Questionnaire Is the Part You Actually Touch

Most small merchants never read the standard itself. What you fill out is an SAQ, short for Self-Assessment Questionnaire. There are several versions, and the point is that you answer only the one matching how you take cards. Answering a longer one than you need is a self-inflicted wound.

SAQ A is for fully outsourced payments. A third party processes and your systems never handle card data. Shortest one, and where most small e-commerce shops want to land.
SAQ A-EP is for e-commerce sites that touch the payment page. A third party processes, but your site helps deliver the payment page.
SAQ B and B-IP are for standalone terminals. The countertop machine not wired into the rest of your network.
SAQ C and C-VT are for networked payment applications and virtual terminals. A point of sale system on your network, or a browser-based terminal.
SAQ P2PE is for validated point-to-point encryption. The card is scrambled inside the reader before it ever reaches your systems.
SAQ D is everything else. The full standard. If you are on D and should not be, that is worth fixing.

The Changes That Land Hardest on Small Shops

Multi-factor authentication for everything touching card data. Multi-factor authentication, or MFA, means a password plus a second proof like a code from an app. The Council’s announcement of version 4 describes expanding Requirement 8 to require MFA for all access into the cardholder data environment, which just means the systems that store, process, or transmit card data.
Confirming your scope once a year. Requirement 12.5.2 asks you to formally check, annually, which systems are actually in that cardholder data environment. Most small businesses have never done this, and doing it usually shrinks the answer.
Quarterly external scanning for e-commerce. The Council states that e-commerce merchants completing SAQ A are now expected to undergo vulnerability scans at least every three months by an Approved Scanning Vendor, or ASV, a company the Council certifies to run those scans.
Targeted risk analysis. Version 4 lets you set how often you perform certain activities based on your own risk. Real flexibility, but it comes with homework. You have to write down why you picked that frequency.
Firewalls are now network security controls. A terminology change covering modern gear that does firewall work without the name. Your obligation did not change.

The Online Checkout Rule, Without the Jargon

Here is the threat, in one paragraph. A modern checkout page pulls in small pieces of code, called scripts, from several places at once: analytics, chat widgets, ad pixels, your shopping cart. If a bad one ends up on that page, it can quietly read what a customer types into the card fields and send it elsewhere. The order goes through and nothing looks wrong for months. The industry calls this e-skimming.

The Council reworked SAQ A around this. It removed three requirements, 6.4.3, 11.6.1, and 12.3.1, and added a new eligibility criterion instead: the merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce systems.

The Council’s FAQ gives two ways to satisfy that. Implement the protections described in 6.4.3 and 11.6.1 yourself or through a third party, or get confirmation from a PCI DSS compliant payment processor that their embedded payment solution includes script attack protections when properly implemented. The Council also clarified this applies only to merchants using embedded payment pages, meaning card fields appear inside a frame on your own checkout. It does not apply if you redirect customers to the processor’s hosted page or fully outsource payments.

Practical read for a small shop: if your checkout sends people to your processor’s page, this is simpler. If card fields appear on your site inside a frame, email your processor for written confirmation. They almost certainly have a standard document ready.

What to Do This Quarter

Find out which questionnaire you are on. Log into your processor’s compliance portal, and call for a reset if you cannot. Everything else depends on this answer.
Ask your processor two questions in writing. Which SAQ applies to how we take cards, and do you provide script protections for your embedded payment solution? Keep the reply.
Turn on MFA everywhere. Not just payment systems. Email is where account takeovers start, and email can reset most of your other passwords.
Hunt down card numbers where they do not belong. Emailed order forms, spreadsheets in accounting, scanned paperwork, sticky notes at the counter. Every one you eliminate shrinks your scope and your risk together.
Collect an Attestation of Compliance from vendors. An Attestation of Compliance, or AOC, is the document a service provider signs confirming their own PCI status. Any vendor touching your payments should hand one over on request.
Answer the questionnaire honestly. A half-finished SAQ is an operations problem. A signed SAQ full of yeses that are not true is a different kind of problem entirely if you ever have a breach.

Bottom line: for most small merchants around Denton County, version 4 is less a rewrite than a nudge toward things you should already be doing. MFA on everything, a written understanding of which systems touch card data, quarterly scanning if you sell online, and a real conversation with your processor about who handles what. The ones who struggle are filling out a questionnaire they never understood, hoping nobody checks.

Again, none of this is legal advice, and your obligations live in your merchant agreement, so loop in your own attorney or your processor. If you want somebody to figure out which questionnaire actually applies and get the technical pieces in place, reach out to Harrison Ward Technology. We help businesses across Lewisville, Flower Mound, and the rest of Denton County sort this out without buying anything they do not need.

Sources

Compliance Cybersecurity Explainers PCI DSS Small Business IT

Comments are closed