Operational Due Diligence

Operational due diligence is the last mile of diligence. A package leaves Shanghai, makes it to a shipping facility in New York, and still has to get on a truck for the last mile to someone’s door. Other assurances (SOC 2, smart contract audits, prior CCSS work) get the risk assessment to the neighborhood. ODD is the truck.

Over the last two years, operational and custody failures account for approximately $4.6 billion in digital asset losses, compared to roughly $1.17 billion from smart-contract vulnerabilities and $594 million from fraud and market manipulation (sources: de.fi, web3isgoinggreat.com, DigOpp analysis as of May 2026). The industry assumes code vulnerabilities drive crypto loss. The data shows otherwise. Every operation that lost money was being audited under one framework or another at the time the loss happened; the failures were not in the audits’ scope.

What ODD actually covers

We map every assurance the target already has (SOC 2 reports, ISO 27001 certificates, smart contract audit outputs, prior CCSS work, penetration test results) and identify exactly what each one does and does not cover. The Standards Board for Alternative Investments (SBAI) operational due diligence framework for digital assets is the closest thing the industry has to a shared standard for this work; we apply it alongside ILPA’s general ODD principles as a baseline. Then we assess the digital-asset-specific operational surface that none of those frameworks were designed for:

• Custody and wallet architecture. Key and wallet generation, storage, ceremonies, recovery, and the full lifecycle of how assets are held. The biggest source of losses in this asset class. Deep CCSS-level work lives in our CCSS practice; ODD covers it at the assurance-coverage level.
• Policy and quorum design. Multi-actor signing thresholds, transaction whitelisting, rule engines, time-locks, amount-locks, and smart contract interaction policies. We test whether the documented quorum matches the quorum actually used.
• Smart contract and DeFi exposure. Protocol audit history, smart contract upgrade authority, admin key controls, and underlying DeFi integrations. Where the operation depends on counterparty smart contracts, we assess the governance and operational design around them, not the code itself.
• On-chain treasury operations. Reconciliation between on-chain state and internal books, stablecoin mint and burn workflows, tokenized asset movements, and prime broker wallet exposure. Where the on-chain reality and the documented procedure diverge, we name the gap.
• Governance controls. Administrator key controls, key-person risk, decision authority, succession planning, and incident history. HR practices and access controls relative to key material and operational authority.
• Financial health. Traditional audited financials (current ratio, debt-to-equity, ARR, burn rate, cash runway). Where applicable, on-chain Proof of Reserves and stablecoin reserve backing verification. Banking and credit relationships, including any account closures since inception.

Business continuity and disaster recovery are tested against actual digital asset failure modes (chain congestion, oracle halts, custodian outages), not just generic IT-DR scenarios. Incident response procedures are reviewed alongside the evidence they have been exercised.

What you get

A report structured around assurance coverage: what is covered, by what, to what standard, and a clean list of what is not. The report opens with a summary, an Impact-Likelihood Heat Map, and a risk table grading each finding from Informational to Critical. Subsequent sections cover the operational surface (custody technology, products and offerings, trading and execution where applicable), financial health, regulation and compliance (licenses, audits, policies, AML/KYC/KYB, investigations, cybersecurity), and insurance.

The report is written to be handed to an LP, a board, a regulator, or a counterparty. No filler.

Typical turnaround

Six to ten weeks from kickoff, depending on the scope and the responsiveness of the target. Updates run faster: two to four weeks once the baseline report exists.

Why ODD is often the entry point

Most new clients come to us for ODD. A service provider wants to publish a diligence report to its trust center. A fund’s board has started asking questions the internal team can’t answer. An LP has asked for evidence before committing. In every case, the question is the same: what does what we already have actually cover, and what’s left?

The pattern we see repeatedly: providers hand over a procedure manual that looks comprehensive on paper. When we ask for evidence to show those procedures were actually followed (signed ceremony runbooks, reviewed access logs, attested quorum, reconciliation outputs from specific dates), it often doesn’t exist. The standard expects evidence, not just documentation. ODD finds where that gap is before someone else does.

When to engage

• A counterparty, LP, or regulator has asked for operational diligence and the existing assurances do not answer the question.
• You are launching a new product (custody, stablecoin, tokenized fund, on-chain credit) and want the operational design pressure-tested before it goes live. For product-specific deep dives, see Stablecoin Operations, RWA Tokenization Audit, On-Chain Credit, and Cross-Chain Bridge Audit.
• You want to publish an ODD report as part of a trust center or buyer-enablement package.
• Your board or risk committee has started asking questions the team can’t answer with current documentation.
• You need to narrow the field of providers before selecting a target for ODD. See Vendor Research & Benchmarking for the field-level work that precedes a target-level engagement.