VARA did not invent the idea that Virtual Asset Service Providers need security testing.
What it did, in the Technology & Information Rulebook, is make the expectation precise: qualified, independent vulnerability assessment and penetration testing—at least annually, and before new systems, applications, or products go live—with results available to the Authority on request. Where relevant to the VA Activities, that scope includes smart contracts.
A cybersecurity policy that never meets a live test is unfinished work under that rulebook. Documentation can look complete. Supervisory questions still land on what happens when someone actually tries to break the systems that hold assets.
What the Rulebook is actually pointing at
Part I of the Technology & Information Rulebook (current version effective mid-2025) is not a marketing checklist. It ties technology governance to concrete surfaces:
- A Technology Governance and Risk Assessment Framework that covers the business you run—not a generic ISO poster
- A Cybersecurity Policy submitted for licensing assessment and reviewed at least annually by the CISO
- Cryptographic key and VA wallet management with no single point of failure in access to, or knowledge of, client Virtual Assets
- Testing and audit by an independent third party, plus internal monitoring that can be evidenced
- Business continuity that assumes cybersecurity events, not only power cuts
- A CISO accountable for Part I (and confidential-information) compliance
If you only remember one sentence from Rule I.E.1, remember this: annual VA/PT is mandatory, pre-change testing is mandatory, and smart-contract effectiveness is in scope when it matters to what you do.
VARA can also notify a VASP to run threat-led penetration testing (TLPT)—external, potentially on live Critical or Important Functions, with findings, remediation, and proof of method delivered back to the Authority. That is a supervisory tool, not an optional exercise.
Where the gap usually appears
The recurring failure is not missing paperwork. It is the distance between “we completed annual testing” and a coherent account of risk on the systems that matter.
### 1. Scope that stops at the marketing site
The Rulebook talks about infrastructure and applications, internal and external vulnerability work, and—where relevant—smart contracts. Custody UIs, admin panels, signing workflows, cloud IAM, vendor integrations, and the path that moves client assets are usually where the money is.
A scrape of the public website plus a vulnerability scanner export does not meet that bar. If the test never touched the systems that hold keys or settle transfers, the brochure was tested—not the VASP.
### 2. Wallet and key controls that exist only in the policy
Part I.D is blunt: no single point of failure; keys online or in one physical location should be insufficient to move assets without further controls; access changes logged; staff departure triggers a decision on whether keys must be rotated.
On paper, every VASP has “multisig” and “HSM.” In production the same patterns keep showing up:
- Shared cloud identities gating multiple signers
- Recovery seeds in the same vault as primary material
- Admin roles that can rewrite wallet policy without a dual-control path
- Temporary hot paths that outlived the launch weekend
An independent test that never maps quorum, recovery, and policy-change paths is ignoring the section of the Rulebook that exists because wallets get emptied.
### 3. Smart contracts treated as a one-off launch artifact
Rule I.E.1 explicitly pulls in audits of effectiveness, enforceability, and robustness of smart contracts when they matter to the VA Activities. Launch-week reports age badly. Upgrades, new modules, parameter setters, and offchain keepers change the risk without a new report titled “Audit v2.”
If the product ships bytecode or depends on it, annual and pre-change testing has to include that layer—or there needs to be a written reason that would survive scrutiny for why it does not.
### 4. Evidence that cannot survive a request
Rules I.E.3 and I.E.4 expect documentation: what was tested, when, by whom, against which systems, with what results—and management processes that show controls stay effective. A vendor slide deck is not an inspection pack.
When the Authority asks, delay is itself a finding.
A practical scope note for 2026
Before buying another annual test, force answers on one page:
- Inventory — systems, apps, cloud accounts, custody stack, smart contracts, and third parties that sit on Critical or Important Functions
- Change triggers — which releases count as “new systems, applications and products” under I.E.1, and who owns the gate
- Key paths — how many independent compromises are required to move client assets; where recovery lives; who can change that map
- Onchain surface — which contracts and upgrade paths are in production scope this year
- Evidence — where reports, remediations, and retests will live so they can be produced immediately
- TLPT readiness — if notified, which live functions are in play, which vendors must participate, and who signs the findings summary
That list is not legal advice. It is the difference between a test that supports the licence and a test that only supports the calendar.
Closing note
The useful question under VARA is not whether a policy document exists. It is whether last year’s live systems would still survive this year’s independent test—across infrastructure, applications, keys, and, where relevant, contracts.
Teams that treat the Rulebook as an operating constraint design scope that way. Teams that treat it as a filing exercise usually discover the gap when someone asks for evidence.
AN3 Intel · field notes on technology risk under Dubai’s virtual asset regime.