Penetration Testing for UAE Finance and Virtual Assets
Four regulators, four licences, one recurring requirement: independent security testing, evidenced. For virtual-asset firms under VARA the requirement is explicit and annual - and the scope that matters reaches well past the web application into the custody boundary.
Four regulators, one underlying requirement
UAE financial services are split across onshore and two free zones, plus a dedicated virtual-assets regulator. Which one licenses you decides the wording of your obligation, but the substance converges: independent security testing, performed regularly, with evidence you can produce.
VARA - Dubai virtual assets
The most explicit of the four. Under the Technology and Information Rulebook, every licensed VASP requires an independent penetration test at least annually, and VARA may require intelligence-led testing in addition where it judges that necessary and proportionate. The rulebook also covers cybersecurity governance, multi-signature key management backed by hardware security modules, cold-storage minimums, and incident reporting on a 24 to 72 hour clock by severity.
CBUAE - onshore banks and finance companies
The Central Bank sets security expectations for licensed onshore institutions, with regular independent testing of internet-facing systems and customer-facing applications as a standing expectation rather than a one-off. Where card data is in scope, PCI DSS Requirement 11.4 applies in parallel and overlaps heavily - scoped together, it is one engagement.
DFSA (DIFC) and FSRA (ADGM)
Both free-zone regulators expect independent security testing proportionate to the firm's risk profile, with annual being the interval firms adopt and defend. Neither publishes a single universal frequency the way VARA does, which in practice means the burden sits on you to justify your cycle - and "annually, plus after material change" is the justification that holds.
And NESA underneath
Financial services is designated critical information infrastructure, so NESA's Information Assurance Standards frequently apply alongside your sector regulator - including its 90-day retest expectation for critical and high findings, and its review of the tester's credentials. Scope for both at once; retrofitting later usually means testing twice.
For VASPs: scope the custody boundary, not the front end
This is the part worth being blunt about. A conventional web application test against a trading interface will find authentication and authorisation issues, and it will leave the actual loss scenario entirely untested. Exchanges do not typically lose assets because of cross-site scripting.
The questions that matter for a virtual-asset firm:
- The signing workflow - who and what can authorise a transfer, how approvals are enforced technically rather than procedurally, and whether a single compromised administrator or service account can move value.
- Hot and cold separation - whether the boundary is genuinely enforced or merely documented, and what reaches across it.
- Key material handling - how HSM-backed signing is invoked, what can invoke it, and whether access to the invoking system is equivalent to access to the key.
- Approval bypass - what someone with partial access can achieve: an operations account, a compromised developer workstation, a privileged read in a treasury system.
- The operational process - the human steps around withdrawals and address allow-listing, which is where social engineering lands in this sector.
These are design and process questions as much as code questions, which is exactly why they need a tester rather than a scanner. The underlying platform still needs the standard treatment - web and API, external and internal network, cloud - but the custody boundary is where the scope should concentrate.
Intelligence-led testing, if it comes up
Intelligence-led testing - the family that includes TIBER-EU and CBEST - starts from real threat intelligence about who targets firms like yours, then emulates those specific adversaries against production, typically without the defending team being told. It measures detection and response as much as vulnerability, and it is longer and more expensive than a standard test.
VARA may require it where it considers that proportionate, which broadly tracks firm size and assets under custody. Most newly licensed VASPs begin with the annual independent test; firms holding significant custody should plan for the question arriving. The honest sequencing advice: a standard penetration test first. Intelligence-led testing against an environment that has never had a conventional assessment produces an expensive report full of findings a cheaper engagement would have caught.
What you get
Fixed price agreed before anything starts. Rules of engagement in writing, including testing windows and escalation contacts - which matters more here than in most sectors, because testing anywhere near production custody infrastructure needs an agreed abort path. Critical findings reported the moment they're found.
The report carries an executive summary for your board and your regulator, a technical body with reproduction steps and CVSS ratings, and mapping to the rulebook or control that required the test. Then remediation support, a retest of what you've closed, and an attestation letter naming the tester, the scope and the dates - which is typically what you hand to the regulator or to an institutional counterparty conducting diligence on you. There's a sample report for the format.
Who performs it
You work with the tester directly. Credentials, since financial-sector and VASP procurement always ask: OSCP+, eCPPT, eWPT, eCIR, plus AZ-500, SC-200 and SC-300 - all verifiable through the OffSec credential wallet. The detection-engineering background before offensive work is directly relevant here: the report covers not only how an attack path functions but what it would have looked like in your monitoring, and whether anything would have caught it. For a regulator asking about detection and response capability, that distinction is the answer.
Remote from Amman, one hour behind Dubai, same working week, Arabic or English.
Next steps
Tell me which licence you hold, what the platform looks like, and whether custody infrastructure is in scope. Fixed quote and start date back. If you're newly licensed and trying to work out what your first test should actually cover, that's a short and useful conversation - get in touch.
Related: penetration testing in the UAE, NESA requirements, and the compliance overview.
UAE finance questions
Under VARA's Technology and Information Rulebook, every licensed Dubai virtual-asset service provider must undergo an independent penetration test at least annually, and VARA may additionally require intelligence-led testing where it considers that necessary and proportionate. The rulebook sits alongside requirements covering cybersecurity programme governance, multi-signature key management backed by HSMs, cold-storage minimums, and incident reporting within 24 to 72 hours depending on severity. The testing obligation is not the whole rulebook, but it is the part that needs an external party.
Intelligence-led testing - the model behind TIBER-EU and CBEST - starts from real threat intelligence about who actually targets firms like yours, then simulates those specific adversaries against production, usually without the defending team knowing. It is longer, more expensive and more revealing than a standard penetration test. VARA may require it where it judges that proportionate, which in practice tracks the size of the firm and the assets under custody. Most newly licensed VASPs start with the annual independent test; firms holding significant custody should expect the question eventually.
Both the DFSA in the DIFC and the FSRA in ADGM expect regular independent security testing proportionate to the firm's risk profile, rather than publishing a single universal interval the way VARA does. Annual is the norm firms adopt and defend, with additional testing after material change. The practical expectation across both free zones is the same as onshore: independent testing, documented remediation, and evidence you can produce on request.
Almost certainly, and earlier than most founders expect. The obligation arrives with the licence rather than with scale, so a firm in a sandbox or newly licensed carries it at exactly the stage when the security programme is least mature. The useful framing is that the first test is cheaper and far less painful when the platform is small - and the findings are the ones you can still fix architecturally rather than patch around.
Yes, and for a VASP that is where the scope should concentrate. A web application test on the trading front end leaves the actual loss scenario untested. The questions worth answering are about the signing workflow, the separation between hot and cold infrastructure, who and what can authorise a transfer, how approvals can be bypassed by someone with partial access, and whether the operational process around key material survives a compromised administrator. Those are design and process questions as much as code ones, which is why they need a human rather than a scanner.
Licensed by VARA, DFSA, ADGM or CBUAE?
Independent testing scoped to the rulebook - including the custody boundary, not just the front end.