PCI DSS v4.0.1 Requirements: Key Updates and What They Mean for Small Businesses

PCI DSS v4.0.1 is the current active standard for payment card security, and as of March 31, 2025, every requirement — including those previously designated as future-dated — is now mandatory. For small businesses that accept card payments, the key changes to understand are around payment page security, stronger access controls, authenticated vulnerability scanning, and moving from annual compliance scrambles to year-round security practices. This guide explains what changed, what it means for your business, and what to do next.

As of March 31, 2025, all merchants and service providers handling cardholder data must comply with every applicable requirement in PCI DSS v4.0.1 — including those that were originally designated as “future-dated” best practices when the standard was first published in March 2022. PCI DSS v4.0 marked the first major update to the standard in over a decade, introducing significant changes to reflect the evolving threat landscape, modern payment methods, and new technology.

For small businesses, the most relevant shift in PCI DSS v4.x is that compliance is now treated as an ongoing practice rather than an annual event. Controls need to be in place and documented year-round — not assembled before a PCI DSS assessment process.

PCI DSS v4.0.1 is the current and sole active version of the standard. It became the only valid version on December 31, 2024, when PCI DSS v3.2.1 was retired. The original PCI DSS v4.0 was published in March 2022 and introduced the updated requirements; v4.0.1 followed as a minor revision (primarily typographical and formatting corrections) and is now the reference document all merchants and service providers must use.

Under the updated framework, organizations undergoing a formal compliance assessment that cannot meet a specific requirement as written, have the option to implement an alternative control following the Customized Approach.  Risk analysis and testing is performed to prove that customized controls provide equivalent risk mitigation

In this guide, we examine what changes have been made to PCI DSS v4.0.1 requirements, what is in effect now, and the impacts on affected businesses.

PCI DSS v4.0.1: Structure, Purpose, and the 12 Core Requirements

PCI DSS v4.0.1 is the global security standard that governs how any business handling payment card data must protect that data. It applies to all merchants and service providers that store, process, or transmit cardholder data and/or sensitive authentication data — regardless of size. For small businesses, the standard is most commonly encountered through a Self-Assessment Questionnaire (SAQ), which maps your payment environment to the specific requirements you need to meet.

The standard is maintained by the PCI Security Standards Council (SSC) and mandated by the major card brands — Visa, Mastercard, and others. It is not a government regulation, but compliance is effectively required: payment processors and acquiring banks enforce it as a condition of accepting card payments.

The applicability of the PCI DSS v4.0.1 remains the same as in previous versions, though there is more emphasis on organizations documenting and confirming their PCI DSS scope.  However, the requirement to document and confirm scope annually (12.5.2) will not be applicable to the majority of self-assessing merchant businesses as it is only included in the SAQ D.  

Enhancements to the standard include its more deliberate and purposeful use of the terms account data, cardholder data, and sensitive authentication data. Requirements must be read as applying specifically to the type of data that is referenced in the requirement; including in the updated and new requirements addressing sensitive authentication data stored prior to completion of authorization (3.2.1, 3.3.2).

PCI DSS v4.0.1 is organized around 12 core requirements, grouped into six control objectives. Each requirement sets out specific security controls that businesses must have in place. The 12 requirements are:

• Install and maintain network security controls — firewalls and equivalent technology to protect your cardholder data environment (CDE) from unauthorized access
• Apply secure configurations to all system components — no vendor-supplied default passwords or unnecessary services
• Protect stored account data — limit what cardholder data you store, and protect what you must keep using encryption and other controls
• Protect cardholder data with strong cryptography during transmission over open, public networks
• Protect all systems and networks from malicious software — deploy and maintain malware protection across your environment
• Develop and maintain secure systems and software — manage vulnerabilities and apply security patches
• Restrict access to system components and cardholder data by business need to know — access control measures based on the principle of least privilege
• Identify users and authenticate access to system components — strong authentication, including multi-factor authentication (MFA) where required
• Restrict physical access to cardholder data — limit who can physically access media (paper or electronic) and systems that store or process card data
• Log and monitor all access to system components and cardholder data — maintain audit logs and review them regularly
• Test security of systems and networks regularly — vulnerability scanning and penetration testing on a defined schedule
• Support information security with organizational policies and a security awareness training program for all personnel

Not every requirement applies equally to every business. You may be eligible to self-assess using an SAQ - determined by your annual transaction volumes.  The SAQ type you complete - determined by your payment method(s) - defines which of the 12 requirements and their sub-requirements you are responsible for. SecureTrust PCI Manager helps you identify your SAQ type and work through exactly the requirements that apply to you.

What’s New in PCI DSS v4.x?

PCI DSS v4.0 introduced more than 60 new or updated requirements, with 51 originally designated as “future-dated” best practices. All of those are now mandatory as of March 31, 2025. For small businesses, the most impactful changes fall into three areas: ecommerce payment page security, expanded multi-factor authentication, and a new requirement for authenticated internal vulnerability scanning.

The new version aims to cement security as a “business-as-usual” or continuous process, adds extra focus on modern and evolving risk areas including e-skimming or Magecart attacks, phishing, and unauthorized access, and emphasizes the importance of building evidence to prove security controls are adequate throughout the year — not just at assessment time.

What’s in Effect Now (and What PCI DSS v4.0.1 Actually Changed)

PCI DSS v4.0 introduced a set of “future-dated requirements” — new controls designated as best practices that merchants had until March 31, 2025, to implement. As of that date, all those requirements became mandatory for all applicable entities. It is important to distinguish this from v4.0.1 becoming the active standard (December 31, 2024) these are two separate milestones.

PCI DSS v4.0.1, according to the PCI SSC, makes no additional or deleted requirements compared to v4.0. It corrects formatting and typographical errors, and clarifies the focus and intent of some requirements. All substantive changes to merchant obligations come from the v4.0 requirements themselves — including the future-dated requirements that became mandatory on March 31, 2025.

To summarize the timeline clearly:

• March 2022: PCI DSS v4.0 published — first major revision in over a decade. New requirements introduced, with 51 designated as future-dated best practices
• June 2024: PCI DSS v4.0.1 published (minor corrections only, no new requirements)
• October 2024: Self-Assessment Questionnaires (SAQs) for PCI DSS v4.0.1 published
• December 31, 2024: PCI DSS v3.2.1 retired; v4.0.1 becomes the sole active standard
• January 2025: Revisions to the PCI DSS v4.0.1 SAQ A and SAQ D – Service Provider published
• March 31, 2025: All future-dated requirements from v4.0/v4.0.1 become mandatory for all applicable merchants and service providers

Payment Page Security (Ecommerce): The Updates That Drive Real Work

PCI DSS v4.0 introduced requirements 6.4.3 and 11.6.1 to protect ecommerce payment pages from e-skimming and script tampering attacks — including Magecart-style e-skimming attacks that inject malicious code into checkout pages to steal card data. Whether these requirements apply to your business depends on which SAQ type you use to validate compliance, and this changed significantly in early 2025.

If you validate using SAQ A-EP or SAQ D, Requirements 6.4.3 and 11.6.1 apply in full:

• Requirement 6.4.3 requires that all payment page scripts are authorized, integrity-checked, and inventoried
• Requirement 11.6.1 requires a change- and tamper-detection mechanism to alert personnel to unauthorized changes to payment pages and scripts, assessed at least weekly

If you validate using SAQ A (card-not-present merchants who have fully outsourced payment processing to a PCI DSS-compliant third party), the picture changed in January 2025. The PCI SSC removed Requirements 6.4.3 and 11.6.1 from SAQ A — effective March 31, 2025 — and replaced them with a new eligibility criterion: merchants must confirm that their site is not susceptible to attacks from scripts that could affect their ecommerce systems.

This does not mean SAQ A merchants are exempt from securing their payment pages; it means the path to demonstrating that security has changed. Per PCI SSC FAQ 1588, not all SAQ A merchants need to meet this new criterion: only those ecommerce merchants with a website that embeds the PCI DSS-compliant payment processor’s hosted payment page/ form in one or more iFrames. The existing PCI DSS requirements were newly introduced to the SAQ A with PCI DSS v4.0, including quarterly ASV external vulnerability scans of e-commerce merchant websites and stricter password/passphrase rules for user and administrator authentication.

The new SAQ A eligibility criterion does not apply to ecommerce merchants that redirect customers from their webpage to their PCI DSS-compliant payment processor’s hosted payment page, or those that fully outsource all website operations to a PCI DSS-compliant Third-Party Service Provider (TPSP).

To meet the criterion, merchants can deploy script protections themselves or obtain confirmation from their PCI DSS-compliant payment processor that their embedded solution already includes those protections.

Full guidance on Requirements 6.4.3 and 11.6.1 is available via the PCI SSC’s Payment Page Security and Preventing E-Skimming supplement.

Access Control Updates That Often Require Policy and System Changes

One of the most significant expansions in PCI DSS v4.x is the broadening of multi-factor authentication (MFA) requirements. Under the previous standard (PCI DSS v3.2.1), MFA was only required for remote access or administrative access into the CDE. Under v4.x, MFA must now be used for all access into the cardholder data environment (CDE) including non-console access by applications, systems, and network devices. This is a meaningful change for many businesses.

The expanded MFA requirement sits under Requirement 8.4.2. It applies to access into the CDE broadly — though the specific implementation requirements vary by SAQ type. Notably, SAQ B-IP merchants (standalone, PCI PTS-approved terminal users not connected to other devices in the same network zone) are not required to implement MFA for non-console administrative access into the CDE under v4.x, though MFA for remote access to the CDE is still required.

Beyond MFA, Requirement 8 also introduces other access control updates businesses should act on:

• Clearly establish and outline roles and responsibilities for CDE access
• Only allow credential sharing in exceptional circumstances
• Increase mandatory password lengths to at least 12 characters
• Where possible, replace 90-day password rotation with dynamic analysis of accounts’ security posture and automatic, real-time determination of access to resources
• Avoid hard-coding passwords, used for interactively logging in, into scripts, files or code

Audit existing administrative access paths, review remote access methods, and reassess any service accounts or third-party access grants against the updated requirements.

Authenticated Internal Vulnerability Scanning: A New Requirement for Many Merchants

Requirement 11.3.1.2 is a new future-dated requirement that became mandatory on March 31, 2025. It requires organizations to perform authenticated internal vulnerability scans — meaning scans that use valid credentials to log into systems and detect vulnerabilities that would not be visible to an unauthenticated scan. This is an extension of the existing internal vulnerability scanning requirement.

Authenticated scanning provides a more complete picture of your internal security posture. An unauthenticated scan can only see what an unauthenticated attacker would see based on open ports and network visibility; an authenticated scan can identify misconfigurations, missing patches, and vulnerabilities that are only visible from within the system.

Whether this requirement applies to your business depends on your SAQ type. While both SAQ C and SAQ D include the requirement for internal vulnerability scanning, only the SAQ D expects those internal scans to be authenticated scans. Check your relevant SAQ to confirm if Requirement 11.3.1.2 is included in your compliance scope. If it is, your authenticated scans must be performed by a qualified internal resource or a third-party scanning vendor, and results must be retained as evidence of compliance.

“Business as Usual” Evidence: What You Need to Keep on File

A main driver of PCI DSS v4.0.1 is moving businesses away from annual compliance scrambles toward continuous security practices. For small businesses validating via SAQ, this means the SAQ itself is more than just a checklist to complete once a year. Controls need to be in place and demonstrable throughout the year — vulnerability scans completed on schedule, training acknowledged, and any security incidents logged and addressed.

The standard makes clear that it is no longer enough to simply confirm you have policies in place at assessment time. You need documented evidence that your policies and procedures are adhered to and controls are running consistently. Common documentation to keep on file includes:

• Vulnerability scan results (quarterly ASV scans, and authenticated internal scans where required by your SAQ type)
• Proof of approval to change or amend controls
• Acknowledgements of security awareness training completion
• Records of control establishment and periodic review
• Incident tickets and remediation records
• Proof of security alerts and responses

A key way to prove your business has continuous controls in place is to follow a structured reassessment and due diligence process after you make significant changes. Our guide to staying PCI compliant after infrastructure changes takes you through the steps to adapt into your ongoing compliance approach.

Defined Approach vs. Customized Approach: Which Applies to Your Business?

PCI DSS v4.0.1 introduced two validation paths: the defined approach and the customized approach. For the vast majority of small businesses, only one of these applies.

The defined approach is the standard route — merchants implement the specific requirements as written in the standard and use the SAQ that matches their payment environment to verify that each requirement is met as stated. This is the right path for the vast majority of small businesses, and what SecureTrust PCI Manager guides you through.

The customized approach allows organizations with more mature or unconventional security controls to propose alternative measures that achieve the same security objective. It requires significantly more documentation, testing, and assessor involvement — and it is not available to merchants validating via SAQ. It is designed for larger entities undergoing formal QSA-led assessments (Report on Compliance). If you are a small business using an SAQ, the customized approach does not apply to you.

If you are a small business, choose the defined approach. It is simpler, less expensive, and the correct compliance path for SAQ-eligible merchants.

Targeted Risk Analysis: Where PCI DSS v4.x Raises the Bar

PCI DSS v4.0.1 introduced targeted risk analyses (TRAs) to support continuous security management. A TRA is a structured assessment that determines how frequently specific security controls should be performed. TRAs are most relevant to merchants using the customized approach or undergoing formal ROC-based assessments.

In addition to use of TRAs with the customized approach, there are a number of recurring PCI DSS requirements that offer flexibility for how frequently the requirement is performed; each of those requirements must be supported by a TRA. Many SAQ types either do not include any PCI DSS requirements that expect a TRA (SAQs A, B, B-IP, C-VT, P2PE and SPoC) or require them only in limited, specific cases — for example, in the SAQ C to justify certain malware scan or log review frequencies.

Where TRAs do apply, they must be reviewed after each significant control or environment change, at least annually, or when customized controls are established. To justify control frequencies, businesses should identify assets and threats, document risk factors, and provide clear reasoning for decisions made.

The PCI SSC’s TRA guidance supplement offers detailed insight into the two different types of TRAs, what TRAs must include and suggested frequencies for multiple DSS requirements.  It is important to note that a TRA is always required to support the frequency you perform each recurring requirement applicable to your business, even if you follow the suggested frequency.  If you are a small business validating via SAQ, check your specific SAQ type to determine whether and where TRAs apply to your compliance obligations.

What to Do Next: A Prioritized PCI DSS v4.x Readiness Checklist

The steps below give you a practical starting point for making sure your business is compliant with PCI DSS v4.0.1. If you are a small business validating via SAQ, focus on the items that apply to your SAQ type(s) — not every requirement in the standard applies to every merchant.

Consult the PCI DSS Document Library for a complete breakdown of all changes and the SAQ Instructions and Guidelines to confirm which SAQ type applies to your payment method(s). Then work through the following:

• Download the relevant SAQ(s) from PCI SSC
• Review all requirements effective as of March 31, 2025, and compare against your current compliance position
• If you run an ecommerce site, determine which payment page security requirements apply to your SAQ type and take steps to protect against script attacks, as needed
• Audit your current access control processes: check which MFA requirements apply to your SAQ type, roll out MFA for all CDE access where required, and ensure all password holders use alphanumeric passphrases of at least 12 characters (if the system does not support 12 characters, the required minimum length is 8 characters)
• Check whether Requirement 11.3.1.2 (authenticated internal vulnerability scanning) applies to your SAQ type, and schedule scans accordingly
• Download guidance for TRAs from PCI SSC if your SAQ type requires them, complete TRAs for each applicable recurring requirement, then ensure you perform each requirement at the determined frequency
• Establish a schedule to respond to payment page script monitoring alerts, for access control reviews and vulnerability scans, and to review TRAs annually to keep compliance continuous
• Gather and keep evidence that all applicable controls are in place and operational throughout the year
• Follow the defined approach for PCI DSS requirement implementation and assessment (compliance validation). The defined approach is the correct method for SAQ-eligible small businesses

Alternatively, utilize services such SecureTrust PCI Manager which help you to determine the correct SAQ type(s) for your business, display your applicable v4.0.1 PCI DSS requirements as an online assessment, and guide you in completing and validating your SAQ.

Common Pitfalls During the PCI DSS v4.x Transition

Common mistakes during the transition to PCI DSS v4.0.1 can delay your compliance validation. Here are the ones most relevant to small businesses:

• Not understanding which SAQ type(s) applies to your payment method(s) — different SAQs have different requirements, and each has specific eligibility criteria.  Using the wrong one is a common mistake
• Treating PCI DSS compliance as an annual event rather than a continuous practice
• Assuming your current security posture is robust enough without verifying it against v4.0.1 requirements
• Not understanding which MFA requirements apply to your specific SAQ type – and failing to implement MFA for all CDE access, if required
• Overlooking the new authenticated internal vulnerability scanning requirement (Req 11.3.1.2) if it applies to your SAQ type
• Neglecting to document “what” it is that the recurring requirement is intended to protect against or the factors that contribute to threats being realized when completing TRAs (where applicable)
• Missing assets and control gaps through careless analysis of your current payment infrastructure
• Relying on outdated or legacy systems that do not support compliance with the standard
• Failing to properly authorize and manage payment page scripts (if applicable to your SAQ type)
• Not using available support — SecureTrust PCI Manager guides you through your SAQ step by step, and your payment processor can answer questions specific to your payment setup

Transitioning to PCI DSS v4.0.1 is a meaningful step toward embedding payment data security into daily business operations — and keeping your customers’ information safer against an evolving threat landscape. The best approach is to take careful stock of your current position, confirm which SAQ type applies to you, and ask your payment processor for guidance wherever needed. Learn more about PCI compliance for small businesses and PCI compliance levels today.