PCI DSS 4.0.1 Compliance: A Mid-Market Guide for 2026

PCI DSS 4.0.1 Compliance: A Mid-Market Guide for 2026

BlueRadius Cyber helps U.S. mid-market companies reach and maintain PCI DSS 4.0.1 compliance, the current version of the Payment Card Industry Data Security Standard that any organization storing, processing, or transmitting cardholder data is required to meet. PCI DSS 4.0.1, published in June 2024, is now the only active version of the standard. Version 3.2.1 was retired on March 31, 2024, and the future-dated requirements introduced in version 4.0 became mandatory on March 31, 2025. If your company accepts card payments and your last validation was against 3.2.1, you are now assessing against a withdrawn standard and carrying real audit and breach-liability exposure.

PCI DSS is a contractual obligation, not a law, but the consequences of non-compliance are concrete: monthly fines passed down from your acquiring bank, higher transaction fees, and in the event of a breach, liability for forensic costs, card reissuance, and potential loss of your ability to process cards at all. Mid-market companies get caught out most often, because they have enough transaction volume to be a real target but have usually treated PCI as a checkbox owned by finance or IT rather than a security program. This guide explains who must comply, how to validate, what changed in 4.0.1, the twelve core requirements in plain language, what it costs, how it overlaps with SOC 2, and a step-by-step readiness checklist.

Who Must Comply, and at What Validation Level

Every merchant and service provider that touches cardholder data must comply with PCI DSS. How you validate that compliance depends on your annual transaction volume, and the thresholds are set by each card brand. The commonly referenced tiers are:

• Level 1: generally more than 6 million card transactions per year, or any organization that has suffered a breach. Requires an annual Report on Compliance (ROC) performed by a Qualified Security Assessor (QSA) or a certified internal assessor, plus a quarterly external scan.
• Level 2: generally 1 million to 6 million transactions per year. Typically validated with a Self-Assessment Questionnaire (SAQ) and an Attestation of Compliance, though some card brands require a QSA.
• Level 3: generally 20,000 to 1 million e-commerce transactions per year. Validated by SAQ.
• Level 4: fewer than 20,000 e-commerce transactions, or up to 1 million total transactions per year. Validated by SAQ.

Service providers, companies that store or process card data on behalf of others, follow a parallel set of levels and almost always face the full assessment. If you are a SaaS platform that handles your customers' cardholder data, you are a service provider, and your customers will ask for your Attestation of Compliance during their own vendor reviews.

Which SAQ Applies to You

The SAQ type you complete depends entirely on how your business handles card data. Choosing the wrong one is the most common mid-market mistake, and it almost always understates the real control burden. Use this table to find the form that matches your actual data flow:

SAQ type	Who it fits	Relative burden
SAQ A	E-commerce or mail/telephone merchants who fully outsource all card handling to a compliant third party (hosted payment page, redirect). No card data touches your systems.	Lowest
SAQ A-EP	E-commerce merchants whose site does not receive card data directly but does control how the payment page is delivered (for example, a JavaScript-embedded form from a processor).	Moderate
SAQ B / B-IP	Merchants using standalone, dial-out or IP-connected payment terminals with no electronic card storage.	Low
SAQ C / C-VT	Merchants with a payment application connected to the internet (C) or a web-based virtual terminal (C-VT), with no card storage.	Moderate
SAQ P2PE	Merchants using a validated point-to-point encryption solution, which dramatically reduces scope.	Low
SAQ D	All other merchants, and all service providers, that store, process, or transmit cardholder data directly. This is the full control set.	Highest

The pattern is clear: the less your own systems touch card data, the shorter your questionnaire and the smaller your assessment. That is why scope reduction, covered in the checklist below, is the single highest-leverage move in any PCI program. A virtual CISO engagement typically starts by confirming the correct merchant level and SAQ before any control work begins.

What Changed in PCI DSS 4.0 and 4.0.1

Version 4.0 was the largest revision to the standard in years, and 4.0.1 refined it with clarifications. The changes that matter most for mid-market companies in 2026:

The customized approach

Organizations can now meet a requirement either through the prescriptive defined approach or through a customized approach that achieves the stated security objective using alternative controls. The customized approach offers flexibility for mature programs but requires a documented targeted risk analysis for each control, so most mid-market teams should start with the defined approach.

Targeted risk analysis

Several requirements now let you set the frequency of an activity based on a documented risk analysis rather than a fixed schedule. That flexibility comes with an obligation: the analysis must be written, reviewed at least annually, and defensible to an assessor.

Expanded multi-factor authentication

MFA is now required for all access into the cardholder data environment, not only remote administrative access. For mid-market environments still relying on single-factor access to in-scope systems, this is frequently the largest remediation item.

Client-side script and payment-page monitoring

Requirements 6.4.3 and 11.6.1 address e-commerce skimming attacks, where malicious JavaScript is injected into a checkout page to steal card data. Merchants must now inventory and authorize every script on payment pages and deploy a change-detection mechanism that alerts on unauthorized modifications. This is a direct response to the rise of Magecart-style attacks and catches many e-commerce teams unprepared. Our e-commerce cybersecurity guide covers the broader storefront attack surface.

The 12 Requirements, Grouped by Goal

PCI DSS organizes its twelve core requirements under six control objectives. Here is the full set in plain language, which is what your control owners actually need to act on:

Goal	Requirement
Build and maintain a secure network	1. Install and maintain network security controls (firewalls, segmentation).
	2. Apply secure configurations to all system components; change vendor defaults.
Protect account data	3. Protect stored account data; do not retain what you do not need.
	4. Encrypt cardholder data in transit across open, public networks.
Maintain a vulnerability management program	5. Protect all systems against malware and keep anti-malware current.
	6. Develop and maintain secure systems and software (patching, secure coding, payment-page script control).
Implement strong access control	7. Restrict access to cardholder data by business need to know.
	8. Identify users and authenticate access, with MFA for all CDE access.
	9. Restrict physical access to cardholder data.
Monitor and test networks	10. Log and monitor all access to system components and cardholder data.
	11. Test security of systems and networks regularly (scans, penetration testing, script monitoring).
Maintain an information security policy	12. Support information security with organizational policies and programs.

Map each requirement to a named owner and a specific piece of evidence. The requirements that consistently consume the most mid-market effort are 3 (do not store what you do not need), 8 (MFA everywhere in scope), 10 (centralized logging), and 11 (scanning, penetration testing, and the new script monitoring).

What PCI Compliance Costs, and How Long It Takes

PCI program cost is driven almost entirely by scope and validation level, so ranges vary widely. The components each carry their own market pricing, and the numbers below are public market ranges, not a BlueRadius quote, intended only as a budgeting frame:

• Self-assessment (Level 2 to 4): the SAQ itself has no fee, but the surrounding work, scoping, remediation, quarterly Approved Scanning Vendor (ASV) scans, and an annual penetration test, makes up the real cost.
• ASV scans: a recurring annual subscription for the required quarterly external scans, typically a modest line item that scales with the number of external IP addresses in scope.
• Penetration testing: priced by scope across external, internal, and segmentation testing. See our penetration testing overview for how scope is defined.
• QSA-led ROC (Level 1): a formal assessor engagement, the largest single cost, justified only when transaction volume or a prior breach forces Level 1 validation.
• Program management: the internal or fractional time to run scoping, evidence collection, and remediation across the year.

On timeline, a mid-market company starting without a formal program should plan on three to six months to a defensible attestation. The schedule is usually gated by three things: segmentation and MFA remediation, the quarterly ASV scan cadence (a failing scan forces a remediate-and-rescan cycle that can run weeks), and evidence collection. Companies that minimize scope by outsourcing card handling to a compliant processor move materially faster, because they remove entire requirement families from their own responsibility.

PCI DSS vs SOC 2: How They Overlap

Many mid-market companies pursue PCI DSS and SOC 2 in the same window, and treating them as two separate projects is where budget gets wasted. They are different instruments aimed at different audiences, but their control cores overlap heavily:

	PCI DSS 4.0.1	SOC 2
Nature	Prescriptive standard with defined requirements	Attestation against flexible Trust Services Criteria
Scope	The cardholder data environment	Systems relevant to the chosen criteria
Driven by	Card brands and acquiring banks	Customer and partner trust requirements
Output	SAQ or ROC plus Attestation of Compliance	Auditor report (Type I or Type II)
Shared core	Access control, encryption, logging and monitoring, vulnerability management, change control, security policy

Because the shared core is large, a company that designs its program to map controls across frameworks from the start can satisfy many PCI and SOC 2 requirements with the same evidence: one access review, one logging pipeline, one set of policies serving both. That cross-mapping is where the cost savings in a multi-framework program come from, and it is the main reason to run both under a single security owner rather than two parallel, duplicated efforts.

The PCI DSS 4.0.1 Readiness Checklist

Use this sequence to move from unknown status to a defensible attestation. Each step builds on the last.

Define and minimize your scope

Identify every system, process, and person that stores, processes, or transmits cardholder data, plus any system connected to that environment. Scope is the single biggest cost driver in PCI. The fastest way to reduce it is to stop touching card data directly by moving to tokenization, a hosted payment page, or a point-to-point encryption (P2PE) solution.

Map your cardholder data flows

Document how card data enters, moves through, and leaves your environment, including third-party processors and call-center or paper-based channels. A current data-flow diagram and network diagram are mandatory evidence, and they reveal in-scope systems teams routinely forget.

Segment the cardholder data environment

Use network segmentation to isolate in-scope systems from the rest of your network. Effective segmentation shrinks the assessment boundary and is one of the highest-value items a security architecture review delivers for a PCI program.

Select the correct SAQ or confirm ROC scope

Confirm your merchant level with your acquirer and select the SAQ that matches how you actually handle card data. Validate this against the data-flow map, not against how the business wishes it worked.

Close control gaps against the twelve requirements

Work the twelve core requirements, mapping each to an owner and a piece of evidence. Prioritize the high-effort items: removing unnecessary stored card data, enforcing MFA across the entire cardholder data environment, centralizing logging, and standing up scanning, penetration testing, and payment-page script monitoring.

Run ASV scans and penetration testing

External vulnerability scans by an Approved Scanning Vendor are required quarterly, and segmentation and application penetration testing is required at least annually and after significant change. Schedule these early, because a failing scan close to your attestation deadline forces a remediate-and-rescan cycle that can take weeks.

Assemble continuous evidence and attest

Collect access reviews, change tickets, scan results, training records, and policy attestations into an audit-ready package, then complete your Attestation of Compliance. Treat evidence collection as a continuous program, not an annual scramble. Our compliance services operationalize this so the evidence exists before the auditor asks.

Where Mid-Market PCI Programs Fail

Scope creep nobody owns. Card data leaks into systems it was never supposed to reach: a spreadsheet, a CRM note field, a recorded support call. Every one of those drags a new system into scope. The fix is data minimization first, controls second.

SAQ optimism. Teams self-select the shortest questionnaire that seems plausible rather than the one their data flow actually demands. An assessor or an acquirer catches it later, usually at the worst time.

Point-in-time thinking. PCI 4.0.1 is explicit that security is a continuous state, not an annual snapshot. Quarterly scans, MFA enforcement, log monitoring, and script integrity checks have to run all year. Pairing PCI with a managed security program is how most mid-market companies sustain that cadence without a dedicated compliance hire.

Frequently Asked Questions

Is PCI DSS a legal requirement?

PCI DSS is a contractual obligation enforced by the card brands through your acquiring bank, not a government law. That distinction rarely helps in practice: non-compliance can trigger monthly fines, increased transaction fees, and suspension of card-processing privileges, and several U.S. states reference PCI standards in their data-security statutes. For any business that depends on accepting cards, it is functionally mandatory.

What version of PCI DSS is current in 2026?

PCI DSS 4.0.1, published in June 2024, is the current and only active version. Version 3.2.1 retired on March 31, 2024, and the future-dated requirements that were best practice under 4.0 became mandatory on March 31, 2025. Any assessment in 2026 must be performed against 4.0.1.

How long does it take a mid-market company to become PCI compliant?

For a mid-market company starting without a formal program, reaching a defensible attestation typically takes three to six months, driven mostly by scope reduction, segmentation work, MFA rollout, and the quarterly ASV scan cycle. Companies that minimize scope by outsourcing card handling to a compliant processor move considerably faster, because they remove entire control families from their responsibility.

Which SAQ should my company use?

It depends on how your systems handle card data, not on your size. A merchant that fully outsources payment to a hosted page uses the short SAQ A; a merchant whose site controls the payment form uses SAQ A-EP; anyone who stores, processes, or transmits card data directly, and every service provider, uses the full SAQ D. Select the SAQ against a current cardholder data-flow diagram, because choosing a shorter form than your data flow justifies is the most common cause of a failed validation.

Can a virtual CISO run our PCI program?

Yes. A fractional virtual CISO commonly owns the PCI program for mid-market companies: confirming merchant level and SAQ, leading scope and segmentation decisions, assigning control owners, coordinating ASV scans and penetration testing, and assembling the evidence package for attestation. For organizations that also need SOC 2 or HIPAA, a vCISO maps the overlapping controls once rather than building each program in isolation. See the vCISO cost guide for how that engagement is typically priced.

How does PCI DSS overlap with SOC 2 and ISO 27001?

The frameworks share a large common core: access control, encryption, logging and monitoring, vulnerability management, change control, and security policy. A company pursuing both PCI DSS and SOC 2 can satisfy many requirements with the same evidence, provided the program is designed to map controls across frameworks from the start rather than running parallel, duplicated efforts. That cross-mapping is where most of the cost savings in a multi-framework program come from.

If your company accepts card payments and you are not certain you are assessing against PCI DSS 4.0.1, start with a scoping review. A focused cybersecurity assessment will confirm your merchant level, surface where card data actually flows, and turn an ambiguous obligation into a defensible plan.