Key takeaways

  • PCI DSS v3.2.1 was retired on March 31, 2024, and v4.0 on December 31, 2024. v4.0.1, published in June 2024, is a limited revision with no new or deleted requirements.
  • The future-dated requirements took effect on March 31, 2025. The PCI SSC says v4.0.1 did not change that date. Before it, they could be marked Not Applicable. Since then, all applicable new requirements must be fully considered in an assessment.
  • Small merchants usually validate with a Self-Assessment Questionnaire. Which one depends on how you take cards. Your acquirer or card brand, not the PCI SSC, decides what you must submit.
  • The cheapest compliance work is reducing scope: use a validated payment provider, keep card data off your own systems, and keep the terminals and the office network separate.
  • E-commerce merchants that embed a provider's payment form must show that their payment page is protected from script attacks. This is a requirement for SAQ A eligibility and is a common gap.

A standard that applies to everyone who takes cards

The Payment Card Industry Data Security Standard (PCI DSS) is published by the PCI Security Standards Council (PCI SSC). It applies to every entity that stores, processes or transmits payment card data, from a global retailer to a dental practice with one terminal. It is a contractual standard, not a statute. Compliance runs through the card brands and the merchant's acquiring bank (the "merchant bank"). The PCI SSC itself says that compliance questions, including which assessment to submit, go to the organizations that manage compliance programs, such as the payment brands and acquirers.

If you take cards and have not looked at the standard since 2022, three dates matter: the retirement of old versions, the publication of v4.0.1, and March 31, 2025.

Version history in plain terms

  • PCI DSS v4.0 was published in March 2022, the first major update in over a decade.
  • PCI DSS v3.2.1 was retired on March 31, 2024.
  • PCI DSS v4.0.1 was published in June 2024. The PCI SSC calls it a limited revision. It corrects formatting and typographical errors and clarifies the intent of some requirements. It has no new or deleted requirements.
  • PCI DSS v4.0 was retired on December 31, 2024. After that date, v4.0.1 is the only active version the PCI SSC supports.
  • March 31, 2025 was the effective date for the future-dated requirements. The PCI SSC states that v4.0.1 does not change it.

As of this article's date, v4.0.1 is the version to use. Check the PCI SSC Document Library for anything newer, and ask your acquirer which version it expects.

What "future-dated" meant, and what it means now

Many of the new v4 requirements were labeled as best practices until March 31, 2025. The PCI SSC's FAQ 1564 explains the rule: before the effective date, a future-dated requirement that was not yet implemented could be marked Not Applicable in a Report on Compliance or Self-Assessment Questionnaire. Commencing on the effective date, all new requirements that apply to an entity's assessment, including those met by a third-party service provider on its behalf, must be fully considered. A QSA company interviewed on the Council's blog said that 51 of the 64 new requirements in v4.0 were future-dated. So most of the new work became mandatory on that day, and more than eighteen months have passed.

If your last self-assessment was filed before 2025, expect the next one to look different. Items you could skip then may now be required.

Changes in v4.0.1 that reach small businesses

The PCI SSC's announcement lists some clarifications. They show where the standard is aimed.

  • Requirement 6: the 30-day patching language applies only to critical vulnerabilities, reverting to v3.2.1 wording. Added notes clarify how the payment page script requirement applies.
  • Requirement 8: multi-factor authentication for all non-administrative access into the cardholder data environment does not apply to accounts authenticated only with phishing-resistant factors, such as security keys.
  • Requirement 12: clearer notes on the relationship between customers and third-party service providers (TPSPs).
  • Requirement 3: clarification for organizations that use keyed cryptographic hashes to make card numbers unreadable.

Which questionnaire applies to you

Most small merchants do not undergo an on-site assessment. They complete a Self-Assessment Questionnaire (SAQ) and an Attestation of Compliance. The PCI SSC's blog on v4 SAQs describes the family. The right one depends on how you take payments.

  • SAQ A: card-not-present merchants that fully outsource payment functions to a validated provider, either by redirecting customers to the provider's page or by embedding the provider's payment form.
  • SAQ A-EP: e-commerce merchants with more exposure on their website than SAQ A allows. It carries many more requirements than SAQ A, including multi-factor authentication for access into the cardholder data environment.
  • SAQ B and B-IP: merchants using standalone terminals. The Council's v4 guidance clarifies that B-IP is only for standalone PCI-approved terminals that are not connected to other types of devices in the same network zone.
  • SAQ C-VT: merchants who type card numbers into a virtual terminal. The v4 eligibility text clarifies this is intended only for standalone computers.
  • SAQ C: merchants with payment applications on their systems.
  • SAQ P2PE: merchants using a validated point-to-point encryption solution.
  • SAQ SPoC: merchants using a phone or tablet with a secure card reader in a validated SPoC solution (released September 2023).
  • SAQ D: everything else. It includes all requirements.

Pick by looking at the real flow of card data, not at what you wish it were. A merchant who thinks it qualifies for SAQ A but also keys cards into a laptop has more than SAQ A.

What the new SAQ questions ask

The Council's blog says all SAQs gained requirements in v4 and lists them by form. A few themes recur.

  • Paper records. If you keep receipts or reports with account data, you need policies for retention and secure storage (Requirements 3 and 9).
  • Payment page scripts. For e-commerce sites with an embedded payment form, you must protect the page from unauthorized script activity (Requirements 6 and 11).
  • External vulnerability scans. SAQ A merchants whose sites redirect to or embed a provider's payment page are expected to have scans by a PCI Approved Scanning Vendor at least once every three months (Requirement 11.3.2). Where a provider manages your e-commerce solution, the scans must still be demonstrably done on your behalf.
  • Authentication. Secure passwords or passphrases, and multi-factor authentication for all access into the cardholder data environment for the forms that include it.
  • People and process. Phishing and social-engineering awareness, defined roles and responsibilities, and for some forms, staff available 24/7 to respond to suspected breaches.
  • Scope confirmation. Requirement 12.5.2 asks organizations to confirm their PCI scope at least annually, which the Council's interview described as scoping becoming an actual requirement.

The script question for online stores

The PCI SSC's FAQ 1588 (February 2025) explains an SAQ A eligibility rule that trips many e-commerce merchants. The merchant must confirm that its site is not susceptible to script attacks that could affect its e-commerce systems. This applies to a page that embeds the provider's payment form, such as an iframe. It does not apply to a page that redirects customers to the provider, or to a merchant that fully outsources payment, for example by emailing a link to the provider's site.

A merchant can make this confirmation in two ways. It can use techniques such as those in Requirements 6.4.3 and 11.6.1, either itself or through a third party. Or it can obtain confirmation from its PCI DSS compliant provider that the provider's solution, implemented as instructed, includes techniques that protect the payment page from script attacks. The FAQ also notes that a provider of scripts unrelated to payment, which cannot affect card data, is not a TPSP for SAQ A. In practice: ask your payment provider for this confirmation in writing and keep it with your records. Also keep a list of the third-party scripts your site loads.

Cut scope first

The most effective PCI control is not having card data to protect. Every system that stores, processes or transmits card data, or that can affect its security, is in scope. A few decisions shrink that set.

  • Use a validated provider and let it collect cards. A hosted page or redirect keeps card numbers off your servers. Check the provider's own PCI status and keep its Attestation of Compliance.
  • Use a validated point-to-point encrypted terminal. This narrows what the office network must protect.
  • Do not keep card numbers. Never store sensitive authentication data, such as security codes, after authorization. Do not write card numbers in email, chat, notes or spreadsheets. Pay attention to old paper.
  • Keep payment devices apart. Terminals should not share a network zone with guest Wi-Fi, cameras or general office computers. Where a questionnaire says standalone, build it that way.
  • Limit who can reach the payment systems and require multi-factor authentication for them.

Managing the provider side

Most small merchants meet PCI DSS partly through someone else: a payment gateway, a point-of-sale vendor, a web host or an IT provider. The PCI SSC's FAQ says that, where an entity relies on a TPSP, the assessor may mark requirements the TPSP meets as Not Applicable only if the TPSP holds a current assessment, and from the effective date new requirements met by the TPSP must be fully considered. You should know which requirements each provider covers, get its Attestation of Compliance each year, and document who is responsible for the rest. This is the same discipline as any vendor risk program.

A practical plan for the next 90 days

  • Trace every way you accept cards: terminals, website, phone orders, mobile readers, invoices, recurring billing. Draw the flow in one page.
  • Ask your acquirer which SAQ and which version it expects, and when the attestation is due.
  • Collect Attestations of Compliance from every payment provider and note the responsibilities each one covers.
  • Fix the basics: patch, remove default passwords, turn on multi-factor authentication, keep terminals on their own network, train staff on phishing.
  • For an online store, get your provider's script-protection confirmation in writing and arrange the quarterly external scans if they apply.
  • Calendar the annual scope confirmation and the yearly refresh of the attestation.

How we help

Our Managed IT Services team runs the day-to-day controls that most questionnaires depend on: patching, multi-factor authentication, network separation for payment devices, endpoint protection, logging and staff awareness training. We can help trace your card flows, prepare the evidence for your questionnaire, and coordinate with your payment provider. We are not a Qualified Security Assessor, and the attestation remains the merchant's own statement to its acquirer.

Sources

This article is general information, not legal advice and not a PCI assessment. Your acquirer or card brand decides which validation you must submit, and the PCI SSC publishes the authoritative standard and questionnaires. Requirement details change between versions; confirm against the current PCI SSC documents. Last reviewed .

Keep reading

Need help with this?

We run your IT day to day so it stays secure: help desk, devices, Microsoft 365, Exchange, Active Directory, backups, networks and monitoring.

Managed IT Services