Learn
The 72-hour figure is real, and it is narrower than it is usually reported. It comes from Rule I.K.1 of the VARA Technology and Information Rulebook, it runs from detection, and it is triggered by two specific kinds of event. A second, shorter clock of 24 hours runs alongside it whenever personal data is involved.
Corrected on 14 July 2026: an earlier version of this article placed these rules in the Company Rulebook (they are in the Technology and Information Rulebook), said the BCDR Plan must address seven areas (Rule I.H.1 lists eight), and carried an excerpt claiming the clock starts when the incident happens rather than when you detect it. Rule I.K.1 runs from detection. The invented list of "material" event categories and the invented report template have been replaced with the text of the rule.
The rule, in full
Rule I.K.1 of the Technology and Information Rulebook is one sentence, and every part of it matters:
"In addition to relevant requirements in the Compliance and Risk Management Rulebook, upon the detection of any occurrence of (i) a material cybersecurity event or (ii) an event triggering the implementation of the BCDR Plan that materially impacts a VASP's business operations, the VASP shall report such event to VARA as soon as reasonably practicable, and in any event no later than seventy-two (72) hours from detection, with all relevant details of the nature, scope and impact of such event and the steps the VASP is or will be taking to mitigate such impact including, but not limited to, whether any notifications or reports have been made to authorities other than VARA."
Four things fall out of that sentence.
- The clock starts at detection. Not at classification, not at confirmation, not when the incident began. From the moment of detection you have 72 hours.
- 72 hours is the backstop, not the target. The primary obligation is "as soon as reasonably practicable". The 72 hours is the outer limit on top of that.
- There are two triggers, not one. A material cybersecurity event, and separately any event that triggers the BCDR Plan and materially impacts business operations. The second trigger has nothing to do with an attacker. A data centre failure that takes withdrawals offline can be reportable even though nobody attacked you.
- The report has a defined content list. Nature, scope and impact of the event, the steps you are taking or will take to mitigate it, and whether any notifications or reports have been made to authorities other than VARA. That last element is routinely left out.
What "material" means: the rulebook does not define it, and there is no published VARA list of qualifying event types. Anyone who gives you one has invented it. What the rulebook does give you is a harder-edged neighbouring duty in Rule I.I.2 of the Compliance and Risk Management Rulebook: "VASPs shall submit a report to VARA immediately upon the discovery of any violation or breach of any law, Regulation, Rule or Directive related to the conduct of any VA Activity." Materiality is your judgement to make and to document, and you should expect to defend that judgement rather than the outcome.
The clocks a VASP is actually running
The 72-hour rule is the one that gets the headlines. It is not the only notification deadline in the rulebooks, and it is not the tightest.
| Deadline | Rule | Trigger |
|---|---|---|
| 72 hours from detection | TIR I.K.1 | A material cybersecurity event, or an event triggering the BCDR Plan that materially impacts business operations. |
| 24 hours | TIR II.C.2 | Runs from the moment you notify a data regulator or a data subject about an incident affecting, or potentially affecting, personal data. You then have 24 hours to tell VARA, with a summary of that report and, where the regulator is in the UAE, a copy of it. |
| Immediately on discovery | CRM I.I.2 | Any violation or breach of any law, Regulation, Rule or Directive related to the conduct of a VA Activity. |
| Immediately | Company Rulebook VI.F.1 | Failure to maintain paid-up capital, net liquid assets, insurance or reserve assets, with daily updates to VARA until the failure is rectified. |
Read Rule II.C.2 carefully, because its trigger is not the incident. It is your notification to someone else. The 24 hours starts when you notify a data regulator or a data subject, so if you notify the UAE Data Office on day five of an investigation, VARA has to hear from you within 24 hours of that, quite apart from whatever you filed under Rule I.K.1 on day three.
The BCDR Plan: eight required areas, not seven
Rule I.H.1 requires VASPs to "implement, maintain, test and update on an annual basis an adequate Business Continuity and Disaster Recovery Plan". The rule then lists the areas the plan must address. There are eight of them, lettered (a) to (h).
| Ref | Area | What Rule I.H.1 requires |
|---|---|---|
| (a) | Triggering events | Events that may trigger the implementation of the BCDR Plan, such as cybersecurity events and technical failures, and the procedures to assess the nature, scope and impact of the event. |
| (b) | Resource requirements | Including Senior Management and staff, systems and other assets. |
| (c) | Recovery priorities | For the VASP's operations, including the preservation of essential data and critical functions and the maintenance of those data and functions. |
| (d) | Communication arrangements | For affected internal and external parties. |
| (e) | Integrity validation | Processes to validate the integrity of information affected by any interruption. |
| (f) | Operational impact mitigation and transfer of functions | Procedures to mitigate operational impact and to transfer operational functions, including escalation of response and recovery activities to designated personnel and management. This is the area most commonly missing from BCDR plans written against a generic IT template. |
| (g) | Alternative site | An alternative site sufficient to recover and continue operations for a reasonable period. |
| (h) | Post-event remediation | Procedures to remediate identified or exploited vulnerabilities, or to upgrade relevant protocols once stable operations are resumed, to prevent similar events. |
Note what is not in the rule. Recovery time objectives and recovery point objectives are not mentioned. Nor are quarterly failover tests, nor a mandated uptime figure, nor a required tabletop cadence. The testing obligation is annual, and it attaches to the plan as a whole. Setting RTOs is good practice and it is the natural way to satisfy the recovery priorities limb in (c), but do not tell yourself VARA demands them, and do not skip (f) because a template did not have it.
The DLT limb is a "should", and it names three things
Rule I.H.2 says the BCDR Plan "should take into consideration and address factors and issues specific to Virtual Assets and DLT including, but not limited to, network malfunction, loss of data or compromise in data integrity, and key storage and maintenance of authorisation layers".
Three named categories, framed as guidance rather than a hard requirement, and open-ended. Fork handling, bridge exploits and consensus stalls are sensible scenarios to plan for and they sit comfortably inside those categories, but they are examples you have chosen, not rules VARA has written. Say so in your plan. A BCDR plan that claims VARA mandates a fork policy is quoting a rule that does not exist.
You cannot start a clock you cannot see
The 72 hours runs from detection, which makes detection capability the load-bearing control. Schedule 1 of the Technology and Information Rulebook, Risk Category 3, sets out seven standards VASPs are expected to meet. This is guidance on the Technology Governance and Risk Assessment Framework rather than a rule in Part I, but it is the clearest statement of what VARA expects a VASP to be able to do.
| Standard | What Schedule 1 expects |
|---|---|
| Transaction monitoring | Behavioural analysis to detect anomalous patterns, rule-based monitoring for known suspicious activities, machine learning capabilities for advanced threat detection, real-time alerting for suspicious transactions, and regular refinement of the detection methodologies. |
| Internal user activity monitoring | Authentication attempts and failures, pattern analysis to detect insider threats, monitoring of access to sensitive or critical systems and administrative activities, and segregation of monitoring from operational teams. |
| Enhanced monitoring | Of developer and signing systems: process creation and termination, network connection analysis, file system change detection, software installation and execution control, and user behaviour analytics. |
| Tactical hardening | The capability to rapidly limit an attacker once a compromise is detected: emergency access revocation including individual endpoints, network segmentation, system isolation procedures, pre-approved emergency change procedures, and regular testing of those capabilities. |
| Investigation capability | Dedicated forensic resources, internal or contracted, that are deployable and responsive in real time or on immediate notice, secure evidence collection, chain of custody documentation, root cause analysis methodologies, and regular training. |
| On-chain analysis | Transaction tracing tools, wallet attribution, collaboration with other VASPs for fund tracing, and regular capability development. |
| Remediation | Complete rotation of all secret components, including passwords, keys and key shards, after incidents; system rebuilding from secure baselines; enhanced monitoring post-incident; formal verification of attacker removal; and a post-incident review. |
The remediation standard is the one to read twice. It expects "complete rotation of all secret components (including but not limited to passwords, keys and key shards) after incidents". Not the compromised ones. All of them.
What this means for your incident procedure
Everything below traces to a rule. Nothing below is a timeline somebody invented.
- Record the detection timestamp as a first-class field. The 72 hours runs from it, so it is the single most important piece of metadata in an incident record. If you cannot evidence when you detected, you cannot evidence that you reported in time.
- Make the materiality decision explicit and dated. The rulebook gives no definition, so the defensible artefact is a documented decision, made by a named person, with reasons.
- Draft against the rule's content list, not a generic template. Nature, scope, impact, mitigation steps taken or planned, and whether other authorities have been notified.
- Do not wait for certainty. The obligation is to report as soon as reasonably practicable and in any event within 72 hours. The rule does not make completeness of the investigation a condition of reporting.
- Wire the 24-hour clock to the act of notifying someone else. The moment a data regulator or a data subject is told, a separate VARA deadline starts.
- Keep the evidence retrievable. Rule I.E.3 requires evidence of tests and audits to be "documented by VASPs and made immediately available by them for inspection by VARA, upon VARA's request".
- Test the BCDR Plan annually and keep the record. Rule I.H.1 makes testing part of the obligation, not an optional maturity step.
Frequently Asked Questions
When does the VARA 72-hour clock start?
At detection. Rule I.K.1 of the Technology and Information Rulebook requires the report "upon the detection" of the event and "in any event no later than seventy-two (72) hours from detection". It does not run from when the incident began, nor from when you classified or confirmed it. The underlying duty is to report as soon as reasonably practicable, with 72 hours as the outer limit.
Which incidents have to be reported to VARA within 72 hours?
Two categories under Rule I.K.1: a material cybersecurity event, and an event that triggers implementation of the BCDR Plan and materially impacts the VASP's business operations. The second category does not require an attacker. The rulebook does not define "material" and publishes no list of qualifying event types.
What must the report to VARA contain?
Rule I.K.1 requires "all relevant details of the nature, scope and impact of such event and the steps the VASP is or will be taking to mitigate such impact including, but not limited to, whether any notifications or reports have been made to authorities other than VARA".
Is there a separate deadline for personal data incidents?
Yes, and it is shorter. Rule II.C.2 requires VASPs to notify VARA "as soon as possible and in any event within twenty-four (24) hours" following their notification to a data regulator or to a data subject of any incident affecting, or potentially affecting, personal data, with a summary of that report and, where the regulator is in the UAE, a copy of it.
How many areas must the BCDR Plan cover?
Eight, lettered (a) to (h) in Rule I.H.1: triggering events, resource requirements, recovery priorities, communication arrangements, integrity validation processes, procedures to mitigate operational impact and transfer operational functions, an alternative site, and post-event remediation procedures.
How often must the BCDR Plan be tested?
Annually. Rule I.H.1 requires VASPs to "implement, maintain, test and update on an annual basis an adequate Business Continuity and Disaster Recovery Plan". The rulebook does not prescribe a testing method, a quarterly failover test, or recovery time objectives.
Running the clocks in Venvera
Venvera does not ship a VARA framework module, so there is no preloaded VARA 72-hour timer. What the platform provides is the machinery those clocks need:
- The incident register records an incident with its notification deadlines and shows the hours remaining against each reporting step, flagging overdue steps (verified in product). The preloaded regulatory timelines are the EU DORA and NIS2 ones, so a VARA 72-hour or 24-hour deadline is tracked as a deadline you set on the incident.
- An authority report generator produces the incident report for a regulator from the recorded incident data, so the nature, scope, impact and mitigation narrative is assembled once (verified in product).
- The evidence library holds the BCDR test records and audit reports that Rule I.E.3 says must be produced immediately on request (verified in product).
- The board view reports open incidents and overdue actions, which is what makes an untested plan visible before an incident does (verified in product).
If you want a fast read on where your resilience programme stands, run a free compliance check.
Detection time, deadlines and evidence in one record
Log the detection timestamp, track the notification deadlines you are bound by, and produce the authority report from the same record.
Book a demo →Primary sources
Every deadline above is quoted from VARA's published rulebooks. Confirm the current text before relying on a specific rule.
- Technology and Information Rulebook, Part I Section K: Notification to VARA - Rule I.K.1, the 72 hour deadline from detection.
- Technology and Information Rulebook, Part I Section H: Business Continuity, Cybersecurity Events and Risk - Rule I.H.1, the eight BCDR areas, and Rule I.H.2, the DLT factors.
- Technology and Information Rulebook, Part II Section C: Provision of Information to VARA - Rule II.C.2, the 24 hour personal data deadline.
- Schedule 1, Risk Category 3: Detection and Response - the seven detection, investigation and remediation standards.
- Compliance and Risk Management Rulebook - Rule I.I.2, immediate reporting of any violation or breach.
Last updated: July 2026. This article is general information, not legal advice. Confirm your obligations with VARA or qualified counsel.
