Dubai’s Virtual Assets Regulatory Authority continues to raise the standard for regulated virtual asset activity. For VASPs operating in, or expanding to, Dubai, the VARA Technology & Information Rulebook defines the controls, testing, documentation, and evidence expected for regulatory readiness.
Rulebook v4 is an important clarification of VARA’s technology and information security expectations, expanding requirements across governance, wallet and key management, independent testing, threat intelligence sharing, Defence-in-Depth, and Threat-Led Penetration Testing.
These changes make security a board-level readiness issue. For VASPs seeking authorisation in Dubai’s mainland or free zones, excluding the DIFC, Rulebook v4 is already worth preparing for as part of the path to market access. Firms must be able to prove that critical controls work across their technology, operations, vendors, and incident response processes.
Whether your VASP is new to VARA compliance or already preparing for review, Hacken supports this process end-to-end: from gap assessment and technical testing to remediation, threat-led penetration testing, evidence building, compliance package preparation, and regulator-facing support.
What Changed in VARA Technology & Information Rulebook v4
VARA’s Rulebook v4 clarifies six important areas that affect how VASPs should prepare their security and compliance programs. Together, these updates give firms a more practical view of what cyber resilience and verifiable control effectiveness should look like in practice.
Schedule 1: VARA Is Moving From Policy to Proof
Schedule 1 provides additional VARA guidance for implementing existing Technology and Information Rulebook expectations. It can be read as an implementation checklist that helps VASPs translate broad cybersecurity, technology governance, and resilience requirements into practical control areas.
The guidance structures technology risk across five categories: organisational security, technical controls, detection and response, customer VA protection, and digital operational resilience. For VASPs, the main impact is clarity. Security teams can use Schedule 1 to map current controls, identify gaps, and prepare evidence across third-party risk, SDLC, key management, multisig, transaction monitoring, incident response, customer authentication, and resilience testing.
TLPT Rules E.5–E.10: Testing Now Extends to Live Threat Scenarios
The new TLPT rules raise the bar from periodic penetration testing to threat-led validation of critical live production systems. VARA can require a VASP to run intelligence-led red-team testing based on risk exposure, business criticality, or VA activities.
The implication is clear: VASPs need to know which systems are critical, whether production testing can be safely managed, which third-party providers fall into scope, and whether qualified external testers are already available.
Rule B.3.s: Threat Intelligence Becomes a Market Resilience Obligation
Rule B.3.s adds cyber threat information sharing as a formal cybersecurity policy criterion. The rule reflects a simple reality: many attacks are not isolated events, but campaigns moving across VASPs, vendors, wallets, and infrastructure providers.
The response now needs to include trusted sharing of indicators, attack patterns, and fund-tracing intelligence, while protecting confidential information and avoiding additional risk to the sharing VASP.
Rule A.2: Defence-in-Depth Is Now Explicit
Rule A.2 now explicitly requires defence-in-depth for cybersecurity-related risk mitigation. This means VASPs cannot depend on a single wallet provider, signing interface, monitoring layer, approval process, or incident response path.
VARA expects layered and independent controls across network, application, endpoint, data, access, monitoring, response, custody, signing, and key management workflows. The key question becomes whether one control can fail without compromising the whole system.
Rule C.1.c: Consumer Protection Enters the Technology Compliance Perimeter
Rule C.1.c adds compliance with CBUAE Notice No. 444 on Consumer Protection Regulation as a formal obligation. This expands the compliance perimeter beyond cybersecurity and data protection alone.
VASPs now need a coherent view across VARA requirements, Dubai Electronic Security Centre obligations, UAE data protection rules, and CBUAE consumer protection expectations, especially where incidents, service continuity, customer safeguards, reporting, and remediation overlap.
Schedule 2: Definitions Make Supervision More Precise
Schedule 2 formalises key terms including TLPT, HSM, Critical or Important Function, CBUAE, and UAE Data Office. These definitions reduce ambiguity around testing scope, key protection, resilience obligations, consumer protection links, and data authority references.
They also make gaps easier to identify: internal policies, control matrices, contracts, and testing plans would need to speak the same language as the rulebook.
Why TLPT Now Matters for VARA Readiness
Rulebook v4 further clarifies VARA’s expectations for Threat-Led Penetration Testing (TLPT): controlled, intelligence-led red-team testing of critical live production systems against realistic threat scenarios. In short, VASPs would need to prove that critical controls work, not simply document that those controls exist.
What VARA Expects From TLPT
VARA may require VASPs to conduct TLPT when risk exposure, business criticality, VA activities, or other relevant risks justify deeper testing. The main requirements are clear:
- Each TLPT must be conducted by a qualified external tester.
- The test must cover Critical or Important Functions on live production systems.
- Relevant third-party service providers must be included in scope.
- Findings and remediation plans must be produced and made available to VARA.
What TLPT Means for VARA Compliance
The updated TLPT rules show that VARA is looking beyond standard testing reports toward evidence that critical virtual asset operations can withstand real attack conditions. This reflects the reality of digital asset risk: major losses rarely come from code alone. In Q1 2026 alone, $482.6 million was stolen across 44 incidents, showing how quickly compromised signing, weak governance, delayed remediation, poor monitoring, failed response, and third-party exposure can turn into material losses.
The Sonne Finance exploit is a clear example. A known vulnerability class affected a Compound v2 fork, and a governance delay created a window before the fix could be deployed. TLPT is built for this type of scenario, testing whether monitoring, escalation, emergency response, and remediation can hold before a known weakness becomes a loss.
For VASPs with operations or growth plans in Dubai, TLPT readiness is both a technical and governance challenge. It requires finding a qualified tester and preparing the full operating environment around the test: defining Critical or Important Functions, involving relevant vendors, managing live production testing risks, protecting TLPT data, and producing auditable remediation evidence.
