Penetration Testing in the UAE
The UAE has more overlapping cybersecurity regimes than almost anywhere else - federal, emirate-level, sector-specific and free-zone - and nearly all of them land on the same requirement: an independent penetration test, at least annually, with evidence. Here's which one applies to you and what the test involves.
The UAE regulatory map, briefly
The UAE layers federal, emirate and sector rules on top of each other. Most organisations are covered by more than one, and the useful insight is that a single well-scoped test can satisfy several at once - if it is scoped that way deliberately rather than by accident.
NESA / UAE Information Assurance Standards
The federal baseline, applying to government entities and to organisations designated as critical information infrastructure across energy, water, transport, telecoms, financial services and healthcare. Technical vulnerability management requires vulnerability assessments and penetration tests to be performed and tracked - annually, in practice. Two requirements catch people out: critical and high findings need documented remediation with evidence of a retest inside a defined window, usually 90 days; and assessors review the credentials of whoever did the testing, with OSCP or equivalent being the stated expectation. The NESA page covers the detail.
Dubai ISR (DESC)
The Dubai Electronic Security Centre's Information Security Regulation binds Dubai government entities and the suppliers who serve them. It runs parallel to NESA rather than replacing it, and organisations working with Dubai government frequently need to evidence both. The testing requirement is substantively similar, so one engagement scoped for both produces one set of evidence.
Financial services: CBUAE, DFSA, ADGM
The Central Bank of the UAE sets expectations for banks and finance companies onshore; the DFSA regulates firms in the DIFC and the FSRA those in ADGM. All three expect regular independent security testing, and all three take a dim view of a vulnerability scan presented as a penetration test. Covered in detail here.
VARA: virtual assets
Dubai's Virtual Assets Regulatory Authority requires every licensed VASP to undergo an independent penetration test at least annually under its Technology and Information Rulebook, with intelligence-led testing where VARA considers it necessary and proportionate. The rulebook sits alongside requirements on HSM-backed key management, cold-storage minimums and incident reporting within 24 to 72 hours by severity.
Healthcare: ADHICS
The Abu Dhabi Healthcare Information and Cyber Security standard applies to healthcare providers and their technology suppliers in the emirate, with security testing and evidence requirements alongside its controls on clinical data. More here.
Data protection
The federal PDPL, plus the separate DIFC and ADGM data protection laws, bring security obligations wherever personal data is processed. They don't name penetration testing as such, but "appropriate technical measures" is the standard, and demonstrating it after an incident is considerably easier with a recent independent test on file.
One test, several obligations
The expensive mistake in the UAE is buying a separate assessment per regulator. In most cases the technical scope overlaps almost entirely - external surface, web applications and APIs, internal network and Active Directory, cloud tenancy - and what differs is the mapping and the reporting, not the testing.
So the engagement is scoped once against everything you're subject to, and the report maps each finding to each applicable control. The practical scope:
- External network - everything reachable from the internet, including the hosts nobody remembers publishing.
- Web applications and APIs - authentication, authorisation, business logic, injection. The customer-facing layer every regulator asks about.
- Internal network - what a foothold reaches, and whether your segmentation actually holds.
- Active Directory - ADCS abuse, Kerberoasting, delegation and ACL paths to Domain Admin.
- Cloud - Entra ID and Azure RBAC escalation, exposed storage, identity misconfiguration.
For VASPs under VARA, add the custody boundary: wallet infrastructure, signing workflows and the operational controls around key material, which is where the loss event actually happens rather than in the web front end.
The credential requirement, specifically
Most compliance pages gloss over this, but it is unusually concrete in the UAE: NESA assessors review who performed the test, and OSCP or equivalent is the expectation. Tests performed by someone without a recognised offensive certification get questioned, and sometimes rejected, at assessment.
I hold OSCP+ - the current, renewed form of the certification - along with eCPPT, eWPT and eCIR on the offensive side, and AZ-500, SC-200 and SC-300 on the Microsoft security side, which is what makes the Entra ID and Azure portion credible rather than generic. Every one is independently verifiable in the OffSec credential wallet, and that verification link belongs in your evidence pack alongside the report.
How the engagement runs
Scope and quote first: you tell me the obligation, the environment and the deadline; you get a fixed price and a start date, usually within one or two weeks. Rules of engagement are agreed in writing, including testing windows, escalation contacts and anything your regulator constrains about where evidence is processed or stored.
Testing typically runs one to two weeks depending on scope, with anything critical reported to you immediately rather than held for the final document. The report follows within days: executive summary, technical findings with reproduction steps and CVSS ratings, control mapping, and prioritised remediation. Then a retest of what you've fixed and an attestation letter - which matters more than people expect in the UAE, because the 90-day retest evidence is itself a requirement, not a nicety.
I work remotely from Amman, one hour behind Dubai, on the same Sunday-to-Thursday rhythm as the region, in Arabic or English. No local office, and I won't claim one - what you get instead is the person doing the work, directly, with verifiable credentials.
Start here
Tell me which regulator you answer to and what's in scope. If you're not certain - and with this many overlapping regimes that's completely normal - a short call sorts it out. The compliance overview compares the frameworks side by side, the free perimeter scan shows your current external exposure in a few minutes, and the sample report shows exactly what you'd receive.
Get in touch - enquiries in Arabic are welcome, and if a filing deadline is driving the timeline, say so in the first line.
UAE: common questions
Roughly: federal entities and designated critical information infrastructure - energy, water, transport, telecoms, financial services, healthcare - fall under NESA's Information Assurance Standards. Dubai government entities and their suppliers fall under DESC's ISR. Banks and finance companies answer to the Central Bank; DIFC firms to the DFSA and ADGM firms to the FSRA; Dubai virtual-asset service providers to VARA. Abu Dhabi healthcare falls under ADHICS. Many organisations are covered by two or three at once, which is normally fine - one well-scoped test can produce evidence for all of them if it is scoped with that in mind from the start.
Yes. Technical vulnerability management under the Information Assurance Standards requires vulnerability assessments and penetration tests to be conducted and tracked, and in practice that means at least annually for covered entities. Two details matter beyond the test itself: critical and high findings need documented remediation with evidence of a retest inside a defined window, typically 90 days - so a test without a retest is an incomplete answer. And NESA assessors review the credentials of whoever performed the test, with OSCP or equivalent being the expectation.
Yes. Under VARA's Technology and Information Rulebook, every Dubai virtual-asset service provider needs an independent penetration test at least annually, and VARA may additionally require intelligence-led testing where it judges that necessary and proportionate. The rulebook also covers key management with HSMs, cold-storage minimums and incident reporting on a 24 to 72 hour clock depending on severity. For VASPs the testing scope usually needs to reach further than a standard web application test - wallet infrastructure, signing workflows and the custody boundary are where the real risk sits.
No. External, web application, cloud and most internal testing is delivered remotely, which is standard across the region. Internal network and Active Directory work runs over a VPN or a jump host inside your environment. Where a regulator or your own policy constrains where data is processed or evidence is stored, that goes into the rules of engagement in writing before anything starts.
Usually within one to two weeks of scope agreement, and faster when a filing deadline is driving it. Because you're engaging the tester directly there is no internal resourcing queue between the signature and the start date. A typical external and web application engagement runs one to two weeks of testing with the report inside a few days of finishing - the timeline in detail is here.
Have a NESA, ISR or VARA deadline?
Tell me the obligation and the scope, and you'll get a fixed quote and a start date.