PCI DSS v4.0 for Financial Services: Frequently Asked Questions
PCI DSS version 4.0 came into full effect on 31 March 2024, replacing version 3.2.1. For UK financial firms that handle, process, store, or transmit cardholder data, the transition to v4.0 brought significant new requirements — particularly around multi-factor authentication, phishing resistance, and web application security. Several of the new "best practice" requirements that could be deferred became mandatory on 31 March 2025. This FAQ answers the questions most frequently raised by UK financial services compliance teams navigating the transition.
PCI DSS v4.0 fully in effect March 2024. New requirements for MFA everywhere, phishing-resistant authentication, and script management represent material changes from v3.2.1.
PCI DSS v4.0 Core Changes
The headline changes in PCI DSS v4.0 relevant to financial services firms:
- MFA expanded: v4.0 requires MFA for all access to cardholder data environments — not just remote access as in v3.2.1. Console access, admin interfaces, and internal applications accessing CDE data all require MFA
- Phishing-resistant authentication: New requirement for phishing-resistant MFA for privileged accounts — hardware security keys (FIDO2) or similar are required; standard TOTP apps are insufficient for admin access
- Targeted risk analysis: Each requirement now requires a tailored risk analysis — more evidence-based, less checkbox-oriented
- Script management: New Requirement 6.4.3 requires firms to manage scripts on payment pages — addressing Magecart/web skimming attacks
- Customised approach: v4.0 formally introduces an alternative to the defined approach — firms can implement controls that achieve the intent of requirements through different means, with risk assessment documentation
Frequently Asked Questions
We use a third-party payment processor and never see card data. Are we still in scope for PCI DSS?
It depends on how payment data flows through your systems. If you never access, process, store, or transmit cardholder data (card numbers, CVVs, PINs) and your third-party processor handles all payment data, you may qualify for SAQ-A (the simplest self-assessment) or even be considered out of scope. However, you need to confirm: (1) all card data is captured directly by your processor with no data passing through your servers; (2) your processor is PCI DSS compliant (obtain their certificate annually); (3) you have no access to cardholder data. If your website hosts any payment pages or scripts — even from a third-party provider — Requirement 6.4.3 (script management) may still apply.
What does "phishing-resistant MFA" mean in practice for PCI DSS v4.0?
Phishing-resistant MFA means authentication that cannot be defeated by a man-in-the-middle attack or real-time phishing. Standard TOTP codes (like Google Authenticator) are not phishing-resistant — an attacker who compromises your login page can relay the TOTP code in real time. Phishing-resistant MFA includes: FIDO2/WebAuthn hardware security keys (YubiKey, etc.), passkeys, and smart card-based authentication. For PCI DSS v4.0 Requirement 8.4.2, phishing-resistant MFA is required for privileged accounts in the cardholder data environment. For non-privileged accounts, standard MFA (including TOTP) continues to satisfy the general MFA requirement.
What is the script management requirement (6.4.3) and what do we need to do?
Requirement 6.4.3 targets web skimming attacks — where malicious scripts injected into payment pages steal card data as customers type it. The requirement applies to payment pages accessed by the consumer's browser. Firms must: (1) maintain an inventory of all scripts on payment pages; (2) have a method to confirm script integrity and authorisation; (3) implement Content Security Policy (CSP) headers to restrict which scripts can run. For firms using third-party payment page providers (like Stripe or PayPal hosted pages), the requirement focuses on ensuring those providers are PCI compliant. For firms that host any payment page elements, CSP implementation and script inventory are mandatory.
How does the "customised approach" work and when should we use it?
The customised approach allows firms to implement controls that achieve the security objective of a PCI DSS requirement through a different means than the defined approach. To use the customised approach for a requirement, you must: (1) conduct and document a targeted risk analysis showing that your alternative control achieves the requirement's stated objective; (2) have the analysis reviewed by a QSA; (3) test the alternative control's effectiveness. The customised approach is useful where a defined requirement does not fit your technical architecture, but requires significantly more documentation than the standard approach. Most firms use the defined approach for the majority of requirements and reserve the customised approach for specific architectural edge cases.
What is a QSA and do we need one for PCI DSS v4.0 compliance?
A Qualified Security Assessor (QSA) is a company and individual certified by the PCI SSC to conduct PCI DSS assessments. Whether you need a QSA depends on your compliance level: Level 1 merchants (over 6 million transactions annually) must have an annual Report on Compliance (ROC) conducted by a QSA. Level 2–4 merchants can typically self-assess using Self-Assessment Questionnaires (SAQs). Service providers — including payment processors and other firms that handle cardholder data on behalf of others — have different requirements. Many Level 2 firms and above choose to engage a QSA for their annual SAQ validation even where not strictly required, as it provides greater assurance and a more defensible compliance position.
Assess your PCI DSS v4.0 compliance gaps
Kyanite Blue specialises in cybersecurity for iGaming operators. MGA-licensed operators across Malta trust our stack.
Get in touchReady to secure your iGaming operation?
MGA-licensed operators across Malta trust Kyanite Blue.