SOC Report Reliance for a Crypto Custodian: Helpful, Not Sufficient

When a company's crypto sits with a third-party custodian, the assertions that matter — does the entity have a right to those assets, do they exist, are they segregated — depend on controls the company itself does not operate. The instinct is to lean on the custodian's SOC report and treat the audit problem as solved. A SOC 1 Type 2 report genuinely helps: it covers controls relevant to financial reporting, tested over a period. But SOC reports written for traditional service organizations often address the wrong things for a digital-asset custodian, leaving the controls that matter most — private-key generation and storage, and whether client assets are commingled — outside scope or inadequately tested. This guide is about that specific reliance decision: which SOC report is relevant, why a clean opinion does not close the audit, and what has to sit alongside it. It is the custodian-side companion to existence and ownership and blockchain as audit evidence.

The reliance decision in brief

• A SOC report describes a service organization's controls plus an independent assessment. For a custodian an audit relies on, the SOC 1 Type 2 (controls relevant to financial reporting, tested over a period) is generally the relevant one; SOC 2 covers security and availability.
• It cannot be relied on alone: SOC reports for digital-asset custodians often inadequately address crypto-specific controls (key generation and storage, commingling), so the auditor gathers more.
• A clean SOC opinion does not mean key-custody and commingling are covered — read the scope and exceptions carefully.
• Pair it with on-chain corroboration and the entity's own controls, and identify the complementary user-entity controls.
• The SOC report improves audit efficiency; it is not a substitute for the auditor's evidence and judgement. This is not audit advice.

What a SOC report is

A Service Organization Control report describes a service organization's controls and an independent assessment of them. For an audit relying on a crypto custodian, the SOC 1 Type 2 — controls relevant to user entities' internal control over financial reporting, tested over a period — is generally the relevant one; SOC 2 focuses on security, availability, and similar trust criteria. Which report, and how it is used, is an auditor judgement under the applicable standards.

Reliance is not automatic

Generally not on its own. SOC reports for digital-asset custodians often inadequately address crypto-specific controls — private-key generation and storage, commingling of client assets — so the auditor typically gathers additional information about the custodian's financial-reporting controls and may perform further procedures. The SOC report is one input that can improve audit efficiency; it is not a substitute for the overall evidence and judgement.

Why crypto-specific controls are the gap

The risks that matter most for digital assets — control of private keys, segregation of client assets, the ability to move or lose assets irreversibly — are not always in scope, or adequately tested, in a general SOC report designed for traditional service organizations. A clean SOC opinion does not automatically cover key-custody and commingling, so reading the report's scope and exceptions carefully is essential, and the assessment is the auditor's (consistent with proof-of-reserves vs audit).

What to give the auditor

Typically the custodian's current SOC 1 Type 2 (and any complementary user-entity controls it specifies), plus independent corroboration (on-chain confirmation of held balances) and evidence of the entity's own controls. Providing the SOC report alone and expecting it to close the audit is the misconception. The entity supplies the evidence; the sufficiency conclusion is the auditor's.

Complementary user-entity controls

SOC 1 reports commonly assume the user entity itself operates certain complementary controls for the service organization's controls to be effective; if the entity does not operate them, reliance is undermined. Identifying and confirming them is part of using a SOC report properly — an auditor-confirmed point, not an assumption.

Practical guidance

1. Get the SOC 1 Type 2 (financial-reporting controls) — not just SOC 2.
2. Don't rely on it alone — crypto-specific controls are often the gap.
3. Read scope and exceptions — a clean opinion ≠ key-custody covered.
4. Add on-chain corroboration + the entity's own controls.
5. Identify and operate complementary user-entity controls.
6. Reliance is the auditor's judgement — standard-specific; not audit advice.

How vendor tools support custodian reliance

Cryptio and Bitwave provide on-chain confirmation of custodied balances that corroborates alongside a SOC report. The tool supplies the corroboration; whether SOC reliance plus corroboration is sufficient is the auditor's judgement.

Where Wag3s fits

Wag3s Ledger reconciles custodied balances to on-chain data with an audit trail, providing the independent corroboration that sits alongside the custodian's SOC 1 Type 2. It supplies one leg of the evidence and helps the entity evidence its own complementary controls; it does not assess the custodian's controls or decide reliance — that assessment and the sufficiency conclusion stay the auditor's. See the Ledger product page.

Further reading

• Proof of Reserves vs Audit
• Blockchain as Audit Evidence
• Auditing Crypto Existence & Ownership
• Auditing Crypto Completeness
• MiCA Crypto Custody for Treasury
• Crypto Audit Readiness

Reading a SOC 1 Type 2 report for a crypto custodian: what to look for

Not all SOC 1 reports are equal in their usefulness for a digital-asset audit. When reviewing a custodian's SOC 1 Type 2, examine these specific elements before drawing any conclusions about reliance.

The scope description. The report's scope section should describe which systems, processes, and locations are covered. For a crypto custodian the critical check is whether key management — specifically key generation, storage, and signing — is within scope. If the scope statement refers only to custody administration systems and client-facing portals without addressing key infrastructure, the report does not address the most significant digital-asset risk.

The control objectives and controls. Look at whether any control explicitly addresses: (a) segregation of client assets from the custodian's own — and whether "segregation" extends to private keys, not only to ledger entries; (b) the procedures for detecting and reporting commingling; and (c) the independent verification of private-key existence and non-replication. A control that reads "client assets are recorded in separate ledger accounts" is a traditional financial-services control; it does not address whether the keys underlying those records are properly separated.

The exceptions noted in the testing. A clean opinion at the report level can mask exceptions noted at the individual control level. If the testing for any key-custody or commingling control notes a deviation, that deviation is relevant even if the overall opinion is unqualified.

The complementary user-entity controls (CUECs). The SOC 1 report will list controls the user entity is assumed to operate for the service organization's controls to be effective. For a crypto custodian these often include: maintaining accurate records of which wallets the entity controls, independently verifying balances against on-chain data, and controlling access credentials to the custody platform. If the entity does not actually operate these controls, reliance on the SOC report is built on a false premise.

The period covered. A SOC 1 Type 2 report covers a testing period — typically six or twelve months. If the report covers a period that ended nine months before the audit, a bridge letter or additional procedures for the gap period are needed. The crypto custody environment changes rapidly, and a stale SOC report has obvious limitations.

This reading process is the auditor's responsibility and judgement; the entity's role is to obtain and supply the report, confirm its own CUECs, and provide independent on-chain corroboration.

Sources

• AICPA & CIMA — SOC 1 — SOC for Service Organizations: ICFR: a SOC 1 examination covers controls at a service organization relevant to user entities' internal control over financial reporting, and a Type 2 report tests their operating effectiveness over a period (issued under SSAE 18); this is the report a user auditor uses, as distinct from SOC 2.
• AICPA & CIMA — Accounting for and Auditing of Digital Assets practice aid (non-authoritative): the gap that SOC reports for digital-asset custodians often inadequately address crypto-specific controls such as private-key custody and commingling, so a SOC report alone is generally not relied upon.
• That a clean SOC opinion does not automatically cover key-custody or commingling, that complementary user-entity controls must be operated by the entity, and that the reliance and sufficiency conclusions remain the auditor's under the standards for using a service organization, is the framing this article applies — not audit advice.