VARA Cybersecurity Requirements Checklist for VASPs

What the VARA Technology and Information Rulebook Covers

The Technology and Information Rulebook is the part of VARA's regulatory framework that sets security, data protection, and confidentiality obligations for every licensed virtual asset service provider in Dubai. It has three parts, plus two schedules, and it applies in addition to the Regulations and VARA's other compulsory rulebooks, not in place of them.

Who counts as a VASP under the Rulebook

The Rulebook applies to any firm VARA licenses to carry out a VA Activity in the Emirate of Dubai. Licensing is the trigger, not company size, headquarters, or the number of customers. A start-up with one licensed activity carries the same obligations as an established exchange. However, the Rulebook expects controls to be proportionate to the business's nature, scale, and complexity. Firms operating inside the Dubai International Financial Centre fall outside VARA's remit.

Licensed VASPs must also comply with VARA's other compulsory rulebooks (Company, Compliance and Risk Management, and Market Conduct) and with any rulebook specific to the activities they are licensed for. A firm that reads only the Technology and Information Rulebook will miss requirements that sit alongside it. Our guide to key VARA regulations maps those wider obligations.

Part I, II, and III at a glance

The Rulebook was published on 19 May 2025 and took effect on 19 June 2025. Part I alone contains eleven sections, labelled A to K, and Schedule 1 groups its guidance into five risk categories: organisational, technical, detection and response, customer virtual assets, and digital operational resilience. The table shows how the three parts divide the ground.

The parts connect in practice. The CISO is responsible for Parts I and III, and may also act as the Data Protection Officer required under Part II, so one role can hold accountability across all three. Schedule 1 is guidance rather than a rule, but it is the clearest indication of the risk areas VARA expects a VASP's framework to cover.

For the wider picture of how these rulebooks fit into VARA's licensing structure, see our explainer on the VARA framework.

The VARA Cybersecurity Requirements Checklist

Part I of the Technology and Information Rulebook is the core of VARA's cybersecurity requirements for VASPs, and the checklist below follows its lettered sections in order. This section covers the five that define a firm's security foundations: the governance framework (I.A), the Cybersecurity Policy (I.B), key and wallet controls (I.D), the CISO and Senior Management (I.I), and staff competency (I.J). Testing, business continuity, and incident notification each have their own sections.

Technology Governance & Risk Assessment Framework

Every VASP must build a Technology Governance and Risk Assessment Framework that turns identified risks into defined policies, processes, and controls (Rule I.A.1). It must be comprehensive but proportionate, sized to the firm's business model, transaction volume, and inherent risk. It must use defence-in-depth for cyber risks. It must also state the firm's cybersecurity objectives, including the competency it expects from staff and, where relevant, clients.

The Rulebook names the governance basics the framework must address: a development, maintenance, and testing process for technology systems; operations controls; backup controls; capacity and performance planning; and availability testing. It serves as a technology-focused governance, risk, and compliance program, not a one-off document. VASPs must review, update, and test it periodically, accounting for emerging technology risks and international standards.

The framework must also comply with the cybersecurity laws and regulators that apply to the firm (Rule I.C). The Rulebook names three: the Dubai Electronic Security Center standards under Dubai Law No. 9 of 2022, the UAE Personal Data Protection Law, and the Central Bank's consumer protection requirements. VARA's Schedule 1 adds guidance across five risk categories: organisational, technical, detection and response, customer virtual assets, and digital operational resilience. It is guidance rather than binding rules, but it shows what an inspector will expect the framework to cover.

Cybersecurity Policy: the mandatory minimum criteria

The Cybersecurity Policy must cover 19 minimum areas, listed in Rule I.B.3(a) to (s). VASPs submit the policy to VARA during licensing and again whenever VARA asks, and the CISO must review and update it at least annually. A policy that omits any of the 19 areas is incomplete on its face. The areas group into five themes.

Item (f) is worth noticing for firms that deploy on-chain code. It places smart contract validation and audit inside the policy, not only inside the testing rules. Our guide to smart contract security audits covers that process in depth. Item (g), secure development and quality assurance, is where a DevSecOps practice and independent source code review usually fit. Firms drafting the policy document itself can start from our information security policy guide.

Cryptographic Key & Wallet Management controls

VASPs must ensure there is no single point of failure in their access to, or knowledge of, the virtual assets they hold (Rule I.D.2). Client private keys stored online or in any one physical location must be insufficient on their own to complete a transaction, unless controls make physical access insufficient. Backups of keys and seed phrases must sit in a separate location from the primary.

Key access needs strict management and an audit log of every access change. When a staff member with access to a key, including a multi-signature key, leaves, the VASP must assess whether to generate a new key. Revoking a signatory's access must be immediate, and key generation must be designed so revoked signatories cannot reach the backup seed phrase. VASPs must also run internal audits every quarter on user access removal, document staff onboarding and offboarding, and document who may grant or revoke access for each role in the key management system.

Access to systems and data is limited to people with a demonstrable business need, with an access log kept. VASPs should also tell clients how to protect their own keys and seed phrases, though that is a "should" rather than a "must". Schedule 1 includes specifics such as HSMs for key storage and a multi-signature threshold above half the signers as guidance, not rules.

CISO appointment and Senior Management oversight duties

Every VASP must appoint a Chief Information Security Officer responsible for ensuring compliance with Parts I and III of the Rulebook (Rule I.I.1). The CISO must be a separate person from the Compliance Officer, but may also serve as the Data Protection Officer. The CISO must be of good standing and appropriately experienced.

Senior Management carries its own duty. It must regularly assess how effectively the firm's processes and controls meet the Rulebook and applicable law, and it must allocate duties so roles do not create conflicts of interest. The Rulebook does not say whether the CISO role can be fractional or outsourced, so firms considering that route should confirm the position with VARA. Our comparison of a CISO and a vCISO sets out how the two models differ.

Staff competency requirements

The Rulebook's staff competency rule is short. VASPs must ensure all staff are aware of the latest cybersecurity risks and developments, including those specific to virtual assets and distributed ledger technology, and calibrate training to the cyber risks each role faces (Rule I.J.1).

The obligation extends beyond that one rule. The framework must set out competency requirements for staff (Rule I.A.3), the Cybersecurity Policy must cover staff vetting (Rule I.B.3(p)), and key management requires documented onboarding and offboarding. Schedule 1 guidance suggests background checks, endpoint protection, and security awareness training for the workforce.

VARA Penetration Testing & Audit Requirements

VARA requires every VASP to have a qualified, independent third party carry out vulnerability assessments and penetration testing at least once a year. Again before introducing any new system, application, or product (Rule I.E.1). On top of that baseline, VARA can order a more demanding threat-led penetration test whenever it considers one necessary and proportionate.

Annual independent VAPT: what's mandatory vs discretionary

The annual test is mandatory, and so is the pre-launch trigger. Rule I.E.1 covers vulnerability assessments and penetration testing and, where relevant to the firm's business, comprehensive audits of the effectiveness, enforceability, and robustness of all smart contract auditing. The "new systems, applications and products" clause is the one firms tend to miss: a clean report from January says nothing about a wallet feature shipped in June. Results go to VARA on request. The rule does not require unprompted filing, but firms must document evidence and keep it available for immediate inspection (Rule I.E.3).

Testing is only one part of the duty. VASPs must also run security testing on infrastructure and applications and carry out internal and external vulnerability audits regularly (Rule I.E.2). They must ensure independent auditors regularly examine their management processes and regulatory compliance (Rule I.E.4). The Rulebook does not define "regularly". Schedule 1 fills the gap with guidance: annual penetration testing, quarterly vulnerability assessments, continuous automated scanning, and testing before any production update. That guidance is not binding, but a firm that assesses less often than quarterly should be ready to explain why.

Threat-Led Penetration Testing (TLPT): when VARA can require it

VARA can notify a VASP that it must carry out TLPT where it considers this necessary and proportionate, weighing the risks the firm is or might be exposed to, the criticality of its business and VA Activities, and any other relevant risks (Rule I.E.5). The Rulebook sets no fixed schedule or numeric threshold, so a firm cannot self-certify its way out. The Rulebook defines TLPT as a controlled, bespoke, intelligence-led red team test that mimics real threat actors against critical live production systems.

A required TLPT must follow set conditions (Rule I.E.6). An external tester carries it out. It may cover Critical or Important Functions on live production systems, and any in-scope third-party providers must participate. The VASP must manage the risk to data, assets, and operations, including disruption to counterparties. Afterward, the VASP and the tester jointly produce a summary of findings, remediation plans, and documentation showing the conditions were met, and the VASP must promptly provide it to VARA.

The tester must meet five criteria (Rule I.E.7): good repute, demonstrable threat intelligence and penetration testing expertise, accreditation or adherence to a formal code of conduct, independent assurance on how the test's risks are managed (including protection of the firm's confidential information), and professional indemnity insurance covering misconduct and negligence. Contracts must require sound handling of test data and must not create new risk. Where a technology provider's participation could harm the quality or security of its services or the confidentiality of related data, it may contract with the tester directly. Still, the VASP must keep it under its direction (Rules I.E.9 and I.E.10). The practical takeaway is that vendor contracts should give VARA-required testing a clear route in, because the VASP is responsible for securing that participation.

For scoping and methodology, see our guide to penetration testing in Dubai and our overview of penetration testing methods. For how TLPT-style exercises differ from a standard test, see red team vs penetration testing.

The 72-Hour VARA Incident Notification Rule

A VASP must report a material cybersecurity event to VARA as soon as reasonably practicable, and no later than 72 hours after detecting it. The same deadline applies to any event that triggers the firm's Business Continuity and Disaster Recovery (BCDR) Plan and materially affects its operations (Rule I.K.1 of the Technology and Information Rulebook).

What triggers the rule

Two kinds of event start the clock. The first is a material cybersecurity event. The second is an event that triggers the BCDR Plan and materially impacts business operations, which could be a cyberattack, but the wording also reaches technical failures. The BCDR section itself lists cybersecurity events and technical failures as examples of BCDR triggers (Rule I.H.1). Both triggers depend on materiality, and the Rulebook does not define the word. Each VASP must decide what counts as material and build that threshold into its incident response procedures before an incident happens. A firm that has never defined it will be debating the question while the deadline runs.

When the 72 hours start

The period runs from detection, not from confirming the cause or completing the investigation. The rule says "as soon as reasonably practicable, and in any event no later than" 72 hours, so 72 hours is a ceiling, not a target. A VASP that knows within a few hours that client keys may be exposed should not wait until hour 70 to notify. Because the clock starts at detection, the firm also needs a reliable way to record when detection occurred, such as a timestamped incident log entry, since regulators will measure against that time.

What the report must contain

The notification must give all relevant details of the event's nature, scope, and impact, and the steps the VASP is taking or will take to mitigate that impact. It must also state whether the firm has reported the event to any authority other than VARA. That last requirement means a VASP dealing with a breach may need to coordinate several regulators at once, so the notification process should identify who decides what goes to whom.

The rule says the report should include "all relevant details," which in practice means an early report will often be incomplete. Nothing in the rule requires waiting for a full root cause analysis. A sensible approach is to file on time with what is known and clearly state what is still under investigation.(H3)

How it differs from the 24-hour personal data rule

The Rulebook contains a second, shorter deadline that firms often confuse with this one. Under Part II, a VASP must notify VARA within 24 hours of notifying a data regulator or a data subject about an incident affecting personal data (Rule II.C.2).

One incident can trigger both rules. A breach of client data through a compromised system is both a material cybersecurity event and a personal data incident, so the firm may have two separate VARA notifications, on two different clocks, to manage.

Preparing before an incident

Rule I.K.1 says it applies "in addition to" the requirements in the Compliance and Risk Management Rulebook, so a VASP should check that rulebook for additional notification duties. The Cybersecurity Policy must already cover incident response with root cause analysis (Rule I.B.3(o)) and escalation procedures for emergencies including ransomware (Rule I.B.3(q)). The notification process is where those policy items get tested. Schedule 1 guidance adds expectations that support fast, accurate reporting: forensic resources that can be deployed at short notice, secure evidence collection with chain-of-custody documentation, and post-incident rotation of all secrets such as passwords, keys, and key shards. The BCDR Plan must also be tested and updated annually (Rule I.H.1), and a notification drill is a straightforward way to do that.

Data Protection Requirements Under Part II

Part II of the Technology and Information Rulebook requires every VASP to comply with all applicable data protection laws, run a written privacy compliance program, and appoint a Data Protection Officer. It also requires the firm to give VARA access to its compliance information wherever that data is stored. The DPO can be the same person as the CISO.

PDPL alignment and DPO/CISO overlap

The legal baseline is broad. VASPs must comply with data protection and privacy requirements in every relevant jurisdiction (Rule II.A.1). In the UAE that means the Personal Data Protection Law (Federal Decree-Law No. 45 of 2021) and any sectoral or free zone rules that apply. It also means data protection laws outside the UAE that reach the firm's activities, "wheresoever conducted." A Dubai-licensed exchange with European clients must therefore consider GDPR as well as the PDPL, and our GDPR guide covers those obligations. The Rulebook also says compliance includes where data may be stored or located and how it is transferred (Rule II.A.2), so cloud hosting choices and cross-border transfers belong in the compliance analysis, not only in an IT decision.

On top of the law itself, VASPs must produce and implement a written compliance programme to protect the privacy of personal data (Rule II.B.1). At a minimum, two things must be in place (Rule II.B.2). The first is a Data Protection Officer with the competencies and experience to perform the statutory duties of the role under applicable law, including Article 11 of the PDPL. The second is a function within the organization responsible for managing and protecting personal data, sized to the level of risk involved, and responsible for implementing and maintaining the relevant processes, procedures, and controls.

The Rulebook explicitly allows the DPO and the CISO to be one individual, a flexibility that matters for smaller VASPs. The limits are worth stating precisely. The CISO must be a different person from the Compliance Officer (Rule I.I.1), so that pairing is not allowed. The CISO is also formally responsible only for Parts I and III of the Rulebook, and Part II compliance sits with the DPO role, so a combined appointment carries both sets of accountabilities in one person. A firm that combines the roles should check that the individual has the capacity and the competencies for both, since the DPO must be able to perform the statutory duties in full.

Two further duties reach beyond the firm's own systems. VASPs must take all necessary steps, including notifications, contractual provisions, and consents, so that VARA can access information relating to Part II compliance regardless of where it is stored, in the manner and timelines VARA sets (Rule II.C.1). That means data processing agreements and consent language should be drafted with VARA access in mind. And when a personal data incident occurs, the firm must notify VARA within 24 hours of notifying a data regulator or data subject. This deadline runs separately from the 72-hour cybersecurity rule covered above (Rule II.C.2).

The Cybersecurity Policy is where the two parts of the Rulebook meet. It must contain procedures that enable compliance with Part II and the PDPL while maintaining data confidentiality at all times (Rule I.B.3). The firm's governance framework must comply with the UAE Data Office's requirements to the extent they apply (Rule I.C.1). For the wider legal picture, including the PDPL's scope and how it interacts with DIFC and ADGM regimes, see our guide to UAE data protection law.

Where VASP Cybersecurity Programmes Fall Short of the Rulebook

The gaps most likely to fail a VARA cybersecurity review are where the Rulebook asks for something more specific than a generic security program delivers: a Cybersecurity Policy covering all 19 minimum criteria, testing before every new launch, documented key-access audits, and incident reporting on a fixed clock. These gaps come from a close reading of the Rulebook's wording, not from a statistical survey of audit results.

A policy that skips the less obvious criteria. Most firms cover information security, access controls, and incident response because every security framework includes them. The criteria that generic templates tend to omit are the ones specific to virtual assets: monitoring and implementing changes to core protocols the VASP does not control (Rule I.B.3(n)), sharing threat intelligence with other VASPs where it benefits the market (item (s)), and supplier probity alongside staff vetting (item (p)). 

Client-side procedures are another easy miss, including authentication checks before an account or contact change (item (k)) and multi-factor authentication for transactions above client-set limits or following a change of wallet address (item (i)). A policy borrowed from a general ISO 27001 template will rarely cover all 19 without deliberate mapping.

Testing that ignores the pre-launch trigger. Rule I.E.1 requires independent testing annually and before introducing any new system, application, or product. A firm that books one penetration test each year, on a fixed date, can comply on the calendar and still breach the rule the day it ships a new wallet feature or integration. The fix is procedural: tie testing to the release process so that new products cannot go live without it.

Key management controls that exist but are not evidenced. The key rules contain several specific, checkable duties. Internal audits of access removal must run quarterly (Rule I.D.2(d)(ii)). When a staff member with key access leaves, the firm must assess whether a new key needs to be generated (I.D.2(c)). Backups of keys and seed phrases must sit in a separate location from the primary (I.D.2(b)). A firm can do all of this in practice and still fail a review because the rules require audit logs and documented procedures, and an inspector will ask to see them.

Test evidence that cannot be produced quickly. The Rulebook says evidence of tests and audits must be documented and made immediately available to VARA on request (Rule I.E.3). Reports stored with an outsourced tester, or scattered across teams, make "immediately" difficult. A single, current repository holding reports, remediation tracking, and management sign-off addresses this.

Incident reporting with no defined threshold. Rule I.K.1 makes materiality the trigger for the 72-hour report but does not define the term. Firms without a documented threshold, and without a timestamped record of when an incident was detected, are debating the definition while the deadline runs. Personal data incidents add a separate 24-hour duty under Part II, so the process needs to handle two clocks.

Requirements filed under the wrong function. Some Part I duties sit outside what most teams think of as cybersecurity. Firms must run distributed ledger tracing software to screen incoming and outgoing transactions and wallet addresses (Rule I.F.2), and any firm using algorithms in its VA Activities needs board-level oversight and documented records of their logic, testing, and biases (Rule I.G). Neither tends to appear on a security team's checklist, so you must assign ownership deliberately.

How to Prepare for a VARA Cybersecurity Assessment

To prepare, map your Cybersecurity Policy against the Rulebook's 19 minimum criteria, then assemble dated evidence for every Part I duty. VARA can ask for the policy at any time (Rule I.B.1). The Rulebook requires test and audit evidence to be available "immediately" on request (Rule I.E.3). The Rulebook does not describe a formal inspection procedure or a fixed assessment format, so this preparation is built from what VARA is entitled to ask for.

Start with the policy, then build the evidence pack

Check the Cybersecurity Policy line by line against Rule I.B.3(a) to (s), and record any criterion that is missing or only implied. Then confirm there is a dated record showing the CISO reviewed and updated it within the last twelve months, because the annual review is a rule, not a good practice (Rule I.B.2).

Next, collect the proof for each recurring duty in one place. The table shows what to hold for each requirement.

The Rulebook asks for evidence of testing and audits specifically, so the other rows are what a careful inspector could reasonably ask to see rather than an explicit list. Keeping everything in a single repository, owned by the CISO, avoids the common problem of reports sitting with outsourced testers.

Some duties cannot be proven with a document alone. The 72-hour cybersecurity notification (Rule I.K.1) and the 24-hour personal data notification (Rule II.C.2) both depend on the firm knowing who decides, who drafts, and where it records detection time. Writing a materiality threshold into the incident procedure and running a tabletop exercise with a notification template will show whether the process holds up. The same applies to key compromise. Schedule 1 guidance describes a formal response plan with rapid key rotation and regular simulation, and although guidance is not binding, it signals what VARA expects to see tested.

Check TLPT readiness

VARA may notify a VASP that it must carry out threat-led penetration testing, and the firm must then ensure that any third-party providers in scope take part (Rule I.E.6). Review vendor contracts now for a clause that lets a regulator-required test proceed. Also confirm that any tester you use could meet the criteria in Rule I.E.7: good repute, threat intelligence expertise, accreditation or a formal code of conduct, independent assurance, and professional indemnity cover.

Work through the gaps in order

A practical sequence is to close policy gaps first, since VARA reviews the policy at licensing; then fix anything with a calendar deadline (the annual test, the annual BCDR test, the quarterly access audit); then tighten evidence retention. 

Conclusion

Meeting VARA's cybersecurity requirements comes down to four things you can prove on request: a Cybersecurity Policy that covers all 19 minimum criteria and is reviewed by the CISO every year, independent testing both annually and before each new launch, documented key-access controls, and an incident process that can meet the 72-hour and 24-hour notification deadlines. Firms most often fall short by having the controls in practice but not the dated evidence, since the Rulebook expects test and audit evidence to be available immediately when VARA asks for it.

The practical starting point is the policy. Map it against Rule I.B.3(a) to (s), close any gaps, and then work outward to testing, key management, and incident readiness. If you want an independent view of where your program stands against these requirements, Femto Security's VARA compliance and penetration testing services are built around the Technology and Information Rulebook.

Frequently Asked Questions (FAQs)

Does VARA require annual penetration testing?

Yes. A VASP must engage a qualified, independent third party to carry out vulnerability assessments and penetration testing at least once a year, and again before introducing any new system, application, or product (Rule I.E.1). Where relevant to the firm's business, the testing must include comprehensive audits of its smart contracts. The firm must provide results to VARA on request, document the evidence, and keep it immediately available for inspection.

How often must the Cybersecurity Policy be reviewed?

At least once a year, and the review and any update must be carried out by the CISO (Rule I.B.2). VASPs submit the policy to VARA as part of licensing and at any later time VARA asks for it (Rule I.B.1). The Rulebook sets a separate, less specific duty for the wider Technology Governance and Risk Assessment Framework, which must be reviewed, updated, and tested "periodically" without a fixed interval (Rule I.A.5).

What is VARA's incident notification deadline?

A VASP must notify VARA of a material cybersecurity event, or of an event that triggers its BCDR Plan and materially affects operations, as soon as reasonably practicable and no later than 72 hours from detection (Rule I.K.1). The report must describe the event's nature, scope, and impact, the mitigation steps being taken, and whether any authority other than VARA has been notified. A separate deadline applies to personal data incidents: VARA must be notified within 24 hours of the firm notifying a data regulator or a data subject (Rule II.C.2).

Can the CISO also be the Data Protection Officer?

Yes. The Rulebook says the CISO may also take on the responsibilities of the Data Protection Officer (Rule I.I.1), and that the DPO can be the same individual as the CISO (Rule II.B.2(a)). Two limits apply. The CISO must be a separate person from the Compliance Officer, and the DPO must have the competencies and experience to perform the role's statutory duties under applicable law, including Article 11 of the PDPL.

What triggers a VARA Threat-Led Penetration Test?

VARA itself triggers it, by notifying a VASP that it must carry out advanced testing when VARA considers this necessary and proportionate (Rule I.E.5). It weighs the specific risks the firm is or might be exposed to, the criticality of its business and VA Activities, and any other relevant risks. The Rulebook sets no fixed schedule or numeric threshold, so a firm cannot rule it out in advance. An external tester must carry out a required test, may cover Critical or Important Functions on live production systems, and must include any third-party providers whose participation is necessary (Rule I.E.6).