Learn
A practised incident response team can contain a breach and file a VARA notification in 72 hours. An unprepared one will still be arguing about who owns the incident response plan.
Let me tell you about the worst 72 hours I’ve witnessed in crypto compliance.
A mid-sized Dubai exchange detected unusual withdrawal patterns at 3am on a Thursday. Their monitoring system flagged it. A junior SOC analyst saw the alert, decided it was probably a false positive, and went back to monitoring other things. By 6am, someone senior looked at it. By 9am, they’d confirmed that a compromised API key was being used to drain client wallets. By noon, they’d contained the incident and frozen the affected accounts.
Good response, right? Technically, yes. The containment was solid.
The problem: nobody notified VARA. The compliance team spent the next 48 hours writing a “perfect” incident report. They wanted to understand the full scope before reporting. They wanted to look competent, not panicked. By the time they filed the notification, 76 hours had elapsed since detection. Four hours past the deadline.
VARA was not impressed. The late notification became a bigger regulatory problem than the incident itself. This article exists so you don’t make the same mistake.
Understanding the 72-Hour Notification Rule
Let me be absolutely clear about how this works, because the details matter:
The clock starts at detection.
Not when you’ve finished your investigation. Not when you understand the full scope. Not when you’ve contained the incident. The moment your monitoring system alerts, the moment an employee reports something suspicious, the moment you have any indication of a cybersecurity event - the 72-hour clock starts.
VARA explicitly states that the initial notification can be preliminary. They’d rather receive an incomplete report on time than a comprehensive report on Tuesday.
What triggers the notification obligation? VARA defines a “Cybersecurity Event” broadly enough that most significant security incidents will qualify:
- Unauthorised access to systems or data
- Compromise of cryptographic keys or wallet infrastructure
- Data breaches involving client information
- Service disruptions affecting VA Activities
- Smart contract exploitation or vulnerabilities under active exploit
- DDoS attacks that impact service availability
- Supply chain compromises affecting your technology stack
- Insider threats or fraud involving technology systems
When in doubt, report. VARA is far more forgiving of a notification that turns out to be unnecessary than of a failure to report something that should have been reported.
What Goes in the Notification
The initial 72-hour notification doesn’t need to be a 40-page report. VARA expects certain minimum information, and it’s worth having a template ready to go before you need it:
| Section | What to Include |
|---|---|
| Detection | When and how the event was detected, who detected it |
| Nature | Type of incident (unauthorised access, data breach, key compromise, etc.) |
| Impact Assessment | Known or estimated impact on clients, systems, and operations (can be preliminary) |
| Containment Actions | Steps taken or in progress to contain the incident |
| Client Impact | Number of clients affected (or estimate), nature of impact, client notification plans |
| Financial Impact | Any known or estimated financial losses, including client asset losses |
| Contact | Designated point of contact for VARA follow-up |
After the initial notification, VARA will specify the timeline for a detailed incident report based on severity. This comprehensive report needs to cover root cause analysis, full impact assessment, remediation actions, and measures to prevent recurrence. But that’s a follow-up exercise. First, hit the 72-hour deadline.
Building an Incident Response Plan That Actually Works
Having an incident response plan in a binder on a shelf doesn’t count. VARA expects a plan that your team can execute under pressure. Here’s what that looks like:
Roles and Escalation
Define exactly who does what. Not “the security team handles incidents.” Specific names, backup personnel, and contact information:
- Incident Commander: The person who owns the response. Usually the CISO or a senior security engineer.
- Technical Lead: Runs the technical investigation and containment.
- Communications Lead: Handles client notifications, media, and internal comms.
- Regulatory Liaison: Owns the VARA notification. This person needs to know the 72-hour process cold.
- Legal Counsel: Available for advice on notification obligations, liability, and law enforcement engagement.
Escalation paths need to be defined by severity. A suspicious log entry doesn’t need to wake the CEO at 3am. A confirmed key compromise does. Define the thresholds clearly.
Crypto-Specific Scenarios
This is where most traditional incident response plans fall apart for VASPs. Your plan needs specific playbooks for scenarios that don’t exist in traditional IT:
Private Key Compromise
Immediate key rotation, asset migration to new wallets, forensic analysis of compromise vector
Smart Contract Exploit
Contract pause (if pausable), fund recovery procedures, audit firm engagement
Hot Wallet Drain
Freeze hot wallet operations, trace stolen funds, engage law enforcement and chain analytics
Blockchain Network Issues
Chain congestion, forks, bridge failures - client communication, trading halt procedures
Insider Threat
Immediate access revocation, key rotation for any keys the insider accessed, forensic imaging
API Key Compromise
Immediate key revocation, transaction audit, client notification for affected accounts
Business Continuity and Disaster Recovery
VARA treats BCDR as a distinct but related requirement. Your incident response plan tells you what to do during an incident. Your BCDR plan tells you how to keep the business running through one.
VARA’s BCDR expectations for VASPs go beyond standard IT continuity:
Recovery Time Objectives (RTOs): Defined for each critical system. For trading engines and wallet operations, VARA expects aggressive RTOs - typically measured in hours, not days. For non-critical support systems, longer RTOs are acceptable.
Recovery Point Objectives (RPOs): How much data loss is acceptable? For transaction records and wallet balances, the answer is effectively zero. For other systems, RPOs should be justified based on business impact.
Client asset protection: This is the VARA-specific addition. Your BCDR plan must specifically address how client assets remain accessible and protected during a disaster. If your primary data centre goes offline, can clients still access their assets? If your trading engine fails, are orders protected? If your key management infrastructure is compromised, what’s the backup?
Alternative processing sites: VARA expects VASPs with significant operations to have a disaster recovery site or equivalent cloud-based failover capability. This needs to be tested, not just planned.
Annual testing: VARA requires annual BCDR testing, with documented results. This isn’t a checkbox test - they want to see realistic scenarios, identified issues, and remediation plans. Tabletop exercises are a minimum. Full failover tests are preferred for critical systems.
The 72-Hour Timeline: Hour by Hour
Here’s a practical timeline template that I’ve used successfully for VARA-regulated incidents:
Hours 0-1: Detect and Assess
Confirm the incident is real. Activate the incident response team. Assign roles. Begin logging everything with timestamps. Start a dedicated communication channel.
Hours 1-4: Contain
Isolate affected systems. Revoke compromised credentials. If assets are at risk, freeze relevant wallet operations. Preserve forensic evidence. Initial severity assessment.
Hours 4-12: Investigate
Determine scope: what systems are affected, what data is compromised, how many clients are impacted. Begin root cause analysis. Engage external forensics if needed.
Hours 12-24: Draft and Review
Draft the VARA notification using your pre-built template. Have legal review it. It doesn’t need to be complete - it needs to be accurate about what you know so far.
Hours 24-48: Prepare and Communicate
Prepare client notification if required. Continue investigation. Update the VARA notification with any new findings. Brief senior management.
Hours 48-72: Submit
Final review of the notification. Submit to VARA. Do not wait until hour 71. Aim for hour 48 or earlier. Buffer time is your friend.
Notice the emphasis on doing things in parallel. You’re not waiting for the investigation to finish before you start drafting the notification. You’re not waiting for containment to complete before you start investigating. Everything runs simultaneously, with clear ownership for each track.
Lessons from Real VARA Incidents
Without naming companies, here’s what I’ve learned from watching VARA-regulated VASPs handle real incidents:
Pre-built notification templates save lives. The team that had a template ready submitted their notification in 18 hours. The team that started from scratch at hour 30 submitted at hour 74. Guess which one had regulatory problems.
Over-report, don’t under-report. VARA has never penalised a VASP for reporting something that turned out to be less serious than initially thought. They have penalised for late or missing reports. When in doubt, file the notification.
Test your response plan quarterly. VARA requires annual BCDR testing, but the best VASPs test their incident response quarterly with tabletop exercises. Different scenarios each time: key compromise, insider threat, smart contract bug, DDoS during high volume.
Keep your incident log in your compliance platform. Tools like Venvera let you track incidents, map them to VARA reporting requirements, and maintain the evidence trail in one place. When VARA asks for your incident history during the annual review, you want a clean, structured record - not a folder of Word documents and email chains.
The follow-up report matters as much as the initial notification. VARA will judge you on both the speed of your initial notification and the quality of your follow-up. Root cause analysis, remediation actions, and prevention measures need to be thorough and evidence-based.
The Bottom Line
72 hours sounds like a lot of time until you’re in the middle of a real incident. Between containing the threat, investigating the scope, coordinating your team, managing client communications, and preserving evidence, those hours evaporate fast.
The VASPs that handle VARA incident reporting well aren’t the ones that never have incidents. They’re the ones that prepared for incidents before they happened: templates ready, roles defined, escalation paths tested, BCDR plans proven, and a compliance platform keeping everything organised.
Build your incident response plan now. Test it next month. Update it after every test. And when something goes wrong - because in crypto, something eventually will - you’ll be ready to report within 72 hours and recover within your defined RTOs.
Be Ready When the Clock Starts
Venvera helps VASPs manage incident reporting workflows, BCDR documentation, and VARA compliance tracking across 13 regulatory frameworks - starting at €399/month.
Book a Demo →Last updated: March 2026. Requirements based on VARA Technology and Information Rulebook, Part I Sections H and K. Always verify current requirements with VARA directly.