VARA Penetration Testing and Smart Contract Audits

If you want the whole of VARA’s binding penetration testing and smart contract audit requirement, it is Rule I.E.1 of the Technology and Information Rulebook, and it reads like this: VASPs must engage a qualified and independent third-party auditor to conduct vulnerability assessments and penetration testing, including (to the extent relevant to the business and VA Activities) comprehensive audits of the effectiveness, enforceability and robustness of all smart contracts, at least on an annual basis and prior to the introduction of any new systems, applications and products.

Two triggers. Annual is the one everyone quotes. “Prior to the introduction of any new systems, applications and products” is the one that actually governs a VASP shipping product, and it has no calendar to hide behind.

Everything else you have read on this subject - quarterly vulnerability assessments, smart contract audits before deployment, formal verification, penetration testing by qualified third parties - is real, but it comes from Schedule 1, which VARA expressly issues as Guidance and phrases as what VASPs are “expected to” do. Schedule 1 is a risk taxonomy for building your Technology Governance and Risk Assessment Framework, not a licensing tier. There is no such thing as a “VASP in Risk Category 2”. This article separates the Rules from the Guidance and sources each one.

Read them together and three things fall out that most testing programmes get wrong.

• The trigger is change, not just the calendar. A VASP that runs a clean annual pen test in January and ships a new custody product in June, untested, has breached I.E.1. The rule says “and”, not “or”.
• Smart contract audits are inside the pen test obligation, not beside it. I.E.1 puts them in the same sentence, qualified by “to the extent relevant to the VASP’s business and VA Activities”. If you deploy or materially rely on smart contracts, the audit is part of the same annual and pre-launch duty and must be done by the same qualified, independent third party.
• “Regular” is a Rule; the interval is yours. I.E.2 obliges the security testing and vulnerability audits to happen “on a regular basis” without setting a number, and adds “on request by VARA”. The quarterly figure that circulates comes from Schedule 1 Guidance, and that distinction is worth keeping straight in your own policy documents.

Schedule 1’s Security testing standard (Risk Category 2, standard 11) is the source of every frequency you have seen attributed to VARA. Its framing sentence is the important part:

“To ensure ongoing identification and remediation of vulnerabilities before they can be exploited, VASPs are expected to conduct appropriate security tests regularly, and in all events prior to any update to a production system. Such security test should include, but not be limited to - a. annual penetration testing by qualified third parties; b. quarterly vulnerability assessments; c. continuous automated security scanning; d. regular best practice security exercises for high-value systems; and e. formal remediation tracking for identified vulnerabilities.”

VARA Technology and Information Rulebook, Schedule 1, Risk Category 2, standard 11

Note how much narrower this is than it is usually reported. It is an expectation, not a Rule. And it is stricter than the Rule in one respect: the Guidance expects testing before any update to a production system, where Rule I.E.1 requires it before the introduction of new systems, applications and products. The Guidance also names formal remediation tracking as a component of the test, not an optional follow-up. That is the item most VASPs cannot evidence.

Risk Category 2’s Smart contract security standard (standard 4) is the other half, and it is short enough to give in full. VASPs are expected to implement formal smart contract review and testing processes including: static and dynamic code analysis; independent third-party audits before deployment and formal verification where applicable; comprehensive penetration testing; and regular re-assessment of deployed contracts.

Threat-Led Penetration Testing is not part of the standing testing programme. Rule I.E.5 is explicit that it is a notification power: “VARA may notify a VASP that it is required to carry out advanced testing by means of TLPT, where VARA considers it necessary and proportionate to do so”, taking into account any specific risks to which the VASP is or might be exposed, the criticality of the VASP’s business or VA Activities, and any other relevant risks. If VARA has not notified you, you do not have a TLPT obligation.

When VARA does notify, Rules I.E.6 to I.E.10 set the conditions. These are the requirements that matter when you write the statement of work:

• External testers only (I.E.6.a). Each TLPT is to be carried out by an external tester. There is no internal-tester carve-out.
• Live production, where required (I.E.6.b). TLPTs may be required to cover Critical or Important Functions and, where required, be performed on live production systems, technologies and processes supporting those Functions.
• Your third parties may be pulled in (I.E.6.c). Where it is necessary for third-party service providers to be included in scope, the VASP shall ensure their participation. That is a contract problem you solve before the notification arrives, not after.
• You own the testing risk (I.E.6.d). The VASP must mitigate the risks of testing, including impact on data, damage to assets, and disruption to Critical or Important Functions at the VASP itself or its counterparts, with due security assurance of data and privacy of client assets.
• Summary, remediation plan, and proof of method (I.E.6.e and I.E.6.f). At the end of testing, the VASP together with the external tester must produce a summary of the relevant findings, the remediation plans, and documentation demonstrating that the TLPT was conducted in accordance with the requirements, and must promptly provide all of it to VARA.

Rule I.E.7 sets the tester criteria, and it is unusually specific for a VARA rule. External testers must be suitable and of good repute; possess all necessary technical and organisational capabilities and demonstrate specific expertise in threat intelligence and penetration testing; be certified by an accreditation body, or adhere to formal codes of conduct or ethical frameworks; provide independent assurance or an audit report on the sound management of the risks of carrying out the TLPT, including protection of the VASP’s confidential information; and be duly and fully covered by relevant professional indemnity insurances, including against risks of misconduct and negligence.

Rule I.E.8 reaches into the contract itself: agreements with external testers must require sound management of the TLPT results and any data processing of them (generation, storage, aggregation, drafting, reporting, communication and destruction), and must not create additional risks for the VASP or any of its systems.

Rules I.E.9 and I.E.10 handle a specific structure. Where a third-party technology service provider’s participation is reasonably expected to have an adverse impact on the quality or security of the services it delivers to the market, or on the confidentiality of data related to those services, the VASP and that provider may agree that the provider contracts directly with the external tester. If they do, the provider must remain under the direction of the VASP, the results must cover the relevant range of services supporting the VASP’s Critical or Important Functions, and all results the provider gives the tester must be a fair representation of, and specific to, the VASP.

Risk Category 5 of Schedule 1 widens the lens from security testing to operational resilience. It is Guidance, and it carries the second concrete frequency in the schedule. VASPs are expected to:

• establish and maintain a sound and comprehensive digital operational resilience testing programme;
• identify weaknesses, deficiencies and gaps, and promptly implement corrective measures;
• follow a risk-based approach, taking into account specific risks, the criticality of assets and services, and any other material risk factor;
• ensure that tests are undertaken by independent external parties;
• classify and remedy all issues revealed, and establish internal validation processes to confirm that every identified weakness is fully addressed; and
• ensure that appropriate tests are conducted at least yearly on all systems and applications supporting Critical or Important Functions.

The programme itself is expected to exercise tools and systems through, among others: vulnerability assessments and scans; open source analyses; network security assessments; gap analyses; physical security reviews; questionnaires and scanning software solutions; source code reviews; scenario-based tests; compatibility testing; performance testing; end-to-end testing; and penetration testing. That list runs to twelve items and is the closest thing VARA publishes to a testing menu. Nothing in it sets a duration, a team structure or a recovery time objective.

A testing calendar built from Section E alone will miss binding audit obligations that VARA places elsewhere. Three matter:

• External audit, annually (Compliance and Risk Management Rulebook I.G.1). An independent third-party auditor must audit the financial statements to produce an annual report, and VARA must be notified of the auditor’s full name and contact details on appointment. VARA may require a VASP to appoint alternative auditors if the originals are not deemed appropriate for the size, complexity and reputation of the business.
• Internal audit, quarterly (Compliance and Risk Management Rulebook I.G.2). Where applicable, an objective internal audit function independent of the operational function, reporting directly to Senior Management, performing audit work regularly and at least on a quarterly basis, informing Senior Management of findings and following up to resolution.
• Wallet transfer mechanisms, if you are a custodian (Custody Services Rulebook III.C.1.c). The methodologies determining transfers between hot, cold and warm wallets must be well documented and subject to internal controls and audits performed by an independent third-party auditor. That is a distinct audit from the Section E penetration test and it is easy to leave uncovered.

Add Rule I.E.4, the regular audit by independent auditors of the VASP’s management processes and regulatory compliance, and the picture is a VASP under four distinct audit regimes: technical testing, financial statements, internal audit, and management-process audit. They have different auditors, different cadences and different reports. Merging them into one line item on a calendar is how gaps get created.

Notice what is absent: no durations, no team sizes, no cost bands, no remediation service levels. VARA does not publish them, so your policy should not pretend to quote them. Where the rulebook leaves an interval open, Rule I.A.2 requires your policies and controls to take into account the nature, scale and complexity of the business, the diversity of its operations, and the volume and size of its transactions. Set the number, write down why, and be ready to defend it.

Making the evidence immediately available, which is the actual Rule

Rule I.E.3 quietly decides whether the rest of the programme counts: evidence of tests and audits must be documented and made immediately available for inspection by VARA on request. A pen test report sitting in someone’s inbox, with no record of which findings were closed and when, does not meet that standard.

Venvera does not ship a VARA framework module, and nothing here is a claim that it does. What it does ship is the structure this resolves into: a resilience testing register where tests are scheduled and each finding carries a severity, an owner, a remediation plan and a remediation status (built for the DORA testing articles, and the same shape a Section E programme needs); an evidence repository with freshness tracking; a risk register to hold the risk-based judgements VARA leaves to you; third-party risk management for the providers Rule I.E.6.c can pull into a TLPT; and a control crosswalk so one test serves ISO 27001, NIST CSF and UAE Information Assurance rather than being rerun for each.

Frequently Asked Questions

How often does VARA require a penetration test?

At least annually, and prior to the introduction of any new systems, applications and products. Rule I.E.1 of the Technology and Information Rulebook joins the two triggers with “and”, so an annual test alone is not sufficient for a VASP that ships new systems or products during the year. The test must be conducted by a qualified and independent third-party auditor, and the results provided to VARA on request.

Does VARA require smart contract audits?

Yes, where relevant. Rule I.E.1 requires the third-party auditor’s work to include, “to the extent relevant to the VASP’s business and VA Activities, comprehensive audits of the effectiveness, enforceability and robustness of all smart contracts”, on the same annual and pre-launch triggers as the penetration test. Schedule 1 Guidance (Risk Category 2, standard 4) adds the expected method: static and dynamic code analysis, independent third-party audits before deployment and formal verification where applicable, comprehensive penetration testing, and regular re-assessment of deployed contracts.

Are quarterly vulnerability assessments a VARA rule?

No. The quarterly figure comes from Schedule 1, Risk Category 2, standard 11.b, which VARA issues as Guidance and phrases as what VASPs are “expected to” do. The binding rule is I.E.2, which requires security testing on infrastructure and applications, and internal and external system vulnerability audits, “on a regular basis and on request by VARA”, without naming an interval. Quarterly is the sensible default and it is the figure VARA has published, but it is not a Rule you breach by choosing a different, justified cadence.

Does every VASP have to perform TLPT?

No. Rule I.E.5 states that VARA may notify a VASP that it is required to carry out TLPT where VARA considers it necessary and proportionate, taking into account any specific risks to which the VASP is or might be exposed, the criticality of its business and VA Activities, and any other relevant risks. Absent a notification from VARA, there is no TLPT obligation. Once notified, Rules I.E.6 to I.E.10 apply, including external testers only, possible testing on live production systems, and mandatory participation of in-scope third-party service providers.

What certifications must a VARA penetration tester hold?

For the standing testing obligation, Rule I.E.1 requires only a “qualified and independent third-party auditor” and names no certification. For TLPT, Rule I.E.7 requires external testers to be suitable and of good repute; to possess the necessary technical and organisational capabilities with specific expertise in threat intelligence and penetration testing; to be certified by an accreditation body or to adhere to formal codes of conduct or ethical frameworks; to provide independent assurance or an audit report on their management of testing risks; and to be duly and fully covered by professional indemnity insurance, including against risks of misconduct and negligence. VARA does not name OSCP, CREST or any other specific credential.

What testing evidence can VARA ask a VASP to produce?

Rule I.E.3 requires that evidence of tests and audits be documented and “made immediately available by them for inspection by VARA, upon VARA’s request”. Rules I.E.1 and I.E.4 separately require the results of the third-party assessments and of the independent management-process audits to be provided to VARA on request. VARA prescribes no report format, no severity scale and no remediation timetable. Schedule 1 Guidance does expect “formal remediation tracking for identified vulnerabilities” as a component of the security test itself, so closure evidence, and not just the report, is the thing to be able to produce.

Primary sources

Every requirement in this article is taken from VARA’s published rulebooks. Confirm the current version before relying on any specific rule.

• Technology and Information Rulebook, Part I Section E - Testing and Audit, Rules I.E.1 to I.E.10, including the TLPT notification power and the external tester criteria.
• Technology and Information Rulebook, Schedule 1, Risk Category 2 (Technical) - Guidance, including the Smart contract security standard (4) and the Security testing standard (11).
• Technology and Information Rulebook, Schedule 1, Risk Category 5 - Guidance on digital operational resilience testing, including the yearly test of systems supporting Critical or Important Functions.
• Compliance and Risk Management Rulebook - Part I Section G: external audit (I.G.1) and internal audit at least quarterly (I.G.2).
• Custody Services Rulebook - Rule III.C.1.c, independent third-party audit of the mechanisms for transfer between wallet types.

Last updated: July 2026. This article is general information, not legal advice. Confirm the current rulebook text and consult VARA directly for entity-specific guidance.