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. Whatever time the incident actually began, and whenever you classify or confirm it, you have 72 hours from the moment of detection.
- 72 hours is the backstop. The primary obligation is "as soon as reasonably practicable". The 72 hours is the outer limit on top of that. Seventy-two hours reads generously until you count the approval steps. A report that needs the CISO, a legal read and a sign-off before it leaves the building has to be drafted while the investigation is still running, and anyone planning to write it on the final morning will file something thin.
- There are two triggers. 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. Leaving the word undefined is defensible drafting. A closed list of qualifying events would be gamed and would age badly. The cost lands on you: write down the materiality test you apply, apply it consistently, and accept that the first time you use it under pressure it will feel uncomfortable.
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 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. This is the pairing that catches otherwise well-run teams, because the second clock is invisible on an incident timeline that only tracks the incident. Put the trigger in the runbook next to the privacy notification step, so the person who sends one is prompted to send the other.
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. Drafting a plan against the eight areas is a couple of weeks for somebody who knows the business. Testing it every year and writing down honestly what failed is the part that costs real time, and it is the part VARA can ask to see.
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. That is easy to write and brutal to execute in the middle of an incident. If you have never rehearsed a full rotation you do not know how long it takes or what it breaks, which makes it a better candidate for your next exercise than for another paragraph in a policy.
What this means for your incident procedure
Everything below traces to a rule. Nothing below is a timeline somebody invented. If you do one thing this week, do the first item. A detection timestamp field is an afternoon of tooling, and it decides whether every later argument about timeliness is winnable.
- 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. 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 mandatory obligation.
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.