Learn
Knowing these 18 criteria before you start writing your cybersecurity policy will save you at least two rounds of revision. Most VASPs learn about half of them the hard way.
I have a confession to make: the first time I reviewed a VASP’s cybersecurity policy for VARA compliance, I thought it was solid. It covered access control. It had incident response procedures. It addressed encryption. It even had a section on employee training. Professional, thorough, well-written.
It failed VARA review. Badly.
The problem wasn’t that the policy was bad. It was that the policy was written for ISO 27001, and VARA requires 18 specific criteria that don’t perfectly align with ISO categories. The policy covered 11 of them. The other 7 - including cryptographic key controls, smart contract security, and virtual asset-specific threat management - were either missing entirely or buried in generic language that didn’t satisfy VARA’s specificity requirements.
So here they are. All 18 criteria from Part I, Section B of the Technology and Information Rulebook, explained in the order you’ll actually want to implement them.
Before You Start: How These Criteria Work
VARA doesn’t just want 18 paragraphs in a policy document. For each criterion, they expect three things:
1. A policy statement - what your organisation commits to
2. Supporting procedures - detailed steps for how you implement it
3. Evidence of implementation - logs, configurations, test results, records proving it’s not just on paper
Criteria 1-6: Access, Identity, and Network Controls
Criterion 1: Access Control
Role-based access control (RBAC) across all systems. Least-privilege principle. Regular access reviews (at least quarterly). Immediate revocation upon role change or termination. This sounds standard, but VARA expects it applied specifically to key management systems, wallet infrastructure, and blockchain node access - not just office IT.
Criterion 2: Identity and Authentication Management
Multi-factor authentication (MFA) for all privileged access, and for all staff accessing production systems. Hardware tokens or FIDO2 keys are strongly preferred over SMS-based MFA (which VARA views as insufficient for high-risk systems). Identity lifecycle management: provisioning, de-provisioning, and regular re-certification of access rights.
Criterion 3: Network Security
Network segmentation between operational environments (production, staging, development). Firewalls and intrusion detection/prevention systems. Specific controls for blockchain node network access. VPN or zero-trust network access for remote staff. Network monitoring with alerting on anomalous traffic patterns.
Criterion 4: Secure Configuration Management
Hardened system configurations based on industry benchmarks (CIS Benchmarks, vendor hardening guides). No default passwords. Disabled unnecessary services and ports. Configuration management database (CMDB) or equivalent for tracking all production assets. Change management process for any configuration modifications.
Criterion 5: Endpoint Security
Endpoint detection and response (EDR) on all corporate devices. Mobile device management (MDM) for any mobile devices with access to corporate systems. Removable media controls. Full-disk encryption on all endpoints. Automated patching with defined timelines (critical patches within 24-48 hours).
Criterion 6: Email and Communication Security
Email filtering with anti-phishing, anti-malware, and anti-spam controls. DMARC, DKIM, and SPF configured for your domains. Secure communication channels for sensitive discussions (especially around key management and wallet operations). This one trips up VASPs that do most communication over Telegram - VARA expects documented, auditable communication channels for operational decisions.
Criteria 7-12: Data, Encryption, and Monitoring
Criterion 7: Data Protection and Classification
Data classification scheme (at minimum: public, internal, confidential, restricted). Classification applied to all data types: customer PII, transaction data, key material, audit logs, operational data. Handling procedures defined for each classification level. This ties directly into your UAE PDPL obligations as well.
Criterion 8: Cryptographic Controls
This goes beyond key management (which has its own dedicated section). Criterion 8 covers encryption standards for data at rest and in transit, certificate management, TLS configurations, and the use of approved cryptographic algorithms. VARA expects you to be specific: “we use encryption” isn’t sufficient. “We use AES-256-GCM for data at rest and TLS 1.3 for data in transit” is.
Criterion 9: Security Logging and Monitoring
Centralised log management (SIEM or equivalent). Logs must be tamper-resistant and retained for the period VARA specifies. Real-time monitoring with alerting for security-relevant events. Specific log categories: authentication events, privileged operations, system changes, transaction anomalies, and key management operations. 24/7 monitoring capability, either in-house or through a managed SOC.
Criterion 10: Vulnerability Management
Regular vulnerability scanning (at least monthly for external-facing systems, quarterly for internal). Defined remediation timelines by severity: critical vulnerabilities patched within 24-48 hours, high within 7 days, medium within 30 days. Vulnerability tracking and reporting. This includes not just traditional infrastructure but smart contract and DApp-specific vulnerability monitoring.
Criterion 11: Patch Management
Separate from vulnerability management (yes, VARA distinguishes them). Patch management covers the operational process: patch identification, testing, deployment, and verification. You need a defined patch cycle, emergency patching procedures, and a process for handling patches that can’t be applied immediately (with compensating controls). Blockchain node software updates are explicitly included.
Criterion 12: Secure Software Development
If you develop software (and most VASPs do), VARA expects a secure development lifecycle (SDLC): code review requirements, static and dynamic analysis, dependency scanning, secure coding standards, and separation of development/testing/production environments. Smart contract development gets additional scrutiny: formal verification is encouraged, and independent audits are required before deployment.
Criteria 13-18: Incident Response, Recovery, and Continuous Improvement
Criterion 13: Incident Response
A defined incident response plan with roles, escalation procedures, and communication templates. The 72-hour notification to VARA is part of this (covered in detail in my incident reporting article). Must include crypto-specific scenarios: key compromise, wallet theft, smart contract exploitation, DDoS attacks on trading engines. Regular tabletop exercises to test the plan.
Criterion 14: Business Continuity and Disaster Recovery
BCDR plans that cover both traditional IT failures and blockchain-specific scenarios (network congestion, chain forks, bridge failures). Defined RTOs and RPOs for each critical system. Annual BCDR testing with documented results. Specific provisions for maintaining client asset access during service disruption.
Criterion 15: Third-Party Risk Management
Due diligence and ongoing monitoring of all third-party technology providers. This includes cloud service providers, API partners, smart contract audit firms, and blockchain infrastructure providers. Contractual requirements for security standards, incident notification, and right-to-audit. Concentration risk assessment if you’re dependent on a single provider for critical functions.
Criterion 16: Physical Security
Physical access controls for data centres, server rooms, and any location housing key material or critical infrastructure. CCTV, access logging, visitor management, environmental controls (fire suppression, climate control). For companies using co-location facilities, you need to demonstrate that the facility’s physical security meets VARA standards.
Criterion 17: Security Awareness and Training
Covered in detail in my CISO and staff competency article, but to summarise: annual security awareness training for all staff, role-specific training for technical personnel, onboarding training before system access, phishing simulations, and documented training records with assessment results.
Criterion 18: Security Governance and Continuous Improvement
Regular review and update of all cybersecurity policies (at least annually). Metrics and KPIs for measuring security effectiveness. Integration of lessons learned from incidents and near-misses. Internal and external audit findings tracked to resolution. This is VARA’s way of ensuring your security programme evolves rather than gathering dust in a document management system.
The DESC Overlay: Don’t Forget the Second Framework
Every one of these 18 criteria also needs to align with the Dubai Electronic Security Center (DESC) standards. DESC isn’t a VARA requirement per se - it’s a Dubai-wide requirement that VARA explicitly incorporates by reference.
The good news: there’s significant overlap. About 70% of DESC controls map directly to one of the 18 VARA criteria. The bad news: the remaining 30% are additional requirements that your VARA-focused policy might miss. DESC has its own specific controls around data localisation, government reporting, and sector-specific security standards.
The practical approach is to build your cybersecurity policy against VARA’s 18 criteria first, then map each criterion to the corresponding DESC controls and fill any gaps. A multi-framework compliance platform makes this manageable. Trying to do it in separate documents is a recipe for inconsistency and audit findings.
Where Policies Actually Fail VARA Review
After reviewing dozens of VARA submissions, the failure patterns are consistent:
Too generic. Policies that say “we implement strong access controls” without specifying what “strong” means. VARA wants specifics: RBAC model, quarterly access reviews, MFA using hardware tokens, privilege escalation approval process.
Missing the crypto-specific criteria. Criteria 8 (cryptographic controls), 12 (secure development for smart contracts), and 15 (third-party risk for blockchain infrastructure) are the most commonly missing or inadequately addressed.
Policy without evidence. Having a beautiful policy document that doesn’t correspond to actual practice. VARA will ask for evidence: show me the last three access reviews, show me your vulnerability scan results, show me your incident response exercise report.
No review cycle. Policies that were written once and never updated. VARA expects annual reviews at minimum, with updates triggered by significant changes (new systems, new threats, incidents, regulatory updates).
Ignoring DESC. I’ve said it before and I’ll say it again: VARA compliance without DESC alignment is incomplete compliance. Build it in from the start.
How to Actually Write the Policy
Here’s the approach that works, based on policies that have actually passed VARA review:
Start with a gap assessment. Map your current security controls against all 18 criteria. Be honest about where you have gaps. This becomes your implementation roadmap.
Structure the policy around the 18 criteria. Don’t try to be creative with the structure. VARA’s reviewers are looking for specific criteria. Make their job easy by mirroring the rulebook’s structure.
Write procedures, not just principles. For each criterion, include both the policy statement (what you commit to) and the operational procedures (how you do it). The procedures should be detailed enough that someone could follow them step by step.
Build your evidence library in parallel. As you implement each criterion, collect the evidence: configuration screenshots, test results, training records, access review reports. Store them in a structured compliance platform - Venvera handles this well across 13 regulatory frameworks starting at €399/month, with VARA-specific assessment templates and DESC cross-mapping built in.
Get the CISO involved from the start. The CISO should own this policy. VARA will check that the named CISO was involved in developing it, not just approving it after someone else wrote it.
The Bottom Line
Eighteen criteria. That’s the number. Not “implement appropriate cybersecurity.” Not “follow industry best practices.” Eighteen specific, enumerated requirements that your cybersecurity policy must address, each with evidence of implementation.
It sounds daunting, and the first draft is genuinely hard work. But once you have a policy that covers all 18 criteria with proper procedures and evidence, you have something much more valuable than a compliance checkbox. You have a security programme that actually works - one that will protect your clients, your business, and your licence.
Start with the criteria. Map your gaps. Build the evidence. And don’t forget DESC.
Map All 18 Criteria in One Place
Venvera gives you VARA-specific assessment templates covering all 18 cybersecurity criteria, DESC cross-mapping, and evidence management - across 13 frameworks, starting at €399/month.
Book a Demo →Last updated: March 2026. Requirements based on VARA Technology and Information Rulebook, Part I Section B. Always verify current requirements with VARA directly.