SOC 2 Compliance for Crypto and Web3 Firms: A Practical Guide

SOC 2 compliance has become the baseline expectation for any crypto or Web3 firm operating in the B2B space. Institutional clients, exchanges, and enterprise partners want documented evidence that the firms they work with manage data securely. A SOC 2 report provides that evidence in a standardised, independently verified format that sophisticated buyers understand and trust.

Yet most crypto firms approach SOC 2 from the wrong direction. They either treat it as a checkbox exercise, commissioning a report without building the underlying controls, or they delay indefinitely because the process feels overwhelming. Neither approach serves the business. This guide cuts through the complexity and provides a practical, Web3-specific implementation path for CISOs, security directors, and founders who need to get this done.

What Is SOC 2

SOC 2, which stands for Service Organisation Control 2, is an audit framework developed by the American Institute of Certified Public Accountants (AICPA). It is designed to assess whether a service organisation's controls related to security, availability, processing integrity, confidentiality, and privacy meet the AICPA's Trust Services Criteria. A SOC 2 examination is conducted by a licensed CPA firm and results in a formal attestation report.

SOC 2 is distinct from other compliance frameworks in an important way: it is not a certification. Unlike ISO 27001, where achieving certification means meeting a defined standard and receiving a certificate, SOC 2 produces a report that describes your controls and attests to whether they are suitably designed (Type I) or whether they operated effectively over a defined observation period (Type II). The report is typically shared under NDA with prospective clients and partners as part of vendor due diligence.

The framework is built around five Trust Services Criteria (TSC):

• Security (Common Criteria / CC): The only mandatory criterion. Covers logical and physical access controls, system operations, change management, and risk mitigation. All SOC 2 examinations must include the Security criterion.
• Availability: Addresses whether systems are available for operation and use as committed or agreed.
• Confidentiality: Addresses whether information designated as confidential is protected as agreed.
• Processing Integrity: Addresses whether system processing is complete, valid, accurate, timely, and authorised.
• Privacy: Addresses whether personal information is collected, used, retained, disclosed, and disposed of in conformity with the organisation's privacy notice and the AICPA's privacy criteria.

The Security criterion is broken down into Common Criteria numbered CC1 through CC9, covering the control environment, communication and information, risk assessment, monitoring activities, control activities, logical and physical access, system operations, change management, and risk mitigation.

SOC 2 differs from ISO 27001 in several important respects. ISO 27001 is an internationally recognised standard against which organisations can be certified by an accredited certification body. SOC 2 is a US-origin framework primarily recognised in North America and used heavily in B2B SaaS markets. ISO 27001 is broader in scope, covering all aspects of information security management. SOC 2 is focused specifically on how a service organisation's controls protect its customers' data and the reliability of its services.

Why Crypto Firms Need SOC 2

The commercial case for SOC 2 in crypto has become compelling. For any crypto firm targeting institutional clients, the absence of a SOC 2 report is now a liability. Institutional investors and asset managers operating under their own fiduciary obligations cannot onboard vendors without completing operational due diligence. A SOC 2 Type II report accelerates that process and frequently unblocks deals that would otherwise stall.

Exchange listing and integration requirements increasingly include security attestation requirements. Several major centralised and decentralised exchanges, custodians, and prime brokers now require prospective integration partners and service providers to produce SOC 2 reports as part of their technical and operational onboarding process. Firms without a report find themselves excluded from high-value distribution channels.

Investor due diligence is another significant driver. Venture capital and private equity firms conducting security due diligence on crypto investments are asking whether portfolio companies have pursued SOC 2. A firm that is actively working towards Type II compliance is demonstrating operational maturity that goes beyond a smart contract audit. This matters for Series A and Series B valuations in an environment where institutional capital demands higher standards from founders.

Regulatory pressure, while not directly mandating SOC 2, is moving in the same direction. MiCA requires CASPs to maintain appropriate technical and organisational security measures. DORA requires ICT risk management and third-party risk management frameworks. Supervisory assessments under both regimes will look at whether firms can demonstrate structured, evidenced security controls. A SOC 2 programme, even if not completed, demonstrates a serious approach to building that evidence base.

For crypto custodians in particular, the trust implications are direct. Customers who entrust digital assets to a custodian need confidence that the custodian's operational security controls are genuinely effective. A SOC 2 Type II report, produced by an independent auditor, provides that confidence in a way that self-attestation cannot.

"For a crypto custodian or B2B Web3 service provider, a SOC 2 Type II report is no longer a differentiator. It is the price of admission to institutional markets. Firms that treat it as optional are handing the enterprise segment to competitors."

The Five Trust Services Criteria Applied to Web3

Understanding how the five Trust Services Criteria apply to Web3-specific operations is essential for scoping your examination and building the right controls programme.

Security (Common Criteria). The mandatory criterion addresses access controls, encryption, monitoring, change management, and incident response. In a Web3 context, the Security criterion will scrutinise how your firm controls access to cryptographic key material, how signing operations are authorised and logged, how your development and deployment pipeline is governed, and how you detect and respond to security incidents. The Common Criteria are the heaviest lift for most crypto firms, but they also have the most direct impact on operational security quality.

Availability. For most crypto firms, particularly exchanges, custodians, and protocol infrastructure providers, availability is a critical criterion. Crypto markets operate continuously. Any interruption to trading, withdrawal, or settlement services has direct financial impact on customers. Availability controls must address redundancy, failover, capacity management, and recovery time objectives. Documenting and testing your business continuity and disaster recovery capabilities is a core component of the Availability criterion.

Confidentiality. Confidentiality controls address how your firm protects information that is designated as confidential, typically defined in your service agreements. For crypto service providers, this includes customer transaction data, portfolio information, API credentials, and any strategic or proprietary information shared by institutional clients. Encryption at rest and in transit, data classification, and access controls on confidential data repositories are key controls under this criterion.

Processing Integrity. Processing Integrity is particularly relevant for exchanges, settlement providers, and any firm where the accuracy and completeness of transaction execution is material. Controls must demonstrate that transactions are processed accurately, that errors are detected and corrected, and that processing outputs are validated. For crypto firms, this extends to smart contract execution integrity and on-chain settlement confirmation processes.

Privacy. Crypto firms that collect personally identifiable information during KYC and AML processes have significant Privacy criterion obligations. Controls must address how PII is collected, what consent mechanisms are in place, how data is retained and disposed of, and how data subject rights requests are handled. With GDPR obligations running in parallel for firms with EU customers, the Privacy criterion should be approached in conjunction with your broader data protection compliance programme. See our post on data loss prevention for crypto firms for related controls.

SOC 2 Type I vs Type II: Which One Do You Need

The choice between SOC 2 Type I and Type II is one of the first decisions to make in planning your compliance programme. Understanding what each report assesses and who will be reading it is essential for making the right call.

A SOC 2 Type I report assesses whether your controls are suitably designed at a specific point in time. The auditor reviews your control documentation, policies, and procedures and provides an opinion on whether the controls, as designed, meet the applicable Trust Services Criteria. Type I does not assess whether the controls actually worked over time. It answers the question: does the design look right?

A SOC 2 Type II report assesses both the design and the operating effectiveness of your controls over a defined observation period, typically six to twelve months. The auditor reviews evidence of control operation throughout the period: logs, tickets, access reviews, change records, training completions, and incident documentation. Type II answers the question: did the controls actually work, consistently, over time?

Most enterprise clients and institutional investors require a Type II report. A Type I report may be accepted as an interim measure while a Type II observation period is in progress, but it is rarely the end state that sophisticated buyers are looking for. The credibility gap between Type I and Type II is significant: any firm can design controls on paper. Demonstrating that those controls operated effectively for twelve months is a substantially higher bar.

The recommended path for most crypto firms is to begin with a readiness assessment, remediate identified gaps, proceed to a Type I audit to validate control design, and then enter the Type II observation period immediately following. This approach provides a marketable report within six to nine months while the evidence base for Type II is being built. The total elapsed time to Type II, from project initiation, is typically twelve to eighteen months.

Firms under immediate commercial pressure from a specific deal or partnership requirement may need to compress this timeline. In those cases, focus exclusively on the Security (Common Criteria) and any additional criteria specifically requested by the counterparty. A narrower scope can be audited more quickly and provides a useful starting point that can be expanded in subsequent annual reports.

The SOC 2 Audit Process

The SOC 2 audit process follows a well-defined sequence of steps. Understanding the full process from the outset helps firms plan resources, timelines, and costs accurately.

Step 1: Scope definition. Define which systems, services, and criteria are in scope for the examination. Scope definition is critical and has significant implications for cost and complexity. Systems that are out of scope will not be assessed, but if they are relevant to the services being audited, an auditor may question their exclusion. Engage with your chosen audit firm early in this process. Output: a defined system description and scope boundary.

Step 2: Readiness assessment. Before engaging an audit firm for the formal examination, conduct a readiness assessment to identify gaps between your current controls and the requirements of the Trust Services Criteria. This can be conducted internally or with the support of an external adviser. A readiness assessment is not the same as the audit itself and is not performed by the audit firm. Output: a gap register with prioritised remediation items.

Step 3: Gap remediation. Address the gaps identified in the readiness assessment. This is often the most resource-intensive phase of the project and should not be underestimated. Common remediation items for crypto firms include formalising access provisioning and deprovisioning procedures, implementing a privileged access management solution, establishing a formal vendor risk management programme, documenting change management processes, and deploying centralised logging and monitoring. Allow three to six months for meaningful remediation before beginning the audit.

Step 4: Select a CPA audit firm. SOC 2 examinations must be conducted by a licensed CPA firm. The market includes large accounting firms, specialist information security audit firms, and boutique providers. For crypto firms, it is worth selecting a firm with experience auditing technology or financial services companies and ideally with some familiarity with blockchain infrastructure. Ask prospective audit firms about their experience with crypto-specific controls such as key management, on-chain transaction logging, and smart contract change management.

Step 5: Observation period (Type II only). For Type II engagements, the observation period begins once the auditor has confirmed that controls are suitably designed. During this period, your team must operate the controls consistently and preserve evidence. This is not a passive phase. Auditors will request samples of control operation evidence throughout the period, and the quality of your evidence management will directly affect the outcome of the examination.

Step 6: Report issuance. Following the examination, the audit firm issues a SOC 2 report containing the auditor's opinion, a description of the system, a description of the controls, and (for Type II) the results of control testing. The report is your firm's primary deliverable and is typically shared under NDA with clients and partners.

SOC 2 Controls for Crypto-Specific Risks

Standard SOC 2 control frameworks were not designed with crypto firms in mind. Applying the Trust Services Criteria to Web3 infrastructure requires identifying the controls that address crypto-specific risks and building them into your control environment before the observation period begins.

Key management controls under CC6. CC6 covers logical and physical access controls. For crypto firms, this must extend to cryptographic key management: how private keys are generated, stored, accessed, and rotated. Hardware security modules (HSMs) and hardware wallets used for key storage must have documented access controls and audit logs. Key ceremony procedures must be documented and executed with appropriate witnesses and controls. The Common Criteria do not prescribe specific key management technology, but the auditor will assess whether your controls provide adequate protection given the sensitivity of the assets involved.

Multi-signature governance under CC6.6. CC6.6 covers access to system components by external parties. Multi-signature wallet governance, including approval thresholds, signer selection criteria, and key rotation procedures, should be documented as formal controls. The governance structure for multi-sig approvals should be defined in policy and the actual operation of approval processes should produce auditable evidence.

Endpoint security for signing devices. Any device used for transaction signing or key management operations requires enhanced endpoint controls. This means full disk encryption, application whitelisting, network isolation from general internet access, and regular security patching. The controls on signing devices are likely to be specifically examined by auditors given their criticality to the system description.

Privileged access controls. CC6.3 addresses privileged access. All privileged accounts, including administrative access to cloud infrastructure, database access, and administrative access to internal systems, must be managed under a formal privileged access management programme with logging, review, and justification requirements. See our guide to privileged access management for crypto firms for implementation detail.

Wallet access logging. All access to wallet infrastructure, including view-only access to balances and full transaction signing operations, should produce tamper-evident audit logs. These logs are both a security control and a critical evidence source for the SOC 2 examination. Log retention periods must meet or exceed the observation period plus any contractual retention commitments to clients.

Smart contract deployment change management. CC8 covers change management. For firms that deploy or upgrade smart contracts, the deployment process must be governed by a formal change management procedure: documented change requests, technical and security review, approval by designated authority, testing requirements, and post-deployment verification. Smart contract upgrades that bypass governance processes are a red flag for auditors and a genuine security risk.

Crypto-specific incident response procedures. CC7.3 through CC7.5 cover incident response. Crypto-specific incident scenarios, including wallet compromise, private key exposure, smart contract exploit, and insider theft of key material, must be addressed in your incident response plan and playbooks. For detailed guidance, see our post on incident response planning for crypto organisations.

Common SOC 2 Failure Points for Crypto Firms

Understanding where crypto firms typically struggle in SOC 2 examinations allows you to address these issues during remediation rather than discovering them during the audit.

Access provisioning without formal approval. One of the most frequently cited exceptions in SOC 2 reports is access being provisioned to systems without formal authorisation. In fast-moving Web3 teams, it is common for engineers to grant each other access informally or for access to accumulate over time as roles change. Establishing a formal joiner-mover-leaver process with documented approvals before the observation period begins is essential. See our guide to identity and access management for crypto firms.

Shared credentials and service accounts. Shared login credentials make it impossible to attribute actions to individual users, which is a fundamental requirement for access control logging under CC6. All users must have individual accounts. Service accounts must be managed under a formal service account policy with defined owners, access reviews, and credential rotation schedules.

Missing or incomplete logging for privileged access. Auditors will specifically test whether privileged actions are logged and whether those logs are retained and reviewed. Gaps in logging coverage, particularly for cloud infrastructure and critical internal systems, are a common exception. Conduct a logging coverage review as part of your readiness assessment and address gaps before the observation period begins.

No formal vendor risk management programme. CC9.2 covers vendor risk management. Many crypto firms rely on a significant number of third-party services: cloud providers, KYC platforms, custody technology providers, oracle networks, and more. Without a formal vendor risk programme that includes security questionnaires, contract terms, and periodic reviews, this criterion is difficult to satisfy. Our post on operational risk management for crypto firms covers third-party risk in detail.

Undocumented change management. Rapid iteration is a feature of Web3 development culture, but it is a liability in a SOC 2 examination. Changes to production systems, smart contracts, and infrastructure must be documented, reviewed, approved, and tested before deployment. Implementing a lightweight but consistent change management process before the observation period begins will avoid exceptions under CC8.

Inadequate separation of duties. Allowing the same individual to initiate, approve, and execute sensitive operations, such as large fund transfers, contract deployments, or administrative account changes, creates both a fraud risk and a control deficiency. Building separation of duties into your operational processes is both a SOC 2 requirement and a fundamental operational security control. See our post on separation of duties for crypto organisations for a detailed treatment.

SOC 2 vs ISO 27001: Which Should You Pursue First

This is one of the most common questions from crypto security leaders, and the answer depends on your market, your regulatory obligations, and your commercial priorities.

Dimension	SOC 2	ISO 27001
Output type	Attestation report	International certification
Issuing body	AICPA (US)	ISO / IEC (international)
Primary audience	US enterprise clients, institutional investors	European regulators, global enterprise, regulated industries
Typical cost	£30,000 to £120,000+	£20,000 to £80,000+
Timeline to first report/cert	3-6 months (Type I), 9-18 months (Type II)	6-18 months
DORA / MiCA relevance	Indirect	Direct
Renewable	Annual re-examination typical	3-year certification cycle with annual surveillance

The practical recommendation is straightforward: if your primary market is North American enterprise clients and institutional investors, pursue SOC 2 first. If your primary regulatory exposure is European, under DORA or MiCA, pursue ISO 27001 first. Firms with material business in both markets should plan to achieve both, typically staggering the programmes by twelve to eighteen months to avoid overwhelming the internal security team.

Critically, both frameworks build on the same underlying control foundations. Firms that build a robust control environment for SOC 2 will find that a significant proportion of the work is directly reusable for ISO 27001. Investing in good controls once and mapping them to multiple frameworks is far more efficient than treating each framework as a separate programme. For a detailed treatment of ISO 27001 in Web3, see our guide to ISO 27001 certification for crypto organisations.

For firms operating under DORA obligations, the NIST CSF can serve as a useful unifying framework that maps onto both SOC 2 and ISO 27001 requirements. See our post on the NIST Cybersecurity Framework for crypto and Web3 firms for guidance on using it as a foundation layer.

Estimated Costs and Timeline

SOC 2 is a meaningful investment. Understanding the cost components in advance allows firms to budget accurately and make the business case to leadership.

Readiness assessment: £5,000 to £20,000. A readiness assessment can be conducted internally using published AICPA guidance, or externally with specialist support. External assessments conducted by firms with crypto sector experience will typically identify more relevant gaps and produce more actionable outputs. Budget the higher end of this range if you are starting from a low maturity baseline.

Gap remediation: £10,000 to £50,000 and above. Remediation costs vary enormously depending on the gaps identified. Technology investments such as deploying a SIEM, implementing a privileged access management solution, or upgrading logging infrastructure are the largest cost drivers. Process and documentation work is largely an internal time cost. Firms with existing security programmes will sit at the lower end; firms building controls from scratch should budget significantly more.

Audit firm fees: £15,000 to £50,000. CPA audit firm fees for a SOC 2 examination vary based on scope, the number of criteria included, the size of the firm, and the audit firm's pricing model. Type I engagements are less expensive than Type II. Boutique specialist firms may offer competitive pricing for smaller crypto companies, but prioritise quality and experience over cost minimisation when selecting an audit partner.

Total investment: £30,000 to £120,000 and above, depending on scope and maturity. Firms with well-developed security programmes and narrow examination scope may come in at the lower end. Firms building controls from scratch across a broad scope should plan for the higher end. Ongoing annual re-examination costs, once the control environment is mature, are typically lower than initial year costs.

The return on investment is commercial as well as operational. A single enterprise contract unlocked by a SOC 2 Type II report will typically exceed the total cost of achieving it. Frame the investment accordingly when building the internal business case.

Frequently Asked Questions