PCI DSS v4.0.1 Changes — Mandatory Requirements for 2026

Why PCI DSS v4.0.1 Matters for KSA and GCC Enterprises

The Payment Card Industry Data Security Standard (PCI DSS) version 4.0 was originally released in March 2022, with a transition period allowing organizations to comply with either v3.2.1 or v4.0. That transition ends on March 31, 2024 for some requirements, but the most significant new mandates — those designated as "future-dated" — become mandatory on March 31, 2026. PCI DSS v4.0.1, published in June 2024, is a minor update that clarifies and corrects language in v4.0 without introducing new requirements. However, the 2026 deadline for v4.0's original future-dated requirements remains unchanged.

For Saudi Arabia in particular, the convergence of PCI DSS v4.0.1 mandatory requirements with the NCA ECC version 2.0 and SAMA CSF version 2.0 creates a compliance landscape where payment security controls must simultaneously satisfy multiple frameworks. Saudi financial institutions, fintech companies operating under SAMA's Sandbox or full licensing, and e-commerce platforms expanding under Vision 2030's digital economy pillars all face heightened scrutiny. Non-compliance with PCI DSS can result in fines, increased transaction fees, or loss of card-accepting privileges — consequences that carry additional reputational weight in the GCC's tightly regulated financial ecosystem.

Organizations should view the transition to PCI DSS v4.0.1 mandatory requirements not merely as a checkbox exercise but as an opportunity to strengthen their overall security architecture. The standard's shift from a prescriptive, one-size-fits-all model toward a more risk-based, customized approach aligns well with the principles of the NCA ECC and SAMA CSF, both of which emphasize continuous risk assessment and tailored controls.

The Most Critical PCI DSS v4.0.1 Changes Mandatory in 2026

PCI DSS v4.0.1 retains all the future-dated requirements from v4.0. Below is a detailed breakdown of each mandatory change, with direct implications for Saudi and GCC organizations.

Requirement 3.3.1 — Targeted Risk Analysis for All Requirements

Perhaps the most conceptually significant change in PCI DSS v4.0.1 changes is the mandatory targeted risk analysis. Starting March 31, 2026, organizations must document a formal targeted risk analysis for each PCI DSS requirement. This means you can no longer simply implement a control because "the standard says so." You must demonstrate that you have assessed the specific risks to your cardholder data environment (CDE) and determined that the control you implemented is appropriate for your risk profile.

For example, Requirement 9.5.1 (physical security for POI devices) will require a targeted risk analysis justifying the frequency of device inspections. In practice, this shifts compliance from a checklist mentality to a risk management exercise — a move that aligns with how the NCA ECC already mandates risk-based control selection. Organizations that have not embedded formal risk analysis processes into their compliance workflows will need to develop them before 2026.

Requirement 8.4.2 — Multi-Factor Authentication (MFA) for All Access

Under PCI DSS v3.2.1, MFA was required only for remote network access originating from outside the CDE and for non-console administrative access within the CDE. Starting in 2026, PCI DSS v4.0.1 changes expand MFA to cover all access to the CDE — including local console administrative access and any user access from within the organization's internal network.

This is a significant expansion. For a typical Saudi bank or fintech, this means every administrator logging into a server console, every database administrator accessing production cardholder data, and every DevOps engineer deploying code to the CDE must authenticate using MFA. The requirement does not mandate a specific MFA technology, but it must be phishing-resistant where the authentication mechanism involves a shared secret. Implementation challenges in the GCC include managing MFA for a distributed workforce and integrating legacy systems that lack native MFA support. CyberSilo's Compliance Standards Automation can map this requirement across your asset inventory and flag non-compliant systems for remediation.

Requirement 6.4.3 — E-commerce Payment Script Integrity

This new requirement addresses the growing threat of web skimming (Magecart-style attacks) by mandating that organizations that accept payment via e-commerce web pages must maintain a script integrity program. Specifically, the requirement covers:

• Managing all payment page scripts — including those loaded from third-party providers — through a documented inventory and change control process.
• Implementing a method to detect and alert on unauthorized modifications to payment page scripts.
• Ensuring that scripts are loaded directly by the merchant's server or are integrity-checked using Subresource Integrity (SRI) or equivalent controls.

For Saudi e-commerce platforms and retail organizations, this requirement is particularly relevant given the rapid growth of online payments under Vision 2030's digital transformation. If your payment page loads a third-party JavaScript for analytics, personalization, or payment tokenization, that script becomes in scope. You must be able to prove that it has not been tampered with. This will require collaboration between your security, web development, and third-party vendor management teams.

Requirement 10.7.2 — Automated Time Synchronization for All Systems

While log management has always been central to PCI DSS, this new requirement explicitly mandates that all systems within the CDE must have their clocks synchronized using an automated, centralized time synchronization mechanism (e.g., NTP). The critical change is that this requirement applies to all devices with logs, not just network security devices and servers. In practice, this means printers, IoT monitoring devices, and even building access controllers within the physical CDE must be synchronized to a central time source.

In large Saudi enterprises with sprawling IT/OT environments, this can be surprisingly complex. Organizations should begin auditing all connected devices in their CDE to ensure time synchronization is enabled and verified.

Requirement 11.6.1 — Additional Detection for Unauthorized Changes

PCI DSS has long required file integrity monitoring (FIM) on critical system files. The 2026 change broadens this to require a change-detection mechanism (which could be FIM or an equivalent compensating control) on all files in the CDE — not just system files. Additionally, the mechanism must alert personnel to unauthorized modifications in near real-time, not just during daily or weekly scans.

This aligns with the threat of ransomware and destructive attacks that modify non-system files such as application code, configuration files, and even data files. For organizations using containerized microservices, this requirement becomes especially challenging and may necessitate agentless detection solutions that can keep up with ephemeral workloads.

Requirement 12.4.1 — Board-Level Oversight

A significant governance change: by 2026, organizations must have board-level (or equivalent senior management) review and approval of the annual PCI DSS compliance program. The requirement explicitly states that executive management must:

• Review the overall compliance status at least annually.
• Acknowledge responsibility for the entity's PCI DSS compliance.
• Approve the risk assessment and remediation plan.

For Saudi organizations subject to NCA ECC governance requirements, this dovetails with existing mandates for board-level cybersecurity oversight. CISOs should prepare board-ready summary materials that connect PCI DSS compliance to broader enterprise risk management and Vision 2030 digital trust objectives.

Requirement 12.5.2 — Annual Security Awareness Training for All Personnel

While security awareness training has been required previously, the 2026 update mandates that training must be specific to the organization's security posture and risk profile, and that it must cover the evolving threat landscape. Additionally, organizations must assess the effectiveness of the training — not merely attendance. This means testing employees on their ability to identify phishing attempts, social engineering, and secure handling of cardholder data.

KSA-based organizations can leverage this requirement to integrate PCI DSS awareness into their broader NCA ECC-aligned security training programs, avoiding duplication of effort.

The Customized Approach vs. Defined Approach

PCI DSS v4.0.1 changes formally introduce two pathways to compliance: the "defined approach" and the "customized approach." The defined approach provides prescriptive, step-by-step control requirements — this is what most organizations have used historically. The customized approach allows an organization to meet the intent of a requirement through a different technical implementation, provided a targeted risk analysis demonstrates that the alternative control is equally effective.

The customized approach offers flexibility for organizations with mature security programs, particularly those in the GCC that must also comply with NCA ECC or SAMA CSF controls. For example, if your organization has implemented a zero-trust architecture with continuous authentication and micro-segmentation, you may choose to customize your response to certain network segmentation requirements rather than adhering to the traditional DMZ-based approach. However, the customized approach demands more rigorous documentation and justification. CyberSilo's Compliance Standards Automation platform can manage the mapping, risk analysis, and evidence repository required for either approach.

How to Prepare for PCI DSS v4.0.1 Mandatory Requirements in 2026

The transition to PCI DSS v4.0.1 changes requires a structured program, not a one-time project. Saudi and GCC organizations should begin the following activities now.

1. Conduct a Requirements Gap Analysis

Identify every future-dated requirement in PCI DSS v4.0.1 that your organization does not currently satisfy. This is the foundation of your remediation plan. Pay special attention to:

• MFA expansion (Requirement 8.4.2)
• E-commerce script integrity (Requirement 6.4.3)
• Targeted risk analysis documentation (across all requirements)
• Change detection on all CDE files (Requirement 11.6.1)
• Board-level oversight (Requirement 12.4.1)

2. Deploy a Compliance Automation Platform

Manual compliance management at the scale required by PCI DSS v4.0.1 is unsustainable, especially for enterprises managing multiple regulatory frameworks. A compliance automation platform provides continuous control monitoring, evidence collection, and gap reporting. For Saudi enterprises managing SAMA CSF, NCA ECC, and PDPL alongside PCI DSS, automation is the only practical path to sustainable compliance. CyberSilo's Compliance Standards Automation platform maps controls across frameworks, automates evidence collection from your existing security tools, and provides dashboards that satisfy both internal governance and QSA requirements.

3. Engage a Qualified Security Assessor (QSA) Early

Work with your QSA to understand their interpretation of the customized approach and targeted risk analysis expectations. Early engagement allows you to align your implementation with the assessor's methodology, reducing surprises during the formal assessment. Given the limited number of QSAs actively servicing the GCC market, early booking is essential.

4. Implement a Script Integrity Program for E-commerce

If your organization accepts card payments via a website or mobile app, begin auditing all third-party scripts loaded on payment pages. Establish a change control process that requires security review for any script addition or modification. Evaluate technical controls such as Content Security Policy (CSP) directives, Subresource Integrity (SRI) tags, and real-time script behavior monitoring tools.

5. Strengthen Governance and Board-Level Reporting

Develop a board-level PCI DSS dashboard that communicates compliance posture, risk levels, and remediation progress. This dashboard should be reviewed at least annually and should demonstrate executive responsibility for the compliance program. Align this dashboard with your existing NCA ECC and SAMA CSF board reporting to present a unified governance picture.

Common Misunderstandings About PCI DSS v4.0.1

Several misconceptions about PCI DSS v4.0.1 changes persist in the market. Clarifying these now can save your organization significant wasted effort.

"PCI DSS v4.0.1 is a new version with new requirements." No. PCI DSS v4.0.1 is a clarification and editorial update to v4.0. It does not introduce new requirements beyond those already present in v4.0. All future-dated requirements originally published in v4.0 remain on schedule for March 31, 2026.

"The customized approach is optional." Yes, but the targeted risk analysis that underpins it is not optional. Even organizations following the defined approach must perform targeted risk analyses for each requirement. The option is whether you use those analyses to justify a customized control or simply to document your rationale for following the defined approach.

"Only e-commerce merchants need to worry about script integrity." Incorrect. If your organization maintains any payment page — including a mobile app, a kiosk, or a customer-facing portal — the script integrity requirement applies. This includes scenarios where a third-party payment processor hosts the payment form on your domain.

Frequently Asked Questions

When do the PCI DSS v4.0.1 mandatory requirements take effect?

All future-dated requirements in PCI DSS v4.0.1 become mandatory on March 31, 2026. Until that date, organizations may continue using PCI DSS v3.2.1 controls for those specific requirements, but must have the v4.0.1 controls fully implemented by March 31, 2026.

What is the customized approach in PCI DSS v4.0.1?

The customized approach allows an organization to meet the intent of a control requirement through a different technical implementation, provided a formal targeted risk analysis demonstrates equivalent effectiveness. It offers flexibility for organizations with complex environments or overlapping regulatory obligations, such as those subject to SAMA CSF or NCA ECC.

Does PCI DSS v4.0.1 require MFA for all access or only remote access?

Starting March 31, 2026, Requirement 8.4.2 mandates MFA for all access to the cardholder data environment, including local console administrative access and internal network user access. Previously, MFA was only required for remote network access and non-console administrative access.

How should Saudi merchants prepare for the e-commerce script integrity requirement?

Begin by creating an inventory of all third-party scripts loaded on any page that accepts payment card data. Implement Subresource Integrity (SRI) tags where possible, deploy Content Security Policy (CSP) headers that restrict script sources, and establish a change management process requiring security approval before any payment page script is added, modified, or removed. Consider deploying a real-time web application firewall with script behavior monitoring.

Do the targeted risk analyses need to be created from scratch?

Not necessarily. Organizations that have already performed risk assessments under standards such as NCA ECC or SAMA CSF can leverage those existing risk analyses as a starting point. The key is ensuring that each PCI DSS control requirement is explicitly addressed in a documented risk analysis. CyberSilo's Compliance Standards Automation can map your existing risk registers to PCI DSS v4.0.1 requirements, reducing duplication.