VARA Cybersecurity Requirements | What Every VASP Must Do
Continue Reading
September 14, 2026
Discover key changes in ISO 9001:2026 vs ISO 9001:2015. Learn about clause updates, quality culture, ethics, climate change, and the transition timeline.
September 2, 2026
What is GDPR? A clear breakdown of its purpose, compliance requirements, key articles, and how it compares to UAE data protection law.
August 28, 2026
What is an information security policy? Learn the core components, policy types, step-by-step writing guide, and get a free template.
The VARA cybersecurity requirements are set out in the Technology and Information Rulebook, which obliges every VARA-licensed VASP to appoint a CISO, keep a Cybersecurity Policy reviewed at least annually, commission independent penetration testing each year, and report a material cyber event to VARA within 72 hours of detection. These are binding Rules, and VARA can ask for your policy and test results at any time.
The rulebook (version dated 19 May 2025) applies to firms licensed by VARA in Dubai, including free zones but excluding DIFC. It sits alongside VARA's Company, Compliance and Risk Management, and Market Conduct Rulebooks, so a VASP has to meet all of them. This guide separates mandatory requirements from guidance, shows what the rulebook does not say (it names no specific standard, such as ISO 27001), and walks through how to build the evidence VARA expects to see.
The VARA cybersecurity requirements are the binding technology, data protection and confidentiality obligations that Dubai's Virtual Assets Regulatory Authority places on every virtual asset service provider (VASP) it licenses. They sit in one document, the Technology and Information Rulebook, and apply in addition to VARA's other rulebooks, not in place of them.
The Technology and Information Rulebook has three operative parts and two schedules. Part I covers technology governance, controls and security: the Cybersecurity Policy, key and wallet management, testing and audit, business continuity, and incident reporting. Part II covers personal data protection. Part III covers confidential information. Schedule 1 offers guidance on building a risk assessment framework, and Schedule 2 holds the definitions.
The rulebook is issued under, and forms part of, the Virtual Assets and Related Activities Regulations 2023. A VASP must also comply with the Company, Compliance and Risk Management, and Market Conduct Rulebooks, plus any rulebook specific to its licensed activities. Responsibility is divided inside the firm. The Chief Information Security Officer (CISO) answers for Parts I and III, while Part II requires a Data Protection Officer, a role the same person can hold.
The rulebook applies to every entity licensed by VARA to carry out a virtual asset activity in the Emirate of Dubai. It defines the Emirate as all zones across Dubai, including Special Development Zones and Free Zones, but excluding the Dubai International Financial Centre (DIFC). A crypto firm licensed by VARA in a Dubai free zone is covered. A firm operating inside DIFC is not.
"UAE" in a search query does not mean nationwide coverage. VARA is a Dubai regulator, and the rulebook binds firms with a VARA license. A company in another emirate, or in DIFC, answers to different regulators, so confirm which regime governs your activity before using this rulebook as your baseline. Coverage can also extend beyond the UAE in one respect: Part II requires a VASP to comply with data protection laws outside the UAE that apply to its activities, wherever they are conducted.
Everything in the rulebook is a binding Rule unless it says otherwise, and Schedule 1 is the exception. VARA publishes it as Guidance, written in "expected to" language, and states that it does not reduce or amend any Rule. Its standards are specific. Examples include multi-signature arrangements where the required signers exceed half of the total signatories, security logs kept for at least one year, and quarterly vulnerability assessments alongside annual third-party penetration testing.
Guidance still matters in practice, because Rule I.A.6 points VASPs to Schedule 1 when they design their Technology Governance and Risk Assessment Framework. The safest reading is to treat it as the benchmark your framework will be measured against, and to document a reason for any departure. Read the verb in each Rule too. Most requirements use "must", but some, such as continuous monitoring under Rule I.E.2, use "should", and your policy should show how you meet them.
The current Technology and Information Rulebook is the version dated 19 May 2025. VARA issued updated versions of all twelve of its rulebooks together, with a 30-day transition period and full compliance required by 19 June 2025. Firms whose policies were written against the 2023 rules should check them against the 2025 text, particularly the testing, threat-led penetration testing and key management provisions.
The rulebook states that it may be amended from time to time, and VARA amends individual rulebooks on its own schedule. Confirm the version on VARA's rulebook site before you rely on any rule number or deadline, and record the version you assessed against in your compliance file.
A VARA-licensed VASP has eight recurring cybersecurity obligations under the Technology and Information Rulebook: a dedicated CISO, an annually reviewed Cybersecurity Policy, annual independent testing, threat-led testing on VARA's request, an annually tested continuity plan, quarterly key access audits, and two separate incident reporting clocks. The table below shows each one with its rule reference, timing, and the evidence to keep on file.
Requirement | Rule | Timing | Evidence to Keep |
|---|---|---|---|
Appoint a CISO, separate from the Compliance Officer | I.I.1–2 | Ongoing | Appointment record, documented experience and standing, proof the role is held by a different person from the Compliance Officer |
Cybersecurity Policy submitted to VARA | I.B.1–2 | At licensing; CISO review at least annually | Current policy version, submission copy, dated record of each annual CISO review |
Independent vulnerability assessment and penetration testing | I.E.1, I.E.3 | Annually, and before new systems, applications or products | Independent tester's report, remediation tracking, smart contract audit reports where relevant |
Threat-led penetration testing (TLPT) | I.E.5–7 | Only if VARA notifies you | Findings summary, remediation plans, documentation that the test followed the rulebook's conditions, tester credentials and contract terms |
BCDR Plan tested and updated | I.H.1 | Annually | Current plan, annual test results, update log |
Report a material cyber event to VARA | I.K.1 | Within 72 hours of detection | Detection timestamp, report to VARA covering nature, scope, impact and mitigation steps, and a record of any other authorities notified |
Notify VARA of a personal data incident | II.C.2 | Within 24 hours after notifying a data regulator or data subject | Copy or summary of the regulator or data subject notification, VARA notification record |
Key access audits | I.D.2(d) | Quarterly | Audit records of access log reviews and user access removals, onboarding and offboarding documentation |
The two reporting deadlines are the ones most often confused, because they start from different events. The 72-hour clock in Rule I.K.1 runs from detection of a material cybersecurity event, or of an event that triggers your BCDR Plan and materially affects operations. The 24-hour clock in Rule II.C.2 runs from the moment you notify a data regulator or a data subject about an incident affecting personal data. A single incident can start both clocks, so your incident response playbook should track them separately.
The evidence column reflects a standing expectation in the rulebook. Rule I.E.3 requires you to document evidence of tests and audits and make it immediately available for VARA inspection on request, and Rule I.E.1 requires you to provide test results when VARA asks. A control that exists but cannot be evidenced will be hard to defend in a review.
This table covers the recurring, time-bound Rules. It does not include Schedule 1 cadences, such as quarterly vulnerability assessments, because Schedule 1 is guidance rather than binding Rule. It also omits ongoing obligations without a fixed interval, including key management, algorithm governance, and transaction screening, which the sections that follow cover in full.
The Technology Governance and Risk Assessment Framework is the VARA cybersecurity framework, the documented system of policies, processes, procedures and controls that a VASP must build to manage the technology risks in its business. Rule I.A of the Technology and Information Rulebook requires it, Schedule 1 explains what a good one covers, and the CISO is responsible for making sure it works. For background on how these functions fit together, see our guide to governance, risk and compliance.
Rule I.A asks for three things. The framework must be proportionate, meaning it reflects the nature, scale, and complexity of the business; the diversity of its operations; the volume and size of its transactions; and the level of risk inherent in its activities. A regional custodian and a high-volume exchange should not use the same framework. It must use defense-in-depth for cybersecurity risks, so no single control bears the full burden. It must also cover all technologies relevant to the VASP's business and activities, not just the trading platform.
The framework has to state the firm's cybersecurity objectives, including the competency expected of staff and, where relevant, end users and clients. It must also address system development and maintenance, operations controls, back-up controls, capacity and performance planning, and availability testing.
Rule I.A.5 then makes it a living document. VASPs must monitor and maintain its effectiveness and review, update, and arrange testing of its policies, processes, procedures, and controls "periodically". The rule sets no fixed interval, unlike the annual reviews required for the Cybersecurity Policy and the BCDR Plan. It lists what should drive the review: the macroeconomic environment, emerging technology risks, and international standards and industry best-practice codes. Set and document your own cadence, and record what triggered any off-cycle review.
Schedule 1 is Guidance rather than a binding Rule, but it describes what the framework should contain. It sets out 30 standards across five risk categories.
The organizational category covers the framework itself and the surrounding enterprise. VARA expects a documented security framework that addresses both wallet infrastructure and enterprise security, a formal risk assessment methodology that accounts for risks in centralised and decentralised structures, and clear security accountability. It also covers secure development, workforce security, infrastructure documentation such as asset inventories and data flow mappings, and third-party technology service providers, where due diligence and written contracts are expected.
The technical category is the largest, with 13 standards covering key generation, wallet creation, key storage, smart contract security, multi-signature arrangements, authentication, developer workstations, security testing and audit logging. Detection and response adds seven standards, from transaction monitoring and internal user activity monitoring to forensic capability, on-chain analysis and post-incident remediation. The customer VAs category addresses customer authentication, withdrawal controls, user education and wallet concentration risk.
The fifth category, digital operational resilience, sets a testing standard: an independent external party should run a programme of tests, at least yearly, on all systems and applications supporting Critical or Important Functions. That term is defined in VARA's Company Rulebook. Treat the five categories as a checklist for your risk register, and note where you meet, adapt or consciously depart from each standard.
The rulebook tells VASPs to consider "international standards and industry best practice codes" but names none. It does not require ISO/IEC 27001 certification, the NIST Cybersecurity Framework, or any other specific standard. Neither is a shortcut to compliance, and neither replaces the Rules.
They are useful as mapping aids. An ISO 27001 management system gives you a structure for risk assessment, policy ownership, internal audit and continual improvement, which supports the organisational category. The NIST Cybersecurity Framework's function-based structure maps naturally onto detection and response. VARA has not published an official crosswalk, so build your own and keep it in the compliance file.
Be aware of the gap. General-purpose standards are technology-neutral and won't prescribe the crypto-specific controls Schedule 1 describes, such as HSM-backed key storage, multi-signature thresholds, key compromise response plans or on-chain analysis capability. Certification tells a reviewer your management system is sound, but it does not show that your key management and wallet controls meet VARA's expectations.
A VASP's Cybersecurity Policy must cover at least 19 topics listed in Rule I.B.3 of the Technology and Information Rulebook, from client authentication and vendor management to ransomware escalation. The policy is submitted to VARA during licensing and again whenever VARA requests it, and the CISO must review and update it at least annually. It must also help the VASP comply with applicable information security, data protection, and privacy laws, including Part II of the rulebook and the UAE's Personal Data Protection Law (PDPL).
The 19 topics fall into groups. Several are infrastructure fundamentals: information security, data governance and classification, access controls, capacity and performance planning, systems operations and availability, physical security and environmental controls, and hardware and infrastructure standards such as network lockdown, desktop security and firewalls. One covers technical assurance: systems and network security, consensus protocol methodology, and code and smart contract validation and audit processes. Another covers systems and application development and quality assurance. The remaining topics fall into the three areas below.
Four of the 19 topics govern how clients interact with the platform. The policy must set procedures for how the VASP facilitates client-initiated transactions, including whether to require multi-factor authentication, or a stronger standard, for transactions above client-set limits (including cumulative limits over a period) and for transactions made after a change in client details such as a wallet address. The rule's wording asks the VASP to consider these safeguards, so the policy should record the decision and the reasoning either way.
The policy must also define client authentication and session controls, including the maximum number of incorrect password attempts, timeout controls and password validity periods. It must require authentication checks for any request to change account or contact details, and address client data privacy, including secure transfer of information, protection against data corruption and unauthorized access, and prevention of leakage.
Schedule 1, which is guidance, sets a higher bar for customer authentication. It expects strong multi-factor authentication, prohibits instant messaging verification for high-risk operations, and recommends withdrawal controls such as tiered limits and cooling periods for large transactions.
The policy must cover vendor and third-party service provider management, and supplier probity and staff vetting. Rule I.D.2(e) adds that VASPs must regularly assess the security of software integrations with external parties. Schedule 1 guidance describes what good looks like: due diligence on each provider, written contracts, and multi-vendor strategies where practicable. It also expects background checks for personnel with access to sensitive or critical systems.
Two further topics are easy to overlook. The policy must set out how the VASP monitors and implements changes to core protocols it does not directly control, which matters for firms building on public chains. It must also cover sharing cyber threat information with other VASPs and entities when that serves the wider virtual asset market, provided sharing does not raise the VASP's own risk or require exposing confidential information. Define who may approve a disclosure and what gets redacted.
Rule I.B.3 requires incident response procedures that include root cause analysis and rectification activities to prevent recurrence. It also requires a governance framework and escalation procedures for decision-making and management of emergency incidents, explicitly naming responses to ransomware and other cyberattacks.
The rulebook does not say whether a VASP may or should pay a ransom, so your escalation procedure has to assign that decision, name who makes it, and record how it is made. The policy should also link to the two reporting clocks: 72 hours to notify VARA of a material cyber event (Rule I.K.1) and 24 hours to notify VARA of a personal data incident after informing a regulator or data subject (Rule II.C.2). Section 8 covers both in detail.
Every VARA-licensed VASP must appoint a Chief Information Security Officer (CISO) who is responsible for ensuring the firm complies with Parts I and III of the Technology and Information Rulebook. The CISO must be a different person from the Compliance Officer, must be of "sufficiently good standing" and "appropriately experienced", and must review the Cybersecurity Policy at least annually. Rule I.I sets out these requirements.
Rule I.I.1 states that the CISO must be a separate individual from the Compliance Officer (CO). The two roles cannot be combined, even at a small firm. This keeps security accountability separate from regulatory compliance oversight, and Rule I.I.3 reinforces this by requiring Senior Management to allocate duties and apportion roles to prevent conflicts of interest.
The rulebook does allow one combination. The CISO may also take on the responsibilities of the Data Protection Officer (DPO), and Rule II.B.2 confirms the DPO can be the same individual as the CISO. The split of responsibility matters here. The CISO is answerable for Parts I and III (technology governance, controls, and confidential information), while the DPO handles Part II on personal data protection. A combined CISO and DPO therefore carries both sets of duties and reporting obligations, including the 72-hour and 24-hour notifications covered in section 8. Firms that combine the roles should confirm the person has the capacity and the competence for both.
Rule I.I.2 requires the CISO to be of sufficiently good standing and appropriately experienced. The rulebook does not define either phrase, and it does not name a required certification, years of experience, or qualification. Anything more specific than that is your own standard, not VARA's.
Because VARA can review your arrangements, build a file that lets you justify the appointment. Keep the CISO's CV and relevant professional history; evidence of experience in security governance and, where relevant, in virtual asset or DLT environments; any professional certifications held; the outcome of background checks; and the board or Senior Management approval of the appointment. Record the reporting line and the authority the role holds, since the CISO has to be able to act on the responsibility Rule I.I.1 assigns. Update the file when the CISO changes, and if the CISO's duties expand to include the DPO role, record how you assessed capacity for both.
The rulebook does not say. Rule I.I.1 requires a VASP to "appoint a Chief Information Security Officer" and does not state whether the person must be a full-time employee, may be contracted, or may serve more than one client. It does not mention a virtual CISO (vCISO) or outsourced arrangement at all, and it neither permits nor prohibits one.
Silence is not approval. The obligation is outcome-based: the CISO must ensure the VASP complies with Parts I and III, review the Cybersecurity Policy each year, and stand behind the firm's controls. Judge an arrangement by whether it can deliver that in practice, including availability during an incident, given the 72-hour reporting window. If you are considering a vCISO, confirm VARA's position directly with the Authority during licensing or through your supervisory contact, and keep the response on file. Our CISO vs vCISO guide compares the two models in more detail.
VARA's key and wallet rules require a VASP to remove any single point of failure in access to client assets, store key backups apart from the primary keys, and rotate or reassess keys whenever a signatory leaves. Rule I.D of the Technology and Information Rulebook sets these binding obligations. Schedule 1 adds guidance on multi-signature thresholds, hardware security modules (HSMs) and cold storage. Rule I.D.1 requires the firm's framework to address key and wallet generation, transaction signing and approval, key and seed phrase storage, and wallet creation and management.
Rule I.D.2 requires a VASP to safeguard access to virtual assets in line with industry best practice and ensure no single point of failure in its access to, or knowledge of, the assets it holds. In practice, no one person, device or location should be able to move client assets alone, and no one person should be the only holder of the knowledge needed to recover them.
The storage rule is specific. Keys stored online, or in any one physical location, must be insufficient on their own to conduct a virtual asset transaction, unless appropriate controls make physical access insufficient. Keep backups of keys and seed phrases in a separate location from the primary key or seed phrase. A backup stored beside the primary fails the rule, no matter how well protected the room is.
Access to systems and data is limited to individuals with a demonstrable business need, with proper identification and an access log (Rule I.D.4). Rule I.D.2(c) adds an audit log recording each change of access to keys. Schedule 1 guidance goes further, expecting HSMs for critical key storage, separation of key components across physical locations and cryptographic methods, and regular testing of backup and recovery procedures. A backup that has never been restored is an untested assumption.
If a staff member with access to a key, including a key in a multi-signature arrangement, leaves the VASP, Rule I.D.2(c) requires assessing whether to generate a new key. The rule asks for an assessment, not automatic rotation, so the decision and its reasoning belong in the compliance file.
Revocation has to be immediate. The key generation process must ensure that a revoked signatory has no access to the backup seed phrase and no knowledge of the phrase used to create the key. That is a design constraint on how keys are created, so a firm that let one person see the seed phrase at generation has a problem it cannot fix at offboarding without generating a new key.
The rulebook also sets a quarterly cadence. VASPs must audit the removal of user access every quarter by reviewing access logs and verifying access. They must also document staff onboarding and offboarding, and document the permission to grant or revoke access to each role in the key management system. Four audits a year, each leaving a written record, is the minimum evidence trail.
Schedule 1 is guidance, but it specifies wallet design. For multi-signature arrangements protecting high-value operations, VARA expects the minimum number of required signers (M) to exceed half the total number of signatories (N), so M > N/2. A 2-of-3 or 3-of-5 setup satisfies this. A 2-of-4 setup does not, because two is not greater than half of four. The guidance also expects signing authorities to be geographically distributed, authorisation mechanisms to be diverse, duties to be separated between signers, and signature processes to be tested regularly.
On key creation, VARA expects HSMs where possible, formal validation of key-generation routines, separation of duties, and full audit logging. On concentration risk, it expects controls that diversify client assets across wallets, including cold storage wallets, VARA-licensed custody providers and physically distributed servers.
Treat these as the benchmark your framework will be measured against, and document any departure with a reason. A 2-of-4 scheme may have a sound operational rationale, but it should be a recorded decision, not an oversight.
Schedule 1 expects a formal key compromise response plan with clear activation triggers, pre-authorised emergency response procedures and formal communication protocols. It also expects rapid key rotation capability, and regular testing and simulation. Pre-authorisation matters because a compromise is the wrong moment to decide who may freeze withdrawals or rotate signers.
The plan should connect to the wider incident obligations. A key compromise is likely to be a material cybersecurity event, which starts the 72-hour reporting clock to VARA under Rule I.K.1. Post-incident, Schedule 1 expects complete rotation of all secret components, including passwords, keys and key shards, followed by rebuilding systems from secure baselines and formally verifying that the attacker has been removed. Section 8 covers incident reporting in full.
A VARA-licensed VASP must have a qualified, independent third party run vulnerability assessments and penetration testing at least once a year and before introducing any new system, application, or product. Rule I.E of the Technology and Information Rulebook also requires smart contract audits where relevant, and lets VARA order threat-led penetration testing (TLPT) on live production systems. Test evidence has to be documented and made immediately available to VARA on request.
Rule I.E.1 says the auditor must be "qualified and independent", and the rulebook defines neither word. It does not name an approved list of testers or require a particular accreditation for the annual test, so you must justify the standard.
In practice, independence means the tester has no stake in the outcome. A team that built or operates the system should not grade it, and neither should a vendor whose product is being assessed. Keep the engagement letter, scope, methodology, the tester's credentials, and a short note explaining why you consider them independent. These are practical suggestions, not VARA wording, but they are the documents a reviewer would ask for.
The trigger is broader than the calendar. The annual test is one requirement, and testing before new systems, applications and products is another. A new custody integration or a new trading feature therefore needs its own assessment before launch. Rule I.E.2 adds that a VASP should maintain continuous monitoring functions and must perform infrastructure and application security testing, and internal and external vulnerability audits, regularly and at VARA's request. Rule I.E.4 separately requires independent auditors to regularly audit your management processes and regulatory compliance.
Where a VASP's business and activities involve smart contracts, the Rule I.E.1 testing must include comprehensive audits of their effectiveness, enforceability and robustness. The Cybersecurity Policy must also cover code and smart contract validation and audit processes (Rule I.B.3).
Schedule 1 describes what a mature process looks like. It expects static and dynamic code analysis, independent third-party audits before deployment, formal verification where applicable, comprehensive penetration testing, and regular reassessment of deployed contracts. The last point matters because an audit is a snapshot. A contract that changes through an upgrade, or that interacts with new external protocols, needs re-review. Our smart contract security audit guide covers the audit process and common vulnerability classes in detail.
The rulebook defines TLPT as a framework that mimics the tactics, techniques and procedures of real threat actors, delivering a controlled, intelligence-led red team test of a VASP's critical live production systems. It is not a routine obligation. Under Rule I.E.5, VARA may notify a VASP that it must carry out TLPT when VARA considers it necessary and proportionate, taking into account specific risks the VASP faces, the criticality of its business and activities, and any other relevant risks.
When notified, the conditions are strict. An external tester must conduct it. It may cover Critical or Important Functions and be performed on live production systems. Where third-party service providers must be in scope, the VASP must ensure they participate. The VASP must also mitigate risks to data, assets and operations during the test. At the end, the VASP and the tester produce a summary of findings, remediation plans and documentation showing the test met the rulebook's conditions, and the VASP promptly gives all of it to VARA.
Rule I.E.7 sets out what the tester must demonstrate. It must be suitable and of good repute, with technical and organisational capability and specific expertise in threat intelligence and penetration testing. It must be certified by an accreditation body or adhere to formal codes of conduct or ethical frameworks. It must provide independent assurance or an audit report on how it manages the risks of carrying out the test, including protection of the VASP's confidential information. It must also hold professional indemnity insurance that covers misconduct and negligence. Rule I.E.8 adds that contracts with testers must require sound management of TLPT results and data, and must not create new risks for the VASP. Because the notice can arrive at any time, vet a shortlist of qualified providers before you need one.
Schedule 1 is guidance, and its security testing standard is more demanding than the binding Rule. It expects annual penetration testing by qualified third parties, quarterly vulnerability assessments, continuous automated security scanning, regular best-practice security exercises for high-value systems, and formal remediation tracking. It also expects regular testing and testing before any update to a production system, which is broader than the Rule's trigger of new systems, applications, and products.
The digital operational resilience standard adds that independent external parties should run tests at least yearly on all systems and applications supporting Critical or Important Functions. It lists 12 types of tests a program should draw on, including vulnerability scans, network security assessments, source code reviews, scenario-based tests, and penetration testing. It also expects issues to be classified, remedied and independently validated as fixed. A finding with no tracked remediation is the weak point in most testing programmes, so keep a register that shows each issue from discovery to verified closure.
A VARA-licensed VASP runs on two separate incident clocks. It must report a material cybersecurity event to VARA within 72 hours of detection (Rule I.K.1). It must tell VARA within 24 hours after it notifies a data regulator or data subject about a personal data incident (Rule II.C.2). The firm also needs a business continuity and disaster recovery plan tested every year. Schedule 1 guidance expects real investigation, on-chain tracing and remediation capability behind both.
Rule I.K.1 covers two triggers: a material cybersecurity event, or an event that triggers the BCDR Plan and materially affects business operations. The VASP must report to VARA as soon as reasonably practicable and no later than 72 hours from detection, so 72 hours is a ceiling, not a target. The report must describe the nature, scope, and impact of the event; the steps being taken to mitigate it; and whether any notifications have gone to authorities other than VARA.
Rule II.C.2 works differently. It applies to any incident that affects, or potentially affects, personal data. Its clock starts when the VASP notifies a data regulator (in the UAE or elsewhere) or a data subject, and VARA must hear as soon as possible and within 24 hours of that notification. The VASP provides a summary of the notification and, where the regulator is in the UAE, a copy of the report, unless applicable law prohibits it and the VASP can demonstrate that to VARA's satisfaction. The deadline for notifying the regulator or data subject comes from the applicable data protection law, not from this rulebook.
Take a ransomware attack that exfiltrates customer data. Detection starts the 72-hour clock immediately. If the VASP notifies a data regulator at hour 30, the 24-hour clock starts then and runs to hour 54, while the event report to VARA is still due by hour 72. The clocks are independent, so delaying the regulator notice postpones only the second one. The rulebook does not say a single report can satisfy both obligations, so track the content requirements for each separately.
Rule I.H.1 requires a VASP to implement, maintain, test and update a Business Continuity and Disaster Recovery (BCDR) Plan every year. The plan must address eight elements: the events that trigger it (such as cybersecurity events and technical failures) and how their nature, scope and impact are assessed; resource requirements; recovery priorities for critical functions and essential data; communication arrangements for internal and external parties; processes to validate the integrity of information affected by an interruption; procedures to mitigate operational impact, including escalation to designated personnel; an alternative site able to sustain operations for a reasonable period; and procedures to remediate exploited vulnerabilities once stable operations resume.
Rule I.H.2 adds a crypto-specific layer. The plan should account for factors particular to virtual assets and distributed ledger technology, including network malfunction, data loss or compromised data integrity, and key storage and maintenance of authorization layers. The rule says "should", but a plan that ignores these would be hard to defend. A practical test is whether the plan says who can authorise a withdrawal freeze or a key rotation when the usual signers are unreachable. That check is a suggestion, not VARA wording.
Schedule 1 is guidance, and its detection and response category sets out seven standards. Four cover detection: transaction monitoring, internal user activity monitoring, enhanced monitoring of developer and signing systems, and tactical hardening. The other three cover what happens after a compromise. For investigation, VARA expects dedicated forensic resources, internal or contracted, that can be deployed in real time or on immediate notice, along with secure evidence collection, chain-of-custody documentation and root cause analysis. That fits Rule I.B.3, which already requires incident response procedures to include root cause analysis.
VARA also expects on-chain analysis capability: transaction tracing tools, wallet attribution, and collaboration with other VASPs to trace stolen funds. Rule I.F.2 backs this with a binding requirement to run distributed ledger tracing software that screens incoming and outgoing transactions and wallet addresses.
For remediation, the guidance expects complete rotation of all secret components, including passwords, keys and key shards. It also expects systems rebuilt from secure baselines with enhanced monitoring, formal verification that the attacker has been removed, and a post-incident review. Security logs feed all of this. Schedule 1 expects tamper-evident logs kept for at least a year, so investigators have history to work from.
VARA requires every VASP to comply with the UAE's Personal Data Protection Law (PDPL) and any other applicable data protection law, run a written compliance program, and appoint a Data Protection Officer (DPO). It also requires VASPs to protect client information under Part III, which limits how that information is used and shared. Part II covers personal data, Part III covers confidential information, and both sit alongside the technical controls in Part I.
Rule II.A.1 requires compliance with all applicable data protection and privacy requirements in every relevant jurisdiction. Within the UAE, that means the PDPL (Federal Decree-Law No. 45 of 2021) plus any sectoral or free zone laws that apply to the firm. Outside the UAE, it means any data protection law that applies to the VASP's activities, wherever they are conducted. A Dubai-licensed exchange serving customers abroad may therefore answer to foreign regimes as well, such as the GDPR where it applies. Rule I.C.1 adds that the firm's Technology Governance and Risk Assessment Framework must comply with the PDPL, its executive regulations and any cybersecurity requirements from the UAE Data Office.
Rule II.B sets two organisational duties. The VASP must produce and implement a written compliance programme that protects the privacy of personal data. It must also appoint a DPO with the competence and experience to perform the statutory duties, including those under Article 11 of the PDPL, and create a function responsible for managing and protecting personal data in proportion to the risk. The DPO can be the same person as the CISO.
On cross-border data, the rulebook does not set its own transfer mechanics. Rule II.A.2 says compliance must cover where data may be stored or located and how it is transferred, so the applicable law decides what is allowed. Map where your data actually sits, including cloud regions and vendor systems, before you assess it against the PDPL and any foreign law.
One requirement here is easy to miss. Rule II.C.1 obliges a VASP to take every step needed, including notifications, contractual provisions and consents, so that VARA can access information about its Part II compliance regardless of where that information is stored. If a vendor holds your data offshore, your contract with them should not block that access. Section 8 covers the 24-hour rule for notifying VARA of a personal data incident (Rule II.C.2).
Part III is narrower than Part II and is the CISO's responsibility. Rule III.A.1 requires a VASP to take all reasonable steps to protect the ongoing confidentiality of client information and related records through enforced policies, procedures, and mechanisms, whether or not a confidentiality agreement exists. Rule III.A.2 limits use of that information to the purposes for which it was provided.
Three rules deal with people. Staff must be familiarised with the internal policies on collecting and processing confidential information and with Part III itself, and the VASP must periodically certify that staff comply. The rulebook sets no interval for that certification, so choose one and document it. Staff must not share confidential information within the firm or with outside entities unless it is necessary for the related virtual asset activity (Rule III.A.4). Neither the VASP nor its staff may use or share confidential information to trade virtual assets (Rule III.A.5).
Part III also interacts with threat intelligence sharing. Rule I.B.3 lets a VASP share cyber threat information with other firms when it benefits the wider market, but only if sharing does not require exposing confidential information. In practice, firms can share indicators of compromise, but client records and identifying details must stay out.
A VARA-licensed VASP must build its cybersecurity framework to comply, to the extent applicable, with three other UAE instruments: the electronic security standards of the Dubai Electronic Security Center (DESC), the Personal Data Protection Law (PDPL), and the Central Bank's Consumer Protection Regulation. Rule I.C.1 names all three, and its wording ("including but not limited to") makes the list non-exhaustive.
The DESC reference points to the electronic security requirements and standards the Centre has adopted under Dubai Law No. (9) of 2022 on the provision of digital services in the Emirate. The PDPL reference covers Federal Decree-Law No. (45) of 2021, its executive regulations, and any cybersecurity requirements the UAE Data Office imposes. The third covers the Consumer Protection Regulation issued under Central Bank Notice No. (444) of 2021, together with any cybersecurity requirements the Central Bank of the UAE (CBUAE) sets.
The rulebook does not say which specific DESC standards or CBUAE provisions apply to a given VASP. The qualifier "to the extent applicable" leaves that judgement to the firm, so document how you assessed each instrument and why you concluded it does or does not apply. Where the PDPL applies, section 9 above covers how VARA's Part II builds on it.
These laws sit outside the Technology and Information Rulebook and change independently of it, so a compliance file should record the version of each one you assessed against. For a wider view of how UAE cybersecurity obligations fit together across regulators, see our UAE cybersecurity regulations guide.
To comply with the VARA cybersecurity requirements, a VASP works through five steps: assess gaps against Parts I to III of the Technology and Information Rulebook, build the framework and Cybersecurity Policy, commission independent testing, set up incident notification, and keep an evidence pack VARA can inspect on request. Appoint the CISO before anything else, because Rule I.I.1 makes that person responsible for Parts I and III and the policy goes to VARA at licensing. The rulebook does not prescribe this order. It is a practical sequence.
Start by listing every binding Rule in Parts I, II and III and recording, for each one, the current control, its owner, the evidence you hold, and its status. Use the table in section 2 as the spine. Keep Schedule 1 in a separate column, since it is guidance, and mark each standard as met, adapted or consciously departed from, with a reason.
Some Rules are easy to miss because they sit outside the headline topics. Check the quarterly key access audits (Rule I.D.2), the distributed ledger tracing software (Rule I.F.2), algorithm governance if your firm uses algorithms (Rule I.G), staff awareness of cybersecurity risks (Rule I.J), and the DPO appointment (Rule II.B). Also decide, and record, whether the DESC standards, PDPL and CBUAE regulation named in Rule I.C.1 apply to you. If you have not yet applied for a licence, finish this step first, since the Cybersecurity Policy must be submitted with the application.
Write the Technology Governance and Risk Assessment Framework first, because the policy hangs off it. Rule I.A requires it to be proportionate to your business and to use defence-in-depth, so record why your controls suit your scale and risk. Then write the Cybersecurity Policy to cover all 19 topics in Rule I.B.3. Because VARA assesses it, address each topic under its own heading and cross-reference the rule number, so a reviewer can find each one without searching. These are presentation suggestions, not VARA requirements.
Build the operating procedures the policy promises at the same time: key generation, storage, and backup procedures; signatory onboarding and offboarding; the BCDR Plan; and the personal data compliance program. Set the CISO's annual policy review and the BCDR annual test as recurring calendar items from day one. The rulebook sets no interval for the framework review beyond "periodic", so choose one and document it.
Rule I.E.1 requires a qualified, independent third party to run vulnerability assessments and penetration testing every year and before any new system, application or product goes live, including smart contract audits where relevant. Firms often miss the pre-launch trigger, so build testing gates into the product roadmap rather than treating the annual test as sufficient. Book testers early enough to fix findings before launch.
Keep the engagement letter, scope, methodology, findings report and a remediation register that tracks each issue to verified closure. Schedule 1 guidance goes further, expecting quarterly vulnerability assessments and continuous scanning, so plan for those if you want to meet the benchmark. Separately, shortlist providers that could satisfy the tester requirements in Rule I.E.7, since VARA can order threat-led testing at any time.
Write down, before an incident, how the two clocks will be handled: 72 hours from detection for a material cybersecurity event (Rule I.K.1) and 24 hours after notifying a data regulator or data subject for a personal data incident (Rule II.C.2). Name who decides whether an event is material, who drafts the VARA report, who approves it, and who notifies other authorities. The report must state the nature, scope and impact of the event, the mitigation steps, and any other notifications made, so prepare a template with those fields.
Log the detection time as soon as you identify an event, because the 72-hour clock starts at detection. Rehearse the playbook with a tabletop exercise that includes a ransomware scenario, since Rule I.B.3 requires escalation procedures covering ransomware and other cyberattacks. The exercise is a suggestion, and Schedule 1 separately expects key compromise response plans to be tested and simulated regularly.
Rule I.E.3 requires evidence of tests and audits to be documented and made immediately available for inspection when VARA asks, and Rules I.E.1 and I.E.4 require test and audit results to be provided on request. Keep the pack current and in one place, rather than assembling it after a request arrives. A sensible pack contains:
The CISO and DPO appointment records and the CISO's experience file
The current Cybersecurity Policy, framework, and annual review log
Testing reports, smart contract audit reports, and the remediation register
The BCDR Plan and annual test results
Quarterly key access audit records and onboarding and offboarding documentation
The incident log, detection timestamps and notification records
Staff awareness and confidentiality certification records
The easiest VARA cybersecurity compliance gaps to spot are the ones where a firm's practice contradicts a single sentence of the Technology and Information Rulebook: relying on ISO 27001 as proof of compliance, testing only existing systems, mixing up the two reporting clocks, storing key backups beside the primary key, leaving the Cybersecurity Policy unreviewed, and giving the CISO and Compliance Officer roles to one person. Each gap below is drawn directly from the rule text. The rulebook publishes no enforcement statistics, so the list shows what a reviewer can check, not how often firms fail.
The rulebook names no standard. Rule I.A.3 asks the framework to consider "international standards and industry best practice codes", and Schedule 1 (guidance) expects the adoption of "best in class standards", but neither requires ISO/IEC 27001 certification or treats it as satisfying the Rules. Certification shows that a management system exists. It says nothing about whether key backups sit in a separate location, whether penetration testing was independent, or whether the 72-hour report can be filed on time. Use ISO 27001 as a mapping aid and test each VARA Rule separately.
Rule I.E.1 requires independent vulnerability assessment and penetration testing at least annually and also before introducing any new system, application or product. A firm that books one annual test against its live platform meets the first trigger and misses the second. A new custody integration, wallet feature or smart contract needs its own assessment before launch. Schedule 1 guidance goes further, expecting testing before any update to a production system, so build testing gates into release planning.
Two rules, two start points. Rule I.K.1 gives 72 hours from detection of a material cybersecurity event, and Rule II.C.2 gives 24 hours after the VASP notifies a data regulator or data subject of a personal data incident. Common misreadings are treating the 24-hour clock as running from detection, or waiting for a regulator notice before starting the 72-hour clock. Neither is what the text says. The 72-hour limit is also a ceiling, since Rule I.K.1 asks for reporting as soon as reasonably practicable.
Rule I.D.2(b) requires backups of keys and seed phrases to be stored in a separate location from the primary key or seed phrase. It also requires that keys stored online, or in any one physical location, be insufficient to conduct a virtual asset transaction, unless controls make physical access insufficient. A backup kept in the same safe, room or cloud account as the original defeats both requirements. Schedule 1 guidance adds regular testing of backup and recovery procedures, so confirm the separated backup can actually be restored.
Rule I.B.1 requires the Cybersecurity Policy to be submitted to VARA as part of licensing and again whenever VARA asks. Rule I.B.2 requires the CISO to review and update it at least annually. A policy that was accurate on the application date and has not changed since is a compliance gap, and it becomes visible the first time VARA requests the current version. Keep a dated review log, and record when nothing needed changing and when it did. The BCDR Plan has its own annual test-and-update requirement under Rule I.H.1.
Rule I.I.1 states that the CISO must be a separate individual from the Compliance Officer. Small firms are often tempted to combine the two, but the rule leaves no room for it. The rulebook does allow a different combination: the CISO may also serve as the Data Protection Officer (Rule II.B.2). Keep the two arrangements distinct when you document your governance structure, so a reviewer doesn't confuse the permitted overlap with the prohibited one.
The VARA cybersecurity requirements apply to a firm once it holds a VARA license to carry out a virtual asset activity in the Emirate of Dubai, regardless of where its headquarters or team sit. A company with no VARA licence is not bound by the Technology and Information Rulebook. A foreign firm preparing to apply should build to it in advance, because VARA assesses the Cybersecurity Policy as part of the licensing process.
The rulebook applies to all VASPs licensed by VARA to carry out any virtual asset activity in the Emirate, and Schedule 2 defines a VASP as an entity holding that licence. Where a firm is incorporated, or where its engineers work, is not the test. The licence is.
Whether a foreign firm needs a licence in the first place is a separate question, and this rulebook does not answer it. That depends on VARA's Regulations and the Dubai virtual assets law, so take legal advice on your activities and customers before assuming you are in or out of scope. Our VARA regulatory compliance strategy guide covers licensing.
The rulebook defines the Emirate as all zones across Dubai, including Special Development Zones and Free Zones, but excluding the Dubai International Financial Centre (DIFC). A firm operating inside DIFC is outside VARA's regime and answers to the DIFC's own regulator. Firms in other emirates, including Abu Dhabi's ADGM financial free zone, also fall under different authorities, and their cybersecurity expectations come from those regimes rather than this rulebook.
This is also why "UAE" in a search query can mislead. Requirements that apply to a VARA licensee in Dubai are not automatically the requirements for a firm elsewhere in the country.
A VARA licence adds obligations without removing others. Rule II.A.1(b) requires a VASP to comply with any data protection laws outside the UAE that apply to its activities, wherever those activities are conducted. A Dubai-licensed exchange with European or UK customers may therefore face the GDPR alongside the PDPL.
Two further rules make cross-border setups harder. Rule II.A.2 says compliance must cover where data is stored and how it is transferred. Rule II.C.1 requires the VASP to take every step needed, including contract terms and consents, so that VARA can access Part II compliance information regardless of where it is stored. If your data or vendors sit in another country, check now that nothing in those arrangements blocks that access.
Start with the Cybersecurity Policy, since Rule I.B.1 requires you to submit it with the application. Appoint a CISO who is a separate person from the Compliance Officer, and build the Technology Governance and Risk Assessment Framework that the policy draws on. The rulebook does not say where the CISO must be based or how much time they must spend on the firm, so confirm your intended arrangement with VARA rather than assuming.
Distributed teams need particular attention. Schedule 1 (guidance) acknowledges the distributed workforce model common in the virtual asset space and expects mandatory endpoint protection on all devices with access to systems, background checks for staff with sensitive access, formal onboarding and offboarding that includes contractors, and minimum security requirements for personal devices used for work. Its multi-signature guidance also expects geographic distribution of signing authorities, which a global firm may already have.
Then check the pieces that take longest to arrange: independent testers who can start before your first product launch, a BCDR Plan with an alternative site, and a map of where your data sits with the vendor contracts to match. The Company, Compliance and Risk Management, and Market Conduct Rulebooks also apply, so plan the cybersecurity work as part of the wider licensing effort.
This guide to the VARA cybersecurity requirements is based on the Technology and Information Rulebook, version dated 19 May 2025, published by Dubai's Virtual Assets Regulatory Authority. Every rule reference on this page (for example Rule I.E.1 or Rule II.C.2) points to that document.
The main source is the Technology and Information Rulebook (PDF, version dated 19 May 2025). VARA also publishes the rulebook as a web page under its Technology and Information Rulebook listing, and lists it among its compulsory rulebooks for all licensed VASPs. The rulebook forms part of the Virtual Assets and Related Activities Regulations 2023, issued under Dubai Law No. (4) of 2022 Regulating Virtual Assets in the Emirate of Dubai.
Where the rulebook refers to other laws, namely the Personal Data Protection Law (Federal Decree-Law No. 45 of 2021), the Dubai Electronic Security Center standards, and the Central Bank's Consumer Protection Regulation, this page describes only what the rulebook says about them. Read the laws themselves for their own requirements.
VARA amends its rulebooks from time to time, and a later version of this rulebook, or a change to the Regulations it sits under, may change a rule number or a deadline. Before relying on any figure here, such as the 72-hour and 24-hour reporting windows, check the version on VARA's site. When the rulebook changes, we update this page.
This page is general information and does not constitute legal advice. Where the rulebook is silent, as it is on whether a virtual CISO qualifies, confirm the position with VARA or a qualified adviser.
Yes. Rule I.E.1 requires a VASP to engage a qualified, independent third party to run vulnerability assessments and penetration testing at least annually, and also before introducing any new system, application or product. Smart contract audits are included where relevant to the business. VARA must provide results on request.
Within 72 hours of detection at the latest for a material cybersecurity event (Rule I.K.1), and sooner where reasonably practicable. A personal data incident has a separate clock: within 24 hours after the VASP notifies a data regulator or data subject (Rule II.C.2).
No. The Technology and Information Rulebook names no specific standard. Rule I.A.3 asks VASPs to consider international standards and industry best-practice codes, and Schedule 1 guidance refers to best-in-class standards. ISO 27001 can support a framework, but certification does not replace meeting each VARA Rule.
Yes. Rule I.I.1 lets the CISO take on the Data Protection Officer responsibilities, and Rule II.B.2 confirms the DPO can be the same person as the CISO. The CISO must still be a different individual from the Compliance Officer, so combining CISO and Compliance Officer is not permitted.
No. Schedule 1 is Guidance, written as what VASPs are "expected to" do, and it does not amend any Rule. It still matters, because Rule I.A.6 points VASPs to it when designing their framework. Treat it as the benchmark and document a reason for any departure.
No. The rulebook defines the Emirate as all zones across Dubai, including Special Development Zones and Free Zones, but excluding the Dubai International Financial Centre. A firm operating inside DIFC falls under a separate regulatory regime, so confirm which regulator governs your activities before using this rulebook.
Not by name in the binding Rules. Rule I.D.2 requires no single point of failure in access to virtual assets, and Schedule 1 guidance expects multi-signature for high-value operations, with required signers greater than half the total signatories. Document any alternative design you rely on.
The rulebook does not say. Rule I.I requires an appointed CISO of good standing and appropriate experience, but it neither permits nor prohibits a virtual or outsourced arrangement. Confirm VARA's position directly and keep the response on file.