PCI DSS v4.0 is live: the seven controls that will catch you out in your next QSA audit

Why v4.0 is a bigger shift than v3.2.1

PCI DSS v4.0 became the only active version of the standard on 31 March 2024, with the legacy v3.2.1 officially retired. If your organisation is still operating on a v3.2.1 Report on Compliance, your next QSA audit will be conducted against v4.0 — and the differences are substantial enough to invalidate compliance work your team completed under the previous version.

The headline additions are well-publicised: the customised approach option, a rewritten Requirement 8 on authentication, and a significant expansion of Requirement 11 covering e-commerce and payment page security. But the seven controls below are the ones our team encounters most frequently as genuine gaps — areas where organisations believe they are compliant and discover during validation that they are not.

The seven controls — in order of how often they cause findings

• 1
  Requirement 8.3.6 — Minimum password complexity has been raised

  V4.0 raises the minimum password length for user accounts to 12 characters (up from 7 in v3.2.1) and specifies that passwords must contain both numeric and alphabetic characters. This sounds straightforward until you map it to every system in scope — including legacy ERP platforms, payment terminals, embedded devices, and vendor-managed systems where the password policy is not yours to set. In almost every pre-audit assessment we run, three to five in-scope systems cannot enforce 12-character passwords without a firmware upgrade, a vendor configuration change, or a waiver process that then requires compensating controls documentation. The compensating control path is legitimate, but it requires a formal risk analysis and a mitigation strategy that your QSA will scrutinise. Start the vendor conversations now.
• 2
  Requirement 8.4.2 — MFA now required for all access into the CDE

  V3.2.1 required MFA for remote access and for administrators accessing the cardholder data environment. V4.0 extends this: MFA is now required for all access into the CDE, including access by users who are on the internal network. This is the single most expensive compliance change for organisations with large internal teams accessing payment systems. It means every internal user — developers, analysts, support staff — who touches a CDE system needs to pass a second authentication factor, not just those connecting remotely. Organisations that deployed MFA for remote access only, which satisfied v3.2.1, now have a gap for internal access patterns they have never instrumented or protected. Mapping those access paths before the audit is essential.
• 3
  Requirement 6.4.3 & 11.6.1 — Payment page script management and tamper detection

  These two new requirements together represent the most significant expansion of PCI DSS scope in the standard's history for organisations that accept payments via web browsers. Requirement 6.4.3 mandates that all scripts executing on payment pages must be authorised, have a documented business justification, and have their integrity protected. Requirement 11.6.1 requires a change- and tamper-detection mechanism that alerts personnel to unauthorised modifications of payment pages. In practice, this means building — or subscribing to — a service that monitors every script tag on every payment page in real time, detects additions or modifications, and generates an alert within 24 hours. Most organisations handling card payments online have dozens of third-party scripts on their payment pages: analytics, A/B testing tools, chat widgets, tag managers. All of them are now in scope for authorisation and integrity verification. Magecart attacks are explicitly the threat model these requirements are designed to address.
• 4
  Requirement 12.3.2 — Targeted risk analysis for customised approach controls

  V4.0 introduces the customised approach — an option that allows organisations to implement controls in ways that differ from the defined approach, provided they can demonstrate that the security objective of the requirement is met. This sounds like flexibility, and in qualified hands it is. In practice, the customised approach requires a formal targeted risk analysis for each customised control, documented evidence that the control meets the requirement's stated objective, and ongoing testing. Most organisations that attempt the customised approach for the first time underestimate the documentation burden. A QSA reviewing a customised approach control will ask for the risk analysis methodology, the evidence that the control was designed against the stated objective, and the ongoing testing cadence. Inadequately documented customised controls fail faster than non-compliant defined approach controls, because the evidentiary bar is higher.
• 5
  Requirement 10.7.2 & 10.7.3 — Automated log failure detection and response

  V4.0 adds explicit requirements that failures of critical security controls — including log management systems — must be detected, alerted, and responded to promptly. Requirement 10.7.3 specifies that failures must be responded to in a timely manner and that the response must include restoring the security control and determining if the failure resulted in an exploitable vulnerability. The gap we encounter most often here is the detection piece: organisations run SIEM platforms that generate alerts for events within logs, but have no mechanism to detect when the logs themselves have stopped arriving. A log pipeline failure, a forwarding agent crash, or a retention gap creates a silent blind spot. The new requirement mandates that the absence of expected log data is itself an alerting condition, not merely an operational footnote.
• 6
  Requirement 3.3.3 — SAD retention prohibition for issuers now explicit

  Sensitive authentication data — full track data, CVV/CVC codes, and PINs — has always been prohibited from storage after authorisation for non-issuers. V4.0 explicitly extends and tightens the prohibition even for card issuers who may have legitimate reasons to retain SAD, requiring them to document their business justification, limit access on a strict need-to-know basis, and encrypt SAD at rest using strong cryptography. For organisations that are not issuers but have inherited systems from mergers or outsourcing transitions, this requirement routinely surfaces legacy data stores containing SAD that was never deleted. A data discovery scan covering all in-scope systems — including backup media, archived logs, and analytics data warehouses — is the necessary first step. Finding SAD in a location that wasn't expected is far better before the audit than during it.
• 7
  Requirement 12.3.3 — Annual review of all cryptographic cipher suites in use

  V4.0 requires that all cryptographic cipher suites and protocols in use are reviewed at least annually, that the review considers current vulnerabilities, and that a migration plan exists for any algorithms or protocols approaching end-of-life. This is a process requirement as much as a technical one. Most organisations have a one-time inventory of cipher suites done during their initial compliance effort, but no annual review cadence, no process for triggering a review when new cryptographic vulnerabilities are published (NIST post-quantum migration guidance, for instance), and no documented migration plan for legacy TLS 1.1 or RC4-based connections that may still exist in corner cases of the environment. The QSA will ask for the date of the last review, the methodology, and evidence that migration plans exist for any protocols on the NIST deprecated list.

The gap-analysis questions we run on every engagement

Before beginning any formal pre-assessment, our team works through the following questions with the client's security and compliance leads. These are the diagnostic checkpoints that most reliably surface the gaps described above.

An honest "no" or "I'm not sure" to any of these questions identifies a gap that should be remediated before the QSA engagement begins. Surfacing it during the audit rather than before it is the costlier path — a finding requires a formal remediation plan, may delay your Report on Compliance, and will be visible in your audit history.

Understanding the customised approach before you choose it

The customised approach is the most misunderstood addition in v4.0. It is not a relaxation of requirements. It is an alternative evidence pathway that carries a higher documentation burden in exchange for greater implementation flexibility.

The defined approach — the traditional compliance path — provides specific implementation guidance for each requirement. Meet the guidance, provide the evidence, get the finding. The customised approach requires the entity to define its own control, demonstrate that the control achieves the stated security objective of the requirement, conduct a targeted risk analysis, and subject the control to independent testing by the QSA.

If you are considering the customised approach for any requirement, the questions to answer before committing are: do you have the internal risk analysis methodology and documentation capability to support ongoing QSA scrutiny? Does your QSA have experience validating customised approach controls? Is the flexibility you gain worth the ongoing documentation overhead? For most of the clients we work with, the answer is to use the defined approach where possible and reserve the customised approach for the specific requirements where operational constraints make the defined approach genuinely unworkable.

The e-commerce scope expansion in detail

Requirements 6.4.3 and 11.6.1 deserve deeper attention because they represent a category of compliance work that most organisations have never had to do before — and because the attack pattern they address (Magecart-style script injection) is both common and consistently underestimated as a risk.

A Magecart attack compromises a payment page by injecting a malicious script — either directly into the merchant's environment or into a third-party script that the payment page loads. The injected script silently captures card data as it is typed and exfiltrates it. The merchant's payment processor sees a valid authorisation. The customer's card data is already in criminal hands. The merchant's own security logs show nothing unusual because the exfiltration happens in the browser, not on the server.

Requirement 6.4.3 addresses this by mandating that the merchant knows — exactly and completely — what scripts are running on their payment pages, that each one has a documented business justification, and that its integrity is protected (typically via Subresource Integrity hashes for scripts loaded from third-party CDNs, or a Content Security Policy that prevents unauthorised script execution).

Requirement 11.6.1 requires a mechanism that detects if the payment page has been modified and alerts within 24 hours. Options include commercial script monitoring solutions, server-side page hash comparison, or third-party managed services that specialise in payment page integrity monitoring.

The operational challenge is the breadth of the scope. If your checkout flow loads ten third-party scripts — Google Tag Manager, an analytics library, a live-chat widget, a fraud-scoring tool, a loyalty programme integration — all ten are in scope. Each needs to be in the authorised inventory. Each needs integrity protection. Any modification to any of them, including a vendor pushing an update to their CDN-hosted library, needs to be detectable within 24 hours.

How to prepare: a 90-day runway to a clean audit

1. 1
   Weeks 1–2: Scope confirmation and system inventory
   Confirm your CDE boundary under v4.0 scoping rules. The scope guidance in v4.0 is clearer than v3.2.1 about what constitutes connected, security-impacting, and in-scope components. Many organisations discover their scope is larger than they assumed, particularly where cloud-hosted systems share network segments with CDE components or where SaaS payment tools were previously considered out-of-scope. Run a sensitive data discovery scan across all in-scope and potentially in-scope systems, including backup media and analytics platforms.
2. 2
   Weeks 3–4: Gap assessment against the seven controls
   Work through the twelve diagnostic questions listed earlier for each of the seven high-risk requirements. For every gap identified, create a remediation task with an owner and a target date. Prioritise Requirements 8.4.2 (MFA for all CDE access) and 6.4.3/11.6.1 (payment page integrity) — these have the longest implementation lead times and are the requirements where commercial tooling may need to be procured, configured, and tested before the evidence is available for QSA review.
3. 3
   Weeks 5–10: Remediation execution
   Execute remediations in lead-time order, not priority order. The gap that takes eight weeks to fix should begin remediation before the gap that takes two weeks, regardless of relative risk. For payment page script management, build the authorised script inventory first, then implement integrity protection, then configure the tamper-detection alerting. Testing the detection mechanism — deliberately modifying a payment page in a test environment and verifying the alert fires — is required evidence. Schedule this test before the QSA engagement begins.
4. 4
   Weeks 11–12: Evidence package and pre-audit dry run
   Compile evidence for all remediated controls before the QSA engagement begins. For each requirement, the evidence should include the control description, the implementation date, test results confirming the control is functioning, and for any controls approaching the boundary of the defined approach, a pre-review with your QSA to confirm the evidence package is sufficient. A pre-audit dry run with your internal team — treating QSA interview questions as a rehearsal — consistently reduces audit duration and finding rates. The QSA process rewards organisations that know exactly where their evidence lives and can produce it without searching.

What happens if a finding is raised

A PCI DSS finding does not automatically mean a failed audit or a lapse in compliance status, but it does mean a formal remediation plan must be documented and accepted by your QSA before the Report on Compliance can be issued. The remediation plan must include the remediation steps, the responsible party, and the target date. Your QSA must validate that the remediation has been completed before closing the finding.

The practical consequence is delay. If a finding is raised against Requirement 6.4.3 because your payment page script inventory is incomplete, the audit cannot close until the inventory is complete and tested. If your QSA engagement has a fixed timeline tied to a contract renewal or a merchant agreement deadline, a finding discovered during the audit — rather than before it — is a material business risk, not merely an administrative inconvenience.

This is why the pre-audit gap assessment matters. A finding in an internal pre-assessment closes with a remediation task and no QSA involvement. A finding in a formal QSA engagement closes with a documented remediation plan, a follow-up validation visit, and an entry in your audit history.

Closing

PCI DSS v4.0 is a more demanding standard than its predecessor — more precise about authentication, more explicit about e-commerce attack surfaces, and more rigorous about the evidence required to demonstrate ongoing compliance. The organisations that navigate it most smoothly are those that treat the gap assessment as the starting point rather than the audit itself as the starting point.

If your next QSA engagement is within the next six months and you have not yet run a v4.0 gap assessment, the seven controls above are the highest-priority starting point. The diagnostic questions in the terminal block are the fastest way to identify whether you have work to do before the QSA arrives.

Star Informatix runs PCI DSS v4.0 pre-assessment engagements for merchants, service providers, and financial institutions across South Asia and the Gulf. If you would like a structured assessment before your next QSA engagement, contact us at hello@starinformatix.com or book a consultation directly.