Learn
A VASP's Cybersecurity Policy is not a formality. Rule I.B.1 of the VARA Technology and Information Rulebook requires you to submit it to VARA for assessment as part of the licensing process, and again at any later time on request. Rule I.B.3 tells you exactly what it has to cover.
Corrected on 14 July 2026: this article previously said there were 18 criteria and then listed 18 headings that do not appear in the rulebook at all. The Technology and Information Rulebook in force since 19 June 2025 lists minimum criteria (a) through (s), which is 19. The figure of 18 comes from the 7 February 2023 version, which ended at (r). Criterion (s), sharing cyber threat information and intelligence, is the addition. Every criterion below is now quoted from the rule itself.
What Rule I.B actually requires
Section B of Part I has three operative rules, and it is worth reading them as a set.
- Rule I.B.1. You must "create and implement a policy which outlines their procedures for the protection of their electronic systems and client and counterparty data stored on those systems". That policy is submitted to VARA for assessment as part of licensing, and on request afterwards.
- Rule I.B.2. The policy must be "reviewed and updated at least annually by their CISO". Not by the CTO, not by an external consultant signing off alone. The named CISO.
- Rule I.B.3. The policy must contain "sound procedures and security mechanisms in accordance with best industry practices" that let you comply with all applicable information security, data protection and data privacy laws, including Part II of the rulebook and the UAE PDPL, "whilst maintaining the confidentiality of data at all times". It then says the policy "must address the following minimum criteria" and lists them from (a) to (s).
Two words in Rule I.B.3 do a lot of work. "Minimum" means the list is a floor, not a ceiling. And each criterion is drafted as a subject the policy must address, not as a control specification. VARA is telling you what your policy must have a considered answer for.
The 19 mandatory criteria, (a) to (s)
These are the criteria in Rule I.B.3, in the order the rulebook lists them.
| Ref | Criterion | What the rule says |
|---|---|---|
| (a) | Information security | The umbrella criterion. The policy has to set out the procedures and security mechanisms protecting the VASP's electronic systems and the client and counterparty data held on them. |
| (b) | Data governance and classification | Classification of the data the VASP holds and the governance around it. |
| (c) | Access controls | Who can reach which system, and on what basis. |
| (d) | Capacity and performance planning | Also appears in Rule I.A.4 as part of the Technology Governance and Risk Assessment Framework, so the two need to agree. |
| (e) | Systems operations and availability concerns | Operational running of the systems and their availability. |
| (f) | Systems and network security, consensus protocol methodology, code and smart contract validation and audit processes | One criterion, four subjects. The consensus protocol and smart contract limbs are where a generic IT security policy usually falls over. |
| (g) | Systems and application development and quality assurance | Development and QA practice, which Schedule 1 expands into a secure development lifecycle with mandatory security review gates before deployment. |
| (h) | Physical security and environmental controls | Explicitly including procedures around access to premises and systems. |
| (i) | Procedures for client-initiated VA transactions | The rule asks for procedures 'including, but not limited to, considering multi-factor authentication or any better standard' for transactions that exceed transaction limits set by the client, such as cumulative limits over a period, and for transactions initiated after a change of personal details by the client, such as the address of a VA Wallet. |
| (j) | Client authentication and session controls | Named examples: the maximum incorrect attempts for entering a password, appropriate time-out controls, and password validity periods. |
| (k) | Authentication checks on changes to client details | Adequate authentication checks when a change to a client's account information or contact details is requested. |
| (l) | Client data privacy | On top of Part II of the rulebook: security and authentication of the means of transfer of information, minimisation of the risk of data corruption and unauthorised access, and prevention of information leakage. |
| (m) | Vendor and third-party service provider management | Third-party technology risk, which the Company Rulebook's outsourcing rules then build on. |
| (n) | Monitoring and implementing changes to core protocols not directly controlled by the VASP | The criterion with no equivalent in a mainstream security standard. Chain forks and protocol upgrades are your problem even though you do not control them. |
| (o) | Incident response | Including root cause analysis and rectification activities to prevent reoccurrence. |
| (p) | Supplier probity and staff vetting procedures | Vetting on both the supplier side and the people side. |
| (q) | Governance framework and escalation procedures | For effective decision-making and proper management and control of risks and emergency incidents, 'including but not limited to responses to ransomware and other forms of cyberattacks'. |
| (r) | Hardware and infrastructure standards | Including network lockdown, services and desktop security, and firewall standards. |
| (s) | Sharing cyber threat information and intelligence with other VASPs and entities | The nineteenth criterion, and the one added since 2023. It applies where sharing is in the best interests of the virtual asset market as a whole, and only where sharing does not increase risks to the VASP or force exposure of its confidential information. |
The three criteria that are most often misread
(i) is not a blanket MFA mandate
Criterion (i) is frequently reported as "VARA requires MFA on every virtual asset transaction". The rule text is narrower and softer than that. It asks for procedures regarding the VASP's facilitation of client-initiated virtual asset transactions, "including, but not limited to, considering multi-factor authentication or any better standard" for two specific cases: transactions that exceed transaction limits set by the client, such as cumulative limits over a period of time, and transactions initiated after a change of personal details by the client, such as the address of a VA Wallet.
So the criterion is about a defensible, documented procedure covering those two trigger cases, and it invites a stronger control than MFA rather than fixing MFA as the standard. Where a harder MFA expectation does appear is in Schedule 1, whose authentication control standard expects "multi-factor authentication for all access to systems with cryptographic keys". Both belong in your policy, but they are different requirements from different parts of the rulebook, and quoting one as the other is how a policy fails review.
(n) has no equivalent in ISO 27001 or NIST
Criterion (n) requires the policy to cover "monitoring and implementing changes to core protocols not directly controlled by the VASP, as applicable". Chain upgrades, hard forks and consensus changes are exogenous events that can break custody, settlement or accounting. Nothing in a generic information security standard tells you to write a procedure for them. If you are lifting a policy template from an ISO 27001 programme, this is the clause that will be missing.
(s) is the criterion that made the count 19
Criterion (s) requires the policy to cover sharing cyber threat information and intelligence with other VASPs and entities. The rule attaches two conditions: sharing must be "in the best interests of the Virtual Asset market as a whole, to enhance operational resilience, manage the threat and, where practicable, minimise and/or mitigate the impact of such threat", and it applies "provided that, sharing such information does not increase any risks to the VASP and/or mandate the exposure of confidential information relating to the VASP sharing such information".
In practice this means the policy needs a named decision owner for sharing, a test for when sharing helps the market, and a confidentiality gate. A policy drafted against the 2023 rulebook will not have it.
Where the testable detail lives: Schedule 1
Rule I.B.3 names subjects. Schedule 1 of the same rulebook, which is guidance on the Technology Governance and Risk Assessment Framework, is where numbers appear. These are the ones an assessor can actually check, and they belong in the policy that has to address the criteria above.
- Audit logging. Capture all security-relevant events, store logs securely with tamper-evidence, "maintaining logs for a minimum of one year", and implement real-time alerting for security events.
- Security testing. "Annual penetration testing by qualified third parties", "quarterly vulnerability assessments", continuous automated security scanning, and formal remediation tracking.
- Multi-signature. For high-value operations, the minimum number of signers M must be greater than the total number of signatories N divided by two, with geographic distribution of signing authorities.
- Authentication. Multi-factor authentication for all access to systems with cryptographic keys, hardware-based authentication for critical operations, and continuous validation of session authenticity.
- Smart contracts. Static and dynamic code analysis, independent third-party audits before deployment, comprehensive penetration testing, and regular re-assessment of deployed contracts.
- Workforce. Mandatory endpoint protection for all devices with access to production systems, background checks for personnel with access to sensitive or critical systems, and formalised onboarding and offboarding.
What sits around the policy
Four obligations are routinely written into the Cybersecurity Policy even though they live elsewhere in the rulebook. Keep the cross-references straight, because the policy is assessed against Rule I.B.3 and these are assessed on their own terms.
| Rule | Obligation |
|---|---|
| I.I.1 | Appoint a CISO responsible for compliance with Part I and Part III. "The CISO must be a separate individual from the CO however the CISO may also take on the responsibilities of the Data Protection Officer under Rule II.B.2." Rule I.I.2 adds only that the CISO must be "of sufficiently good standing and appropriately experienced". |
| I.C.1 | Comply with the electronic security requirements of the Dubai Electronic Security Center under Law No. (9) of 2022, with the PDPL and UAE Data Office requirements, and with the CBUAE Consumer Protection Regulation under Notice No. (444) of 2021. |
| I.E.1 | Engage a qualified and independent third-party auditor for vulnerability assessments and penetration testing, including smart contract audits where relevant, "at least on an annual basis and prior to the introduction of any new systems, applications and products". |
| I.K.1 and II.C.2 | Report a material cybersecurity event, or a BCDR-triggering event that materially impacts operations, no later than 72 hours from detection. Separately, notify VARA within 24 hours of telling a data regulator or a data subject about an incident affecting personal data. |
The evidence the rulebook actually names
The rulebook does not publish an evidence schedule for the Cybersecurity Policy. What it does say is narrower and more useful than a generic evidence checklist:
- The policy itself is submitted to VARA in licensing and on request (Rule I.B.1).
- The CISO's annual review has to have happened, so the policy needs a review date and a reviewer (Rule I.B.2).
- "Evidence of tests and audits must be documented by VASPs and made immediately available by them for inspection by VARA, upon VARA's request" (Rule I.E.3). Immediately is the operative word.
- Results of vulnerability assessments, penetration tests and any independent audits are provided to VARA on request (Rules I.E.1 and I.E.4).
- Key access changes are audit-logged, and internal audits of user access removal are performed quarterly (Rule I.D.2).
Anything beyond that list is a sensible practice rather than a VARA requirement, and it is worth being honest with yourself about which is which when you build the file that goes to the regulator.
Frequently Asked Questions
How many criteria must a VARA cybersecurity policy address, 18 or 19?
Nineteen, under the Technology and Information Rulebook in force since 19 June 2025. Rule I.B.3 lists minimum criteria (a) through (s). The 7 February 2023 version of the rulebook ended at (r), which is where the figure of 18 came from. The added criterion, (s), is sharing cyber threat information and intelligence with other VASPs and entities.
Does VARA require multi-factor authentication on every virtual asset transaction?
Not in those words. Criterion (i) of Rule I.B.3 requires procedures for client-initiated transactions "including, but not limited to, considering multi-factor authentication or any better standard" for transactions that exceed client-set transaction limits and for transactions initiated after a change of client personal details. Separately, the Schedule 1 authentication control standard expects multi-factor authentication for all access to systems holding cryptographic keys.
Who has to review the cybersecurity policy, and how often?
The CISO, at least annually. Rule I.B.2 states that VASPs "must ensure that their Cybersecurity Policy is reviewed and updated at least annually by their CISO".
Can the CISO also be the Compliance Officer or the Data Protection Officer?
The CISO cannot be the Compliance Officer. Rule I.I.1 requires the CISO to be a separate individual from the CO. The same rule allows the CISO to take on the Data Protection Officer responsibilities under Rule II.B.2.
Does the cybersecurity policy have to be submitted to VARA?
Yes. Rule I.B.1 requires VASPs to submit the Cybersecurity Policy to VARA for assessment as part of the licensing process, and at any subsequent time on request from VARA.
Is there a VARA cybersecurity policy template?
VARA does not publish one. The rulebook gives the 19 subjects the policy must address in Rule I.B.3 and the risk mitigation standards in Schedule 1. A policy that was drafted from a generic ISO 27001 template will typically be missing criterion (n), on core protocol changes outside the VASP's control, and criterion (s), on threat intelligence sharing.
Keeping the policy reviewable in Venvera
Venvera does not ship a VARA control catalogue today, so there is no preloaded set of 19 VARA criteria to tick off. What the platform does carry is the lifecycle the rule expects around the document:
- The policy module versions a policy and moves it through draft, in review and approved, recording the named approver and the approval date, which is the trail Rule I.B.2's annual CISO review has to leave (verified in product).
- The AI policy review runs an existing policy against a framework and returns the gaps, so a draft can be checked before it goes to the regulator (verified in product).
- The evidence library holds the penetration test and audit reports that Rule I.E.3 says must be produced immediately on request (verified in product).
- The crosswalk engine reuses controls and evidence across the frameworks in the catalogue, including UAE IA and ISO 27001, which is where most of the underlying security work already sits for a Dubai VASP (verified in product).
If you want a fast read on where your security programme stands, run a free compliance check.
Keep the policy, the review and the evidence together
Versioned policies with a named approver, an evidence library, and control reuse across the frameworks you already run.
Book a demo →Primary sources
Every criterion above is quoted from VARA's published rulebook. Confirm the current text before relying on a specific rule.
- VARA Technology and Information Rulebook, Part I Section B: Cybersecurity Policy - Rules I.B.1, I.B.2 and I.B.3, minimum criteria (a) to (s).
- VARA Technology and Information Rulebook - effective 19 June 2025, including Rules I.C, I.D, I.E, I.I, I.K, Part II and Schedule 1.
- Schedule 1: Guidance on Technology Governance and Risk Assessment Frameworks - the risk mitigation standards, including logging, testing, multi-signature and authentication.
- VARA rulebook archive - the 7 February 2023 Technology and Information Rulebook, whose criteria list ended at (r).
Last updated: July 2026. This article is general information, not legal advice. Confirm your obligations with VARA or qualified counsel.
