SOC 2 for a Crypto Wallet or Lending Platform: What Is Different

Direct answer: The framework is the same, the scope is not. If you custody keys or assets, the audit boundary has to include key management, and auditors will press on segregation of duties, withdrawal approval and insider threat far harder than they would for ordinary SaaS. Most crypto businesses also need Availability and Confidentiality alongside Security, where a normal startup needs Security only.

Why institutional counterparties ask

A bank, an exchange, a fund or a corporate treasury cannot onboard you without a third-party assurance report. SOC 2 Type II is the one they recognise. For lending platforms it usually arrives with the first institutional lender; for wallets it arrives with the first enterprise or custody partner.

What changes for a wallet

Key generation, storage and recovery move to the centre of the audit. Expect questions on where private keys are generated, whether anyone can extract them, how hardware security modules or secure enclaves are used, what the recovery flow permits, and who could reconstruct a key by colluding with whom.

The last one matters most. Segregation of duties is a normal SOC 2 control that becomes existential when the thing being separated is control of customer assets. If one engineer can move funds alone, that will be a finding regardless of how strong the cryptography is.

What changes for a lending platform

Availability moves from optional to expected, because liquidation logic that stops running has direct financial consequences for customers. Auditors will look at monitoring, incident response and capacity in a way they would not for a marketing tool.

Confidentiality usually comes in too, given position and collateral data. And the interaction between your controls and any oracle or price feed you depend on becomes part of the conversation, because a dependency that fails is your availability problem.

Which criteria to pick

Security is mandatory in every SOC 2. For a wallet, add Confidentiality and consider Availability. For a lending platform, add Availability and Confidentiality. Processing Integrity comes up occasionally where you are executing transactions on a customer's behalf and someone wants assurance the execution is complete and accurate.

Each additional criterion adds controls, evidence and audit hours, so pick from what counterparties actually ask for rather than from what sounds thorough.

The boundary decision

Custody infrastructure has to be in scope. Beyond that the useful question is whether your on-chain components are in the boundary at all. Usually the contracts themselves sit outside it, with the systems that deploy, monitor and interact with them inside, and a penetration test covering the surrounding infrastructure referenced as evidence.

Getting this wrong in either direction is expensive, which is why it is the first thing we settle. See SOC 2 for crypto companies, what a web3 penetration test covers, and SOC 2 in 75 Days for what the programme costs.

How the custody architecture changes the control design

Auditors do not test cryptography. They test whether a single person or a single compromise can move customer assets. The architecture you chose determines what that test looks like, and three broad shapes come up.

Hardware security modules with a signing service. Keys are generated inside the module and never leave it. The control questions move to who can invoke a signing operation, what authorises the invocation, and who administers the module itself. That last one catches people out. If two platform engineers hold administrative credentials on the HSM and can also deploy the signing service, they can in principle change what gets signed, and the fact that the key never left the hardware is beside the point. Expect the auditor to ask for the administrator list, the quorum policy, and evidence that the quorum was actually enforced rather than configured and then bypassed for an incident.

Multi-party computation. Shares are distributed across parties or environments and no complete key exists anywhere. The audit follows the shares. Where does each one live, who administers each environment, and can the same person or the same cloud account reach a threshold number of them. An MPC setup where all three shares sit in the same cloud tenancy under one IAM boundary is a single point of compromise wearing a distributed costume, and a competent auditor will say so.

On-chain multisignature. The policy is enforced by the contract, which is the cleanest story to tell and the easiest to undermine operationally. The questions are who holds each signer key, on what device, whether any two signers report to the same person, and what the recovery path is when a signer leaves the company. The recovery path is usually the weak point, because it is designed for an emergency and therefore designed to be fast.

Whichever shape you run, the artefact the auditor wants is a written key management policy that matches what actually exists, plus records showing the policy was followed for real events during the observation period. Not the design document. The events.

The key ceremony and how to evidence it

Key generation is a one-off event, usually performed before the observation period, and it is the hardest thing in a crypto SOC 2 to evidence after the fact. If you generated your production keys eighteen months ago in a room with two engineers and no script, there is no honest way to reconstruct proof of it now.

What good looks like: a written ceremony script agreed in advance, named participants with defined roles, a witness who is not one of the operators, a signed attestation from each participant afterwards, sealed tamper-evident bags with serial numbers recorded for any hardware, and a video recording retained under access control. For rotations and for any new key generated during the period, run it that way and the control tests itself.

For keys that predate the programme, the workable position is a documented reconstruction: what was done, by whom, what evidence survives, and a management assertion acknowledging the limitation, paired with a forward-looking ceremony procedure. Auditors accept that far more readily than a retrospectively tidy account that does not survive questioning. Trying to present a reconstruction as contemporaneous evidence is how a manageable scope note becomes a credibility problem across the whole engagement.

Withdrawal approval, in the detail auditors actually test

Everyone writes a policy saying withdrawals above a threshold require dual approval. The testing is where it comes apart. The auditor takes a population of withdrawals across the period, samples them, and asks for the approval record on each one. Four failure patterns show up repeatedly.

The break-glass path. There is an emergency route for when the normal approval system is down, it was used four times during the year, and nobody documented why. Break-glass is not a finding. Undocumented break-glass is.

Approver independence. The two approvers are the CTO and an engineer who reports to the CTO. Formally two people, practically one decision. Whether this becomes an exception depends on the auditor and on how you have described the control, which is an argument to describe it accurately rather than aspirationally.

Threshold drift. The policy says dual approval above a given value. The system enforces a threshold that was raised during a busy period and never lowered. The document and the configuration disagree, and the configuration is what operated.

Automated withdrawals. Hot wallet top-ups, rebalancing, and liquidation flows execute without a human. That is fine and it is normal, but it needs to be described as a separate control with its own limits, monitoring and alerting, rather than quietly falling inside a policy that claims everything is dual-approved. If a script can move funds, the control is the script's constraints plus who can change the script, and change management on that repository becomes one of the most heavily tested areas in the audit.

Insider threat controls that go beyond the standard set

Ordinary SaaS gets a background check policy and an offboarding checklist. Custody businesses get asked harder questions, and it is worth deciding your answers before an institutional counterparty's reviewer asks.

Production access for engineers is the first one. Standing access to systems that can influence signing is difficult to defend. The pattern that holds up is time-bound elevation tied to a ticket, with the grant, the reason and the expiry all logged, and the logs reviewed. Second is separation between whoever writes deployment code and whoever approves a release to the signing environment. Third is monitoring that treats unusual internal behaviour as an event: an engineer pulling the full customer address table, an access grant outside working hours, a configuration change to approval thresholds. Fourth is what happens when someone with any signing role leaves, which should include key rotation or share reissuance rather than only revoking an account.

None of this is exotic. It is the same access management and change management the criteria already require, applied where the consequence is irreversible. That irreversibility is the whole reason the questions get harder.

Subservice organisations, carve-outs, and where your report stops

Most crypto businesses depend on somebody else for part of the thing being audited: a qualified custodian, an exchange or liquidity venue, a node infrastructure provider, a fiat payments partner, and the cloud underneath all of it. SOC 2 handles this through subservice organisations, and you choose between the carve-out method, where their controls are excluded and their own report is referenced, and the inclusive method, where their controls appear in yours.

Carve-out is almost always right, and it puts an obligation on you that companies routinely skip: you must have a control that monitors the subservice organisation, which in practice means obtaining and reading their SOC 2 report every year, recording what you concluded, and noting any complementary user entity controls they list. Those complementary controls are the things their report says you are responsible for. If your custody partner's report states that user entities are responsible for configuring withdrawal allowlists, and you have not, their clean report does not help you and your auditor will find the gap.

Your own report will carry complementary user entity controls in the other direction, aimed at your customers. Institutional counterparties read that section closely, because it tells them what work lands on them. Writing it clearly is worth doing well. A vague list reads as a company that has not thought about the shared responsibility boundary.

What SOC 2 does not cover, and what your counterparty may also want

A recurring source of wasted effort is assuming the report answers questions it was never designed to answer.

Proof of reserves is not SOC 2. A Type II tells a reader that your controls operated. It does not attest that assets exist or that liabilities are covered. If a counterparty wants reserve assurance, that is a separate engagement, typically an agreed-upon procedures report, and it needs a different conversation with a different scope.

Smart contract audits are not SOC 2 either. A contract review from a specialist firm speaks to code correctness. Your SOC 2 speaks to the organisation that deploys, monitors and operates around that code. Sophisticated counterparties ask for both and understand they are different documents. Presenting one as the other invites a question you do not want.

Regulatory registration is separate again. Money services business registration in Canada, state licensing in the United States, and whatever regime applies to your lending activity are legal obligations that a SOC 2 neither satisfies nor replaces. Where they interact usefully is evidence reuse: the transaction monitoring, record keeping and staff training you already run for regulatory reasons produce artefacts your auditor can test, so build them once and map them to both.

Penetration testing is a control input, not the report. The criteria expect you to test, and for a custody business the useful scope covers the signing service, the internal APIs around it, the approval workflow, and the operator interfaces, because that is where a realistic attacker goes. A test that only covers the public marketing site technically satisfies the box and tells your counterparty nothing. Ours start from $1,000 for narrow scopes and rise with complexity, and the scoping conversation is worth more than the price comparison.

Incidents, and how the report handles one

A security incident during the observation period does not invalidate the audit. What the auditor tests is whether your incident response control operated: was it detected, triaged, escalated, communicated and closed the way your own procedure says it should be. A well-handled exploit with a complete record often reads better to an institutional counterparty than a year with no incidents and no evidence that anyone was watching.

Where it goes badly is when the response happened entirely in a private channel, decisions were made by whoever was awake, and the write-up was produced weeks later from memory. Keep a timestamped log during the event, record who authorised each containment action, and hold a post-incident review with dated actions. For a custody business, add chain-specific scenarios to your tabletop exercises: a compromised signer, a stuck or reorganised transaction, a dependency outage on a price feed, and an exploit in a protocol you have exposure to but do not control.

Timeline and what drives the cost

The framework does not take longer for a crypto business. The remediation does, and three things drive it.

Segregation of duties is the largest. Companies that grew fast usually have two or three people who can do everything, because that is what shipping required. Splitting those responsibilities means hiring or restructuring, and it is a months-long change rather than a documentation exercise. Start it first, because everything else can be compressed and this cannot.

Additional criteria are the second. Availability and Confidentiality alongside Security add controls, evidence and audit hours, roughly in proportion. Pick from what counterparties have actually asked for in writing.

Evidence completeness is the third, and it is the one you control. Auditors price disorganisation into their quotes because a disorganised client takes longer to audit. On one engagement we saw an audit firm take $11,000 off its own number once the readiness position was documented and a preparation firm was confirmed. That is a single data point rather than a promise, but it points at where the money is.

Our own fixed-scope readiness work starts at a $3,000 gap analysis, and continuous compliance retainers pick up the quarterly cadence afterwards, which for a custody business is where most of the value sits.

When you should not do this yet

Some honest cases where a SOC 2 is the wrong purchase this quarter.

Nobody has asked in writing. If the requirement came from a conversation at a conference rather than from a counterparty's onboarding pack, wait. Institutional onboarding requirements are specific and they vary. Getting the actual checklist first often reveals that the blocker is a different document, or that a Type I plus a remediation plan unlocks the relationship while the Type II period runs.

Your segregation of duties is genuinely broken. If one engineer can move funds alone today, do not open an audit. That is a finding waiting to be written down and shared with every counterparty who reads the report. Fix the approval architecture first, run it for a quarter, then start the observation period. Six weeks of delay is cheaper than a qualified opinion you will be explaining for a year.

You are pre-product or pre-custody. Controls have to operate across a period. If the custody system you would be auditing is being rewritten this quarter, the report will describe something that no longer exists by the time anyone reads it.

You have a capable internal security lead and a simple stack. If someone in-house has run a SOC 2 before and your architecture is a single custody provider with a thin application on top, hire the auditor directly, use a free control library to structure the work, and spend the difference on penetration testing. We would rather say that than bill for supervising work that does not need supervising. Where we earn our fee is the messy version: bespoke key infrastructure, several subservice organisations, and a counterparty deadline that has already been agreed.

If you are in the messy version, tell us what your counterparty actually asked for and we will tell you what the work involves and what you can do without us.