PCI DSS GCC Compliance Guide 2026 | MENA Cyber Wire

What is PCI DSS and who does it apply to in the GCC
Why PCI DSS matters beyond the compliance checkbox
The GCC payment landscape driving compliance urgency
Understanding the PCI DSS merchant levels
The 12 core requirements of PCI DSS v4.0 explained
How a PCI DSS assessment works in practice
The most common PCI DSS failures in GCC organisations
PCI DSS and the broader GCC regulatory environment
What to demand from a PCI QSA before you engage one

What is PCI DSS and who does it apply to in the GCC

The Payment Card Industry Data Security Standard, universally referred to as PCI DSS, is a set of security requirements developed and maintained by the Payment Card Industry Security Standards Council (PCI SSC), the body founded by American Express, Discover, JCB, Mastercard, and Visa to establish a unified security baseline for organisations that handle payment card data.

PCI DSS applies to any organisation that processes, stores, or transmits cardholder data. The scope of that definition is broader than most organisations initially appreciate. It covers not only the banks and payment processors that sit at the centre of the payment ecosystem, but also the merchants that accept card payments, the technology providers that build payment systems, the service providers that host payment infrastructure, and the software vendors whose applications interact with payment data in any form. In the GCC context, this means the standard applies to retail chains, e-commerce platforms, hospitality groups, healthcare providers accepting card payments, government entities with online payment portals, and the fintech companies that are reshaping payments across the region.

Compliance is contractually enforced through the card brands. Organisations that accept Visa, Mastercard, or other card network payments are bound by their merchant agreements to maintain PCI DSS compliance. Non-compliance does not primarily result in regulatory fines, though those can follow in regulated sectors. It results in financial penalties from the card brands, potential loss of the ability to process card payments, and significantly increased liability exposure in the event of a breach involving cardholder data.

$10.9Bvalue of digital payment transactions in the UAE in 2025, making PCI DSS compliance a commercial imperative for any business in the payment chain

300%increase in payment fraud incidents targeting GCC merchants and fintech platforms between 2022 and 2025

v4.0the current version of PCI DSS, which introduced significant new requirements around authentication, risk analysis, and targeted risk assessments that many GCC organisations are still working to implement

Why PCI DSS matters beyond the compliance checkbox

The instinct to treat PCI DSS as a contractual obligation to be satisfied and forgotten is understandable, but it consistently produces compliance programmes that fail both the auditor's intent and the organisation's actual security needs. PCI DSS is better understood as a minimum baseline security standard for payment environments that, when implemented properly, addresses the most commonly exploited vulnerabilities in payment infrastructure.

The requirements covering network segmentation, access control, encryption, vulnerability management, and monitoring are not bureaucratic impositions. They reflect the accumulated learning of two decades of payment card breaches and the attack patterns that have proven most effective against insufficiently secured payment environments. Organisations that implement PCI DSS controls with genuine security intent, rather than as a paper exercise, consistently experience lower rates of payment fraud, smaller breach impacts when incidents occur, and stronger negotiating positions with acquiring banks and payment processors.

For GCC enterprises operating in the fintech, e-commerce, and digital payments sectors, PCI DSS compliance has also become a commercial differentiator. Enterprise clients, government procurement processes, and international partners increasingly require evidence of PCI DSS certification as a condition of doing business. A valid Report on Compliance (ROC) or Self-Assessment Questionnaire (SAQ) from a certified assessor is a commercially meaningful credential in a market where payment security has become a board-level concern.

"We had a potential enterprise client in the financial sector walk away from a contract because we could not produce a current PCI DSS certification. The compliance programme that felt like overhead became a revenue-critical capability the moment we lost that deal." - Chief Technology Officer, UAE fintech platform

The GCC payment landscape driving compliance urgency

Several structural characteristics of the GCC payment landscape have elevated PCI DSS compliance from a background obligation to an urgent operational priority for enterprises across the region.

The UAE's position as a regional hub for fintech innovation has produced a dense ecosystem of payment service providers, digital wallets, buy-now-pay-later platforms, and payment gateway operators, each of which sits within the PCI DSS scope by virtue of their role in the payment chain. The UAE Central Bank's licensing framework for payment service providers has tightened significantly in recent years, and CBUAE supervisory expectations increasingly incorporate PCI DSS compliance as an implicit requirement for licensed entities processing card payments.

Saudi Arabia's Vision 2030 digital economy agenda has driven extraordinary growth in e-commerce and digital payments, with the Saudi Payments Company (mada) overseeing a domestic payments infrastructure that connects to international card networks. SAMA's regulatory framework for payment service providers in the Kingdom references PCI DSS compliance explicitly, and the NCA's Essential Cybersecurity Controls create additional security obligations that overlap substantially with PCI DSS requirements for entities in the payment sector.

Across both markets, the growth of omnichannel retail, the expansion of contactless payments, and the emergence of embedded finance in non-financial applications have all expanded the population of organisations that handle cardholder data without necessarily recognising that PCI DSS applies to them. Merchants who outsource their payment processing to a compliant provider but retain access to transaction data, retailers who store card numbers in their CRM for customer service purposes, and hospitality groups who take card details over the phone for reservations are all within PCI DSS scope, regardless of whether their compliance programmes reflect that reality.

Understanding the PCI DSS merchant levels

Level 1 - Over 6M transactions/year

Requires an annual on-site audit conducted by a certified Qualified Security Assessor (QSA) and a quarterly network scan by an Approved Scanning Vendor (ASV). The highest scrutiny level with the most stringent assessment requirements.

Level 2 - 1M to 6M transactions/year

Annual Self-Assessment Questionnaire (SAQ) completed by an internal security team or QSA, plus quarterly ASV scans. Some card brands require Level 2 merchants to use a QSA rather than self-assessing.

Level 3 - 20,000 to 1M e-commerce transactions/year

Annual SAQ and quarterly ASV scans. Level 3 applies specifically to merchants whose transactions occur predominantly through e-commerce channels, making it directly relevant to GCC online retail.

Level 4 - Under 20,000 e-commerce or up to 1M other transactions/year

Annual SAQ recommended and ASV scans where applicable. Level 4 covers the largest population of GCC merchants by number, including most SMEs and smaller digital businesses that accept card payments.

The 12 core requirements of PCI DSS v4.0 explained

Requirement 01 - Install and maintain network security controls

Firewalls, network access controls, and segmentation controls that isolate the cardholder data environment (CDE) from other network segments and from the internet. Network segmentation is one of the most impactful PCI DSS controls, as it limits the scope of the compliance assessment and reduces the attack surface for any breach targeting payment data.

Requirement 02 - Apply secure configurations to all system components

Eliminating default credentials, removing unnecessary services and protocols, and applying hardening standards to all systems within the CDE. Default username and password combinations remain among the most commonly exploited vulnerabilities in payment infrastructure globally, including in GCC deployments.

Requirement 03 - Protect stored account data

Governing what cardholder data can be stored, for how long, and in what form. PCI DSS prohibits storing sensitive authentication data after authorisation and requires that Primary Account Numbers (PANs) stored for legitimate business purposes are rendered unreadable through strong encryption, hashing, truncation, or tokenisation.

Requirement 04 - Protect cardholder data with strong cryptography during transmission

Ensuring that cardholder data transmitted over open, public networks is protected with strong cryptographic protocols. TLS 1.2 or higher is required for all transmission of PAN over public networks, and organisations must maintain an inventory of all trusted keys and certificates used to protect transmission.

Requirement 05 - Protect all systems against malware

Deploying anti-malware solutions on all systems commonly affected by malware and ensuring those solutions are kept current and actively running. PCI DSS v4.0 expanded this requirement to include periodic evaluations of systems not commonly targeted by malware, requiring documented risk assessments to justify any exclusions.

Requirement 06 - Develop and maintain secure systems and software

Establishing a vulnerability management programme that addresses security vulnerabilities in a timely manner, developing software following secure development practices, and protecting public-facing web applications against known attack types. PCI DSS v4.0 introduced stronger requirements around web application firewalls and automated technical solutions for detecting and preventing web-based attacks against payment pages.

Requirement 07 - Restrict access to system components and cardholder data by business need to know

Implementing access control systems that grant access to the cardholder data environment only to individuals whose job functions require it. Access control must be deny-by-default, and access must be explicitly granted based on documented business justification. Quarterly access reviews are required to identify and remove unnecessary or inappropriate access rights.

Requirement 08 - Identify users and authenticate access to system components

Ensuring that all users accessing the CDE are uniquely identified and authenticated. PCI DSS v4.0 strengthened authentication requirements significantly, mandating multi-factor authentication for all access to the CDE, not just remote access, and introducing minimum password complexity and rotation requirements that are more stringent than the previous version.

Requirement 09 - Restrict physical access to cardholder data

Controlling physical access to systems that store, process, or transmit cardholder data, including data centres, server rooms, and point-of-sale terminals. Physical security controls include access logs, visitor management, media destruction procedures, and protection of point-of-interaction devices against tampering or substitution.

Requirement 10 - Log and monitor all access to system components and cardholder data

Implementing audit logging across all CDE systems and retaining logs for at least 12 months, with a minimum of three months immediately available for analysis. Logs must capture sufficient detail to reconstruct events, and automated log review mechanisms must be in place to identify anomalies and suspicious activity in real time.

Requirement 11 - Test security of systems and networks regularly

Conducting regular vulnerability scans, penetration testing, and intrusion detection monitoring across the CDE. PCI DSS requires both internal and external vulnerability scans quarterly, annual penetration testing that tests for the ability to reach the CDE from both internal and external positions, and change-triggered testing when significant changes are made to the environment.

Requirement 12 - Support information security with organisational policies and programmes

Establishing and maintaining an information security policy, security awareness training for all personnel, and a formal risk management programme. PCI DSS v4.0 introduced targeted risk assessment requirements that must be completed at defined intervals and whenever significant changes occur, replacing the more prescriptive approach of earlier versions with a risk-based model that allows organisations to tailor controls to their specific environment.

How a PCI DSS assessment works in practice

Phase 01 - Scoping

Defining the cardholder data environment, all systems that store, process, or transmit cardholder data, and all systems connected to or that could impact the security of the CDE. Scoping is the most consequential phase of a PCI DSS assessment. An overly broad scope inflates the compliance effort substantially. An incorrectly narrow scope creates compliance gaps and invalidates the assessment. Network segmentation controls that effectively isolate the CDE from other systems can dramatically reduce scope when properly implemented and tested.

Phase 02 - Gap assessment

Evaluating the current state of controls against each applicable PCI DSS requirement to identify gaps that must be remediated before the compliance assessment. A gap assessment produces a prioritised remediation roadmap that sequences effort by risk and by the dependencies between requirements. Organisations that proceed directly to a compliance assessment without a gap assessment frequently discover significant deficiencies at the worst possible time.

Phase 03 - Remediation

Implementing the controls and addressing the gaps identified during the gap assessment. Remediation typically involves technical work such as deploying network segmentation, implementing encryption, strengthening authentication controls, and establishing log management, alongside process and policy work to document procedures, establish training programmes, and implement governance mechanisms that sustain compliance over time.

Phase 04 - Formal assessment

For Level 1 merchants and service providers, a formal on-site assessment conducted by a certified Qualified Security Assessor. The QSA reviews documentation, interviews personnel, observes processes, and tests controls across all 12 requirement areas. The output is a Report on Compliance (ROC) that attests to the organisation's compliance status and identifies any exceptions or areas of non-compliance that require management attention.

Phase 05 - Self-assessment for lower levels

For Level 2, 3, and 4 merchants, a Self-Assessment Questionnaire completed by the organisation, sometimes with QSA assistance. Different SAQ types apply to different payment acceptance methods, and selecting the correct SAQ is itself a scoping exercise. SAQ D covers the broadest scope and applies to merchants and service providers that do not qualify for a more limited questionnaire type.

Phase 06 - Sustained compliance

PCI DSS compliance is an annual obligation, not a one-time achievement. Sustaining compliance requires ongoing vulnerability scanning, log monitoring, access reviews, security awareness training, and change management processes that ensure new systems and processes introduced during the year do not introduce compliance gaps. PCI DSS v4.0's customised approach allows organisations to define targeted risk analyses that justify controls tailored to their specific environment rather than defaulting to prescriptive requirements.

The most common PCI DSS failures in GCC organisations

Failure 01 - Underestimating the scope of the cardholder data environment

Organisations frequently define their CDE too narrowly, excluding systems that technically fall within scope because they are connected to or can impact the security of in-scope systems. A common example is the corporate email server that receives payment card dispute correspondence, or the CRM system that stores full PANs for customer service purposes. Incorrect scoping invalidates the entire compliance assessment and creates undisclosed liability that the organisation has simply chosen not to look at.

Failure 02 - Treating compliance as a point-in-time exercise

Organisations that mobilise a compliance effort ahead of their annual assessment, achieve a passing result, and then allow controls to drift until the next assessment cycle are not maintaining PCI DSS compliance. They are documenting it annually. Breaches attributable to lapses in PCI DSS controls between assessment cycles are the organisation's liability regardless of their most recent certification status, and acquirers increasingly scrutinise the sustainability of compliance programmes rather than simply accepting annual attestations.

Failure 03 - Inadequate network segmentation

Network segmentation between the CDE and other network segments is one of the most impactful PCI DSS controls and one of the most commonly implemented incorrectly. Firewalls that are in place but insufficiently restrictive, network segments that are nominally separated but connected through undocumented pathways, and flat network architectures where the CDE is technically isolated but reachable from general corporate systems all represent segmentation failures that expand both the compliance scope and the attack surface simultaneously.

Failure 04 - Misunderstanding third-party service provider responsibilities

Outsourcing payment processing to a PCI DSS-compliant provider does not transfer all compliance obligations to that provider. Organisations retain responsibility for the controls they manage, the access they provide to their systems, and the data flows that exist between their environment and the service provider's. Many GCC merchants operate under the mistaken belief that using a compliant payment gateway exempts them from PCI DSS requirements, which is only partially true and depends entirely on whether any cardholder data flows through or resides in systems the merchant controls.

Failure 05 - Failing to address PCI DSS v4.0 new requirements

PCI DSS v4.0, which became the only active version of the standard in March 2024, introduced a set of new requirements that were initially designated as best practices but became mandatory from March 2025. Organisations that achieved compliance under PCI DSS v3.2.1 and assumed their controls carried over directly have frequently discovered that the v4.0 requirements around targeted risk assessments, payment page script management, and phishing-resistant authentication represent genuine gaps in their compliance programmes.

Failure 06 - Engaging unqualified assessors

The PCI DSS assessment market in the GCC includes providers who offer compliance consulting, gap assessments, and SAQ assistance without holding the Qualified Security Assessor certification that is required to conduct a formal Level 1 ROC assessment. Using an unqualified provider to complete a compliance assessment produces documentation that the card brands do not recognise and that provides no protection against financial penalties in the event of a breach. Organisations requiring a formal ROC must verify that the provider is listed on the PCI SSC's current register of approved QSA companies.

PCI DSS and the broader GCC regulatory environment

PCI DSS exists within a regulatory environment that has become significantly more complex for GCC enterprises over the past three years. Understanding how PCI DSS relates to other applicable frameworks is essential for building an efficient compliance programme that does not duplicate effort across overlapping requirements.

The UAE PDPL creates data protection obligations that apply to cardholder data as personal data. Where PCI DSS governs the security of payment card data specifically, the PDPL governs the processing of personal data more broadly. Organisations that process payment card data are likely to be processing personal data simultaneously, which means both frameworks apply and their requirements must be managed in an integrated way. The 72-hour breach notification requirement under the PDPL, for example, applies in addition to the breach notification obligations that arise under card brand rules and merchant agreements.

For GCC financial institutions subject to SAMA's Cybersecurity Framework, the overlap between SAMA controls and PCI DSS requirements is substantial. A compliance programme that maps controls across both frameworks simultaneously, identifying where a single control satisfies both sets of requirements, delivers significantly better efficiency than separate compliance workstreams managed in isolation. Similarly, organisations pursuing ISO 27001 certification will find that a well-implemented PCI DSS programme satisfies many of the information security management requirements that ISO 27001 addresses, reducing the incremental effort required for certification.

Organisations in the GCC that approach PCI DSS as one component of an integrated compliance programme, rather than as a standalone obligation, typically reduce their total compliance investment by 30 to 40 percent compared to those managing each framework separately. The efficiency gain comes from building a unified control framework that satisfies multiple requirements simultaneously rather than maintaining separate evidence bases for each standard.

What to demand from a PCI QSA before you engage one

Verified QSA certification listed on the PCI SSC register
The PCI Security Standards Council maintains a public register of all currently approved Qualified Security Assessor companies. Before engaging any provider for a formal Level 1 assessment or ROC, verify that the company and the specific QSA individual assigned to the engagement appear on this register. QSA certifications must be renewed annually, and providers whose certificates have lapsed are not authorised to issue valid ROC documentation. This is a non-negotiable verification step that takes minutes and prevents engagement with unqualified providers.
Demonstrated experience in your specific payment environment
PCI DSS assessments for a Level 1 e-commerce platform look fundamentally different from assessments for a hospitality group with distributed point-of-sale infrastructure, a fintech platform with cloud-native payment processing, or a service provider operating as a payment gateway. QSAs whose reference experience does not match your payment acceptance model will miss environment-specific risks and produce assessments that are technically compliant but practically incomplete. Ask for specific examples of completed assessments in comparable environments before engaging.
Genuine PCI DSS v4.0 expertise including new requirements
PCI DSS v4.0 introduced significant changes to authentication requirements, targeted risk assessment methodologies, payment page security, and the customised approach that allows organisations to demonstrate compliance through alternative controls. QSAs who are not current on v4.0 requirements will produce assessments that miss newly mandatory controls and fail to advise on the customised approach options that could reduce compliance burden for organisations with mature security programmes. Verify specific v4.0 experience, not just general PCI DSS familiarity.
GCC regulatory integration across PDPL, SAMA, and CBUAE
PCI DSS assessments conducted without reference to the GCC regulatory context in which the organisation operates will produce compliance programmes that satisfy the card brands but leave gaps against local regulatory obligations. QSAs with genuine knowledge of UAE PDPL, SAMA Cybersecurity Framework, CBUAE payment service provider guidelines, and NCA ECC can design compliance programmes that satisfy multiple frameworks simultaneously, reducing total compliance cost and producing integrated evidence that serves all applicable regulatory obligations.
Scoping expertise that genuinely reduces your compliance burden
The most impactful contribution a skilled QSA makes is often not in the assessment itself but in the scoping work that precedes it. A QSA who understands how to apply network segmentation, tokenisation, and point-to-point encryption to minimise the scope of the CDE can reduce both the compliance effort and the ongoing maintenance burden substantially. Ask prospective QSAs to describe how they approach scope reduction and what options they would explore for your specific payment environment before committing to an assessment engagement.

For GCC enterprises navigating the intersection of rapid digital payment adoption, tightening regulatory oversight, and a threat environment in which payment data remains among the most sought-after targets, PCI DSS compliance is no longer a background obligation managed by the finance team's IT contact. It is a business-critical programme that determines the organisation's ability to participate in the digital economy, its exposure in the event of a breach, and its standing with the acquiring banks, payment networks, and enterprise clients whose requirements it must satisfy. The organisations that invest in genuine compliance programmes, led by qualified assessors with regional expertise, are the ones that turn a regulatory requirement into a competitive credential.