SOC 2 for Crypto and Web3

Ask a crypto exchange or a Web3 infrastructure provider why they need a SOC 2 report and the answer is almost always the same: an institutional counterparty, a banking partner, or an enterprise customer asked for it before they'd sign. In an industry that has spent the better part of a decade defending itself against accusations of being unregulated and opaque, an independent attestation of your security controls is one of the few credentials that actually moves a deal forward.

But SOC 2 was not written with crypto in mind. The framework assumes a fairly conventional SaaS company: a web app, a database, some cloud infrastructure, employees with laptops. Crypto and Web3 companies have all of that, plus a layer of risk the standard doesn't explicitly address: private key custody, smart contract logic, on-chain settlement, and infrastructure that often spans multiple blockchains and third-party custodians. Getting SOC 2 right in this sector means mapping a generic framework onto a genuinely unusual risk surface, and that's where most first-time readiness projects go sideways.

Why crypto and Web3 companies get asked for SOC 2 specifically

a SOC 2 report has become the default trust signal that institutional finance and enterprise software buyers ask for, and crypto companies increasingly sell into both. A custodian courting a bank as a client, an exchange integrating with a payment processor, or a Web3 infrastructure vendor selling API access to a traditional fintech will all run into the same requirement: show us your SOC 2 report before we send you production traffic or customer funds.

It's also a response to the sector's own history. High-profile custody failures and exchange collapses have made every serious counterparty in this space allergic to taking security claims on faith. A SOC 2 Type II report, produced by an independent CPA firm rather than self-attested, is the closest thing to proof that a crypto company's controls actually work day to day, not just on paper.

The sector-specific stakes

Technically, SOC 2 is an attestation, not a certification, but almost everyone in the buying process searches for and refers to it as SOC 2 certification, so we'll use that language too. It's built around five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is the only one that's mandatory; the other four are added based on what your business actually does and what your customers care about.

For crypto and Web3 companies, that scoping decision carries more weight than it does for a typical SaaS business:

• Key management is the whole ballgame. Where private keys live, who can sign transactions, how multi-signature or MPC schemes are configured, and what happens during key rotation or personnel offboarding are the controls institutional buyers scrutinize hardest. A SOC 2 report that glosses over key custody isn't going to satisfy a bank's diligence team.
• Processing Integrity often matters more than it does elsewhere. If your platform executes trades, settles transactions, or triggers smart contract calls, buyers want assurance that processing is complete, accurate, timely, and authorized. That's a criterion many SaaS companies skip; crypto companies frequently shouldn't.
• Smart contracts sit outside SOC 2's normal vocabulary. The framework wasn't written with immutable, publicly deployed code in mind. A credible readiness process has to translate your change-management and code-review controls into language that covers contract deployment, upgrade mechanisms, and audit history, not just your CI/CD pipeline for the web app.
• Third-party and sub-custodian risk compounds quickly. Most crypto companies rely on custodians, node providers, bridges, or oracle networks they don't control. Vendor management controls need to actually reflect that dependency chain, not just list your cloud provider.
• Availability has real teeth. Downtime during volatile market conditions isn't a minor SLA miss, it's a direct financial exposure for customers who can't exit a position. Buyers will ask how you monitor and respond to that.

Get the scoping wrong, either by treating a crypto platform like a generic SaaS app or by including criteria that don't reflect what you actually do, and you end up with a report that either fails to answer the questions institutional buyers actually have, or drags the audit out with evidence requests for controls you never needed in the first place.

How traztech scopes SOC 2 for crypto and Web3 companies

We run fixed-scope SOC 2 readiness engagements, and for crypto clients that starts with a plain conversation about what you actually custody, process, and expose to counterparties, before we touch a single control. That determines which Trust Services Criteria belong in scope, how key management and signing workflows get documented as controls, and where smart contract governance needs to show up in the evidence set. From there we build out the policies, control descriptions, and evidence collection process your environment is actually missing, in a fixed timeline and fixed price, so you're not paying by the hour while a scope creeps. You can see how that fits alongside our broader work on the compliance readiness page.

One thing we're clear about upfront: traztech prepares you for the audit, we don't perform it. SOC 2 reports have to be issued by an independent, licensed CPA firm, that's a requirement of the standard itself, and any vendor telling you otherwise is either confused or cutting a corner you don't want cut. We coordinate with an independent CPA auditor on your behalf, hand off a clean, organized evidence package, and stay involved through the audit so you're not fielding auditor questions alone. The result is a report your counterparties can actually rely on, produced by the right party, on a timeline you set going in.

Getting started

If an institutional partner, exchange integration, or enterprise customer has put a SOC 2 report on your roadmap, the earlier you scope it correctly the less rework you'll do later. Ready to talk about where your platform actually stands and what a fixed-scope readiness engagement would look like for your architecture? Contact traztech and we'll walk through it.

Drawing the system boundary when half the system is public

Every SOC 2 report opens with a system description written by management, and for a crypto company that document is harder to write than the controls themselves. A conventional SaaS description covers an application, a database, a cloud account, and the people who operate them. Yours has to answer a question the template does not ask: where does your system end and the chain begin.

The workable boundary in most engagements runs like this. In scope: your application and APIs, the signing infrastructure and the policy engine that governs it, the key material you control, your nodes or your relationships with node providers, the internal tooling that initiates or approves transactions, and the people with access to any of it. Out of scope, and stated as such: consensus behavior of the underlying networks, the correctness of protocols you do not operate, and the actions of counterparties once assets have settled. Between those two lists sits the awkward middle: bridges, oracles, and sub-custodians you depend on but do not control.

Auditors handle that middle with the carve-out or inclusive method, and the choice has consequences. Carve out a sub-custodian and you must describe the complementary subservice organization controls you rely on them to perform, which means your report tells the reader in plain language that a material part of custody security is somebody else's responsibility. Institutional diligence teams read that section carefully. If the carved-out party has its own SOC 2 or ISO 27001 report, you should be collecting it, reviewing it, and documenting that review as a vendor management control, because the first follow-up question from a bank is always whether you actually read the report you are relying on.

The same applies in the other direction. Complementary user entity controls are the things your customers must do for your controls to work, and crypto platforms tend to have real ones: withdrawal allowlists the customer configures, API key scoping, multi-user approval thresholds set at the customer's discretion. Write them explicitly. A vague CUEC section reads as an attempt to shift blame; a specific one reads as a platform that understands its own shared responsibility model.

Evidence for key management that an auditor can actually test

Key custody is the control set your buyers care most about and the one that produces the most confusion during fieldwork, because a CPA firm's standard evidence request list has no line item for a key ceremony. The gap is not that the controls are missing. It is that they exist as tribal practice and never as testable artifacts.

What holds up: a written key management policy that names the generation procedure, the storage medium, the quorum required to sign, the personnel roles involved, and the rotation and revocation triggers. A ceremony script that was followed, with a signed attendance record, a video or witness attestation, serial numbers of the hardware used, and the resulting public identifiers recorded. A documented threshold configuration for your multi-signature or MPC setup, with evidence of the configuration as deployed rather than as designed. Access reviews that cover signer roles specifically, not just the identity provider. Offboarding records showing that a departing engineer's signing capability was revoked and the remaining quorum re-established, with a date.

The offboarding one is where reports pick up exceptions. A company terminates an employee, disables their email and VPN the same day, and takes three weeks to rotate a shard or update a signer set because that requires coordinating three people and a hardware device. The auditor tests ten terminations, finds two where the signing access lag exceeded the policy commitment, and now there is an exception in a report you will hand to a bank. The fix is not heroics during the audit window. It is writing a policy commitment you can meet, then meeting it. If quorum reconstitution honestly takes five business days, say five business days.

What SOC 2 does not answer, and what your counterparty may actually be asking for

A meaningful share of the SOC 2 requests crypto companies receive are asking for something else wearing that name. Sort this out before you scope anything.

Proof of reserves is not SOC 2. If the counterparty wants assurance that customer assets exist and are not rehypothecated, that is an agreed-upon procedures engagement or a reserves attestation, and it is a different report with a different scope. A SOC 2 Type II can cover the controls around reconciliation and segregation of customer assets, which is adjacent and useful, but it does not assert a balance at a point in time.

A smart contract audit is not SOC 2. Your change management controls can show that contract code went through review and testing before deployment. They say nothing about whether the code is free of reentrancy bugs. Buyers who want the second thing need a specialist code audit, and pointing them at a SOC 2 report will cost you credibility.

AML and KYC obligations are not SOC 2. Registration status, transaction monitoring, and sanctions screening live in a regulatory conversation. Controls over the systems supporting those programs can be in scope; the adequacy of the program under a given regime is not what a service auditor opines on.

Penetration testing is not SOC 2, though SOC 2 will ask whether you do it. Most trust criteria mappings expect periodic testing by a qualified party, and the auditor wants the report and the remediation record. If the counterparty's real question is whether your platform can be broken into, they want the test, not the attestation. We wrote about what that looks like for this sector in penetration testing for crypto, and testing starts from $1,000 as a fixed-scope engagement.

Timing, observation windows, and the gap nobody plans for

Type II reports cover a period, and the period is the thing that kills deadlines. A three-month initial window is common and acceptable for a first report, but the window cannot start until the controls are actually operating, and controls that exist only as documents do not count. Teams routinely lose six weeks because access reviews, vulnerability scanning cadence, or change approval records only began producing evidence halfway through the intended period, which forces the window later and the report later still.

Two practical consequences. First, if a counterparty has given you a date, work backward: report issuance, fieldwork, observation window, control operation start, readiness build. That arithmetic usually shows you need to begin now rather than next quarter. Second, once you have a report, plan the next one immediately, because the period gap between report end and the next window start is exactly the thing enterprise vendor risk teams flag. A bridge letter from management covering the gap keeps deals moving, and it needs to be ready before it is requested, not written the afternoon someone asks.

What drives the cost up in this sector

The readiness fee moves on a small number of factors. Whether you self-custody or rely entirely on a qualified custodian, since self-custody pulls key management, ceremony evidence, and hardware inventory into scope. How many chains and how many distinct signing architectures you operate, because each one is its own control narrative. Whether Processing Integrity is in scope, which brings transaction completeness and accuracy testing and is a real addition to evidence volume. How many sub-custodians, node providers, and bridges are in the dependency chain. Whether you have any prior security program at all, or are starting from a shared spreadsheet and good intentions.

The audit fee moves on different factors: the number of criteria in scope, the number of controls the auditor must test, the number of locations and legal entities, and how clean your evidence package is when you hand it over. That last one is the only lever you fully control, and it is worth pulling. Audit firms price partly on uncertainty, so a readiness position they can inspect before quoting tends to come back cheaper than a company that shows up with a shared drive and a promise, and it is worth asking each firm you approach how a documented control set changes their number. Our fixed-scope readiness track is published as SOC 2 in 75 Days from $3,000 for the gap analysis so you can do that arithmetic before you call anyone.

When you should not buy SOC 2 readiness from us

Some of the crypto companies that call us should spend the money elsewhere, and we would rather say that early than take an engagement that does not help.

When the counterparty has not actually asked. Building a report on speculation, before a named partner has put it in writing, is a real cost against a hypothetical benefit. Ask the counterparty what document they need and when. The answer is sometimes a completed questionnaire and a pentest report, which you can produce far faster.

When the deal timeline is shorter than the observation window. If the partner needs assurance in six weeks, no honest readiness engagement gets you a Type II. Negotiate a Type I plus a committed Type II date, or supply a security questionnaire response, current test results, and a remediation plan. We would rather help you assemble that package than sell you a project that lands after the deal is decided.

When ISO 27001 is the better fit. If your counterparties are European or your institutional partners are outside North America, they may prefer or require ISO 27001, and doing SOC 2 first is a detour. Check before you scope.

When you are pre-product or pre-revenue. A company with four engineers and no production custody does not need an attestation. It needs sound key handling from the beginning, which is mostly free if you set it up before there is anything to migrate. Write the policy, use hardware, set a quorum, log approvals, and revisit in a year.

When you have in-house capability and only need review. Teams with a security lead who has been through this before often need a gap review and an auditor introduction rather than a full build. That is a smaller retainer and we will scope it that way.

If the report comes back with exceptions

Exceptions are not automatically fatal, and treating them as a catastrophe usually makes the sales conversation worse rather than better. A Type II report with two testing exceptions, each accompanied by a management response describing the cause, the remediation, and the date it was completed, reads as a company that is honest and operating. A report with no exceptions from a platform that shipped forty releases in the period reads, to an experienced diligence analyst, as a report with narrow testing.

What to do: get the exception language precise about the population and the number of instances, write a management response that says what changed rather than what you intend, and be ready to speak to it directly in the counterparty call. If the exception touches key custody, expect it to be the entire subject of that call, so bring the evidence that the fix is operating now. If the same exception recurs in the next period, that is the genuine credibility problem, so close it properly the first time rather than papering over it in the response.