PCI DSS 4.0.1 Requirements for Small Merchants
Published 20 min read
Version in forcePCI DSS v4.0.1
Source: PCI SSC document library, read on 2026-10-22
Top-level requirements12, grouped under 6 goals
Source: PCI SSC, PCI DSS v4.x Quick Reference Guide, p. 8, read on 2026-10-22
What v4.0.1 changedwording; no requirement added or deleted
Source: PCI SSC blog, Just Published: PCI DSS v4.0.1, read on 2026-10-22
New v4.0 requirementsmandatory since 31 March 2025
Source: PCI SSC, Prioritized Approach Tool for PCI DSS v4.0.1, read on 2026-10-22
PCI DSS 4.0.1 has 12 requirements, from network security controls to security policies, and v4.0.1 added none: it is a wording revision of v4.0. What changed for small merchants is the calendar. The new requirements that PCI DSS v4.0 introduced as best practices became mandatory on 31 March 2025. Which of them you answer depends on your SAQ: on SAQ A, the Council counts 14 or 27 requirements; on SAQ D, all of them.
The 12 requirements in plain words
PCI DSS v4.0.1 is the version of the standard in force, and it still rests on 12 top-level requirements. Each one is a family: the number on the left is the family, and the rules you actually answer to sit underneath it as numbered sub-requirements like 3.3.1 or 8.3.6. The Council groups the families under 6 goals. Below, each family gets its official title, what it means at a shop counter or on a small web store, and one real sub-requirement so you can see the level of detail.
Build and Maintain a Secure Network and Systems
- 01
Install and maintain network security controls.
Firewalls and router rules, which v4 calls network security controls, sit between your card systems and everything else.
Req. 1.3.1Inbound traffic to the card data environment is limited to what is necessary, with “All other traffic … specifically denied.”
- 02
Apply secure configurations to all system components.
Nothing runs on factory settings: default passwords changed, unused accounts and services switched off.
Req. 2.2.2Vendor default accounts you use get a new password; the ones you do not use are removed or disabled. POS terminals included.
Protect Account Data
- 03
Protect stored account data.
Keep as little card data as you can, and never keep what a thief could use to copy the card.
Req. 3.3.1“SAD is not stored after authorization, even if encrypted.” That covers the card verification code, full track data and PINs.
- 04
Protect cardholder data with strong cryptography during transmission over open, public networks.
A card number that crosses the internet travels encrypted, on valid certificates.
Req. 4.2.1Only trusted keys and certificates are accepted, and certificates are confirmed valid, not expired or revoked.
Maintain a Vulnerability Management Program
- 05
Protect all systems and networks from malicious software.
Anti-malware on the computers that touch card data, and since v4, tools that catch phishing too.
Req. 5.4.1Processes and automated mechanisms detect and protect personnel against phishing attacks.
- 06
Develop and maintain secure systems and software.
Patch on time, and look after the web page where customers pay.
Req. 6.3.3Patches for critical vulnerabilities are installed within one month of release; the rest on a timetable set by risk.
Implement Strong Access Control Measures
- 07
Restrict access to system components and cardholder data by business need to know.
Each person sees only what their job needs. The weekend cashier does not need the admin login.
Req. 7.2.1Access is based on job function, with “The least privileges required” to do the job.
- 08
Identify users and authenticate access to system components.
Everyone has their own login, passwords are long, and remote or admin access needs a second factor.
Req. 8.3.6Passwords need “A minimum length of 12 characters (or IF the system does not support 12 characters, a minimum length of eight characters)” with letters and numbers.
- 09
Restrict physical access to cardholder data.
Lock up paper with card numbers on it, shred it when done, and keep an eye on your terminals.
Req. 9.4.6Paper with cardholder data is “cross-cut shredded, incinerated, or pulped” when no longer needed.
Regularly Monitor and Test Networks
- 10
Log and monitor all access to system components and cardholder data.
Systems that handle card data keep logs, and someone reads them.
Req. 10.5.1Audit log history is kept for at least 12 months, with the most recent three months immediately available.
- 11
Test security of systems and networks regularly.
Scheduled scans and tests find the holes before someone else does.
Req. 11.3.2External vulnerability scans “At least once every three months” and “By a PCI SSC Approved Scanning Vendor (ASV).”
Maintain an Information Security Policy
- 12
Support information security with organizational policies and programs.
The paperwork that holds it together: a policy, staff training, a list of your providers, an incident plan.
Req. 12.10.1An incident response plan “exists and is ready to be activated,” naming who to notify, the payment brands and acquirers included.
Source: PCI SSC, PCI DSS v4.x Quick Reference Guide, p. 8; Prioritized Approach Tool for v4.0.1, read on 2026-10-22
Requirement 1 and Requirement 8 each have a deeper guide here. Requirement 1 is where a shop owner asks whether the router their internet provider gave them counts as a firewall; the guide to a PCI compliant firewall answers that. Requirement 8 is where v4 set the 12-character password minimum; the PCI password requirements guide walks through length, rotation and MFA.
How to read a requirement number
Every rule in the standard has an address. The first number is the family, the second the section, and the third (sometimes a fourth) the requirement you are tested on. Here is the password rule, top to bottom:
Requirement 8The family
Identify users and authenticate access to system components.
8.3The section
Strong authentication for users and administrators is established and managed.
8.3.6What you answer
“A minimum length of 12 characters (or IF the system does not support 12 characters, a minimum length of eight characters)”, numbers and letters both.
Under many requirements sit Applicability Notes, and they are where small merchants win or lose time. 8.3.6, for one, does not apply to POS terminal accounts that can reach one card number at a time. Read the note before you answer the question.
You meet each requirement the standard's own way, which the Council calls the Defined Approach and describes as useful for “those new to information security or PCI DSS.” The other route, the Customized Approach, “is intended for risk-mature entities” and needs an assessor to write tests for your own controls. That is not a corner shop's route.
Source: PCI SSC, Quick Reference Guide p. 20; Prioritized Approach Tool for v4.0.1, read on 2026-10-22
What changed: v4.0, then v4.0.1
Version 4.0 is where the new rules came in. Version 4.0.1 only tidied up: the Council published PCI DSS v4.0.1 in June 2024 as “a limited revision” with “no additional or deleted requirements.” PCI DSS v4.0 was retired on 31 December 2024. Since then v4.0.1 is “the only active version of the standard supported by PCI SSC.” If someone tells you there are new v4.0.1 rules to learn, they mean the v4.0 ones.
- March 2022PCI DSS v4.0 published, with its new requirements marked as best practices for now (PCI SSC blog, Jun 2024)
- 31 March 2024PCI DSS v3.2.1 retired (PCI SSC blog, Jun 2024)
- June 2024PCI DSS v4.0.1 published: “a limited revision” (PCI SSC blog, Jun 2024)
- October 2024The SAQs for PCI DSS v4.0.1 published (Council bulletin dated 15 October 2024) (PCI SSC bulletin)
- 31 December 2024PCI DSS v4.0 retired; v4.0.1 is “the only active version of the standard supported by PCI SSC” (PCI SSC blog; bulletin)
- January 2025SAQ A changed: payment-page script rules out, a new eligibility criterion in (PCI SSC blog, 30 Jan 2025)
- 31 March 2025The future-dated requirements became mandatory; the January 2025 SAQ A took effect (PCI SSC blog; PA tool)
What v4.0.1 did change was wording. The Council's own list of the main edits, with what each means if you run a small shop:
Swipe sideways for the whole row
| Where | What v4.0.1 changed | What it means for you |
|---|---|---|
| Req. 3 | Clarified notes for issuers, and for keyed cryptographic hashes that make card numbers unreadable | Rarely you: it matters only if you issue cards or hash stored card numbers. |
| Req. 6 | “Reverted to PCI DSS v3.2.1 language that installing patches/updates within 30 days applies only for ‘critical vulnerabilities.’” | Critical patches within one month of release; the rest on a timetable set by your own risk ranking (6.3.3). |
| Req. 6 | Added notes on how the payment-page script rule (6.4.3) applies | Scripts inside a processor's embedded iframe are the processor's job, not yours. |
| Req. 8 | MFA for all non-administrative access into the CDE does not apply to accounts that sign in only with phishing-resistant factors | If every login to your card systems already uses a phishing-resistant factor, 8.4.2's MFA does not apply to those accounts. |
| Req. 12 | Clarified several points about customers and third-party service providers (TPSPs) | Your provider's compliance still does not make you compliant (12.8.1). |
| Appendices | Removed the Customized Approach sample templates from Appendix E | Not you: a small merchant on an SAQ uses the Defined Approach. |
Source: PCI SSC blog, Just Published: PCI DSS v4.0.1, read on 2026-10-22
The requirements that became mandatory on 31 March 2025
When v4.0 came out, many of its new requirements carried a grace note in the standard: “a best practice until 31 March 2025, after which it will be required.” The v4.0.1 revision “does not impact the effective date.” So the new requirements that PCI DSS v4.0 introduced as best practices became mandatory on 31 March 2025, and an SAQ you sign today answers for them like any other requirement.
These are the ones a merchant can meet. Requirements written only for service providers or card issuers are left out. The last column reads from our checklist, so it shows which SAQs carry a line for the requirement.
Swipe sideways for the whole row
| Req. | What it asks | Milestone | On our checklist for |
|---|---|---|---|
| 3.2.1 | Your retention rules also cover any sensitive authentication data kept before a payment is authorized. | 1 | SAQ D |
| 4.2.1.1 | An inventory of the trusted keys and certificates you use. | 2 | SAQ D; others: check your form |
| 5.4.1 | Automated tools that detect and protect staff against phishing. Training alone does not meet it. | 2 | SAQ D; others: check your form |
| 6.4.2 | An automated web-attack filter in front of public-facing web applications. It replaces Requirement 6.4.1. | 3 | SAQ A-EP, SAQ D |
| 6.4.3 | Every payment-page script authorized, its integrity assured, and listed with a written reason. | 2 | SAQ A-EP, SAQ D |
| 7.2.4 | Every user account and its access, vendors' included, reviewed at least once every six months. | 4 | SAQ D |
| 8.3.6 | Passwords of at least 12 characters (eight if the system cannot take 12), letters and numbers. | 2 | SAQ A, SAQ A-EP, SAQ C-VT, SAQ C, SAQ D |
| 8.4.2 | MFA for all non-console access into the card data environment, not only for administrators. | 2 | SAQ A-EP, SAQ C, SAQ D |
| 8.5.1 | MFA that cannot be replayed or bypassed, using at least two different types of factor. | 2 | SAQ D; others: check your form |
| 8.6.1 | System and application accounts that a person can log in with: interactive use only for an exceptional, approved and documented need, tied to a named person. | 4 | SAQ D; others: check your form |
| 8.6.2 | Passwords for system and application accounts that allow interactive login are never hard coded in scripts, configuration files or source code. | 4 | SAQ D; others: check your form |
| 8.6.3 | Passwords for system and application accounts changed at a frequency your targeted risk analysis sets, on suspected compromise, and complex enough for that frequency. | 4 | SAQ D; others: check your form |
| 9.5.1.2.1 | Your own targeted risk analysis sets how often, and how, card terminals are inspected. | 2 | SAQ D; others: check your form |
| 10.4.1.1 | Audit log reviews done by automated mechanisms. | 4 | SAQ D; others: check your form |
| 10.7.2 | Failures of critical security controls detected, alerted and fixed promptly. | 4 | SAQ D; others: check your form |
| 11.6.1 | A change- and tamper-detection check on the payment page's scripts and security headers, at least weekly. | 2 | SAQ A-EP, SAQ D |
| 12.3.1 | A written targeted risk analysis for every requirement that lets you pick your own frequency. | 2 | SAQ A-EP, SAQ D |
| 12.3.4 | Hardware and software reviewed every 12 months for vendor fixes and end-of-life plans. | 6 | SAQ D; others: check your form |
| 12.6.3.1 | Security awareness training covers phishing and social engineering. | 6 | SAQ A-EP, SAQ C-VT, SAQ C, SAQ D |
| 12.10.7 | Incident steps for finding stored card numbers somewhere they should not be. | 2 | SAQ D; others: check your form |
Future-dated requirements listed20
Source: PCI SSC, Prioritized Approach Tool for PCI DSS v4.0.1 (applicability notes, milestone column), read on 2026-10-22
The rows that matter most to online shops are 6.4.3, which makes you manage every script on your payment page, and 11.6.1, which wants a weekly tamper check on that page. The Council itself cited “stakeholder feedback regarding the complexity of implementing” them when, in January 2025, it changed SAQ A: it removed “PCI DSS Requirements 6.4.3 and 11.6.1 for payment page security, and Requirement 12.3.1 for a Targeted Risk Analysis to support Requirement 11.6.1,” and added an eligibility criterion that the merchant “confirm their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s).”
Read that carefully. The change affects only what SAQ A merchants report. The Council says it does “not remove or diminish the underlying requirements within PCI DSS.” SAQ D covers every requirement, so both rules are on it. Our SAQ A-EP checklist carries both as well; confirm them in your A-EP form.
Source: PCI SSC blog, Important updates for merchants validating to SAQ A (30 Jan 2025), read on 2026-10-22
A targeted risk analysis is the Council's name for “a risk analysis that focuses on a specific PCI DSS requirement(s) of interest”; see the SAQ A guide for the script criterion in practice.
Which requirements reach your SAQ
The standard is written for everyone from a corner shop to a card processor, and your SAQ is the filter between the two. The Council's own count makes the point: SAQ A comes to 14 requirements with no access to your own webpage and 27 with a redirect or a processor iframe, while any other e-commerce setup lands on SAQ D, all requirements. Pick your SAQ to see how many of our checklist lines fall in each family, and which of the March 2025 requirements are among them.
Which SAQ do you file?
Online or phone orders, with every card data job handed to a PCI DSS compliant processor.
Lines per requirement
01 Network security controlsnone
02 Secure configurations1
03 Stored account datanone
04 Encryption in transitnone
05 Malware and phishingnone
06 Secure systems and software1
07 Need-to-know accessnone
08 Logins and passwords3
09 Physical access and paper4
10 Logs and monitoringnone
11 Security testing2
12 Policies and programs5
SAQ A, checklist lines23
New since 31 March 2025, on your list
- 8.3.6Passwords of at least 12 characters (eight if the system cannot take 12), letters and numbers.
Future-dated1
The Council's count for SAQ A is 14 requirements, or 27 with a redirect or a processor iframe; our checklist breaks them into the lines shown here.
Read from our checklist, which is our reading of each SAQ's eligibility text and each requirement's scope. Your SAQ form has the final list of questions.
What v4 changed, told by the way you take cards:
Online, fully outsourced
6.4.3 and 11.6.1 are off your form. In their place, you confirm your site is “not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s).”
Scans stay: SAQ A includes 11.3.2 and 11.3.2.1 if your pages redirect to, or embed, the processor's page. See what an ASV scan is.
of them future-dated1
Terminals and paper
Your lines are about hardware and paper: a list of every terminal, regular inspections for tampering, staff who know a fake repair visit when they see one (9.5.1), and paper locked up and shredded (9.4).
New near you: 9.5.1.2.1, where your own targeted risk analysis sets how often you inspect. Look for it in your form.
of them future-dated0
of them future-dated0
Virtual terminal or POS system
Passwords of 12 characters (8.3.6), though not for POS terminal accounts that reach one card number at a time. Our SAQ C checklist adds MFA for non-console and remote access (8.4.2 and 8.4.3).
Yearly security awareness training that now covers phishing and social engineering (12.6.3.1).
of them future-dated2
of them future-dated3
Source: PCI SSC, SAQ Instructions and Guidelines v4.0.1 r1, p. 10, read on 2026-10-22
Where to start: the Council's own order
If the list still looks long, the Council has already sorted it. Its Prioritized Approach puts every requirement in one of 6 milestones, in the order it suggests you work, and the first one comes with a line worth taping to the till:
“If you don't need it, don't store it.”
- 1
“Do not store sensitive authentication data and limit cardholder data retention.”
3.3.13.2.19.4.61.2.412.5.2
Find every place a card number or security code sits (order notes, inboxes, spreadsheets, paper) and get rid of what you do not need. What you may keep
- 2
“Protect systems and networks and be prepared to respond to a system breach.”
1.3.18.3.68.4.211.3.212.8.112.10.1
Lock down the network and the logins, list your providers, and write the incident plan before you need it. Incident plan template
- 3
“Secure payment applications.”
6.3.16.3.36.4.2
Keep your POS software and website platform updated, and get critical patches in within the month.
- 4
“Monitor and control access to your systems.”
7.2.17.2.410.2.110.4.1
Put the six-monthly access review on the calendar, and remove a leaver's access at once.
- 5
“Protect stored cardholder data.”
3.4.13.5.1
Only if you must keep card numbers: mask them on screen and make them unreadable where stored, or let a token stand in. Tokens or encryption
- 6
“Complete remaining compliance efforts, and ensure all controls are in place.”
12.1.112.6.112.6.3.1
Write the security policy down, train staff on it, and have each of them acknowledge it. Policy template
Source: PCI SSC, Prioritized Approach Tool for PCI DSS v4.0.1, read on 2026-10-22
The spreadsheet itself is free. Mark each requirement Yes, No or N/A and it works out a percentage per milestone. The Council adds: “You may share this document with your acquirer or Qualified Security Assessor to provide an assessment of progress your organization has completed toward PCI DSS compliance.” If you are behind, that is a better conversation than a blank AOC.
Quick reference
Versions and counts
Version in forcePCI DSS v4.0.1
v4.0 retired31 Dec 2024
Future-dated requirements mandatory31 Mar 2025
SAQ A, no access to your own webpage14
SAQ A, redirect or processor iframe27
SAQ A-EP139
SAQ D for Merchantsall
Your listyour SAQ
The clocks
Password length, minimum (8.3.6)12 chars
Password-only login, change (8.3.9)90 days
Critical patches, installed within (6.3.3)1 month
Access review, at least every (7.2.4)6 months
Payment-page tamper check (11.6.1)weekly or TRA
ASV scan where your SAQ has it, every (11.3.2)3 months
Training, on hire and every (12.6)12 months
SourcePA tool, v4.0.1
Sources
- PCI SSC: Document library (PCI DSS v4.0.1) (pcisecuritystandards.org), read on 2026-10-22
- PCI SSC: PCI DSS v4.x Quick Reference Guide (Jan 2025) (docs-prv.pcisecuritystandards.org), read on 2026-10-22
- PCI SSC: Prioritized Approach Tool for PCI DSS v4.0.1 (Jan 2025) (docs-prv.pcisecuritystandards.org), read on 2026-10-22
- PCI SSC blog: Just Published, PCI DSS v4.0.1 (11 Jun 2024) (blog.pcisecuritystandards.org), read on 2026-10-22
- PCI SSC: SAQs for PCI DSS v4.0.1 Now Available (15 Oct 2024) (pcisecuritystandards.org), read on 2026-10-22
- PCI SSC blog: Updates for merchants validating to SAQ A (30 Jan 2025) (blog.pcisecuritystandards.org), read on 2026-10-22
- PCI SSC: SAQ Instructions and Guidelines v4.0.1 r1 (Apr 2025) (docs-prv.pcisecuritystandards.org), read on 2026-10-22
- PCI SSC: Glossary (pcisecuritystandards.org), read on 2026-10-22