We value your privacy

We use cookies to analyse site traffic and improve your experience. You can accept all cookies or reject non-essential ones. See our Privacy Policy for details.

GR IT SERVICES
  • Contact
Get a quote
  2. Audit and compliance
  3. PCI DSS
PCI DSS compliance, UAE

PCI DSS: the cheapest compliance is the data you never store.

Most UAE merchants we assess are paying to protect cardholder data they had no business keeping. Scope reduction is the single largest lever in PCI DSS, and it is the one consultants skip because it shrinks the engagement. We start there, then work through what genuinely remains in scope.

Book a PCI scope reviewSee what applies to you
PCI DSS compliance and scope reduction for UAE merchants
  • v4.0.1The version assessments run against
  • 51 requirementsFuture-dated, effective 31 March 2025
  • Scope firstReduce before you protect
  • Not a QSAWe prepare, a QSA assesses
What PCI DSS work actually involves

Eight areas, and the first one decides the cost of the other seven.

PCI DSS is unusual among compliance frameworks in that the amount of work is almost entirely within your control. Everything in the standard applies to your cardholder data environment, so the size of that environment is the variable that matters, and most organisations have never seriously tried to shrink it.

Scope definition, and then scope reduction

Everything that stores, processes or transmits cardholder data is in scope, along with anything connected to it that could affect its security. Most merchants discover their scope is larger than assumed, usually through a call recording system, a shared network segment, a spreadsheet somebody made, or a support mailbox that receives card numbers. Finding these is unglamorous and it is worth more than any control you could buy.

Getting card data out of places it should not be

The single most valuable thing we do on these engagements. Card numbers sitting in email archives, in CRM free-text fields, in call recordings, in scanned forms on a file share, in a legacy database nobody has opened in years. Each one drags a system into scope. Removing them and stopping the process that put them there is cheaper than protecting them, permanently, forever.

Working out which validation route applies to you

Your obligations depend on your merchant or service provider level and how you accept payments, which determines whether you complete a self-assessment questionnaire and which one, or require an assessment by a qualified assessor. Getting this wrong wastes money in one direction and creates exposure in the other. Your acquiring bank is the authority on what it requires, and we help you ask them the right question.

Network segmentation that actually holds

Segmentation is how you keep the rest of your business out of scope, and it is only effective if it is real. That means the controls are enforced, documented, and tested rather than assumed because two systems are on different subnets. Where segmentation is claimed, it has to be validated, and a failed segmentation test expands your scope retroactively in a way that is expensive and awkward.

The technical control set, applied to what remains

Once scope is honest, the controls follow: access control on need-to-know, multi-factor authentication into the cardholder data environment, encryption in transit and at rest, logging and monitoring with actual review, vulnerability management, secure configuration, and change control. None of this is exotic. What makes it hard is applying it consistently to a live payment environment without breaking trade.

The future-dated requirements that are now live

Version 4.0 introduced 64 new requirements, of which the Council confirmed 51 were future-dated and effective from 31 March 2025. That date has passed, so these are simply requirements now. Organisations that assessed early against the transitional position and have not revisited it since are frequently non-compliant against requirements they were told they had time to prepare for.

Third parties, because most breaches arrive through them

Your payment gateway, your hosting provider, your point of sale vendor, your call centre. You need to know which of them are in scope, hold evidence of their compliance status, and have written agreements covering their responsibilities for cardholder data. This is a requirement, and independently it is the area where merchant compromises most often originate.

Evidence, and keeping it true between assessments

PCI DSS is a point-in-time validation of a set of controls that are meant to run continuously, and the gap between those two things is where organisations fail. Quarterly scans, periodic reviews, access recertification, log review, testing. We keep these running through the year, because assembling twelve months of evidence in the fortnight before an assessment does not work and everyone involved knows it.

The conversation nobody wants to have first

Ask why you are storing card numbers at all before you protect them.

This is the part of a PCI engagement that saves the most money and gets proposed the least, because it makes the engagement smaller. We would rather have a smaller engagement and a client who stays.

  • Most UAE merchants storing cardholder data cannot articulate why. The usual answers are that the system does it by default, that somebody wanted it for refunds years ago, or that nobody has ever asked. None of those justify the cost of protecting it, and refunds in particular are usually handled by your gateway with a token rather than a card number.
  • Tokenisation and a hosted or redirected payment page move most of the burden to your provider. If cardholder data never touches your systems, most of the standard falls away and your validation route becomes dramatically simpler. This is not a loophole, it is the design the payment industry intends, and it is available to almost every merchant.
  • The hidden scope is rarely in the payment system. It is in the call recordings that captured a customer reading a card number aloud, the support mailbox where somebody sent one, the CRM note a salesperson typed, the scanned authorisation forms on a shared drive. We go looking for these specifically, because each one silently pulls another system into scope.
  • A realistic outcome for a mid-sized UAE merchant is moving from an environment that needs substantial protection to one where card data barely exists in your estate. That changes the annual cost of compliance permanently, not just for this assessment cycle, and it also removes the thing an attacker was after.
Ask us to find where card data actually lives
How we approach it

Four things that make a PCI engagement worth what it costs.

PCI work attracts providers who benefit from a large scope. We benefit from clients who stay, which points us in the opposite direction.

We reduce scope before we sell you controls

The first deliverable is a map of where cardholder data actually is, followed by a plan to remove as much of it as possible. This makes our own engagement smaller and it is the right advice. If we can get you to a hosted payment page and tokenisation, your annual compliance cost falls permanently, and we would rather have that relationship than a bigger first invoice.

We prepare, a qualified assessor validates

We are not a QSA and cannot issue a Report on Compliance. We do the discovery, the scope reduction, the remediation and the evidence, and we support you through assessment or self-assessment. Where a QSA is required we help you appoint one and prepare properly for them, which is the difference between a smooth assessment and a long one.

We work with your acquirer rather than around them

Your acquiring bank determines your validation requirements, and UAE acquirers do not all handle this identically. We help you ask them the specific questions that establish your level and route, in writing, before you commit budget. A surprising number of merchants are working to requirements nobody ever confirmed applied to them.

We keep the evidence alive between assessments

Scans, log review, access recertification, segmentation testing, third-party evidence. Run through the year, these are routine. Assembled in the fortnight before an assessment, they are a crisis and they do not stand up. Priority response applies, P1 within 5 minutes, P2 within 10, P3 within 30, which matters when a payment path is affected.

Where this applies

Six UAE situations and what each one actually needs.

The right answer varies enormously by how payment is taken. In three of these six, the correct advice is mostly about removing card data rather than protecting it.

A retail group with card terminals across several stores

Card present transactions, a device estate across locations, and a network that connects stores to head office. The work here is device inventory and physical inspection, segmentation between store networks and corporate systems, and making sure a compromise in one location cannot reach the others. Terminal tampering is a genuine risk in this model and is addressed by process rather than by technology.

An ecommerce business taking payments online

Usually the easiest to improve dramatically. Moving to a hosted payment page or a properly implemented redirect keeps card data off your servers entirely and reduces your obligation to a fraction of what it was. What remains in scope is the integrity of your own website, because an attacker who can modify your checkout page can capture data before it ever reaches the provider.

A hospitality or restaurant group

Card present at the table, card not present for bookings, and frequently a property management or reservation system that stores card details to guarantee a booking. That last one is the problem: guarantee data is often kept far longer than needed and in more places than anyone realises. Tokenising it or shortening its retention is usually the highest-value change available.

A travel agency or tour operator

High card not present volumes, telephone bookings, card details arriving by email or messaging from customers, and onward transmission to airlines and hotels. This sector consistently has the widest hidden scope of any we assess in the UAE. The work is as much about changing how customers are asked to pay as about securing systems, and it needs commercial buy-in rather than only IT.

A service provider handling payments for others

Payment facilitators, billing platforms, managed hosting for merchants, and business process outsourcers running call centres. Service providers face a more demanding validation position than most merchants, and their clients increasingly ask for evidence as a condition of contract. Here compliance is a commercial asset rather than an overhead, and it should be scoped and timed accordingly.

A business that has just been asked by its bank

A common way this starts: the acquiring bank asks for a compliance position and nobody internally knows what that means. The right first move is not to buy anything. It is to establish your level and validation route with the acquirer in writing, then map where card data actually is. Frequently the honest answer turns out to be much simpler than feared.

Three approaches

Reduce the scope, protect the scope, or hope.

The middle column is where most UAE merchants sit and it is the expensive one. They are paying every year to protect an environment that could have been made much smaller once.
Cardholder data stored in your estate
Scope reduced firstLittle or none
Full scope protectedYes
UnassessedUnknown
Systems in scope
Scope reduced firstFew
Full scope protectedMany
UnassessedUnmapped
Annual cost of compliance
Scope reduced firstLow and stable
Full scope protectedHigh and recurring
UnassessedNil until an incident
Validation route
Scope reduced firstSimplest available
Full scope protectedMost demanding
UnassessedNone
Call recordings handled
Scope reduced first
Full scope protectedSometimes
Unassessed
Segmentation tested
Scope reduced first
Full scope protectedClaimed
UnassessedNot applicable
Post-March 2025 requirements addressed
Scope reduced first
Full scope protectedPartially
Unassessed
What an attacker would find
Scope reduced firstTokens
Full scope protectedCard numbers
UnassessedCard numbers
Exposure if breached
Scope reduced firstLimited
Full scope protectedSevere
UnassessedSevere
Where most UAE merchants sit
Scope reduced firstUncommon
Full scope protectedCommon
UnassessedCommon in SMEs
Feature
Scope reduced first
Full scope protected
Unassessed
Cardholder data stored in your estate
Little or noneYesUnknown
Systems in scope
FewManyUnmapped
Annual cost of compliance
Low and stableHigh and recurringNil until an incident
Validation route
Simplest availableMost demandingNone
Call recordings handled
Sometimes
Segmentation tested
ClaimedNot applicable
Post-March 2025 requirements addressed
Partially
What an attacker would find
TokensCard numbersCard numbers
Exposure if breached
LimitedSevereSevere
Where most UAE merchants sit
UncommonCommonCommon in SMEs
How you accept payment changes everything

Four payment models and what each does to your scope.

This table is about direction of travel rather than precise validation requirements, which depend on your level and your acquirer. The pattern is consistent: the further cardholder data stays from your systems, the smaller and cheaper your obligation.
Payment modelEffect on your scope
Hosted payment page at the providerCustomer enters card on the provider pageSmallest scope available
Redirect or iframe from your siteCard data bypasses your serversSmall, but your site integrity is in scope
Direct post or API from your applicationCard data transits your systemsSubstantially larger scope
Storing card numbers yourselfData at rest in your estateLargest scope and the highest risk
Card present terminals in storeDevices and their network in scopeDevice inventory and inspection required
Telephone orders with call recordingRecordings capture card dataCommonly missed, frequently in scope
Card details arriving by emailMail system and archives in scopeShould be stopped, not protected
Tokenisation by your providerYou hold a token, not a card numberRemoves most storage obligations
How we run it

Five stages, and the first two usually shrink the rest.

We deliberately do discovery and scope reduction before designing any controls, because designing controls for an environment you are about to shrink is wasted work.
  1. 1

    Establish your level and validation route

    With your acquiring bank, in writing. Merchant or service provider, which level, which validation route, and what evidence they expect. This costs nothing and it prevents the most expensive error in PCI work, which is preparing for a more demanding route than the one that applies to you.

  2. 2

    Find where cardholder data actually is

    Discovery across systems, mailboxes, file shares, CRM records, call recordings, backups and archives. We expect to find card data in places nobody predicted, because we always do. The output is a map of true scope, which is usually larger than the assumed scope and is the basis for everything after it.

  3. 3

    Reduce the scope

    Remove data that has no business reason to exist, stop the processes that create it, move to tokenisation or a hosted payment page where the payment model allows, and segment what genuinely has to remain. This stage produces the permanent saving. Everything after it is proportional to how well this went.

  4. 4

    Remediate the controls that remain

    Access and multi-factor authentication, encryption, logging and review, vulnerability management, secure configuration, change control, third-party agreements, and specifically the requirements that became effective on 31 March 2025. Prioritised by risk and by what your validation route actually requires.

  5. 5

    Validate, then keep it true

    Self-assessment or QSA assessment as applicable, with us preparing the evidence and supporting the process. Then the ongoing cadence: scans, reviews, segmentation testing, third-party evidence and access recertification, so that next year is a repeat rather than a rebuild.

“The previous quote we had was for securing everything that touched card data. This one started by asking why we were storing it. Six weeks later we were not storing it at all, and the assessment that followed was a fraction of what we had budgeted for. It felt like being talked out of a sale.”
Finance Director
Travel group, Dubai · Client reference available on request
Straight answers

What UAE merchants ask about PCI DSS.

Assessments are performed against PCI DSS v4.0.1. Version 3.2.1 was retired on 31 March 2024, so it can no longer be used as the basis for an assessment. Version 4.0.1 is a limited revision of 4.0 that clarified wording without changing the substance or the timing of the new requirements. If your last assessment was against 3.2.1 and you have not revisited it since, you have a meaningful gap to close rather than a version number to update.

Yes, they are in force. Version 4.0 introduced 64 new requirements, and the PCI Security Standards Council confirmed that 51 of them were future-dated with an effective date of 31 March 2025. That date has passed, so they are simply requirements now with no transitional position available. This catches organisations that assessed during the transition window, noted the future-dated items as out of scope at the time, and have not revisited the list since.

PCI DSS obligations flow through your acquiring bank and your card scheme agreements rather than from a government regulator, so whether anyone has asked you is not quite the test. If you accept card payments, the requirement exists in your merchant agreement. In practice the trigger is usually the acquirer asking for a compliance position, a large customer asking during procurement, or an incident. The cost of establishing your position now is small; the cost of establishing it during an incident is not.

Stop storing cardholder data, and stop it reaching your systems in the first place. A hosted payment page or a properly implemented redirect keeps card numbers with your provider, and tokenisation replaces stored card numbers with values that are useless to an attacker. For most merchants this is not a compromise, it is the intended design, and it converts a large recurring compliance burden into a small one permanently. It is the first thing we look at on every engagement.

Almost certainly, and it is the most commonly missed piece of scope we find in the UAE. If a customer reads a card number aloud during a recorded call, that recording contains cardholder data, and every system that stores, backs up or transcribes it is in scope. The solutions are practical: pause and resume recording around payment, move payment to an automated telephone step, or route the payment to a link sent to the customer. What does not work is discovering it during an assessment.

No. Formal validation is performed either by you through a self-assessment questionnaire or by a Qualified Security Assessor producing a Report on Compliance, depending on your level and your acquirer requirements. We are not a QSA. We do the discovery, the scope reduction, the remediation and the evidence preparation, and we support you through whichever validation route applies. Where a QSA is needed, we help you appoint one and prepare for them properly.

Your acquiring bank tells you, and you should get it in writing. Levels are driven principally by annual transaction volume per card brand, and the level determines whether you self-assess and with which questionnaire, or whether an assessor is required. UAE acquirers do not all communicate this proactively, so it is worth asking directly rather than assuming. Preparing for a more demanding route than the one that applies to you is a common and expensive mistake.

No, and this is a widespread misunderstanding. Your provider being compliant covers their environment, not yours. What it does do is reduce your scope substantially, sometimes to a very small residual obligation, which is why choosing the right integration model matters so much. You still have obligations of your own: the integrity of your website or application, your third-party management, your access controls, and evidence of your provider status.

Usually yes, because it is how you keep the rest of your business out of scope. The important caveat is that segmentation only counts if it is real and tested. Two systems on different subnets with a permissive firewall rule between them are not segmented in any meaningful sense, and a failed segmentation test expands your scope retroactively, which is both expensive and awkward to explain. If you claim segmentation, budget for testing it.

Discovery and scope work is typically two to four weeks. Scope reduction depends on how much card data you are removing and how deeply it is embedded in commercial processes, which can be anywhere from weeks to a few months, because it often requires changing how customers are asked to pay rather than only changing systems. Remediation and evidence then follow the reduced scope. A mid-sized merchant with a cooperative payment provider typically works to a three to six month timeline.

The consequences run through your card scheme and acquirer agreements and can include forensic investigation costs, fines passed through by the acquirer, liability for fraudulent transactions, and in serious cases restrictions on your ability to accept cards. We are not going to quote figures, because they depend on the schemes, the volumes and the circumstances. What we will say plainly is that the commercial consequence of losing card acceptance is existential for most merchants, which is why the scope reduction conversation is worth having early.

They sit alongside it. Cardholder data is personal data, so the federal data protection law applies to it in addition to your PCI obligations, and firms in DIFC or ADGM have their own regimes on top. The practical implication is that a breach may carry both scheme consequences and data protection notification obligations, on different timescales and to different parties. That mapping should be done before an incident, as part of your response plan, not during one.

Both of yours, in different ways. If they handle cardholder data on your behalf they are in scope as a service provider and you need evidence of their compliance status, plus written agreements setting out their responsibility for the data. Their compliance does not discharge yours, and your oversight of them is itself a requirement. Outsourced call centres taking card payments by phone are one of the higher-risk arrangements we see, and they are frequently governed by a contract that never mentions card data.

There are two costs. Assessment fees, where a QSA is required, are the assessor own and are driven by the size and complexity of your cardholder data environment, which is precisely what scope reduction shrinks. Our preparation and remediation work is scoped separately. We do not publish figures because the range is very wide, but we will tell you at the outset what drives the number, and the first thing we will try to do is make the environment smaller so that both costs fall.

With two things that cost nothing. Ask your acquiring bank, in writing, what merchant level you are and what validation they require. And ask internally whether anyone can explain why you store cardholder data, if you do. Those two answers determine the shape and cost of everything that follows, and in a meaningful number of cases they reveal that the obligation is far smaller and simpler than the organisation assumed.
PCI readiness

Fifteen questions before you spend anything.

The first group is scope, which decides the cost of everything else. The second is the controls that apply to whatever remains. The third is what keeps you compliant between assessments, which is where most organisations quietly fail.

Scope, where the money is

  • Do you store cardholder data anywhere, and can you say why?
    If there is no clear answer, the answer is to stop.
  • Have you searched for card data outside the payment system?
    Email, CRM notes, file shares, call recordings, backups.
  • Do you record calls where customers read card numbers aloud?
    The most commonly missed piece of scope in the UAE.
  • Is your network segmented, and has the segmentation been tested?
    Claimed segmentation that fails testing expands scope retroactively.
  • Could a hosted payment page or tokenisation remove most of this?
    For most merchants it can, and it is a permanent saving.

Controls on what remains

  • Is multi-factor authentication enforced into the cardholder environment?
    Including for administrators and third parties.
  • Is access granted on need-to-know and reviewed periodically?
    Reviewed means evidenced, not intended.
  • Are vulnerability scans running on the required cadence?
    And are the findings actually being fixed.
  • Are logs collected from in-scope systems and reviewed?
    Collection without review satisfies nothing.
  • Have you addressed the requirements that became effective 31 March 2025?
    They are no longer future-dated. They are requirements.

Staying compliant between assessments

  • Do you know your merchant or service provider level?
    It determines your validation route. Ask your acquirer.
  • Do you hold current compliance evidence for your providers?
    Gateway, host, point of sale vendor, call centre.
  • Do your third-party agreements address cardholder data responsibility?
    A requirement, and usually missing.
  • Is there an incident response plan covering a card data compromise?
    With the acquirer notification path already identified.
  • Is anyone maintaining evidence through the year?
    Rather than reconstructing it before the assessment.
Related reading

The pages around this one.

IT audit services in Dubai

The wider audit practice, including how to tell which kind of engagement your situation actually calls for before anybody quotes for one.

Learn more

VAPT and penetration testing in Dubai

Technical testing, including the scanning and testing obligations that apply to a cardholder data environment and how they are evidenced.

Learn more

ISO 27001 certification in the UAE

The management system standard that sits underneath most compliance work, and how its evidence reduces the effort for sector requirements.

Learn more
Next step

Before you budget for controls, find out what is actually in scope.

A scope review is short and it frequently changes the whole shape of the programme, usually downward. If we can get card data out of your estate entirely, your compliance cost falls permanently rather than for one cycle, and that is the outcome we aim for first.

Book a PCI scope reviewCall +971 56 613 2743

Related Services

Explore more solutions that work great with this service

CBUAE IT Requirements

Which Rulebook articles actually bind your licence

Learn more

SOC 2 Readiness UAE

Type II preparation, and when ISO 27001 fits better

Learn more

IT Audit Services Dubai

Assessment, technical test or certification, scoped properly

Learn more

ISO 27001 Certification UAE

The 2022 edition, and whether you should certify at all

Learn more

VAPT Testing

CREST-certified vulnerability assessment and penetration testing

Learn more

UAE PDPL Compliance

Federal Decree-Law 45 of 2021 readiness and operations

Learn more

Cybersecurity Audit

Security assessment and compliance audit

Learn more

Managed Security Services

MSS on Microsoft Defender XDR and Sentinel

Learn more
GR IT SERVICES

Leading IT services provider in Dubai,
delivering enterprise-grade solutions
for businesses across the UAE.

Microsoft CSP PartnerCISGuard

Get the Helpdesk app

Raise and track IT tickets from your phone.

Download on the App StoreGet it on Google Play
Learn more about the app

Microsoft 365

  • Microsoft 365 Administration
  • M365 Reporting & Auditing
  • Microsoft 365 Licensing
  • Microsoft Copilot
  • Microsoft 365 Apps
  • Windows 365 Cloud PC
  • Microsoft SharePoint
  • Outlook & Exchange

Security

  • Microsoft Defender
  • Microsoft Purview
  • Microsoft Intune
  • Microsoft Entra
  • Compliance Manager
  • Cybersecurity Audits
  • Copilot for Security
  • Microsoft Sentinel
  • Microsoft Priva

Infrastructure

  • Google Workspace
  • Cloud Migration Services
  • Data Analytics & BI
  • Active Directory
  • Server Management
  • Apple Business
  • Apple Jamf Pro
  • IP Telephone
  • Data Backup
  • Website Development

IT Services

  • Managed IT Services
  • IT Support Dubai
  • IT AMC Dubai
  • New Office IT Setup
  • IT Relocation
  • Remote IT Support
  • On-Call IT Support
  • Startup IT Business Kit
  • Disaster Recovery & BC

Company

  • About Us
  • Careers
  • Contact
  • Blog

Contact

  • Iris Bay Tower, Office 903,
    Business Bay, Dubai, UAE
  • +971 56 613 2743
  • hello@gritservices.ae
  • gritservices.ae

© 2026 GR IT Services. All rights reserved.

Privacy PolicyTerms of UseCookie Policy