Learn
🕑 15 min read
📅 March 12, 2026
🏫 Deep Dive
When most VASPs hear “cybersecurity policy,” they think of a 20-page document that sits in a shared drive and gets reviewed once a year. VARA thinks of something very different.
Part I, Section B of the VARA Technology and Information Rulebook (VARA_EN_169_VER20250519) does not just require VASPs to have a cybersecurity policy. It specifies 18 minimum criteria that the policy must address. Each criterion maps to a specific domain of security controls, and VARA expects not just documented policies but operational evidence that each criterion is being implemented, monitored, and continuously improved.
In this article, we break down all 18 criteria one by one - explaining what each requires, what VARA assessors look for during inspections, and how to build a cybersecurity programme that satisfies the letter and spirit of the regulation. Whether you are preparing a VARA licence application or strengthening your existing compliance posture, this is the definitive reference.
⚠️ Regulatory Context
These 18 criteria represent the minimum requirements. VARA may impose additional cybersecurity requirements based on your risk category (Schedule 1), the nature of your VA Activities, and the findings of any supervisory inspection. VASPs in higher risk categories should expect more prescriptive standards for each criterion. Additionally, all cybersecurity measures must align with DESC (Dubai Electronic Security Center) standards - a parallel requirement that many VASPs overlook.
👥
Prerequisite
Before the 18 Criteria: The Mandatory CISO
Before we examine the 18 criteria, it is essential to understand the structural requirement that underpins them: VARA mandates every VASP to appoint a Chief Information Security Officer (CISO) who is directly responsible for the cybersecurity programme, including the development, implementation, and ongoing maintenance of the cybersecurity policy.
The CISO requirements under VARA are notably specific:
- Separation of roles: The CISO must be a separate individual from the Compliance Officer. VARA does not permit these functions to be combined, even in smaller VASPs. The rationale is clear - cybersecurity and regulatory compliance require different expertise, and combining them creates conflicts of interest and capability gaps.
- Direct reporting line: The CISO must report directly to senior management or the board, not through the CTO or IT department. This ensures cybersecurity has independent voice at the leadership level.
- Demonstrated expertise: The CISO must have demonstrable qualifications and experience in information security. VARA may review the CISO’s credentials during the licensing process.
- Outsourced CISO: For smaller VASPs, VARA may permit an outsourced or virtual CISO arrangement, but this requires explicit notification to and approval from VARA. The outsourced CISO must still meet the same qualification standards.
💡 Why This Matters
The CISO is the individual VARA will hold accountable for the cybersecurity programme. During inspections, VARA assessors will interview the CISO directly, review their reports to the board, and assess whether they have the authority and resources to fulfil their mandate. If your CISO is a title without substance, VARA will identify this immediately.
📜
Part I, Section B
The 18 Mandatory Cybersecurity Policy Criteria
Each criterion below is a mandatory component of your VARA cybersecurity policy. We have grouped them into four logical clusters for clarity, but VARA’s rulebook presents them as a single list of minimum requirements.
Cluster A: Core Security Foundations
The baseline policies that define your security posture
1
Information Security
Your cybersecurity policy must establish the overarching information security framework, including the scope of the policy, security objectives, roles and responsibilities, and the information security governance structure. This is the foundational criterion that sets the context for all subsequent controls.
What VARA expects: A clear definition of what constitutes “information assets” in your VASP context (including blockchain infrastructure, wallets, APIs, customer data, trade data), classification of those assets by sensitivity, and documented ownership for each asset category.
2
Data Governance and Classification
A formal data governance framework covering the classification, handling, storage, transmission, and destruction of all data processed by the VASP. Data must be classified according to sensitivity levels (e.g., public, internal, confidential, restricted), with specific controls applied to each classification level.
What VARA expects: A documented data classification matrix, evidence that all data repositories have been classified, data handling procedures for each classification level, and controls for data at rest and in transit. Particular attention to customer KYC/AML data, transaction records, and cryptographic key material.
3
Access Controls
Comprehensive access control policies covering user provisioning, de-provisioning, role-based access control (RBAC), least privilege principles, privileged access management (PAM), and regular access reviews. This applies to all systems - including blockchain infrastructure, administrative consoles, trading engines, and customer-facing platforms.
What VARA expects: Evidence of quarterly access reviews, documented approval workflows for privileged access, automatic de-provisioning of leavers, segregation of duties (especially between those who can initiate and approve transactions), and audit trails for all access changes.
4
Asset Inventory and Management
A comprehensive inventory of all technology assets - hardware, software, network devices, cloud services, blockchain nodes, wallets, and APIs. Each asset must be classified, assigned an owner, and included in the vulnerability management and change management scope.
What VARA expects: An up-to-date Configuration Management Database (CMDB) or equivalent, evidence that asset discovery scans are performed regularly, and proof that decommissioned assets are securely wiped and removed from the inventory.
Cluster B: Network and Operational Security
Controls that protect your infrastructure and operations
5
Network Security
Network architecture must implement defence-in-depth principles: network segmentation, firewalls, intrusion detection/prevention systems (IDS/IPS), DDoS protection, and encrypted communications. For VASPs, this extends to blockchain node infrastructure, API gateways, and the segregation of customer-facing systems from back-office and wallet management systems.
What VARA expects: Network architecture diagrams, evidence of segmentation between production/development/staging environments, firewall rule reviews (at least annually), and DDoS mitigation testing results. Hot wallet infrastructure must be on isolated network segments.
6
System Security and Hardening
All systems must be hardened according to industry benchmarks (e.g., CIS Benchmarks). This includes secure baseline configurations, removal of unnecessary services and default credentials, patch management, and endpoint protection. VARA expects VASPs to maintain documented hardening standards for each system type in their environment.
What VARA expects: Hardening standards documentation, evidence of compliance scanning against those standards, patch management SLAs (critical patches within defined timeframes), and endpoint detection and response (EDR) deployment on all endpoints.
7
Security Monitoring and Logging
Comprehensive logging of security-relevant events across all systems, with centralised log management (SIEM or equivalent), real-time alerting for critical security events, and defined log retention periods. Logs must be tamper-evident and protected from unauthorised modification or deletion.
What VARA expects: A deployed SIEM with documented use cases and alerting rules, evidence of log review processes (daily/weekly), minimum 12-month log retention, and proof that wallet transaction logs, administrative access logs, and authentication events are all captured.
8
Application Security
Secure software development lifecycle (SSDLC) practices for all applications developed or operated by the VASP. This includes secure coding standards, code review processes, static and dynamic application security testing (SAST/DAST), and secure deployment practices. For VASPs, this explicitly includes smart contract development.
What VARA expects: Documented SSDLC procedures, evidence of security testing in CI/CD pipelines, smart contract audit reports from independent third parties, and proof that security findings are tracked to remediation.
9
Encryption and Cryptographic Controls
Policies governing the use of cryptography for data protection, including encryption standards for data at rest and in transit, key management procedures, and approved cryptographic algorithms. This criterion works in conjunction with Part I, Section C (Cryptographic Key and Wallet Management) but focuses on the broader use of encryption across the VASP’s operations.
What VARA expects: Documented encryption standards (minimum AES-256 for data at rest, TLS 1.2+ for data in transit), a cryptographic key management policy, evidence that sensitive data is encrypted in all states, and regular review of cryptographic standards against evolving threats.
Cluster C: Transaction Security and Authentication
Controls specific to virtual asset operations
10
Multi-Factor Authentication for VA Transactions
This is one of the most VA-specific criteria in the rulebook. VARA requires multi-factor authentication (MFA) for all virtual asset transactions - not just user login, but the actual execution of trades, withdrawals, and transfers. This goes beyond what most traditional cybersecurity frameworks require.
What VARA expects: MFA enforced on all customer-initiated VA transactions (withdrawals, transfers, trades above defined thresholds), MFA for all administrative and operational actions on wallet infrastructure, and documented MFA bypass procedures (which must be extremely limited and audited). Hardware-based MFA (FIDO2/WebAuthn) is preferred over SMS-based OTP.
⚠️ Critical Distinction
VARA’s MFA requirement for VA transactions is not the same as MFA for login. Many VASPs implement MFA at the authentication layer (login) but not at the transaction layer (withdrawals, transfers). VARA requires both. A customer who has already authenticated with MFA must still confirm high-value or sensitive transactions with an additional authentication factor. This is a common deficiency found during VARA inspections.
11
Customer and End-User Protection
Security controls specifically designed to protect customers and end users, including account security measures, anti-phishing protections, withdrawal address whitelisting, cooling-off periods for new addresses, and security notifications for account changes. This criterion bridges cybersecurity and consumer protection.
What VARA expects: Documented customer security features (withdrawal whitelisting, email/SMS notifications for account changes, device management), evidence that customers are educated about security risks, and metrics on account compromise incidents and response times.
12
Physical Security
Physical security controls for data centres, offices, HSM storage locations, and any physical infrastructure involved in VA operations. This includes access control systems, CCTV surveillance, environmental controls, and visitor management. For VASPs using cloud infrastructure, physical security requirements shift to vendor due diligence and contractual assurances.
What VARA expects: For on-premise infrastructure: documented physical access logs, CCTV retention policies, clean desk policies, and secure destruction procedures for media. For cloud-hosted: evidence that cloud providers meet equivalent physical security standards (SOC 2 Type II reports, ISO 27001 certification).
Cluster D: Incident, Vendor, and People Management
Organisational and process-level controls
13
Incident Response and Management
A comprehensive incident response plan covering detection, classification, containment, eradication, recovery, and post-incident review. The plan must include defined severity levels, escalation matrices, communication procedures (internal and external), and the 72-hour VARA reporting obligation. Incident response must be tested through regular tabletop exercises and simulations.
What VARA expects: A documented incident response plan, evidence of at least annual incident response exercises, pre-drafted VARA notification templates, a designated incident response team with clear roles, post-incident reports for all significant incidents, and a lessons-learned process that feeds back into control improvements.
14
Ransomware Prevention and Response
VARA specifically calls out ransomware as a separate criterion - reflecting the elevated threat landscape for financial and crypto firms. The policy must address ransomware-specific prevention controls (email filtering, endpoint detection, backup strategies), a documented position on ransom payments, and recovery procedures that do not depend on paying a ransom.
What VARA expects: Documented ransomware-specific playbooks, immutable backup strategies (air-gapped or immutable storage), evidence of ransomware simulation exercises, a board-approved position on ransom payment decisions, and proof that critical systems can be recovered from backups without paying ransoms.
15
Vendor and Third-Party Risk Management
Due diligence, contractual controls, and ongoing monitoring for all third-party technology vendors. This is particularly critical for VASPs that rely on third-party custody solutions, blockchain analytics providers, KYC/AML vendors, cloud infrastructure, and market data providers. The policy must define vendor risk assessment procedures, minimum security requirements for vendors, and exit strategies.
What VARA expects: A vendor register with risk classifications, evidence of due diligence assessments for critical vendors, contractual requirements including audit rights and data protection clauses, regular vendor security reviews, and documented exit plans for critical vendor dependencies.
16
Security Awareness and Training
A mandatory security awareness programme for all employees, contractors, and relevant third parties. Training must cover general cybersecurity hygiene, VASP-specific risks (social engineering targeting crypto employees, SIM swap attacks, insider threats), phishing simulations, and role-specific training for developers, operations staff, and senior management.
What VARA expects: Documented training curricula, evidence of completion (training records), at least annual mandatory training for all staff, phishing simulation results and trend analysis, and specialised training for staff with privileged access or key management responsibilities.
17
Vulnerability Management
A structured vulnerability management programme covering vulnerability scanning (automated and manual), vulnerability prioritisation, remediation SLAs, and exception management. VASPs must conduct regular vulnerability assessments performed by independent third parties, with results documented and remediation tracked to completion.
What VARA expects: Evidence of regular vulnerability scans (at least monthly for external, quarterly for internal), defined remediation timeframes by severity (e.g., critical within 48 hours, high within 7 days), documented exceptions with risk acceptance sign-off, and annual independent vulnerability assessments.
18
Risk Assessment and Continuous Improvement
The final criterion requires VASPs to conduct regular cybersecurity risk assessments, maintain a risk register, and implement a continuous improvement cycle for their cybersecurity programme. Risk assessments must consider evolving threats specific to the VA industry (smart contract exploits, bridge attacks, oracle manipulation, key compromise scenarios) and must be updated at least annually or after significant changes.
What VARA expects: A documented risk assessment methodology, a cybersecurity risk register with risk ratings and treatment plans, evidence of at least annual risk assessment reviews, integration of threat intelligence into risk assessments, and documented improvement initiatives driven by risk assessment findings, incidents, and audit results.
📄
Evidence Management
What Evidence Does VARA Require?
Policies alone do not satisfy VARA. For each of the 18 criteria, VARA expects operational evidence that the controls are implemented and functioning. Here is a summary of the evidence types VARA typically requests:
💡 Practical Tip: Build Your Evidence Library Early
Do not wait until a VARA inspection to start collecting evidence. Build an evidence library from day one, organised by criterion number. Every time you conduct a security review, run a vulnerability scan, complete a training session, or respond to an incident - file the evidence against the relevant criterion. When VARA asks, you should be able to produce evidence within hours, not weeks.
📈
Implementation Strategy
Priority Matrix: Where to Start
Not all 18 criteria carry equal weight in VARA’s assessment. Based on our experience with VARA licensing reviews and inspections, here is how we recommend prioritising your implementation effort:
🔴 Critical Priority (Implement First)
- #10 MFA for VA transactions
- #13 Incident response (72-hour reporting)
- #3 Access controls and PAM
- #9 Encryption and cryptographic controls
- #14 Ransomware response
🟠 High Priority (Implement Second)
- #5 Network security
- #7 Security monitoring and logging
- #8 Application security
- #17 Vulnerability management
- #15 Vendor risk management
🔵 Standard Priority (Implement Third)
- #1 Information security framework
- #2 Data governance
- #6 System hardening
- #11 Customer protection
- #16 Security awareness training
⚫ Foundational (Ongoing)
- #4 Asset inventory
- #12 Physical security
- #18 Risk assessment and continuous improvement
This prioritisation reflects VARA’s inspection focus areas and the criteria most likely to result in licence conditions or enforcement action if found deficient. The “Critical Priority” criteria are the ones VARA assessors review first - if these are not in place, the rest of the assessment is academic.
🔍
Inspection Findings
The Most Common Deficiencies VARA Finds
Based on published VARA enforcement actions and our direct experience supporting VASPs through inspections, these are the cybersecurity deficiencies that appear most frequently:
MFA not enforced on withdrawal transactions
VASPs implement MFA for login but not for transaction execution. VARA considers this a critical deficiency because it is the transaction layer - not the authentication layer - where customer funds are at risk. Every withdrawal, transfer, and high-value trade must require re-authentication.
No ransomware-specific playbook
Many VASPs have a generic incident response plan that mentions ransomware as one threat type. VARA expects a dedicated ransomware response playbook with specific procedures for containment, communication, recovery from backups, and a documented board-level position on ransom payments. Generic incident response does not satisfy Criterion 14.
Vendor risk assessments missing or superficial
VASPs frequently rely on critical third-party services (custody technology, blockchain analytics, cloud hosting, market data) without conducting formal security due diligence. VARA expects documented vendor risk assessments, security questionnaires, and contractual protections - not just commercial agreements.
Security logs not centralised or monitored
VASPs generate logs from multiple systems but do not centralise them in a SIEM or equivalent platform. Without centralised log management, security events cannot be correlated, anomalies cannot be detected, and forensic investigations after incidents are severely hampered. VARA views this as a fundamental operational gap.
No evidence of incident response testing
Having an incident response plan is necessary but not sufficient. VARA expects evidence that the plan has been tested through tabletop exercises, simulations, or actual incident responses. VASPs that cannot demonstrate testing are assumed to have untested - and therefore unreliable - incident response capabilities.
“The 18 criteria in Part I, Section B are not aspirational guidelines. They are mandatory minimum standards that VARA will assess during licensing, annual reviews, and inspections. VASPs that treat cybersecurity as a cost centre rather than a regulatory obligation will find that the cost of non-compliance - licence conditions, fines, and reputational damage - far exceeds the cost of implementation.”
- Analysis based on VARA Technology and Information Rulebook (VARA_EN_169_VER20250519)
About This Article
This analysis is based on the VARA Technology and Information Rulebook (VARA_EN_169_VER20250519), publicly available VARA regulatory publications and enforcement actions, and Venvera’s direct experience supporting VASPs with cybersecurity compliance in Dubai. The 18 criteria reflect the minimum requirements as published; VARA may impose additional requirements based on risk category and VA Activity type.
VARA cybersecurity policy
VASP cybersecurity compliance
VARA 18 criteria
Dubai crypto security
VARA incident response
VARA MFA requirements
Disclaimer: This article is for informational purposes only and does not constitute legal or regulatory advice. VASPs should consult with qualified legal and compliance professionals regarding their specific VARA obligations. Regulatory requirements may change; always refer to the latest VARA publications. The 18 criteria described are based on the Technology and Information Rulebook (VARA_EN_169_VER20250519) as of March 2026.
© 2026 Venvera. All rights reserved.