PCI DSS 4.0 Requirements Mid-Market Retailers Still Miss

A retailer can have a valid payment processor, a recent security assessment, and a checkout system that still exposes cardholder data. The risk often sits between teams. Store operations manage terminals. The e-commerce team changes checkout scripts. An IT provider patches systems. Finance keeps the processor contract. Nobody has the complete picture.

That division of work matters under the PCI DSS 4.0 requirements. The standard expects businesses to understand their payment environment and show that controls work in practice. For mid-market retailers with several locations and an online store, PCI DSS 4.0 requirements can develop new gaps before the next assessment.

The current published standard is PCI DSS v4.0.1. Most delayed requirements became effective on March 31, 2025. This guide explains the controls retailers are most likely to overlook in a mixed store and online environment, how to check them, and what evidence an assessor may expect. These are important areas to test, not a measured ranking of the most common failures.

TL;DR

PCI DSS 4.0 requirements can be missed when a retailer assumes its payment provider owns every security duty, leaves checkout scripts unchecked, fails to scan merchant-hosted payment webpages, or overlooks access to payment systems. Retailers also need current terminal inventories, documented security reviews, and evidence that changes to their payment environment have been assessed. PCI DSS v4.0.1 is the current published revision, and the delayed requirements have been in effect since March 31, 2025. Start by mapping every payment channel, confirming the right assessment method with your acquirer, and checking who owns each required control. An annual questionnaire alone won’t reveal a control that stopped working last month.

What PCI DSS 4.0.1 requires in 2026

PCI DSS sets security requirements for organizations that store, process, or transmit payment account data, or can affect its security. PCI DSS requirements for retailers cover every size of business, though the checks each merchant must report depend on its payment setup and the rules of the party accepting its compliance submission. Mid-market isn’t a separate PCI classification with its own fixed control list.

PCI DSS v4.0 was retired on December 31, 2024. The Council’s v4.0.1 release announcement confirms that the revision clarified existing provisions without adding or removing requirements. The March 31, 2025 start date for the future-dated controls stayed in place. Calling them optional or future requirements in a 2026 article would now be wrong.

The biggest change for many retail teams is the need to prove that recurring work actually occurs. The 2026 retail DBIR overview reports that confirmed retail breaches nearly doubled from its previous dataset, although that is a broad retail finding rather than a mid-market failure rate. A policy doesn’t show that someone checked a payment page or fixed a vulnerability. Records must show what happened.

PCI DSS 4.0.1 compliance also allows more room to use defined methods that fit a particular environment, where the standard permits that flexibility. That room comes with documentation duties. A retailer choosing the frequency of a control through a targeted risk analysis must explain the decision and review it when required. It can’t choose a convenient schedule without support.

For PCI DSS 4.0 requirements, the practical question is simple: Which systems can touch card data or change how a payment is collected? The answer determines which PCI DSS requirements for retailers deserve direct attention. Hosted checkouts and store terminals can create different obligations.

Why retailers get their PCI DSS scope wrong

Accurate scope is the starting point for the PCI DSS 4.0 requirements. The cardholder data environment, or CDE, includes the people, processes, and technology involved in storing, processing, or transmitting cardholder data. Systems that connect to that environment or could affect its security may also fall within the assessment. The exact boundary depends on how the retailer handles payments.

A retailer may have 20 stores, a web shop, and a call center. Each channel may use a different path. Drawing 1 box labeled “payments” hides those differences.

The Council’s significant change guidance identifies events that can affect the security of the CDE, including new equipment, software upgrades, changes to account-data flow, and changes to supporting service providers. A retailer that replaces its checkout system or changes its network design should ask whether the scope has changed before treating last year’s diagram as current.

Find the boundaries before choosing controls

Build a payment-flow map for every channel. Start where a customer presents a card or enters payment details. Follow the data or payment instructions through terminals, applications, networks, and providers. Note any internal system that could alter a payment page or administer a payment component. Identify remote support paths and systems that share network access with the CDE.

Then compare the map with the last assessment. Record what changed. Requirement 12.5.2 requires merchants to document and confirm PCI DSS scope at least once every 12 months. Significant changes require a separate review under Requirement 6.5.2, and those changes should be reflected in the next scope confirmation. Some environments may have extra requirements. A store opening, processor switch, or acquisition can make the annual review stale much sooner.

A useful PCI DSS compliance checklist begins with this map. Without it, later scan results and access lists may look complete while missing an entire channel. Scope reduction is possible through sound design, but an assumption that a provider handles card data isn’t enough to prove a merchant system is out of scope.

Payment page scripts: the requirement hidden in routine website changes

For PCI DSS payment page security, Requirement 6.4.3 addresses scripts loaded and executed in the consumer’s browser on applicable payment pages. It requires a method to confirm that scripts are authorized, a method to assure their integrity, and an inventory that explains why each script is necessary. This part of PCI DSS payment page security targets code that could be altered to steal card details during checkout.

Marketing may add an analytics tag without asking security. An agency may change a tag manager, or a payment plugin may load outside code. Such changes can affect checkout even if the retailer never sees the card number.

The Council’s payment page guidance addresses the controls used to reduce e-skimming risk and makes clear that a retailer must evaluate its actual implementation. It doesn’t require every business to buy the same script-monitoring product. The chosen controls must meet the applicable requirement and work in the deployed checkout.

What a script inventory should show

Record each script, its location, business reason, approver, and integrity-check method. Include scripts loaded through tag managers. A source-code list alone may miss code added in the browser.

Consider a hypothetical checkout with a payment iframe and a tag manager. The tag manager begins loading a new measurement tool. Security must determine whether it can affect the payment process.

For teams assessed against Requirement 6.4.3, PCI DSS payment page security starts with testing the browser’s real output rather than relying only on developer tickets. Compare what runs on checkout pages with the authorized list. Investigate items that lack an owner, a purpose, or evidence of integrity checks. This is one of the PCI DSS 4.0 requirements that can drift as websites are updated throughout the year.

Checkout tamper detection: why a clean server scan isn’t enough

Among the PCI DSS 4.0 requirements, 11.6.1 addresses unauthorized modification to applicable payment pages as received by the consumer’s browser, including security-impacting HTTP headers. The requirement calls for a change- and tamper-detection mechanism that alerts personnel to unauthorized changes. Checks must occur at least once every 7 days, or at a frequency supported by the targeted risk analysis allowed by the requirement.

A server scan may find missing patches, but it can’t prove the customer’s payment page is unaltered. PCI DSS payment page security must address the browser output where the control applies.

A PCI DSS payment page security monitoring design should define which pages are watched, which changes trigger an alert, and who investigates. The team needs a way to separate approved releases from suspicious changes. An alert nobody reviews won’t help.

Test the full alert process

Run a controlled change through the normal release process and confirm that monitoring detects the expected difference. Check how alerts are recorded, who receives them, and how quickly a reviewer can identify the cause. Retain approved-change records and investigation results. If a third party provides monitoring, establish whether that party only sends alerts or also reviews them.

Retailers with several branded storefronts should account for all relevant checkout versions, including regional pages and mobile layouts. Shared platforms can still produce different checkout scripts.

PCI DSS payment page security Requirement 11.6.1 isn’t directly listed in the January 2025 SAQ A in the same way as in other applicable assessments. The distinction matters for PCI DSS 4.0.1 compliance.

The SAQ A exception many e-commerce teams misread

While reviewing PCI DSS 4.0 requirements, a merchant that outsources account-data functions may qualify for Self-Assessment Questionnaire A, or SAQ A, if it meets all eligibility conditions. But a retailer can’t choose SAQ A simply because its processor advertises a hosted payment service. The checkout design still matters.

In January 2025, the PCI Security Standards Council removed Requirements 6.4.3 and 11.6.1 from the updated SAQ A. It also removed the related 12.3.1 item for the frequency decision under 11.6.1. The Council added an eligibility condition requiring merchants to confirm their sites aren’t susceptible to script attacks that could affect their e-commerce systems.

The Council’s SAQ A clarification explains how merchants using embedded payment pages may address the condition. They can use suitable techniques to protect their webpages, or obtain the specified confirmation from their PCI DSS compliant provider supplying the embedded payment form, provided the solution is implemented as instructed. The statement needs to cover the protection built into that solution, rather than simply saying the processor is compliant.

Embedded forms and redirects are different

For a qualifying redirect, the SAQ A script-attack condition applies differently than it does for an embedded payment form. That difference shouldn’t be turned into a broad claim that redirects have no merchant security duties. A compromised merchant page can still create a serious problem, and other applicable SAQ A controls remain.

Merchants should also distinguish SAQ A from SAQ A-EP and SAQ D. The checkout’s origin, payment-page elements, and other eligibility conditions affect which form may be used. The acquirer or payment brand is the right party to confirm the validation method. For PCI DSS 4.0.1 compliance, the wrong questionnaire creates a false record.

The SAQ applicability FAQ also warns against using questionnaire eligibility as a general test of which requirements apply to an ROC without agreement from the compliance-accepting entity. PCI DSS 4.0 requirements remain in the standard even when an SAQ doesn’t list them.

External vulnerability scans that outsourced checkouts still need

When reviewing PCI DSS 4.0 requirements, some retailers assume that sending customers to a payment provider means their own e-commerce site no longer needs PCI scanning. That assumption is unsafe. A compromised merchant page could redirect customers to a fake payment site.

The Council’s June 2026 ASV scan clarification confirms that SAQ A e-commerce merchants with webpages redirecting to a third-party service provider or including its embedded iframe remain subject to the external scanning requirements included in SAQ A. Requirements 11.3.2 and 11.3.2.1 are relevant. This applies even where payment processing itself is fully outsourced.

Requirement 11.3.2 calls for external vulnerability scans by a PCI Security Standards Council Approved Scanning Vendor, or ASV, at least once every 3 months. Additional scans are required after significant changes where applicable. Passing scans must meet the program’s requirements, including resolving findings and completing rescans as needed.

For a retailer with several shop domains, the first step is to identify which publicly accessible systems fall within the required external scan scope. A website migration or newly launched regional store could leave an older scan schedule covering only the original domain.

Don’t confuse an ordinary vulnerability scan with a passing ASV scan. A security tool may provide useful findings without meeting PCI SSC’s ASV program criteria. Keep ASV scope, dates, reports, and rescans in the PCI DSS compliance checklist. Retailers should confirm any scope dispute with the ASV and the organization accepting their compliance evidence.

Third-party providers: the duties a contract doesn’t remove

Payment processors, commerce platforms, managed network providers, and support contractors can all affect PCI DSS scope. Outsourcing a function changes who performs a control, but it doesn’t automatically remove the merchant’s duty to check that the function is protected.

The Council’s outsourcing FAQ states that merchants retain responsibilities for provider compliance, written acknowledgments of security duties, annual monitoring of provider status, and clear assignment of shared duties. These appear in Requirement 12.8 where applicable. A receipt showing that a retailer paid for a service isn’t evidence that the provider covers the required controls.

Review what the provider actually assessed

Request the provider’s relevant Attestation of Compliance, or AOC, and read its service description. Confirm that it covers the payment functions your organization uses. A provider may have compliant hosting operations while a separate product or optional support service falls outside the assessed scope.

A PCI DSS compliance checklist should include a responsibility matrix that assigns each shared control. For example, the provider may patch the payment platform while the retailer controls account permissions for staff who can configure it. Both parties need to know which evidence they must keep. A generic contract sentence saying that the provider handles security isn’t a workable control assignment.

Acquired stores may use different terminal suppliers. Connect each provider to a payment flow and a current compliance status.

PCI DSS requirements for retailers include regular service-provider reviews because suppliers and contracts change. Keep dated evidence of the review and any follow-up. If the provider’s assessment is old or doesn’t cover a service, investigate the gap rather than treating the document as a blanket approval.

MFA and user access: the gap beyond administrator accounts

Requirement 8.4.2 expanded multi-factor authentication, or MFA, coverage to all applicable access into the CDE. Some retailers previously focused MFA on remote administrators while allowing ordinary staff to reach payment systems through trusted internal networks. That pattern needs another look under the PCI DSS 4.0 requirements.

To meet PCI DSS requirements for retailers, begin with the accounts that can enter the CDE or change its security. Include named employees, support contractors, and service accounts where relevant. Compare the identity system’s policies with actual application settings. MFA enforced for a VPN doesn’t necessarily cover every other way a user can reach an in-scope system.

There are important distinctions among Requirements 8.4.1, 8.4.2, and 8.4.3. Under PCI SSC’s passkey guidance, qualifying FIDO2 synced passkeys can satisfy 8.4.2 as a single phishing-resistant authentication factor under the stated applicability note. That treatment doesn’t automatically extend to the other MFA requirements. The method and access path both matter.

Access reviews need current roles

For PCI DSS 4.0.1 compliance, an access review compares current job duties with permissions. Store managers may have moved to new locations. Seasonal users may still be active. An IT contractor may retain access after an upgrade. Accounts that no longer need access should be removed through the retailer’s normal access-control process.

The PCI DSS compliance checklist should also check whether shared accounts hide individual activity, whether elevated privileges are limited to the people who need them, and whether access changes are recorded. PCI DSS 4.0.1 compliance depends on technical enforcement and evidence that the people with access are authorized. An HR termination spreadsheet by itself doesn’t prove an application account was disabled.

Testing matters most at the exceptions. Try the emergency support process, an alternate login route, and a newly provisioned user. The main sign-in page may not be the only route.

Vulnerability management and patch deadlines retailers misapply

Retail payment software has different maintenance cycles. Plugins change often, while POS devices may depend on vendor updates. A current in-scope asset list is essential.

Requirement 6.3.3 requires critical security patches and updates to be installed within 1 month of release. Other applicable updates follow appropriate timeframes based on risk. The PCI Council’s vulnerability guidance also explains how risk rankings and treatment of scan findings work. Retailers shouldn’t apply the same deadline to every finding without considering the standard’s actual language.

Scanning and patching are separate tasks

Internal vulnerability scans under Requirement 11.3.1 must occur at least once every 3 months and after significant changes where required. Requirement 11.3.1.2 adds authenticated scanning where systems support it. Scans identify potential problems; patch and remediation records show what happened after the finding.

A recurring gap is a vendor-dependent terminal or POS application that can’t be updated through ordinary tools. The retailer still needs to document the affected component and work through an acceptable way to address the risk. Simply recording “vendor managed” without a documented response leaves the issue unresolved.

Use one process to track the release date, affected asset, severity decision, responsible owner, due date, and closure evidence. If a scan requires a rescan, keep its result. For PCI DSS requirements for retailers, the result matters more than the number of reports produced. An old critical finding hidden in a quarterly summary can represent a live exposure.

Checkout systems and store equipment have different attack paths and maintenance options. Document those differences.

Payment terminals: physical controls across multiple stores

For card-present transactions, PCI DSS requirements for retailers include Requirement 9.5, which addresses point-of-interaction devices that directly read payment cards. It requires an accurate device list, periodic inspections for tampering or unauthorized substitution, and training for staff who work around the devices. A mid-market retailer can miss this control when terminal inventory sits with store operations while compliance records sit with head office.

The Council’s terminal security FAQ explains that the standard doesn’t require every terminal to be physically tethered. The required approach centers on tracking devices, inspecting them, and helping staff identify signs of interference. The precise inspection frequency should follow the applicable PCI DSS requirements, including a targeted risk analysis where the standard calls for one.

For a useful PCI DSS compliance checklist, record each applicable terminal’s location, make, model, and unique identifier. This allows staff to spot a device that has been swapped without authorization. Keep records of inspections and staff training. When terminals move between stores, update the inventory before the next scheduled audit.

What store teams should be able to explain

Staff should know what an expected terminal looks like and what to do if a device seems changed or damaged. Store managers need a clear reporting path. The procedure should cover taking a suspicious device out of use in line with the incident plan and preserving evidence.

Some smartphones and other commercial off-the-shelf devices have different applicability under Requirement 9.5. Don’t copy the same inspection claim across every payment method without checking the definition. A useful PCI DSS compliance checklist names the actual deployed devices and states which requirements apply to them.

Log reviews and risk analyses that need real evidence

Payment security work often produces a large volume of alerts and logs. Requirement 10.4.1 calls for daily reviews of specified security events and systems. Under Requirement 10.4.1.1, automated mechanisms are required to perform those audit log reviews. Unused logs don’t prove compliance.

Other in-scope systems may follow the periodic review frequency permitted under 10.4.2. The Council’s log review FAQ explains that the required frequency depends on the system and event category. Requirement 10.4.2.1 uses a targeted risk analysis to set the frequency for other applicable logs. Treating all systems as eligible for weekly review would miss the daily requirement for specified categories.

PCI DSS requirements for retailers also mean the review process should show which events matter, who examines them, and how unusual activity gets investigated. An automated alerting product can help, but the team still needs records that alerts reached someone and that material findings received follow-up.

Targeted risk analysis isn’t a checkbox

Requirement 12.3.1 covers targeted risk analyses for controls where the standard permits an organization to determine activity frequency. A sound analysis identifies the assets protected, the threats involved, and the reasons for the selected frequency. It needs review at least every 12 months, with updates when appropriate.

The Council’s risk analysis guidance helps distinguish frequency-setting analyses from those used for a customized approach. A customized approach carries different documentation and testing duties.

A store group setting a terminal inspection interval must consider device exposure and how quickly tampering could be noticed. A monthly staff meeting alone isn’t a risk justification.

PCI DSS payment page security brings the same discipline to permitted choices about monitoring frequency. The evidence should match the configuration actually deployed, not a generic policy copied from another retailer.

How to check your controls before the next assessment

Retailers can make the PCI DSS 4.0 requirements more manageable by reviewing controls in the order that their payment dependencies appear. Start with the payment flows, then confirm the controls protecting them. This reduces the chance of collecting a thick folder of evidence for the wrong environment.

The Council’s merchant guidance makes clear that validation and reporting are governed by the relevant payment brands and acquirers. Confirm whether your organization must submit a specific SAQ, a Report on Compliance, or other requested evidence. Don’t select a form solely from transaction volume or a provider’s marketing page.

Use the following review as a working PCI DSS compliance checklist. It’s an internal preparation aid, not a substitute for the full standard or your approved assessment method.

A practical review sequence

First, appoint an owner for each payment channel. That person doesn’t need to operate every control, but must know where its evidence is kept. Then compare the current system map with provider records and the last assessment. Resolve differences before deciding that any control is complete.

Next, test a sample of real actions: a checkout release, a terminated user, a critical patch, a scan finding, and a terminal replacement. If a sample shows exceptions, expand the test and investigate the cause.

Finally, track open items through closure and retain the supporting proof. Where a requirement is genuinely inapplicable, document the basis instead of leaving the field blank. For PCI DSS 4.0.1 compliance, a truthful gap record is more useful than an unsupported claim that a control has passed. An assessor can then evaluate the actual environment and the corrective work performed.

Conclusion: fix the gaps between teams

Mid-market retailers tend to run payments across more systems than any one department controls. That makes handoffs a recurring source of PCI DSS risk. Checkout scripts can change without security review. Providers can replace services without an updated responsibility map. Stores can move terminals without changing the inventory.

The PCI DSS 4.0 requirements demand attention to those everyday changes. Start with accurate scope, confirm the assessment method, and check that each important control works in practice. Focus on records that connect a control to a real action: an approved script, a reviewed alert, a completed scan, or a fixed vulnerability. Those records expose gaps between assessments.

Frequently asked questions

Is PCI DSS 4.0 still valid in 2026?

PCI DSS v4.0 was retired on December 31, 2024. PCI DSS v4.0.1 is the current published revision as of October 2026. The delayed controls became effective on March 31, 2025. Merchants should use the current documents and confirm their reporting duties with their acquirer or payment brand.

Do mid-market retailers have different PCI DSS requirements?

No separate PCI DSS rules apply solely because a business is described as mid-market. The PCI DSS 4.0 requirements depend on the environment and what the merchant does with payment data. Validation requirements also depend on the relevant payment brand or acquirer. A retailer with both stores and e-commerce may have several payment flows to assess.

Does using a payment processor remove PCI DSS responsibilities?

No. Outsourcing may reduce the systems a retailer directly manages, but it doesn’t end merchant responsibilities. The retailer must understand which services the provider covers and which controls remain with the merchant. Applicable duties include written agreements and checking provider compliance status at least annually.

Does every online retailer need requirement 6.4.3?

Requirement 6.4.3 applies where the standard and the merchant’s assessment scope require it. The January 2025 SAQ A removed it as a separately assessed item and added a script-attack eligibility condition. Other merchant assessments may still include 6.4.3. The payment setup and accepted validation method determine the answer.

What does PCI DSS requirement 11.6.1 monitor?

It addresses unauthorized changes to applicable payment pages as received by a customer’s browser, including security-impacting HTTP headers. Where required, change- and tamper-detection mechanisms must alert personnel. Checks occur at least every 7 days or at an allowed risk-based frequency. Server scans alone don’t prove this control works.

Does SAQ A still require external ASV scans?

Yes, for merchant e-commerce webpages covered by the SAQ A scanning requirements. PCI SSC clarified in June 2026 that redirects and embedded payment iframes don’t remove those duties. Applicable external scans must use a PCI-approved ASV. The scan scope and passing results should be reviewed with the ASV and compliance-accepting entity.

How often must PCI DSS external vulnerability scans run?

Requirement 11.3.2 calls for external vulnerability scans at least once every 3 months. Applicable significant changes can require additional scanning. The merchant must address findings and obtain passing results in line with the ASV program. An ordinary security scan isn’t automatically the same as a passing ASV scan.

Is MFA required for everyone accessing the CDE?

Requirement 8.4.2 applies to all applicable access into the cardholder data environment. Retailers should check ordinary users as well as administrators and account for different access routes. Other MFA provisions have separate conditions. The correct result depends on the actual authentication method and the particular requirement.

Can FIDO2 passkeys replace MFA under PCI DSS?

Qualifying FIDO2 synced passkeys may meet Requirement 8.4.2 as a single phishing-resistant factor under its applicability note. That doesn’t mean one passkey factor satisfies Requirements 8.4.1 or 8.4.3. Retailers should check which type of access is involved before changing a sign-in policy.

How quickly must critical security patches be installed?

Requirement 6.3.3 sets a deadline of 1 month after release for patches addressing critical vulnerabilities. Other applicable patches have risk-based timelines. Retailers should keep records showing affected assets, release dates, severity decisions, and when fixes were applied. Vendor responsibility alone doesn’t replace evidence of remediation.

How often should store payment terminals be inspected?

PCI DSS requires periodic inspections of applicable point-of-interaction devices, with the frequency supported by the relevant targeted risk analysis. The interval depends on the devices and their exposure. Retailers also need a current device list and staff training so potential substitution or tampering can be recognized and reported.

What is a targeted risk analysis under PCI DSS?

A targeted risk analysis documents why an allowed control frequency fits the threats and assets involved. Requirement 12.3.1 sets the content and review expectations for frequency-based analyses. These analyses must be reviewed at least every 12 months. They aren’t permission to replace a fixed schedule with any interval the retailer prefers.

Does PCI DSS require daily log reviews?

Requirement 10.4.1 calls for daily review of specified security events and systems. Other in-scope logs may qualify for periodic review under 10.4.2 and its related risk analysis requirement. Automated mechanisms are required for the daily reviews under 10.4.1.1. For PCI DSS 4.0.1 compliance, the retailer should document which logs fall into each category.

Does opening a new store change PCI DSS scope?

It can. A new store may bring payment terminals, network paths, or a service provider that wasn’t covered by the last assessment. The retailer should review the new environment and determine whether the change is significant. Scope should be confirmed at least annually and after significant changes as required.

What evidence should retailers keep for their PCI assessment?

Evidence depends on the applicable requirements, but useful records include current payment-flow diagrams, access reviews, scan results, approved script inventories, provider AOCs, and terminal inspection logs. Records should show that controls operated throughout the review period. The acquirer or payment brand determines the required validation and reporting route.