Skip to content
AUSEC
Esc
  • Home/
  • Services/services/
  • Penetration testing/services/penetration-testing/
  • Vulnerability assessment/services/vulnerability-assessment/
  • Security audit/services/security-audit/
  • Compliance consulting/services/compliance-consulting/
  • Incident response and digital forensics/services/digital-forensics/
  • Corporate training and workshops/services/corporate-training/
  • Audit methodology/methodology/
  • Security posture quiz/#quiz
  • Threat Lab: attack simulator/threat-lab/#simulator
  • Threat Lab: cyber kill chain/threat-lab/#kill-chain
  • Threat Lab: defence in depth/threat-lab/#defence
  • Threat Lab: spot the phish/threat-lab/#phish
  • Threat Lab: terminal/threat-lab/#terminal
  • Frameworks hub/frameworks/
  • Framework cross-mapping/frameworks/#crossmap
  • PCI DSS v4.0.1/frameworks/pci-dss/
  • ISO/IEC 27001:2022/frameworks/iso-27001/
  • ISO/IEC 27002:2022/frameworks/iso-27002/
  • NIST Cybersecurity Framework 2.0/frameworks/nist-csf/
  • CERT-In Audit Guidelines (India)/frameworks/cert-in/
  • Training and internships/training/
  • Resources: articles and checklists/resources/
  • PCI DSS v4.0.1: what changed, and what it means now/resources/pci-dss-4-0-1-changes/
  • ISO/IEC 27001:2022 Annex A for beginners/resources/iso-27001-annex-a-beginners/
  • NIST CSF 2.0: the Govern function explained/resources/nist-csf-govern-function/
  • How to prepare for a CERT-In audit/resources/prepare-cert-in-audit/
  • Glossary/resources/#glossary
  • Team and certifications/team/
  • About Ausec/about/
  • Contact and book an assessment/contact/
  • Privacy policy/privacy/
  • Terms of use/terms/
  • Responsible disclosure/responsible-disclosure/
  • Design system/styleguide/

PCI DSS v4.0.1: what changed, and what it means now

PCI DSS v4.0.1 is now the only active version, and the future-dated requirements became mandatory on 31 March 2025. Here is what changed and where organisations most often fall short.

· 6 min read

PCI DSS v4.0 was published in March 2022 and replaced v3.2.1, which was retired at the end of March 2024. In June 2024 the PCI Security Standards Council published v4.0.1, a limited revision that corrects and clarifies wording without adding new requirements. v4.0 itself was retired at the end of 2024, so every assessment now uses v4.0.1.

Version 4 introduced a large set of new requirements. Some applied immediately; most were future-dated and treated as best practice until 31 March 2025. That date has passed, so they are now assessed like any other requirement.

The changes that matter most in practice

  • Multi-factor authentication for all access into the cardholder data environment, not only remote and administrative access (Requirement 8.4.2).
  • Longer passwords: at least 12 characters where the system supports it (8.3.6).
  • Payment page script management: an inventory of scripts on payment pages, with each one authorised and its integrity assured (6.4.3).
  • Change and tamper detection on payment pages, so unauthorised modifications are spotted (11.6.1).
  • Automated mechanisms to review audit logs (10.4.1.1).
  • Anti-phishing mechanisms to protect staff (5.4.1).
  • Targeted risk analyses to justify how often certain activities are performed (12.3.1).
  • Scope confirmed and documented at least once every 12 months (12.5.2).

The customised approach

Version 4 lets mature organisations meet a requirement's stated objective with their own control design, instead of the defined approach. It requires a documented targeted risk analysis and a controls matrix, and the assessor tests the control specifically. It is useful for unusual architectures, but it is more work to evidence, not a shortcut.

Where organisations fall short

  • Scope drift: card data appears in logs, tickets or analytics tools nobody included in scope.
  • MFA gaps on service accounts and console access inside the environment.
  • No owner for payment page scripts, especially tags added by marketing tools.
  • Risk analyses written once to satisfy a requirement and never revisited.

Where to start

Confirm your scope first: where card data is stored, processed and transmitted, and which systems can affect its security. Then run a gap assessment against v4.0.1, giving the formerly future-dated requirements extra attention. Your acquirer or the card brands decide whether you validate through a Report on Compliance or a Self-Assessment Questionnaire.