How I review onchain infrastructure
If a financial firm depends on something onchain, that dependency belongs in its ICT risk file, even while the rules on how to classify it are still unsettled. This page sets out what a review covers, why it matters under DORA, the seven areas I work through, and what you get back. It is a method, not a rating.
What a review covers
A review looks at a single onchain dependency that a financial firm relies on: a network, a protocol, an oracle, a bridge, a custodian, or a tokenization vendor. The unit is the dependency, not the asset. The question is not whether a token is a good investment. It is whether the thing you depend on can fail, how you would know, and what you would do about it.
Why this matters under DORA
DORA applies to crypto-asset service providers authorised under MiCA (DORA Article 2(1)(f); ESMA Q&A 2364). If you are one, my view is that the onchain infrastructure you rely on is hard to leave out of your ICT risk management.
The harder question is the public network itself. The European Supervisory Authorities have not settled whether a public permissionless blockchain is an ICT third-party service provider. The closest official analogy is Joint ESAs Q&A 2024_7290 (November 2025), on payment infrastructure. Until that is resolved, the defensible course is to treat the dependency as though it has to stand up to third-party scrutiny, and to document why you treated it that way.
The seven review areas
The first six areas follow the European Securities and Markets Authority's 2026 Common Supervisory Action on crypto-asset service provider custody resilience, which runs from H2 2026 to H1 2027 and covers governance arrangements, key and storage management, transaction controls, incident detection and response, smart contract risks, and third-party dependencies, so a review lines up with what a supervisor is already examining.
The seventh area is built on Commission Delegated Regulation (EU) 2024/1774, Article 6(4), which requires provision for updating cryptography as cryptanalysis develops, and documented mitigation and monitoring where that is not possible.
- Governance arrangements. Who decides, who can act alone, and where the authority to move value actually sits.
- Key and storage management. How signing keys are generated, held, backed up and recovered, and who could quietly lose or move them.
- Transaction controls. The limits, approvals and checks between an instruction and a settled transaction that cannot be reversed.
- Incident detection and response. How you would notice an exploit, a depeg or a stalled network, and what you would do in the first hour.
- Smart contract risks. The code you rely on but do not control: upgrade paths, admin keys, audit history and known failure modes.
- Third-party dependencies. The oracles, bridges, custodians and node providers underneath the one you think you depend on.
- Cryptographic agility. Whether the cryptography can be updated as it ages, and what the plan is where it cannot.
What you get
For each of the seven areas you get five things, written so a compliance team can lift them straight into an ICT risk file:
- The dependency. What you actually rely on, named plainly.
- The risk. How it can fail, and what that failure looks like for you.
- The mitigation. What reduces the risk, and what it costs to run.
- A monitoring indicator. One thing you can watch that tells you the risk is changing.
- An exit consideration. What moving off this dependency would take, worked out before you are forced to.
No score, no traffic light. A file your own team can read, question and defend.
Independence
Independence is the point of doing this at all. Any position I hold in something I review is disclosed at the top of that review, and I hold to a fixed set of rules on trading, commissioned work and corrections. Those rules are set out in full on the independence and disclosures page.