A commercial kitchen inspection does not hand you a list of approved fridges. It asks whether food is held at a safe temperature, whether you can show that it was, and whether anybody noticed on the night it was not. A sushi counter, a wood-fired pizza place and an industrial bakery pass the same inspection with almost nothing in common in the room. The criteria are about outcomes. The equipment is yours.
That is the thing about SOC 2 for Web3 that protocol teams are usually told last and need first. The objection we hear on nearly every enterprise deal is that SOC 2 was written for SaaS, and that a stack built on multisigs and onchain custody does not fit it. The stack is right. The conclusion is wrong, and the reason is in the criteria themselves.
Quick answer
SOC 2 is not a certificate and not a control checklist. It is an examination performed by a licensed CPA firm against five outcome-based criteria, covering a system you describe yourself. A multisig, a signer policy and a third-party custodian are not exceptions to SOC 2. They are the controls that answer it.
SOC 2 is not a certificate, and that changes the question
Start here, because almost every wrong assumption downstream comes from getting this bit wrong.
SOC reports were established in 2011 and are examinations performed by CPAs under the AICPA’s Statements on Standards for Attestation Engagements, giving a company’s customers independent assurance that its controls are suitably designed and operating effectively. That description comes from the Journal of Accountancy’s February 2026 feature on SOC quality, and the same article contains a parenthesis worth more than most compliance blog posts: compliance is “a term never used in SOC 2 examinations”.
There is no SOC 2 certificate, no certifying body and no badge you are awarded. There is a report, written by an accountancy firm, about your controls, and it is restricted to specified parties who understand your system well enough to read it. Fireblocks, one of the custody platforms Web3 teams most often sit behind, completed a SOC 2 Type II examination performed by Ernst and Young and its own announcement says customers and prospects can receive a copy of the report on request. That is how these documents travel. Nobody publishes one.
| What people assume SOC 2 is | What it is |
|---|---|
| A certification you pass or fail | An examination, with an opinion attached to it |
| A fixed list of required controls | Five categories of outcome-based criteria |
| Awarded by a standards body | Issued by a licensed CPA firm you engage and pay |
| A public badge for the website | A restricted report, shared with customers on request |
| Written for SaaS, so irrelevant to protocols | Written for any company whose customers depend on its systems |
That last row is the one this article exists to argue, so here is the argument.
If you want the long version before you finish reading, the Fidesium SOC 2 field guide for Web3 teams covers the mapping in more depth and comes as a PDF.
The criteria are outcome-based, which is why your stack is not the problem
The criteria in question are the Trust Services Criteria, set by the AICPA’s Assurance Services Executive Committee. The current set is the 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy, with revised points of focus published in 2022. Those five words in the title are the five categories, and an examination is scoped to the categories that are relevant to what you sell rather than to all of them by default.
The AICPA describes the criteria in one sentence, and it is the sentence to send to whoever on your team believes SOC 2 cannot accommodate a multisig:
“The TSC are outcome-based criteria designed to be used when evaluating whether a system and related controls are effective to provide reasonable assurance of achieving the objectives that management has established for the system.”
Read that slowly. Outcome-based. Objectives that management has established. The criteria describe what has to be true. You decide, and then write down, what your system is and how it achieves that. There is no clause anywhere that says the access control has to be an identity provider rather than a threshold signature scheme.
The second half of the mechanism is the description. Alongside the criteria sit the 2018 SOC 2 description criteria, which the AICPA calls a set of benchmarks used when preparing and evaluating the description of the company’s system. You write that description. You draw the boundary around what is in scope, name the components, name the things you depend on but do not run, and the examination then tests what you said against what is actually happening.
For a protocol team, that boundary is the single most consequential decision in the whole exercise, and it is one nobody makes for you.
What the criteria actually ask of a multisig
Here is the translation, one row at a time. The left column is the substance of what a SOC 2 examination is testing. The middle column is the answer a SaaS company gives. The right column is the answer a protocol gives, and it is a perfectly good one.
| What the criteria ask | The usual SaaS answer | The answer in a protocol stack |
|---|---|---|
| Who can authorise a change that moves value, and how is that restricted? | Admin roles in a production console, granted through single sign-on | The signer set on the multisig and its threshold, who holds each key, and on what device |
| How is access removed when somebody leaves? | Deprovision the account, revoke the tokens | Rotate the signer set on chain, retire the key, and keep the transaction that did it |
| How do you know a change was reviewed before it shipped? | Pull request approvals and a deployment log | The same pull request record, plus the proposal, the signatures collected and the transaction hash |
| How would you notice something abnormal? | Application alerting and log review | Onchain monitoring tuned to the protocol’s own behaviour, alongside the usual infrastructure alerting |
| What about the things you depend on but do not run? | A subprocessor list and a vendor review | The same list, with the custodian, the RPC provider, the oracle and the bridge on it |
| How is the most sensitive material protected? | Encryption, key management, least privilege | The same, applied to signing material, which is the highest-value asset in the company |
| How do you know the system does what you claim? | Tests, reconciliation, error handling | The audit report, the deployed bytecode, and the distance between the two |
Nothing in the right-hand column is a workaround. In several rows it is stronger evidence than the SaaS equivalent, because a signature and a transaction hash are a permanent public record and a console log is not.
The friction is real, and it is practical rather than conceptual. Your controls live in places an examiner has not looked before, and somebody has to write them down in a form that survives fieldwork. That is the work, and it stops well short of rewriting your architecture.
Two rows deserve a note. Access control is where most findings land, in every industry, and it is worth reading our engineers on why access control checks produce so many false positives before you assume a scanner has this covered. And the dependency row is where Web3 is genuinely harder than SaaS, because an oracle or a bridge is a dependency with a live economic surface, not a vendor with a status page.
The losses that make the news are already inside SOC 2’s scope
The strongest argument for taking SOC 2 seriously as a protocol team is not a procurement questionnaire. It is that the failures which have actually emptied wallets are, disproportionately, the failures these criteria are aimed at.
Bybit: the multisig worked and the contracts were sound
The Safe Ecosystem Foundation’s statement is unusually direct about what happened. The forensic review concluded that the attack “was achieved through a compromised Safe{Wallet} developer machine resulting in the proposal of a disguised malicious transaction”. And then, flagged “Important!” in the same statement: the review “did NOT indicate any vulnerabilities in the Safe smart contracts or source code of the frontend and services”.
The multisig worked. The contracts were sound. What failed was a developer endpoint, a set of credentials, and the gap between what a signer saw on screen and what they were actually signing. Every one of those is a control the criteria ask about, and none of them is Solidity.
The npm attack: the deception was in a dependency, not a contract
In September 2025 a compromised package pushed malware that hooked wallet APIs and swapped recipient addresses for look-alikes, chosen by string similarity so the user reviewing the address on screen saw something that looked correct. Our own write-up of how that wallet address swap worked has the mechanics. The financial damage was small, roughly $500. The lesson is not. A single compromised account pushed malicious code deep into a dependency tree, and the deception happened at the interface rather than in any contract.
That is vendor and dependency management, which is a SOC 2 question with a boring name and an expensive answer.
Ronin: a permission that outlived its purpose
If you want one incident that is entirely about the criteria in this article, it is this one. Sky Mavis’ own post-mortem explains that the attacker “managed to get control over five of the nine validator private keys” and that Sky Mavis’ own four “would not be enough to forge withdrawals”. The fifth signature came from a permission granted months earlier: “This traces back to November 2021 when Sky Mavis requested help from the Axie DAO to distribute free transactions due to an immense user load. The Axie DAO allowlisted Sky Mavis to sign various transactions on its behalf. This was discontinued in December 2021, but the allowlist access was not revoked.”
A threshold scheme is a good control. It was defeated by a stale authorisation nobody reviewed. The same document adds that the hack “occurred on March 23rd 2022, and was discovered on March 29th”, because “we didn’t have a proper tracking system for monitoring large outflows from the bridge”. A periodic access review and a monitored withdrawal threshold are both ordinary SOC 2 controls, and either one would have changed that week.
An audit reads your code. None of those three incidents was a code problem. If you want a second pair of eyes on the surface that is not the contract, that is what blockchain penetration testing and continuous security services are for, and monitoring output doubles as the evidence an examiner will ask for anyway.
Type 1, Type 2, and the part the observation window really costs
A Type 1 report speaks to the design of your controls. A Type 2 speaks to how they operated across a period, which is why it is the one enterprise buyers ask for and the one that takes real time. Fireblocks’ own account of its Type II examination gives you the shape of that: Ernst and Young inspected its processes over six months.
That period is the reason a SOC 2 programme cannot be started the week the questionnaire arrives, and it is also the reason the exercise is genuinely useful rather than ceremonial. You do not pass by having good policies in March. You pass by operating them from March to September and being able to show it.
This is the same argument we have made about smart contract audits for years, in a different vocabulary. A report describes a moment; security only holds if it is a process, and a point-in-time audit starts losing accuracy the day it ships. A Type 2 examination is the accountancy profession arriving at the same conclusion, which is that operating a control for six months is worth more than designing one for a week.
The practical consequence: start collecting evidence before you start the window, not during it.
| Start now | Why it costs more later |
|---|---|
| A written signer policy, with the threshold and who holds what | Reconstructing who held a key eight months ago is guesswork, and guesswork does not pass fieldwork |
| An access review you actually run, on a schedule | This is the control that catches a permission which outlived its purpose, which is exactly what happened at Ronin above |
| Onchain monitoring with alerts that go somewhere | An alert with no documented escalation path is not a control, it is a dashboard |
| A dependency and subprocessor list that includes oracles, RPC providers, bridges and custodians | These get added under deadline pressure and then never reviewed |
| Change records that tie a pull request to the transaction that deployed it | Both halves exist already in most teams. Nobody has joined them up |
The order to do this in
The sequence is the same for a protocol as for anyone else, and the AICPA’s overview of SOC engagements is a fair explanation of why any of it exists: your customers are carrying risk by depending on you, and they want something better than your word for it.
- Scope. Decide which trust services categories are relevant and what is inside the system boundary. Get this wrong and everything after it is either theatre or a rewrite.
- Design. Write controls that describe how your team actually operates, not how a template says a SaaS company operates. A control nobody follows is worse than no control, because now it is a documented failure.
- Operate. Run them through the observation window and collect the evidence continuously rather than assembling screenshots the week before fieldwork.
- Attest. The CPA firm does its fieldwork, and somebody who speaks both languages sits between your engineers and the examiner.
Where a security firm fits, and where it does not
Being straight about this is more useful than a pitch.
The examination is performed, and the report issued, by a licensed CPA firm. Fidesium is not a CPA firm, does not certify anybody, and does not issue SOC 2 reports. Any Web3 security company telling you otherwise is describing something that does not exist.
What a security firm is genuinely good for is everything on either side of that: readiness against the criteria scoped to your actual protocol surface, control design that fits multisigs and custody instead of fighting them, evidence pipelines wired into the tools you already use, monitoring that produces the operating evidence rather than a screenshot, and translation during fieldwork so your engineers are not explaining what a threshold signature is at billing rates.
Choose the CPA firm carefully, and not on price. The Journal of Accountancy piece cited above exists because SOC 2 tooling vendors now dominate the search results for this term and market on speed, and CPAs who perform these examinations are publicly worried about what that does to quality. Their advice to buyers is worth repeating: vet the firm’s size, capacity and references, ask about its peer review results, ask about scope and sampling procedures, and treat an offer that looks unrealistically fast or cheap as the warning it is. As one of the practitioners quoted puts it, if a SOC 2 report gets rejected by a business partner, “it’s not worth the paper it’s on”.
That is also our position on the code side, which is why our audit reports are published rather than summarised. Manual smart contract audits start at $5,000, continuous scanning starts at $399 a month, and the published record behind both is $250M+ secured across 110+ contracts audited. None of that makes a protocol secure, and nobody honest will tell you it does. What it does is give you evidence, which is the currency both an attacker and an auditor deal in.
If SOC 2 is on your roadmap because a customer put it there, start with the SOC 2 field guide for Web3 teams and then talk to us about scoping.
Frequently asked questions
Does SOC 2 apply to a Web3 company with multisigs and onchain custody?
Yes. The Trust Services Criteria are outcome-based rather than a prescribed control list, and the AICPA defines them as criteria for evaluating whether a system and its controls achieve the objectives management has established for that system. A multisig, a signer policy and a third-party custodian are controls that answer those criteria. They are not exceptions to them.
Is SOC 2 a certification?
No. There is no SOC 2 certificate and no certifying body. A SOC 2 report is an attestation examination performed by a licensed CPA firm under the AICPA’s attestation standards, and the resulting report is restricted to specified parties rather than published. The Journal of Accountancy notes that compliance is a term never used in SOC 2 examinations at all.
Who issues a SOC 2 report?
A licensed CPA firm that you engage. Security consultancies, compliance tooling vendors and audit firms can help you prepare, design controls and collect evidence, but they cannot issue the report or attest to your controls. When Fireblocks completed its SOC 2 Type II examination, the examination was performed by Ernst and Young as an independent audit firm.
Which Trust Services Criteria does a protocol need?
The 2017 Trust Services Criteria cover five categories: security, availability, processing integrity, confidentiality and privacy. An examination is scoped to the categories relevant to what you actually provide to customers, decided during scoping and stated in your system description, rather than applied to all five by default.
How does a multisig satisfy a SOC 2 access control criterion?
By being written down and evidenced like any other access control. The signer set and threshold define who can authorise a change that moves value, key custody defines where that authority physically lives, signer rotation is your deprovisioning process, and the on-chain transaction record is your evidence. A signature and a transaction hash are a stronger audit trail than a console log, not a weaker one.
What is the difference between a SOC 2 Type 1 and a Type 2 report?
A Type 1 addresses how controls are designed. A Type 2 addresses how they operated across a period of time, which is why enterprise buyers ask for it and why it cannot be produced quickly. Fireblocks’ own account of its Type II examination describes Ernst and Young inspecting its processes over six months.
Does a smart contract audit count as SOC 2 evidence?
It can support several criteria, but it does not replace them. An audit is evidence about the code, and most of what a SOC 2 examination tests sits around the code: access, change management, monitoring, vendor dependencies and incident response. The Bybit attack in February 2025 is the clearest illustration, because the forensic review found no vulnerability in the Safe smart contracts and the compromise came through a developer machine instead.
What security evidence do enterprise customers ask a Web3 vendor for?
Usually a SOC 2 Type 2 report if one exists, and in its absence a stack of substitutes: a current smart contract audit report, penetration test results, a written signer and key management policy, evidence of access reviews, a subprocessor list covering custodians, oracles and RPC providers, an incident response plan, and proof that monitoring exists and that alerts reach a person.
