PCI DSS 4.0 Is Mandatory Now: A 2026 Compliance How-To for Merchants & Their MSP

PCI DSS 4.0 was not a cosmetic version bump. The Payment Card Industry Security Standards Council designated dozens of new requirements as "future-dated," giving organizations a runway to implement them. That runway closed on March 31, 2025. The current revision, v4.0.1 (published June 2024), is now the operative standard, and 2026 assessments are evaluated against the full requirement set with no remaining transition relief.

Two shifts make this more than a checkbox exercise. First, the standard pushes merchants from a once-a-year compliance snapshot toward continuous operational assurance, with controls that must demonstrably run all year, not just during the audit window. Second, for any merchant that takes payments through a browser, the consumer's payment page is now an explicit attack surface the standard expects you to monitor. Magecart-style skimming attacks that inject malicious JavaScript into checkout pages drove the new client-side requirements, and they apply to far more merchants than most realize, including those who assumed a hosted or iframe payment form put them out of scope.

The enforcement reality is straightforward: acquiring banks and card brands can levy fines, raise transaction fees, or restrict card acceptance for non-compliant merchants, and a breach involving cardholder data while non-compliant compounds the liability dramatically. Compliance is also increasingly a contractual precondition for working with larger partners and platforms.

You cannot scope a program you have not sized. Your merchant level is set by the card brands and driven primarily by annual transaction volume, ranging from Level 4 (smallest, typically fewer than roughly 20,000 e-commerce transactions or under a million total) up to Level 1 (the largest, generally above six million transactions, or any merchant a brand designates after a breach). Level 1 merchants must validate through an annual Report on Compliance (ROC) performed with a Qualified Security Assessor and quarterly external scans by an Approved Scanning Vendor. Levels 2 through 4 generally self-assess, though exact thresholds vary slightly by card brand.

Choosing the right Self-Assessment Questionnaire

If you self-assess, the SAQ type matters enormously because it dictates how many of the standard's requirements actually apply to you. The major types map to how you accept payments:

• SAQ A — card-not-present merchants who have fully outsourced cardholder data handling to validated third parties (for example, a fully hosted or properly implemented iframe checkout). Note that v4.0 revised SAQ A's eligibility conditions, and the new client-side script requirements now reach merchants who previously thought SAQ A excused them.
• SAQ A-EP — e-commerce merchants whose site does not receive card data directly but can affect the security of the payment transaction (for example, a page that redirects to or embeds a payment processor's form but is itself controllable). This is the category that most underestimates its obligation.
• 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 connected to the internet, or those using a virtual terminal on an isolated workstation.
• SAQ D — the comprehensive questionnaire for merchants who store, process, or transmit cardholder data directly and do not fit a narrower type. This is the heaviest lift.

Picking the wrong SAQ is one of the most common and costly mistakes, because it either inflates your effort or, worse, signs off on controls you do not actually have. Validate your selection against the official eligibility criteria with your acquirer or assessor before you build anything.

Every system that stores, processes, or transmits cardholder data, and every system that can affect the security of those systems, is in scope. The single most effective way to lower cost, risk, and ongoing effort is to shrink that footprint before you start applying controls.

1. Tokenization and outsourcing. Replace stored card numbers with tokens, and route capture through a validated payment processor so raw card data never touches your environment. Done correctly, this can move an e-commerce merchant from the sprawling SAQ D down to a far lighter SAQ. The cheapest cardholder data to protect is the data you never hold.
2. Network segmentation. Isolate the cardholder data environment (CDE) from the rest of your corporate network with firewalls and access controls so that the dozens of in-scope requirements apply only to a small, well-defined zone instead of every laptop and server you own. Without segmentation, your entire flat network is your CDE.
3. Data flow mapping. You cannot segment what you have not mapped. Diagram exactly how card data enters, moves through, and leaves your business, including call-center notes, email, and back-office spreadsheets where sensitive data quietly accumulates.

Scope reduction is also where strong access controls pay off. Restricting and monitoring administrative access to in-scope systems is foundational, which is why disciplined privileged access management (PAM) and least-privilege principles are increasingly part of well-run cardholder data environments.

Several v4.0 additions catch merchants off guard because they demand ongoing work rather than a one-time configuration. These are the controls most likely to fail a 2026 assessment.

Targeted risk analyses

PCI DSS 4.0 introduced the targeted risk analysis (TRA) as a documented, repeatable exercise. There are two flavors. The first lets you justify the frequency of certain recurring activities based on your environment's risk profile rather than a one-size-fits-all interval, but you must produce a written analysis to defend that frequency. The second applies whenever you meet a requirement using the customized approach (more below). Assessors now expect to see TRA documentation, reviewed at least annually. "We do it when we get around to it" is no longer a valid answer.

Anti-phishing and authentication

The standard strengthened expectations around defending against phishing and around authentication, most notably broader multi-factor authentication for access into the CDE, plus processes and automated mechanisms to detect and protect personnel from phishing attacks. Phishing remains the front door for credential theft and business email compromise, so this requirement reflects how most card-data incidents actually begin.

Client-side script integrity for e-commerce

This is the requirement getting the most attention, and rightly so. Two new controls govern the payment page rendered in the consumer's browser:

• Requirement 6.4.3 — manage all scripts that load on the payment page: confirm each is authorized, ensure its integrity, and maintain an inventory with a written justification for why each script is necessary.
• Requirement 11.6.1 — deploy a tamper- and change-detection mechanism that alerts you to unauthorized modifications of the HTTP headers and the payment page content as received by the consumer's browser, evaluated at least weekly or at a frequency set by a targeted risk analysis.

These exist to stop digital skimming, where attackers inject a few lines of JavaScript to siphon card numbers as customers type them. Crucially, these requirements can apply even to merchants using third-party or embedded payment forms, because the surrounding page can still be compromised to manipulate the payment flow. If you run e-commerce, assume 6.4.3 and 11.6.1 are in scope until you have documented evidence otherwise.

For each requirement, v4.0 gives you two ways to demonstrate compliance. The defined approach means implementing the control exactly as written and validating against the stated testing procedures, the right path for the vast majority of merchants. The customized approach lets a risk-mature organization engineer its own controls to meet a requirement's stated objective, validated by the assessor against a mandatory targeted risk analysis.

Two practical points. First, the customized approach is genuinely demanding: it requires documented risk analysis, controls matrices, and a QSA willing to test bespoke controls. It is not a shortcut, and it cannot be used with the self-assessment questionnaires. Second, that means most SMB and mid-market merchants who self-assess will use the defined approach by default. Reserve the customized approach for specific, well-justified cases in larger enterprises with mature security and risk programs. Trying to "customize" your way around a control you simply have not implemented is a fast route to a failed assessment.

PCI DSS 4.0 raised the bar from an annual scramble to a year-round operating discipline, and that is precisely the gap most merchants, from SMB retailers to enterprise e-commerce teams, struggle to staff internally. A capable MSP closes it without forcing you to build a dedicated compliance function from scratch.

Concretely, a provider typically owns the recurring, technical, and evidence-heavy work:

• Scoping and segmentation: designing and maintaining the network segmentation and firewall rules that keep your CDE small, and producing the data-flow documentation assessors require.
• Continuous monitoring and detection: running log management, vulnerability scanning, file-integrity monitoring, and the client-side change detection that 11.6.1 demands, often delivered through managed detection and response (MDR).
• Identity and access controls: enforcing MFA into the CDE, managing privileged access, and operating the anti-phishing controls the standard now expects.
• Evidence and documentation: maintaining the script inventories, targeted risk analyses, patch records, and access reviews so that audit time is a retrieval exercise, not a fire drill.

What sensibly stays in-house is ownership of the business decisions: which payment channels you offer, your risk appetite, vendor relationships with your acquirer and assessor, and final sign-off on the attestation. The strongest arrangements are collaborative, in a co-managed IT model where your team retains control and the provider supplies the operational muscle and specialized tooling. For merchants without senior security leadership, a fractional CISO can own the program strategy and assessor relationship, while managed IT services handle the day-to-day execution. Mapping PCI work alongside your other obligations is exactly the kind of cross-framework planning a structured compliance program exists to coordinate.

Does PCI DSS 4.0 apply to my small business if I use a third-party processor like Stripe or Square?

Almost certainly yes. Outsourcing payment processing reduces your scope, but it does not eliminate it. Even SAQ A merchants who fully outsource cardholder data handling have obligations, and the new client-side script requirements (6.4.3 and 11.6.1) can reach e-commerce merchants whose own web pages surround or embed a third party's payment form. The right question is not "am I in scope" but "which SAQ applies and which specific requirements does it carry," which you should confirm with your acquiring bank or a qualified assessor.

What is the difference between v4.0 and v4.0.1, and which do I need to comply with?

PCI DSS v4.0.1, published in June 2024, is a limited-revision update that corrects errata and clarifies wording from v4.0. It did not add new requirements or change deadlines. v4.0.1 is the current operative version, so your 2026 assessment should be conducted against it. If your documentation still references v4.0, update it, but you do not need a separate remediation effort solely because of the point release.

How long does it take to become PCI DSS 4.0 compliant?

It depends heavily on your scope and starting point. A small merchant who has fully outsourced payments and completes a short SAQ may validate in weeks, while an enterprise e-commerce operation completing a Report on Compliance with significant remediation can take many months. The bigger shift in 4.0 is that compliance is no longer a finish line: the standard expects controls to operate continuously, so plan for an ongoing program rather than a one-time project.

The future-dated requirements are live, the payment page is in scope, and 2026 is the year assessors expect to see continuous, documented controls rather than an annual snapshot. Whether you are a single-location retailer sizing your SAQ for the first time or an enterprise e-commerce team operationalizing client-side script monitoring at scale, the path is the same: reduce scope, implement the controls that now bite, and run them all year. If you want a partner to design the architecture, operate the monitoring, and keep your evidence audit-ready, contact LayerLogix to map your environment and build a PCI DSS 4.0 program you can actually sustain.