PCI DSS 4.0 for small merchants: what changed and what you must do

PCI DSS 4.0 for small business comes down to three things: identify how you accept card payments, complete the right Self-Assessment Questionnaire (SAQ), and meet the standard’s new requirements that became mandatory on March 31, 2025. The current version is PCI DSS v4.0.1, a limited revision published in June 2024 that replaced v4.0. If you accept, process, store, or transmit cardholder data in any way, the standard applies to you regardless of size.

The good news for most small merchants: if you use a reputable payment processor and never touch raw card numbers, your obligations are real but manageable. The hard part is knowing which requirements actually apply to your setup, and not accidentally taking on the full standard when a short questionnaire would do.

What PCI DSS 4.0 is and why it changed

PCI DSS (Payment Card Industry Data Security Standard) is a set of security requirements maintained by the PCI Security Standards Council and enforced by the card brands (Visa, Mastercard, American Express, Discover, JCB) through your acquiring bank or payment processor. It is a contractual requirement, not a government law, but the consequences of ignoring it are concrete: higher transaction fees, fines passed down from your processor, loss of the ability to accept cards, and far greater liability if you suffer a breach.

Version 4.0 was a structural rewrite of the standard. It retired version 3.2.1 on March 31, 2024, after which 4.0 became the only active version. The Council then published v4.0.1 in June 2024 as a limited revision: it clarifies wording and corrects errors but adds and removes no requirements. PCI DSS v4.0 was retired on December 31, 2024, leaving v4.0.1 as the only active version you validate against today.

Many of 4.0’s new requirements were “future-dated,” meaning they were best practice at first and became fully mandatory on March 31, 2025. As of 2026, all of those requirements are in force and assessed during any PCI validation.

The biggest themes in 4.0

• Customized approach. Larger organizations can now meet a requirement’s intent through alternative controls, validated by an assessor. Most small merchants will stick with the traditional “defined approach” and can ignore this.
• More emphasis on continuous security. The standard pushes you to treat PCI as an ongoing program, not a once-a-year scramble. Several requirements now ask you to define roles, document who is responsible, and confirm controls are actually working.
• Stronger authentication. Password minimums increased, and multi-factor authentication (MFA) expanded to all access into the cardholder data environment, not just remote and administrative access.
• Targeted risk analysis. Instead of fixed timeframes for some tasks, you document your own risk-based justification for how often you perform them.

The change that matters most to small e-commerce merchants

If you run an online store, the requirements that have caused the most confusion are 6.4.3 and 11.6.1, which address scripts running on your payment pages and detecting unauthorized changes to them. These target “Magecart”-style attacks, where attackers inject malicious JavaScript to skim card data as customers type it.

In late January 2025, the Council updated the SAQ A questionnaire, the shortest one, used by merchants who fully outsource their payment page. For merchants who qualify for SAQ A, Requirements 6.4.3 and 11.6.1 (and the related risk analysis under 12.3.1) were removed and replaced with two eligibility conditions: every element of your payment page must come directly from a PCI DSS compliant processor, and you must confirm your site is not susceptible to script-based attacks that could affect the payment system.

There is an important nuance the Council clarified in FAQ 1588. This new carve-out is aimed at merchants who embed the processor’s payment form on their own page, typically through an iframe. Merchants who instead redirect the customer to the processor’s own domain were already eligible for SAQ A and did not carry the same script-security burden, because the browser isolates the processor’s page from your site once the redirect happens. If you do not qualify for SAQ A at all, those script-security requirements still apply to you in full.

The takeaway: how you embed or hand off your payment form determines both which questionnaire you complete and how much work you take on.

Step 1: Determine your merchant level

Card brands sort merchants into levels based on annual transaction volume. The exact thresholds vary slightly by brand, but the general structure is:

• Level 4 covers the smallest merchants and is where nearly all SMBs land. It typically allows self-assessment.
• Levels 2 and 3 cover mid-volume merchants, usually still self-assessment with more scrutiny.
• Level 1 covers the highest-volume merchants and typically requires an annual on-site audit by a Qualified Security Assessor (QSA) or an internal audit signed off by an officer of the company.

Most small businesses are Level 4 and validate compliance themselves. Confirm your level with your acquiring bank or processor, because they set your validation obligations.

Step 2: Find your SAQ type

The Self-Assessment Questionnaire is how eligible merchants attest to compliance. Picking the right one is the single most important decision in scoping your effort, because it dictates how many requirements apply. Common types include:

• SAQ A — Card-not-present merchants (e-commerce or mail/telephone order) who fully outsource cardholder data handling to a PCI-compliant third party. Shortest questionnaire.
• SAQ A-EP — E-commerce merchants whose website does not receive card data but can affect the security of the payment transaction (for example, a payment form on your own page that draws on a processor’s elements). More requirements than SAQ A.
• SAQ B / B-IP — Merchants using standalone, dial-out or IP-connected payment terminals with no electronic cardholder data storage.
• SAQ C / C-VT — Merchants with payment application systems or virtual terminals, isolated from other systems.
• SAQ P2PE — Merchants using a validated point-to-point encryption solution.
• SAQ D — Everyone else, including merchants who store cardholder data or do not fit another type. This is the long one.

Your goal is to legitimately qualify for the simplest SAQ that fits your setup, usually by outsourcing more, not by claiming an SAQ you do not qualify for. Your processor or bank can confirm which applies.

Step 3: Do the work that actually applies

Once you know your SAQ, the requirements become concrete. For a typical small e-commerce or SaaS merchant, the practical checklist looks like this:

• Reduce scope first. The less cardholder data you touch, the fewer requirements apply. Use hosted payment pages, tokenization, and a P2PE or validated processor so card numbers never hit your systems.
• Inventory and segment. Document every system, person, and process that could affect payment security. Keep your cardholder data environment separated from the rest of your network.
• Lock down access. Enforce unique IDs, strong passwords, and MFA for anyone who can reach payment systems or admin tools. Remove default credentials.
• Patch and harden. Keep systems updated, run anti-malware where required, and configure firewalls and secure settings on anything in scope.
• Manage your vendors. Maintain a list of third-party service providers that handle cardholder data, confirm their PCI status, and keep written responsibility agreements. This overlaps heavily with broader vendor risk management.
• Monitor and log. Capture logs for in-scope systems and review them. For e-commerce, address payment-page script integrity if your SAQ requires it.
• Test and document. Run the required vulnerability scans (an Approved Scanning Vendor external scan is required for many SAQ types), keep policies current, and complete a targeted risk analysis where the standard calls for it.
• Train your people. Anyone handling cards or supporting payment systems needs security awareness training.

Common mistakes that trip up small merchants

The most expensive errors are usually scoping errors. Storing the full card number or the security code “just in case” pulls you into SAQ D and a far larger control set. Pasting card numbers into email, CRM notes, or chat does the same. Treating PCI as a one-time form rather than an ongoing program means controls quietly drift out of compliance, and your annual attestation becomes inaccurate. Because PCI shares so many controls with frameworks like SOC 2 and ISO 27001, many of these practices double as evidence elsewhere, which is why continuous control monitoring is worth setting up once and reusing.

Penalties and what is actually at stake

The PCI Council does not fine merchants directly. Instead, fines flow from the card brands to your acquiring bank, which passes them to you, and amounts vary by contract and circumstance, so be skeptical of anyone quoting a precise universal figure. What is consistent is the shape of the risk: non-compliance can mean increased fees, monthly penalties, mandatory forensic investigation after an incident, and in serious cases termination of your ability to process cards. After a breach, being out of compliance also weakens your position significantly. The cost is rarely a single line item, which is why thinking about the broader cost of non-compliance is the right frame.

Your 2026 action plan

1. Confirm your merchant level and the correct SAQ with your processor or acquiring bank.
2. Map exactly how card data flows through your business and remove every unnecessary touchpoint.
3. Complete the applicable SAQ honestly, run any required scans, and address gaps.
4. Sign and submit your Attestation of Compliance on the schedule your processor requires (typically annually).
5. Build a light recurring routine so controls stay in place between attestations.

PCI DSS 4.0 rewards merchants who outsource card handling and keep good documentation. For a small team, the heavy lift is staying organized across access reviews, vendor records, scans, and evidence all year. Forteri is a multi-framework compliance platform built for SMBs that maps PCI alongside SOC 2, ISO 27001, HIPAA, and NIST CSF, so the policies, monitoring, vendor records, and evidence you maintain for one framework carry over to the rest. If PCI is one of several boxes you need to check without an enterprise budget, it is worth a look.