PCI DSS 4.0.1: What Small Businesses Must Do Now

If your business accepts credit cards, PCI DSS 4.0.1 already applies to you, and the deadline to comply has passed. Version 4.0.1 became the only active version of the standard on March 31, 2025, and dozens of controls that used to be optional "best practice" are now required. For a small merchant that means real, checkable work: turning on multi-factor authentication, training staff every year, and knowing exactly where card data moves through your business.

Most owners never look at the standard until a payment processor or an insurer asks for a signed attestation. This is a plain-English guide to what changed and what a small business actually has to do. If you want help with the work itself, our PCI DSS compliance services identify the right questionnaire, build the controls and keep the evidence your bank asks for.

What is PCI DSS, in plain terms?

PCI DSS is the security rulebook that every business storing, processing, or transmitting payment card data has to follow. It is not a government law. The major card brands created it and enforce it through your bank and payment processor. Break the rules or suffer a breach, and the penalties reach you through your merchant agreement.

What changed in version 4.0.1?

Version 4.0 introduced roughly 60 new requirements. About 50 of them were treated as best practice until March 31, 2025, when they became mandatory; UpGuard's 2026 PCI guide tracks the full list. The changes that reach small merchants most directly:

• Multi-factor authentication for anyone who can touch the systems that handle card data.
• Annual security awareness training that now has to cover phishing and social engineering, not just generic policy.
• A wider vulnerability net. You address all discovered vulnerabilities on a risk basis, not only the critical ones.
• Anti-malware controls that include scanning removable media such as USB drives.
• Targeted risk analysis so you can document why you handle a given control the way you do.

Which requirements matter most for a small merchant?

The standard has 12 core requirements grouped under six goals: build secure networks, protect card data, run a vulnerability program, control access, monitor and test, and keep a written security policy. For a business under 20 or 30 staff, the ones that trip people up are MFA, quarterly external vulnerability scans (if any internet-facing system is in scope), keeping a current network diagram, and proving that training actually happened.

If you outsource your entire checkout to a compliant provider like Stripe, Square, or a hosted e-commerce cart, your scope shrinks a lot. You still have to attest, but you are confirming that you did not build your own card-handling systems rather than proving you secured one.

How do I know which SAQ applies to my business?

Nearly every small business is a Level 4 merchant: fewer than 20,000 card-not-present transactions, or up to a million total transactions, a year. Level 4 merchants usually validate with a Self-Assessment Questionnaire (SAQ) instead of a full external audit. Which SAQ you use depends on how you take payments:

• SAQ A when your e-commerce and card handling are fully outsourced to a third party.
• SAQ B for standalone terminals with no electronic card storage.
• SAQ C if you run a payment application connected to the internet.
• SAQ D for everything else, including any storage of card data.

Your acquiring bank or processor tells you which one they expect. When in doubt, ask them in writing.

PCI DSS checklist for small merchants

Your checklist is the SAQ your acquiring bank or processor accepts, so confirm which one applies before you start. The table summarizes the PCI DSS v4.0.1 requirements each merchant SAQ carries, from the PCI Security Standards Council's SAQ Instructions and Guidelines (April 2025) and the SAQs themselves in its document library. The gap between them is large: the Council counts 27 requirements for SAQ A when your website redirects to or embeds your processor's payment page, and 139 for SAQ A-EP.

SAQ	Who it fits	What the checklist covers (PCI DSS v4.0.1 requirement numbers)
SAQ A	Card-not-present merchants (online, mail or phone order) that outsource all card handling to PCI DSS compliant providers. Every element of the payment page comes from the provider, and any card data you keep is on paper.	Vendor default accounts (2.2.2); retention and disposal of paper records (3.1.1, 3.2.1); critical patches within one month (6.3.1, 6.3.3); unique user IDs and passwords of at least 12 characters (8.2, 8.3); securing and destroying paper with card data (9.4); quarterly external scans by an Approved Scanning Vendor (11.3.2); managing your providers and checking their PCI DSS status every year (12.8); an incident response plan (12.10.1). The system items (2, 6, 8 and 11) apply to the web page that redirects to or embeds the payment page. Since January 2025 you also confirm that your site is not susceptible to script attacks that could affect your e-commerce systems.
SAQ A-EP	E-commerce merchants whose own website affects the payment page, for example by creating the payment form or loading scripts in the shopper's browser, with no card data stored, processed or transmitted on their own systems.	Most of the standard for the website: network security controls (1), secure configuration (2), anti-malware (5), an inventory and integrity checks for payment page scripts (6.4.3), access control and MFA (7, 8), logging and log review (10), quarterly ASV scans (11.3.2), an external penetration test every 12 months and segmentation testing (11.4), change and tamper detection on the payment page (11.6.1), and policies, training that covers phishing, and incident response (12).
SAQ B	Merchants using only imprint machines or standalone dial-out terminals, with no electronic card data storage.	No sensitive authentication data kept after authorization, and card numbers masked when displayed (3.3, 3.4.1); access based on job function (7.2.2); media handling (9.4); a list of terminals, regular inspection for tampering and staff training to spot it (9.5); a security policy and awareness program (12.1, 12.6.1); provider management (12.8); an incident response plan (12.10.1).
SAQ B-IP	Merchants using only standalone, PCI-listed approved PIN Transaction Security (PTS) terminals with an IP connection to the processor, with no electronic card data storage.	Everything in SAQ B, plus a network diagram and network controls around the terminals (1.2, 1.3, 1.4.3), vendor default accounts, encrypted administrative access and wireless settings (2.2.2, 2.2.7, 2.3), strong cryptography in transit (4.2.1), patching (6.3), MFA for remote access (8.4.3), quarterly ASV scans (11.3.2) and segmentation testing if you rely on segmentation (11.4.5).
SAQ C-VT	Merchants that key one transaction at a time into a PCI DSS compliant third-party virtual terminal, on an isolated computer with a securely connected browser, with no electronic card data storage.	Network controls around that computer (1.3, 1.5.1); secure configuration (2); anti-malware (5); patching (6.3); access control and MFA for administrative access (7.2.2, 8.4.1); physical security (9); and policies, training that covers phishing, provider management and an incident response plan (12).
SAQ C	Merchants with payment application systems connected to the internet, with no electronic card data storage.	Most of the standard for the payment environment: network controls (1.3), secure configuration (2), encryption in transit (4), anti-malware (5), patching (6), access control and MFA (7, 8.4), physical security (9), logging and log review (10), wireless checks, quarterly internal and ASV scans, segmentation testing and change detection (11.2, 11.3, 11.4.5, 11.5.2), and the policy set in 12.
SAQ D	Every merchant that does not fit another SAQ, including any business that stores card data electronically.	All applicable PCI DSS requirements, including internal and external penetration testing at least every 12 months and after significant changes (11.4).

Two practical notes. First, several of these requirements, including the 12-character password minimum, MFA for all access into the cardholder data environment and training that covers phishing, became mandatory on March 31, 2025, and the Council warns merchants not to assume an SAQ is the same in versions 3.2.1 and 4.x. Second, scope is the cheapest control: moving checkout to your processor's hosted payment page, or terminals onto an isolated network, can move you to a shorter SAQ. We are not a QSA or an ASV; we build the controls and keep the evidence, and your acquirer decides which SAQ it accepts.

What happens if we ignore it?

Non-compliance fees start at a few thousand dollars a month and climb. They are billed to your bank, which passes them to you. The larger risk is a breach: if card data leaks and you were not compliant, you can face forensic audit costs, card-reissue charges, and the loss of your ability to accept cards at all. Many cyber insurance policies also ask about PCI status, and a wrong answer can void a claim.

Frequently asked questions

Does PCI apply if we only take a few cards a month?

Yes. There is no minimum. The moment you accept a card, you agree to PCI DSS through your merchant contract. Volume changes which questionnaire you use and how you validate, not whether the standard applies to you at all.

We use Square and never see card numbers. Are we still on the hook?

You are, but the burden is light. Fully outsourced setups usually qualify for SAQ A, the shortest questionnaire. You confirm each year that you have not pulled card data into your own systems and that your staff follow basic security practices.

Is annual security awareness training really required?

Yes, and version 4.0 expanded it to include phishing and social engineering specifically. A short annual course with simulated phishing satisfies both PCI and most cyber insurers. Our guide to security awareness training shows what that looks like in practice.

Do we need quarterly vulnerability scans?

If any system in your card data environment faces the internet, yes, and they must be run by an Approved Scanning Vendor. Businesses that fully outsource payments and expose nothing card-related online often avoid this, but confirm your scope before you assume it.

How long does it take a small business to get compliant?

For an outsourced setup, a focused week or two. For a business that stores card data or runs its own payment application, plan for a few months to close gaps like MFA, logging, and network segmentation before you sign the attestation.

PCI DSS overlaps heavily with the controls that stop real attacks, so the effort is rarely wasted. Strong authentication, current patching, and trained staff protect you whether or not an auditor is watching. If you are not sure where your business stands, book a complimentary risk assessment and we will map your card data flows and show you the shortest path to compliance.

By The NetSys Group Team. The NetSys Group has delivered managed IT, cybersecurity, and cloud services since 1998. Our engineers hold degrees in electrical and computer engineering and are certified Microsoft and Cisco instructors, serving businesses across NY, NJ, CT, PA, and Southwest Florida.