Learn
🕑 11 min read
📅 March 12, 2026
🏫 Regulatory Intelligence
Dubai’s Virtual Assets Regulatory Authority (VARA) has established one of the most prescriptive incident reporting and business continuity frameworks for virtual asset service providers (VASPs) anywhere in the world. Under the Company Rulebook, Part I (Technology and Information Governance), Sections H (Incident Response & Business Continuity) and K (Cybersecurity Event Reporting), VASPs operating in or from the Emirate of Dubai face clear, enforceable obligations around how they detect, respond to, recover from, and report security incidents.
The centrepiece requirement is straightforward: material cybersecurity events must be reported to VARA within 72 hours of detection. But the simplicity of that headline masks significant operational complexity. What constitutes a “material” event? What must the report contain? How does the 72-hour clock interact with your BCDR activation protocols? And what happens when the incident itself is a DLT-native scenario - a fork event, a consensus failure, a key storage compromise - that traditional business continuity frameworks were never designed to handle?
This article unpacks both obligations in detail: the business continuity and disaster recovery (BCDR) requirements under Section H, and the incident notification rules under Section K. If you operate a VASP under VARA’s jurisdiction, these two sections will shape the core of your operational resilience programme.
🛡
Part I, Section H
Business Continuity and Disaster Recovery: What VARA Requires
VARA’s BCDR requirements go well beyond the “have a plan” expectation that many VASPs assume is sufficient. The Company Rulebook mandates that every licensed entity must implement, maintain, test, and update a comprehensive BCDR Plan. This is not a shelf document - it is a living operational programme that must be reviewed and refreshed at least annually, and updated immediately following any material incident, significant infrastructure change, or organisational restructuring.
The BCDR Plan must address seven core areas, each of which requires documented procedures, assigned responsibilities, and evidence of testing:
| # | Requirement Area | VARA Expectation | Practical Implementation |
|---|---|---|---|
| 1 | Triggering Events | Define the specific events that activate the BCDR Plan, including cyber incidents, system failures, and DLT-specific scenarios | Catalogue all trigger conditions with clear thresholds. Include blockchain-native events (consensus failure, smart contract exploit, bridge compromise) alongside traditional IT triggers (ransomware, DDoS, data centre failure). |
| 2 | Resource Requirements | Identify personnel, infrastructure, and third-party resources needed for recovery | Map critical staff with backup designations. Identify hardware, cloud, and custodian dependencies. Document vendor SLAs for key infrastructure and establish pre-negotiated emergency response agreements. |
| 3 | Recovery Priorities | Establish a tiered recovery sequence with defined RTOs and RPOs | Rank systems by criticality: hot wallet access, withdrawal processing, order matching engine, KYC/AML systems, client portal. Set Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) for each tier. |
| 4 | Data Integrity Validation | Procedures to verify that recovered data is complete, accurate, and uncompromised | Implement cryptographic validation of restored databases against on-chain records. Reconcile wallet balances, pending orders, and client positions post-recovery. Log all validation checksums. |
| 5 | Communication Arrangements | Pre-defined communication protocols for regulators, clients, staff, and third parties | Maintain up-to-date contact trees. Pre-draft notification templates for VARA, clients, and media. Designate a communications lead who is not part of the technical response team. |
| 6 | Alternative Site / Infrastructure | Documented failover capability to alternative infrastructure or location | Deploy geographically separated hot standby or warm standby environments. Test failover at least quarterly. If using multi-cloud, ensure each provider can independently sustain critical operations. |
| 7 | Vulnerability Remediation | Post-incident vulnerability assessment and remediation tracking | After every BCDR activation, conduct a root cause analysis and vulnerability scan. Track remediation actions to closure with assigned owners and deadlines. Feed findings back into the BCDR Plan update cycle. |
DLT-Specific Consideration
VARA explicitly requires that the BCDR Plan account for virtual asset and distributed ledger technology-specific factors. This includes network malfunction (node outages, peer disconnection, mempool congestion), data loss on distributed ledgers (chain reorganisation, orphaned blocks, state corruption), and key storage issues (HSM failure, seed phrase compromise, multi-sig key unavailability). Traditional IT disaster recovery frameworks do not cover these scenarios. Your BCDR Plan must be purpose-built for the VA/DLT operating environment.
⛓
DLT-Native Threats
BCDR Scenarios Unique to Virtual Asset Operations
One of the most significant challenges for VASPs is that conventional BCDR playbooks - designed for centralised IT environments - do not adequately address scenarios that are native to blockchain and virtual asset infrastructure. VARA recognises this gap and expects your BCDR Plan to explicitly address the following categories of DLT-specific disruption:
Consensus Mechanism Failure
When the underlying blockchain’s consensus mechanism stalls or forks unexpectedly, transaction finality is lost. Your BCDR Plan must define how you handle pending transactions, communicate with clients, and determine which chain branch to follow. This includes scenarios where your validator or node operator experiences desynchronisation from the main network.
Key Storage Compromise
Whether you use HSMs, MPC wallets, or multi-signature schemes, a compromise of private key material is a catastrophic event unique to VA operations. Your BCDR Plan must address emergency key rotation, asset migration to clean wallets, and forensic investigation of the compromise vector - all while maintaining client asset segregation.
Fork Events (Hard & Soft)
Planned or unplanned forks create operational complexity: which chain do you support? How do you handle client assets on both chains? What if a forked chain creates duplicate token balances? Your plan must include fork assessment procedures, client communication templates, and a decision framework for chain selection that considers liquidity, security, and community consensus.
Smart Contract Exploit / Bridge Failure
If your VASP interacts with DeFi protocols, bridges, or smart contracts, an exploit in any of these systems can result in immediate, irreversible asset loss. Your BCDR procedures should include circuit-breaker mechanisms (automatic suspension of affected integrations), exposure assessment tools, and pre-defined escalation criteria for engaging blockchain security firms.
For each of these scenarios, VARA expects documented procedures that include: detection mechanisms (how will you know it is happening?), containment actions (how will you limit the damage?), recovery steps (how will you restore normal operations?), and post-incident review (what will you change to prevent recurrence?). The Plan must be tested against at least one DLT-specific scenario annually.
Annual Testing Requirement
VARA mandates that the BCDR Plan be tested at least once per year through tabletop exercises, simulation drills, or full failover tests. Testing must cover both traditional IT disaster scenarios and VA/DLT-specific scenarios. Results must be documented, reviewed by senior management, and used to update the Plan. Failure to test is treated as a compliance deficiency, regardless of whether an incident has occurred.
⏰
Part I, Section K
The 72-Hour Notification Requirement
Section K of the Company Rulebook establishes the core incident reporting obligation: material cybersecurity events must be reported to VARA within 72 hours of detection. The clock starts not when you finish your investigation, not when you convene your incident response team, but when the event is detected - the moment your monitoring systems, staff, or third parties identify something that may constitute a material cybersecurity event.
This is an important distinction. Unlike some regulatory frameworks where the clock starts at “classification” or “confirmation,” VARA’s clock runs from detection. If your SIEM flags a potential intrusion at 09:00 on Monday, you have until 09:00 on Thursday to submit your report to VARA - regardless of whether you have fully characterised the event by that point.
What Constitutes a “Material Cybersecurity Event”?
VARA does not provide an exhaustive list, but the regulatory guidance and enforcement precedent indicate that the following categories of events are considered material and trigger the 72-hour reporting obligation:
- Unauthorised access to systems containing client data, virtual assets, or private key material
- Data breaches involving personal data, financial records, or transaction data
- Theft or loss of virtual assets from hot wallets, cold storage, or client accounts (regardless of amount)
- Ransomware or destructive malware affecting operational systems
- Denial of service attacks that materially impair client access or transaction processing
- Smart contract exploits affecting client assets or platform integrity
- Insider threats involving misuse of privileged access to VA systems or key material
- Third-party provider breaches that expose your systems, data, or client assets to compromise
The threshold is deliberately broad. VARA expects VASPs to err on the side of reporting. If there is any doubt as to whether an event is “material,” the regulatory expectation is clear: report it. Under-reporting will attract far more scrutiny than over-reporting.
| Report Element | Required Content |
|---|---|
| Nature of Event | Classification of the event type (e.g., data breach, unauthorised access, VA theft, system compromise). Include the attack vector or failure mode if known. |
| Scope of Impact | Number of affected clients, volume and value of assets at risk, systems compromised, geographic extent. Include both confirmed and estimated impact. |
| Client Impact Assessment | Specific impact on client assets, services, and data. Whether client funds are at risk or have been lost. Whether client-facing services have been suspended. |
| Mitigation Steps Taken | Immediate containment actions, remediation measures deployed or planned, timeline for full resolution. Include both technical measures (e.g., wallet freezing, system isolation) and operational measures (e.g., client notifications, law enforcement engagement). |
| Root Cause (Preliminary) | Initial assessment of the root cause. If the investigation is ongoing, provide what is known and commit to a follow-up report with confirmed findings. |
| Contact Information | Designated point of contact for VARA follow-up queries, including the CISO and Compliance Officer details. Available 24/7 during the active incident period. |
The 72-Hour Reporting Timeline
Hour 0
Detection
SIEM alert, staff report, third-party notification, or client complaint triggers awareness. Clock starts immediately.
Hours 0–24
Triage & Containment
Activate incident response team. Contain the threat. Begin impact assessment. Determine materiality. Start drafting the VARA notification.
Hour 72
VARA Notification Due
Submit formal report including nature, scope, impact, and mitigation steps. Investigation may be ongoing - that is acceptable, but the report must be filed.
🔍
Schedule 1, Risk Category 3
Detection and Response Capabilities
Your ability to meet the 72-hour reporting requirement depends entirely on your ability to detect events in the first place. VARA’s Schedule 1, Risk Category 3 (Detection and Response) sets out the monitoring and investigation capabilities that every VASP must maintain. Without these capabilities, you cannot reliably identify material events - and you cannot start the clock if you do not know the clock should be running.
The detection and response requirements span six capability areas:
Transaction Monitoring
Deploy behavioural analysis and machine learning models to detect anomalous transaction patterns. This goes beyond AML/CFT screening - VARA expects real-time monitoring that can identify account takeover, market manipulation, wash trading, and unusual withdrawal patterns.
Internal User Monitoring
Monitor privileged user activity including system administrators, wallet operators, and anyone with access to key material. Track logins, privilege escalations, data exports, and configuration changes. Insider threat detection is not optional for VASPs.
Developer & Signing System Monitoring
Monitor code deployment pipelines, smart contract interactions, and signing infrastructure. Any unauthorised code change, unexpected signing request, or modification to transaction approval flows must trigger an alert. This is where supply chain attacks typically manifest in VA environments.
On-Chain Analysis
Maintain capability to trace on-chain transactions, identify tainted funds, and monitor wallet addresses associated with your platform. Use blockchain analytics tools to detect funds flowing to or from sanctioned addresses, mixing services, or known exploit addresses.
Tactical Hardening
Continuously update detection rules based on emerging threat intelligence. Subscribe to VA-specific threat feeds. Harden systems proactively against known attack vectors (e.g., SIM swapping for MFA bypass, clipboard hijacking for address replacement, phishing targeting crypto personnel).
Investigation Capability
Maintain in-house or contracted capability to conduct forensic investigations. This includes digital forensics, blockchain forensics, and the ability to preserve evidence in a manner suitable for law enforcement engagement. Remediation must be tracked through to completion.
📝
Practical Guidance
Building a VARA-Compliant Incident Response Plan
The intersection of BCDR (Section H) and incident reporting (Section K) means your incident response plan must serve two masters simultaneously: operational recovery and regulatory compliance. Here is a practical framework for structuring your IRP to satisfy both:
Phase 1: Preparation (Before Any Incident)
- Establish an Incident Response Team (IRT) with clear roles: Incident Commander, Technical Lead, Communications Lead, Legal/Compliance Lead, and VARA Liaison
- Pre-draft VARA notification templates covering the mandatory report elements (nature, scope, impact, mitigation)
- Maintain a “go bag” of pre-populated data: entity details, licence number, CISO contact information, system architecture diagrams, and wallet inventory
- Establish 24/7 on-call rotation for the IRT - incidents do not observe business hours
- Retain a blockchain forensics firm on retainer for rapid engagement (aim for sub-4-hour response SLA)
Phase 2: Detection and Triage (Hours 0–6)
- Log the exact time of detection - this is the start of your 72-hour clock
- Perform initial triage: is this a confirmed incident, a false positive, or an event requiring investigation?
- Assess materiality against your pre-defined criteria (aligned to VARA’s expectations)
- If material, activate the IRT and begin the formal incident response process
- Begin containment: isolate affected systems, freeze compromised wallets, suspend affected services
Phase 3: Investigation and Reporting (Hours 6–72)
- Conduct parallel workstreams: technical investigation and VARA report preparation
- Document all findings in a forensically sound manner - chain of custody matters
- Assess client impact: how many clients affected, value of assets at risk, services impaired
- Prepare the VARA notification with all required elements, even if some findings are preliminary
- Submit to VARA before the 72-hour deadline. It is better to file a preliminary report and update it than to miss the deadline waiting for complete information
Phase 4: Recovery and Post-Incident (After Submission)
- Execute BCDR recovery procedures to restore affected systems and services
- Validate data integrity against on-chain records before resuming client-facing operations
- Provide follow-up reports to VARA as the investigation progresses and new information emerges
- Conduct a formal post-incident review within 30 days of resolution
- Update the BCDR Plan, incident response procedures, and detection rules based on lessons learned
Cross-Reference: Data Incident Reporting
If a cybersecurity event also involves a personal data breach, VASPs face an additional obligation under Part II of the Company Rulebook: a data incident must be reported to VARA within 24 hours of the initial data incident report being filed. This is a tighter deadline than the 72-hour cybersecurity notification. In practice, any incident involving client data will trigger both clocks simultaneously, and the 24-hour data notification deadline will be the binding constraint. Ensure your IRP accounts for both reporting streams.
⚠
Compliance Pitfalls
Common Mistakes VASPs Make with Incident Reporting and BCDR
Treating BCDR as a Document, Not a Programme
Many VASPs create a BCDR document during initial licensing and never revisit it. VARA expects a living programme with annual testing, post-incident updates, and regular review by senior management. An untested plan is, for regulatory purposes, no plan at all.
Using IT-Only BCDR Templates
Off-the-shelf BCDR templates designed for traditional IT environments do not address DLT-specific scenarios. VARA will look for evidence that your plan covers consensus failures, key storage issues, and chain-specific events. A BCDR Plan that only references server recovery and data backup is incomplete.
Waiting for Certainty Before Reporting
The most dangerous mistake is delaying the VARA notification until the investigation is complete. The 72-hour clock does not pause while you investigate. File a preliminary report with what you know and commit to follow-up reports. VARA would rather receive an early, incomplete report than a late, complete one.
Ignoring the 24-Hour Data Notification
VASPs that focus exclusively on the 72-hour cybersecurity notification often forget the 24-hour data incident reporting obligation under Part II. Any incident involving personal data triggers both timelines. Missing the 24-hour deadline while waiting for the 72-hour one creates a separate compliance failure.
Key Takeaways
- 72-hour notification: Material cybersecurity events must be reported to VARA within 72 hours of detection, not classification. The clock starts the moment you know.
- BCDR is mandatory and testable: Implement, maintain, test, and update your BCDR Plan annually. Testing must include DLT-specific scenarios.
- Seven BCDR areas: Triggering events, resource requirements, recovery priorities, data integrity validation, communication arrangements, alternative infrastructure, and vulnerability remediation.
- DLT-native scenarios: Consensus failures, key storage compromise, fork events, and smart contract exploits must be explicitly addressed in your BCDR Plan.
- 24-hour data deadline: Data incidents trigger a separate, faster 24-hour reporting obligation under Part II. Both clocks run simultaneously.
- Report early, update later: VARA expects timely, preliminary reports over late, comprehensive ones. File what you know by the deadline and provide follow-ups.
This article is for informational purposes only and does not constitute legal or regulatory advice. Virtual asset service providers should consult their legal counsel and VARA directly for entity-specific guidance on incident reporting and business continuity obligations. Published March 2026. References: VARA Company Rulebook Part I (Technology and Information Governance), Sections H and K; VARA Schedule 1, Risk Category 3 (Detection and Response); UAE Federal Decree-Law No. 45 of 2021 (PDPL).