DORA Source Code Review: Do Smart Contract Audits Count?
Quick answer. Partly: an independent smart contract audit is one of the tests DORA names, since Article 25(1) lists "source code reviews where feasible". It is not the whole program: pair it with pentests and other Article 25 tests.
Video transcript
Does a smart contract audit count as DORA resilience testing? Partly. It is one of the tests DORA names, but it is not the whole program.
Article 25 of DORA lists source code reviews where feasible among the tests a program should include. Smart contract code usually sits in your own repository or onchain, so feasibility is rarely in doubt.
To count, it must meet Article 24: chosen on a risk basis, run by independent testers, every finding fixed and validated, and repeated at least yearly for critical or important functions.
But an audit reviews one commit. It misses live roles and timelocks, keys and signers, and offchain web apps, APIs and cloud. It is not threat-led penetration testing either.
So map the Article 25 list onto your real stack: code review for contracts, scans for exposed hosts, scenario tests for key compromise, and pentests for apps and cloud.
Then file the audit as evidence: scope and commit hashes, the function it supports, tester independence, findings with fix review, proof the deployed bytecode matches, and the next test date.
Guardian's Vanguard audit pairs two independent teams with an invariant suite that outlives the audit. Browse more than 300 published Guardian reports.
Read the full article for the checklist, and confirm with counsel how your supervisor will treat it. Or talk to Guardian at guardian.security.
DORA, the EU's Digital Operational Resilience Act (Regulation (EU) 2022/2554), has applied since 17 January 2025.
It covers crypto-asset service providers (CASPs) authorized under MiCA and issuers of asset-referenced tokens. Chapter IV makes each of them, other than microenterprises, run a digital operational resilience testing program.
For a firm whose services run on smart contracts, the audit is the obvious test to include. So does it count?
This article explains the technical and security side of DORA's digital operational resilience testing requirements (Articles 24 and 25 of Regulation (EU) 2022/2554). It is not legal advice; confirm how it applies to you with counsel.
What Article 25 Lists
Article 24(1) requires a "sound and comprehensive digital operational resilience testing programme".
Article 25(1) says the program must provide for "the execution of appropriate tests, such as":
- vulnerability assessments and scans
- open source analyses
- network security assessments
- gap analyses
- physical security reviews
- questionnaires and scanning software solutions
- source code reviews where feasible
- scenario-based tests
- compatibility testing, performance testing and end-to-end testing
- penetration testing
Three details matter for smart contracts.
First, the words such as make the list illustrative. Article 25 does not demand every test on every system.
The choice of tests is risk-based (Article 24(3)) and proportionate to the firm (Article 4(2)).
Second, "where feasible" attaches to source code review only. DORA does not define it, but RTS 2024/1774 Article 16(8) uses it for code from ICT third-party providers and open-source projects.
Smart contracts rarely raise that access problem. The code usually sits in the firm's own repository or is verified onchain.
Third, Recital 56 calls these tests, penetration testing aside, "the assessment of basic requirements". Threat-led penetration testing (TLPT) under Article 26 is separate, and required only of entities their competent authority identifies.
Where an Audit Fits
DORA defines an ICT asset as "a software or hardware asset in the network and information systems used by the financial entity" (Article 3(7)).
On a plain reading, a CASP's custody contracts or an issuer's mint and burn logic are software the firm uses to deliver its service.
If they support a critical or important function (Article 3(22)), Article 24(6) applies: appropriate tests at least yearly.
RTS 2024/1774 says what the review should involve. Article 16(3) requires source code reviews "covering both static and dynamic testing".
A thorough smart contract audit maps onto those requirements closely:
| Audit component | What it does | Where it lands |
|---|---|---|
| Manual review | Researchers attack logic, roles and integrations | DORA Article 25(1), source code review |
| Static analysis | Detectors run over the source | RTS 2024/1774 Article 16(3), static testing |
| Invariant fuzzing | Properties tested against generated call sequences | RTS 2024/1774 Article 16(3), dynamic testing |
| Findings by severity | Each issue classified, with a fix | DORA Article 24(5), prioritize and classify |
| Fix review | Each fix verified at a pinned commit | DORA Article 24(5), remedy and validate |
| Review of integrated code | Libraries, forks, oracles and bridges | RTS 2024/1774 Article 16(8) |
The same review serves MiCA
Commission Delegated Regulation (EU) 2025/305 sets what goes into a CASP authorization application.
Article 9(b) asks for a description of a third-party cybersecurity audit, if one is available. The tests it should ideally cover end with: "where the applicant uses and/or develops smart-contracts, a cybersecurity source code review of them".
One audit can answer both files, provided it is documented for both.
What an Audit Misses
An audit reviews one commit. Article 24 asks for a comprehensive program, and several gaps sit outside the code.
- Live configuration: role holders, timelocks and oracles, which can all change after the report.
- Keys and signers: multisig thresholds, signer devices, key storage and signing procedures.
- Offchain systems: web apps, APIs, keepers, relayers, cloud and CI/CD need other Article 25 tests.
- Time: a two-year-old launch audit does not cover this year, or code shipped since.
- Production: TLPT tests critical live production systems (Article 3(17)). A code review is not TLPT.
- Independence: Article 24(4) requires independent testers. A review by the code's authors is hard to defend.
Building the Full Program
Map the Article 25 list onto the stack you actually run:
| Article 25 test | Applied to a crypto stack |
|---|---|
| Source code reviews | Contracts, keepers, bots and transaction-signing backends |
| Vulnerability assessments and scans | Internet-facing hosts, admin panels, exposed storage, outdated software |
| Open source analyses | Imported libraries tracked against advisories (RTS 2024/1774 Article 10(2)(d)) |
| Network security assessments | Cloud networks, node and RPC infrastructure, remote access paths |
| Scenario-based tests | Key compromise, unreachable signer quorum, oracle failure, chain halt |
| End-to-end testing | Deposit to withdrawal, or mint to redemption, across the stack |
| Penetration testing | Web apps, APIs, signing services, cloud accounts and the deploy pipeline |
Fuzzing earns its place twice. During the audit, it is dynamic testing of the contract code.
Kept as a regression harness, it retests every change against the same safety properties. That helps keep the yearly testing claim true between audits.
For pentests and TLPT, see DORA penetration testing requirements. For other regimes, see Crypto Regulatory Compliance.
Filing the Audit as Evidence
A supervisor wants to trace each test to a system, a function and a result. File these with every audit:
- Scope: repositories, commit hashes, contracts, chains, addresses, and what was out of scope.
- Function supported: the critical or important function each contract serves, and why this test (Article 24(3)).
- Tester independence: who reviewed, and confirmation they did not write the code (Article 24(4)).
- Method: manual review, static analysis and dynamic testing such as fuzzing (RTS 2024/1774 Article 16(3)).
- Findings by severity, each with an owner, a remediation decision and a date (Article 24(5)).
- Fix review: the auditor's check of every fix at a pinned commit, showing weaknesses are "fully addressed" (Article 24(5)).
- Deployment match: proof that deployed bytecode, live roles and parameters match what was reviewed.
- Change log: every change shipped since the audit, and the review each one received.
- Next test date: within a year for critical or important functions (Article 24(6)).
- Disclosure route: how you disclose vulnerabilities (RTS 2024/1774 Article 10(2)(e)) and how researchers report them.
Reuse the same pack for MiCA authorization, with the non-technical description RTS 2025/305 Article 9(d) asks for.
How Guardian Helps
Vanguard, Guardian's flagship audit, puts two independent teams on the same scope.
Team A uses expert manual review and fuzzing. Team B is driven by Helix, Guardian's AI auditor. Only human-verified findings reach the report.
Guardian writes the protocol's core safety properties as an invariant suite that outlives the audit as a regression harness.
Vanguard also includes six months of review for updates to the audited scope (up to 2,500 smart contract SLOC, or 10,000 SLOC for offchain code).
Guardian's Regulatory & Compliance assessments map each artifact to its provisions. An audit with fix review maps to DORA Article 25 and MiCA RTS 2025/305 Article 9.
Deployment verification, matching deployed bytecode to the audited commit, maps to DORA Article 9(4)(e).
Browse 300+ published Guardian reports in the audit portfolio.
Frequently Asked Questions
Does a smart contract audit satisfy DORA resilience testing requirements?
Partly. Article 25(1) lists source code reviews among the tests a DORA program should include. But Article 24 requires a risk-based, comprehensive program, with appropriate tests at least yearly on all systems supporting critical or important functions.
Is a smart contract audit the same as TLPT under DORA?
No. TLPT under Article 26 is an intelligence-led red team test of critical live production systems, required at least every 3 years only of entities their competent authority identifies. A source code review is an Article 25 test.
Can our own developers do the source code review?
Article 24(4) allows internal testers, but tests must be undertaken by independent parties, with conflicts of interest avoided. Developers reviewing their own code will struggle to meet that, so use reviewers who did not build the contracts.
Does DORA apply to DeFi protocols?
DORA covers types of firm, such as MiCA-authorized CASPs, not software; whether a protocol's operators are in scope depends on what they do. A regulated firm relying on a protocol's contracts should consider them in its testing program.
Sources
- Official Journal of the EU: Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA), 14 December 2022
- Official Journal of the EU: Commission Delegated Regulation (EU) 2024/1774, RTS on ICT risk management tools, methods, processes and policies, 13 March 2024
- Official Journal of the EU: Commission Delegated Regulation (EU) 2025/305, RTS on the information in an application for authorisation as a crypto-asset service provider, 31 October 2024
- Official Journal of the EU: Regulation (EU) 2023/1114 on markets in crypto-assets (MiCA), 31 May 2023
- Guardian: Vanguard
- Guardian: Regulatory & Compliance Assessments
Turn your audit into DORA evidence
Guardian audits your contracts with two independent teams and maps every report, fix review and deployment check to the provisions it answers.