First-time PCI DSS 4.0 teams most often fail on scope, not on technology. The common errors are an unconfirmed cardholder data environment, no targeted risk analyses, MFA applied only to remote access, unmanaged payment page scripts and the wrong self-assessment questionnaire. Each one is cheap to fix before an assessor finds it.
Mistake 1: treating v4 as v3.2.1 with extra paragraphs
The PCI Security Standards Council retired v3.2.1 on 31 March 2024. Version 4.0 was a rewrite, not a patch: the Council's own summary of changes sorts its edits into evolving requirements, clarifications and restructuring. Version 4.0.1, published in June 2024, was a limited revision. It fixed typographical errors and clarified intent, and it added or deleted no requirements. So a v4 plan is a v4 plan, and v4.0.1 is the text you will be assessed against.
Mistake 2: assuming the "future-dated" items can wait
Many new requirements were labelled best practice until 31 March 2025. That date has passed, so they are now assessed like everything else. Examples from the summary of changes: MFA for all access into the cardholder data environment (8.4.2), a minimum password length of 12 characters (8.3.6), automated audit log reviews (10.4.1.1), authenticated internal vulnerability scans (11.3.1.2), an inventory of bespoke and custom software (6.3.2) and protection against phishing (5.4.1).
If your plan was written in 2023, rebuild it from the current list.
Mistake 3: never writing the targeted risk analysis
Requirement 12.3.1 asks for a documented targeted risk analysis behind every requirement that lets you choose how often to do something. Think malware scans, periodic log reviews, point of interaction device inspections. The Council's sample template asks you to name the asset, the threat, the factors that raise likelihood or impact, and why your chosen frequency is enough. Missing frequencies are an easy finding.
Mistake 4: MFA on the VPN and nowhere else
Version 4.0 widened MFA to all access into the cardholder data environment, not just remote entry. Count every path: console logins, jump hosts, admin tools, cloud consoles. Also check that the MFA system itself is set up so it cannot be bypassed, which is the point of 8.5.1.
Mistake 5: ignoring the browser
Requirements 6.4.3 and 11.6.1 cover scripts that load and run on your payment pages and detection of tampering with page headers and content. The Council has said these two were the hardest for many merchants to implement and published extra guidance and FAQ updates for them. If you embed a hosted payment form, read the current SAQ A eligibility criteria before assuming you are exempt.
Mistake 6: picking a questionnaire by hope
Your payment flow decides your self-assessment questionnaire, not your preference. An e-commerce site that redirects fully to a processor is a different case from one that serves its own payment page. SAQs also cannot be used to document the customized approach, so if you want that route you need a full assessment.
Mistake 7: scope drawn once, then forgotten
Requirement 12.5.2 requires you to document and confirm scope at least every 12 months and after significant change. Service providers must do it every six months (12.5.2.1). First timers draw a data flow diagram for the assessor and never update it.
What to do
- Download v4.0.1 and the summary of changes from the PCI SSC document library. Read the requirements, not a vendor summary.
- Map where account data is stored, processed or transmitted, then confirm scope in writing and date it.
- Decide which questionnaire or report type applies by talking to your acquirer or payment brand, since they set validation rules.
- List every requirement with a flexible frequency and write a targeted risk analysis for each.
- Close the former future-dated items: MFA coverage, password length, automated log review, authenticated scans, software inventory.
- Inventory payment page scripts and set up change and tamper detection for page content.
- Assign owners for each requirement area. Version 4.0 adds a roles and responsibilities requirement to most areas, such as 8.1.2 and 10.1.2.
Quick check
Is PCI DSS 4.0 or 4.0.1 the one I follow?
Follow v4.0.1. It is a limited revision of v4.0 with clarifications and no added or removed requirements.
Are the 31 March 2025 requirements optional now?
No. They were best practice until that date and are now assessed as requirements.
How Safeguard helps automate this
Several of the mistakes above are evidence problems: you did the work but cannot show it. Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code rather than by screenshot, and monitoring keeps running between assessments. Technical evidence for items like the bespoke software inventory and vulnerability management comes from your real code and dependencies: scans, SBOMs and reachability. Autonomous remediation can open tested fix pull requests for vulnerable dependencies. It is off by default, every category starts on Manual, and you choose which categories run automatically and set the approval level. A qualified assessor still validates your compliance; Safeguard helps you prepare and keep evidence ready. Book a call.
Sources
- PCI SSC: Just Published, PCI DSS v4.0.1
- PCI SSC: Summary of Changes from PCI DSS v3.2.1 to v4.0
- PCI SSC podcast on e-commerce requirements effective after 31 March 2025
- PCI DSS v4.0 SAQ A-EP
- The full v4.0.1 standard sits behind a download gate we could not fetch, so requirement numbers come from the Council's summary of changes. Check them against the standard.
Last reviewed: 18 October 2026.
