Why Security Due Diligence Matters in Crypto

The case for rigorous security due diligence in crypto is straightforward: the sector has lost more than five billion dollars to security incidents in the past three years, and the majority of those losses were not from on-chain code vulnerabilities. They were from operational security failures: compromised private keys, insider theft, social engineering of personnel with privileged access, and inadequate incident response that allowed attackers to move assets before recovery was possible.

Institutional investors conducting financial due diligence on a crypto firm will scrutinise revenue, tokenomics, legal structure, and market position with considerable rigour. Many of those same investors conduct minimal security due diligence, accepting a smart contract audit report as sufficient evidence of security posture. This is a significant analytical gap. A smart contract audit assesses the code; it says nothing about whether the keys that control that code are stored securely, whether the team has been background-screened for insider risk, or whether the firm would detect and contain a sophisticated network intrusion within a timeframe that prevents asset loss.

The consequences of this gap are visible in the post-incident analysis of major crypto losses. Ronin Bridge's $625 million exploit in 2022 was enabled by compromised validator private keys, not a smart contract bug. The FTX collapse exposed catastrophic failures in key management, access control, and financial governance that an operational security assessment would have identified. Multiple exchange and protocol exploits have traced to social engineering of employees with privileged access rather than on-chain code vulnerabilities.

For investors, the implication is that security due diligence is a material financial risk assessment requirement, not an optional technical formality. For founders and security leaders preparing for fundraising or acquisition, the implication is that the security due diligence process needs to be treated with the same rigour and preparation as financial and legal due diligence.

"Accepting a smart contract audit as a complete security assessment is like accepting a building inspection report as a complete assessment of a financial institution. The code is one layer. The people, the processes, and the full technology stack are the rest of the picture, and they account for the majority of material risk in crypto."

Security Due Diligence vs Smart Contract Audit: The Distinction

A smart contract audit is a structured technical review of deployed or pre-deployment smart contract code. The auditor examines the code for known vulnerability patterns: reentrancy vulnerabilities, integer overflows and underflows, access control weaknesses in the contract logic, flash loan attack surfaces, oracle manipulation risks, and similar on-chain risks. The output is a report categorising findings by severity and providing remediation guidance. Smart contract audits are valuable, necessary for any protocol deploying material value on-chain, and have a well-established methodology and market of providers.

A security due diligence assessment addresses a categorically different set of questions. It does not examine on-chain code. It examines the organisation, the people who operate it, the processes they follow, and the technology environment in which they operate. The central questions are: could a sophisticated adversary gain control of the firm's key material or critical systems, and if so, what would prevent them from doing so or limit the damage they could cause?

The People dimension covers who has access to privileged systems and key material, how they were recruited and screened, how their access is monitored, and what controls exist to detect and prevent insider threat. The Process dimension covers how key management operations are governed, how incidents are detected and handled, how vendors and third parties are assessed, how access is provisioned and deprovisioned, and how security testing is conducted and actioned. The Technology dimension covers the security configuration of infrastructure and endpoints, the deployment and management of key management technology, network segmentation, monitoring and detection capabilities, and the security of development and deployment pipelines.

Both types of assessment are necessary for a complete picture. A firm with an audited, verified smart contract deployed from a compromised development environment, controlled by keys managed without adequate hardware protection, operated by a team with no security awareness, is not a secure firm. The smart contract audit is one layer of a multi-layer security assessment requirement.

The Complete Security Due Diligence Checklist

The following checklist covers the ten core domains of crypto security due diligence. Each domain includes the specific questions and evidence items that a rigorous assessment should address. The checklist is structured for use by both investors conducting outgoing due diligence on a target firm and by firms preparing to undergo incoming due diligence.

1. Key Management Practices

Key management is the highest-priority domain in any crypto security due diligence. The firm's ability to protect private key material determines whether it can protect the assets under its control. A failure in key management is almost always catastrophic and frequently irreversible.

Evidence to request and assess:

• Documented key management policy covering key generation, storage, access, rotation, and destruction procedures
• Evidence of hardware key storage: hardware security modules for institutional-grade custody or hardware wallets for operational hot wallet management
• Multi-signature wallet governance documentation: approval thresholds, signer selection criteria, key holder procedures, and evidence of governance being followed in practice
• Key ceremony documentation for any keys generated under formal ceremony procedures, including witnesses, procedures followed, and output records
• Key rotation history and schedule: evidence that keys are rotated according to policy rather than remaining static indefinitely
• Procedures for key holder succession: what happens if a key holder is unavailable, incapacitated, or departs the firm
• Evidence that key material is not stored in software systems, configuration files, code repositories, or communication platforms

Questions to ask in management interviews: Who has access to key material, and what is the minimum number of individuals required to authorise a transaction above a defined threshold? When was the key management policy last reviewed and updated? Has there ever been a key management incident, near-miss, or policy breach?

2. Access Control Policies

Access control governs who can do what within the firm's systems and infrastructure. Weak access control policies are one of the most consistently exploited vectors in crypto security incidents, both by external attackers who compromise an employee's account and by insiders who leverage excessive permissions.

Evidence to request and assess:

• Identity and access management (IAM) policy documentation covering access provisioning, review, and deprovisioning procedures
• Privileged access management policy and evidence of implementation: how are administrative accounts managed, logged, and reviewed
• Evidence of regular access reviews: periodic certification of user access to sensitive systems with sign-off by account owners or management
• Offboarding procedure documentation and evidence of consistent execution: are accounts deprovisioned promptly and completely when employees leave
• Multi-factor authentication deployment evidence: which systems require MFA, which accounts are exempt, and why
• Least privilege evidence: are user permissions scoped to the minimum required for the role, or are excessive permissions common
• Evidence of separation of duties for sensitive operations: are the same individuals able to both initiate and approve high-value transactions or critical configuration changes

3. Insider Threat Controls

Insider threat is disproportionately significant in crypto relative to other financial sectors because the irreversibility of on-chain asset transfer means that a malicious insider with appropriate access can cause losses that cannot be recovered. The history of crypto exchange collapses and protocol exploits includes multiple cases where insider access was the primary attack vector.

Evidence to request and assess:

• Background screening policy and evidence: are employees in sensitive roles subject to pre-employment background checks covering criminal history, financial history, and previous employment verification
• NDA and confidentiality agreement execution records for all employees and contractors with access to sensitive systems or key material
• Access monitoring evidence: is privileged access activity logged and reviewed, are anomalous access patterns detected and investigated
• Separation of duties controls for key management operations: can any single individual perform a complete key management operation without oversight
• Offboarding security procedures: is access revoked immediately on departure, are credentials changed following access removal, is key material rotated when key holders depart
• Security clearance or enhanced screening for roles with access to key management infrastructure, particularly relevant for firms with institutional custody obligations

4. Incident Response Readiness

The quality of a firm's incident response planning determines how much damage is caused when a security incident occurs. In crypto, where every minute of uncontained access to wallet infrastructure can result in additional asset loss, the speed and effectiveness of incident response is a direct financial risk variable.

Evidence to request and assess:

• Documented incident response plan specific to the firm's crypto operations: not a generic IT incident response policy but a plan that addresses crypto-specific scenarios including wallet compromise, key exposure, smart contract exploit, and insider theft
• Evidence that the IR plan has been tested: tabletop exercise records, simulation outcomes, and lessons learned documentation
• Escalation path documentation: who is contacted in what order for what severity of incident, and what authority does each person have to take remediation action
• On-call and out-of-hours response capability: crypto incidents do not occur only during business hours; the IR plan must cover 24/7 response capability
• Evidence of past incident handling: how were previous incidents detected, contained, and communicated; were regulatory notification obligations met
• Pause and circuit breaker mechanisms for DeFi protocols: does the protocol have the ability to pause operations in the event of an active exploit, and is that capability documented and tested

5. Security Governance

Security governance determines whether security is embedded in the firm's decision-making or treated as a peripheral operational function. The absence of clear security accountability at an appropriate organisational level is a structural risk: security investments will be deprioritised, security findings from testing will remain unactioned, and security decisions will be made without adequate expertise.

Evidence to request and assess:

• CISO or equivalent role: is there a named individual with responsibility and accountability for security, and do they have appropriate authority and seniority
• Security policy suite: documented, current policies covering information security, acceptable use, data classification, incident response, access control, and vendor management
• Board oversight evidence: does the board receive regular security reporting, are security risks on the board risk register, has the board been briefed on the security programme
• Security budget allocation: is there a dedicated security budget that is commensurate with the firm's asset base and risk exposure
• Security committee or equivalent governance body: is there a forum for security decisions that includes representatives from technology, operations, legal, and compliance
• Security programme roadmap: evidence that the firm has a forward-looking security improvement plan rather than a reactive, incident-driven approach to security investment

6. Vendor and Third-Party Risk

Crypto firms are typically highly dependent on third-party services: cloud infrastructure providers, custody technology vendors, oracle networks, KYC and AML platforms, exchange connectivity APIs, and more. Each third-party dependency is a potential attack surface. The failure or compromise of a critical third-party provider can directly affect the security of the firm's operations and assets.

Evidence to request and assess:

• Vendor risk management policy and process documentation: how are third-party providers assessed before onboarding and periodically thereafter
• Critical third-party register: a documented list of providers on whom the firm depends for critical functions, with associated risk assessments
• Security questionnaire or assessment evidence for critical providers: has the firm obtained security attestation from providers handling sensitive data or critical functions
• Contractual security requirements: do service agreements with critical providers include security obligations, breach notification requirements, and audit rights
• Concentration risk assessment: is the firm excessively dependent on any single provider such that a failure or compromise of that provider would cause catastrophic operational impact
• Evidence of third-party incident response coordination: is there a defined process for responding to security incidents originating from or affecting third-party providers

7. Regulatory Compliance Posture

Regulatory compliance posture in crypto is both a direct legal risk and an indirect indicator of operational maturity. Firms that have engaged seriously with regulatory requirements under MiCA, DORA, or applicable VASP registration frameworks have typically built the governance structures, documentation, and control environments that also underpin good security practice.

Evidence to request and assess:

• MiCA authorisation status or roadmap: is the firm authorised as a CASP, in application, or has it assessed whether it needs authorisation
• DORA compliance programme status: has the firm assessed its DORA obligations, and is there an ICT risk management framework in place
• VASP registration documentation for applicable jurisdictions: Financial Crimes Enforcement Network (FinCEN) registration in the US, FINTRAC in Canada, FCA registration in the UK, and equivalent registrations elsewhere
• SOC 2 compliance status: is the firm working towards or has it achieved SOC 2 Type II certification
• AML and KYC programme documentation: is there a documented AML programme, is it being implemented and tested, are transaction monitoring systems in place
• Regulatory examination history: has the firm been subject to regulatory examination, and if so, what were the findings and how were they addressed

8. Security Testing History

A firm's security testing history provides evidence of how seriously it takes its security posture and whether identified vulnerabilities are addressed. A firm that has never commissioned a penetration test or that has an extensive finding backlog with no remediation evidence is a materially higher-risk target than one that tests regularly and remediates findings systematically.

Evidence to request and assess:

• Penetration test reports for the past two to three years, covering both network and application testing of critical systems
• Smart contract audit reports for all deployed contracts, with remediation evidence for identified findings
• Remediation tracking records: evidence that findings from testing are tracked to closure, not simply acknowledged and filed
• Bug bounty programme: does the firm operate a bug bounty programme, and are there examples of valid findings received and rewarded
• Internal security testing capability: does the firm conduct internal security reviews of code, infrastructure configurations, and access controls, or does it rely entirely on periodic external testing
• Vulnerability disclosure policy: is there a formal process for researchers or counterparties to report security vulnerabilities, and is it publicly published

9. Security Awareness

The majority of successful attacks against crypto firms involve a human element: a phishing email that captures credentials, a social engineering call that manipulates an employee into revealing information or taking a harmful action, or an insider who exploits their access for personal gain. Security awareness training addresses the human layer of the security stack. Its absence is a predictable and exploitable gap.

Evidence to request and assess:

• Security awareness training programme: is there a structured training programme, how frequently is training conducted, and is completion tracked and enforced
• Phishing simulation results: has the firm conducted phishing simulations, what are the click rates and credential submission rates, and is there evidence that simulation results have driven training improvements
• Role-specific security training for high-risk roles: are individuals with access to key management infrastructure, custody systems, or privileged administrative access subject to enhanced security training
• Security briefing for new joiners: is security training part of the onboarding process for all new employees, not just technical staff
• Documented security culture indicators: does the firm have a responsible disclosure culture, are security concerns reported internally, is there evidence that security is valued at the organisational level rather than treated as a compliance burden

10. Business Continuity and Disaster Recovery

Business continuity planning (BCP) and disaster recovery (DRP) address the firm's ability to maintain or rapidly restore operations following a major disruptive event. In crypto, business continuity has dimensions that do not exist in traditional financial services: the possibility of irreversible asset loss means that recovery from a security incident may not be possible in the same way as recovery from a system outage.

Evidence to request and assess:

• Business continuity plan documentation: is there a documented BCP covering the firm's critical functions, dependencies, and recovery procedures
• Disaster recovery plan: is there a documented DRP with defined Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) for critical systems
• BCP and DRP testing evidence: have the plans been tested through tabletop exercises or live drills, when was the last test, and what were the outcomes
• Key person dependency assessment: is the firm excessively dependent on specific individuals for critical functions, and are succession and backup procedures documented
• Geographic and infrastructure redundancy: are critical systems replicated across independent infrastructure to protect against single points of failure
• Crypto-specific continuity considerations: are there documented procedures for maintaining asset security during a continuity event, including procedures for key material protection when normal operations are disrupted

Red Flags That Should Trigger Concern or Kill a Deal

Not all gaps in a security due diligence assessment are equal. Some findings represent areas for improvement in a broadly sound security programme; others represent fundamental failures that indicate either severe negligence or an organisation that has not seriously engaged with its security obligations. The following are the red flags that should trigger either a deal pause, a significant risk adjustment, or in the most serious cases, a decision not to proceed.

Single Point of Control for Key Management

Any arrangement where a single individual can initiate and complete a material asset transfer without a second authorised party is a critical finding. This is true whether the single point of control is technical (a single-signature hot wallet with no multi-sig requirement) or operational (a multi-sig arrangement where one person effectively controls enough signers to reach threshold). Single-point-of-control key management is both a major security vulnerability and a major governance failure. It is the operational pattern that enabled several of the largest crypto losses in recent years.

No CISO or Equivalent Role

The absence of a named individual with accountability for security is a governance failure at the organisational level. It does not mean the firm has no security, but it means that security decisions are being made without a dedicated function, security risks are not being reported to management in a structured way, and there is no one accountable for driving security programme improvements. For any firm managing material assets on behalf of others, this is a red flag that goes beyond security into corporate governance.

Undisclosed Security Incidents

A security incident that is discovered during due diligence but was not disclosed in the target firm's responses to initial questions is a significant red flag. It raises questions about the completeness and accuracy of all other due diligence responses. Firms that have experienced security incidents and managed them well, with a documented response, lessons learned, and remediation programme, are actually demonstrating security programme maturity. Firms that conceal incidents are demonstrating a governance and transparency problem that extends beyond the security domain.

No Security Testing History

A firm that has never commissioned a penetration test against its critical systems, particularly one that has been operating for more than twelve months and managing material assets, is demonstrating either negligence or a fundamental underestimation of its security risk. The absence of security testing history does not mean the firm has no vulnerabilities; it means it has no knowledge of them.

Software Key Storage for Material Assets

Any evidence that private keys controlling material asset balances are stored in software systems, including cloud secrets managers, code repositories, internal wikis, communication platforms, or unencrypted files, is a critical finding. Software key storage is categorically inadequate for keys controlling material value. It means the keys are accessible to anyone who can compromise the software system in which they are stored, and potentially to the cloud provider or any other party with access to the underlying infrastructure.

No Incident Response Plan

The absence of a documented incident response plan for a firm managing material digital assets is a critical operational security gap. When an incident occurs, and in crypto the question is when not if, an undocumented response process will be slower, less consistent, and more likely to make decisions that worsen the outcome. Delayed asset freeze, failure to notify appropriate parties, and evidence destruction through reactive system remediation are all failure modes that an IR plan prevents.

Regulatory Non-Compliance

Evidence that the firm is operating without required regulatory authorisations, has failed to register as a VASP in jurisdictions where it is required to do so, or has received regulatory findings that have not been actioned is a legal risk that sits alongside and compounds the security risk. Regulatory non-compliance also often indicates an organisational culture that does not take compliance obligations seriously, which tends to correlate with security culture deficiencies.

How to Prepare Your Firm for Incoming Due Diligence

Preparation for incoming security due diligence should begin well before a fundraising round, strategic partnership negotiation, or acquisition process is initiated. Firms that engage with due diligence preparation proactively, rather than reactively under deal pressure, achieve better outcomes in the process itself and build a stronger underlying security posture in the process.

The starting point is an honest internal assessment against the ten checklist domains above. This assessment should be conducted with the same rigour and independence as the incoming external assessment will be. Identify which domains have documented, evidenced controls in place, which have partial coverage, and which have material gaps. Prioritise remediation of gaps in the order that reflects their risk significance: key management first, then access control and incident response, then the remaining domains.

Document everything that is already in place. One of the most common failures in security due diligence preparation is not the absence of controls but the absence of documentation for controls that exist. Security teams that operate good practices informally, without policy documentation, will be unable to demonstrate those practices during due diligence. The process of documenting existing controls also frequently identifies gaps between the intended control and the actual operational practice, which is itself valuable information.

Commission a pre-due-diligence penetration test if the firm has not had one in the past twelve months. An external penetration test provides two benefits: it identifies vulnerabilities that should be remediated before they appear in due diligence findings, and it provides a testing report with remediation evidence that demonstrates security testing maturity to investors. A clean penetration test report, or one with all findings remediated and documented, is a significant positive signal in a due diligence process.

Engage with your regulatory obligations. Begin or advance your MiCA authorisation process if applicable. Assess your DORA obligations. Ensure your AML and KYC programme is documented and evidenced. Regulatory compliance documentation is one of the most commonly requested evidence sets in crypto security due diligence, and gaps in this area create both legal and security risk signals for investors.

Building a Security Data Room

A security data room is a structured, organised repository of security documentation that can be shared with investors, acquirers, or counterparties under NDA as part of a due diligence process. A well-prepared security data room significantly accelerates the due diligence process and allows the firm to present its security posture in the most favourable accurate light.

A security data room should contain, organised by domain:

• Security policy suite: Current versions of all security policies, with version history and approval signatures
• Key management documentation: Key management policy, key ceremony records (redacted as appropriate), HSM and hardware wallet inventory, multi-signature governance documentation
• Access control evidence: IAM policy, privileged access management documentation, most recent access review records, MFA deployment evidence
• Security testing history: Penetration test reports for the past two to three years, smart contract audit reports, bug bounty programme details, and remediation tracking evidence for all material findings
• Incident response documentation: Current IR plan, tabletop exercise records, any past incident reports with response documentation
• Vendor risk register: Critical third-party register with risk assessment summaries, relevant supplier security attestations
• Regulatory compliance documentation: Authorisation certificates or application status documentation, DORA programme documentation, AML programme documentation, any regulatory examination correspondence
• Security governance evidence: Board security reporting examples, security committee minutes, security programme roadmap
• BCP and DRP documentation: Current plans with test records and RTO/RPO definitions
• Security training records: Training programme documentation, completion records, phishing simulation results

Not all of this documentation needs to be disclosed to all counterparties. Sensitive items such as detailed penetration test reports should be shared only under NDA and only with parties who have a legitimate need to review them. A tiered disclosure approach, sharing summary information in early stages and detailed documentation in later stages of a process, is standard practice and is expected by sophisticated counterparties.

Conducting Due Diligence as an Investor or Acquirer

For institutional investors and acquirers conducting security due diligence on a crypto target, the checklist above defines the scope of the assessment. The practical question is how to conduct the assessment effectively within the constraints of a due diligence process.

Documentation review is the starting point. Request the security data room and review the available documentation against the checklist. Gaps in documentation are themselves findings: a firm that cannot produce a key management policy, a penetration test report, or an incident response plan on request is communicating something significant about its security programme maturity.

Management interviews supplement documentation review. Schedule structured interviews with the CISO or equivalent, the head of operations, and ideally the CEO or founder on security governance. These interviews should probe the accuracy and depth of the documentation: does the person responsible for key management actually understand the key management procedures documented in the policy, or are they reading from a document they have not previously engaged with. Authentic, detailed responses from management are a positive signal; vague or evasive responses to specific security questions are a negative one.

Technical verification is the third component for high-stakes due diligence. Where the deal size or risk profile justifies it, commission an independent technical assessment of specific high-priority areas: a penetration test of critical systems, an independent review of key management architecture, or a review of cloud infrastructure security configuration. Technical verification findings provide an independent data point against the documentation and management claims from the documentation review and interviews.

For investment decisions rather than acquisitions, where a full technical assessment may not be proportionate, the documentation review and management interview process, conducted by experienced practitioners with deep crypto security knowledge, provides a reliable basis for risk assessment. The objective is not to certify the target's security but to identify material risks that should be reflected in deal terms, deal structure, or the investment decision itself.

Frequently Asked Questions

What does crypto security due diligence cover?

Crypto security due diligence covers the full operational security stack of a Web3 firm, assessed across three dimensions: People, Process, and Technology. It goes significantly beyond a smart contract audit. Key areas include key management practices, access control policies, insider threat controls, incident response readiness, security governance, vendor and third-party risk, regulatory compliance posture, security testing history, security awareness training, and business continuity planning. The objective is to produce an evidence-based assessment of the firm's operational security risk before capital is deployed or an acquisition is completed.

How is security due diligence different from a smart contract audit?

A smart contract audit assesses the code quality and security of deployed or pre-deployment smart contracts. It identifies vulnerabilities in the on-chain logic: reentrancy, integer overflows, access control weaknesses in the contract code, and similar technical issues. Security due diligence assesses the operational security posture of the organisation behind the contracts: how keys are managed, who has access to privileged systems, how incidents are handled, whether the team has been background-screened, and how the firm would respond to a sophisticated targeted attack. Both are necessary for a comprehensive security assessment; they answer fundamentally different questions.

What are the biggest red flags in a crypto security due diligence?

The most significant red flags include: no documented key management policy or evidence of hardware key storage; single-factor authentication on privileged systems; no incident response plan or evidence of IR testing; pending or undisclosed security incidents or exploit history; no CISO or equivalent accountable security role; concentration of key management control in a single individual without documented succession or backup procedures; no security testing history or remediation evidence for prior penetration test findings; and regulatory non-compliance with applicable frameworks such as MiCA or DORA. Any single one of these factors warrants significant additional scrutiny; multiple red flags together should trigger either a deal pause or a material risk adjustment.

How should a crypto firm prepare for incoming security due diligence?

Preparation for incoming security due diligence should begin well before a fundraising or acquisition process. Core preparation steps include: conducting an internal security assessment against the standard checklist areas to identify and remediate gaps; ensuring all security policies and procedures are documented and current; compiling a security testing history with remediation evidence; ensuring the incident response plan is documented and has been tested; verifying regulatory compliance filings are current; and preparing a security programme roadmap that demonstrates a forward-looking improvement trajectory. Firms that approach due diligence with a pre-prepared security data room close processes significantly faster and at better valuations than firms that are assembling documentation under deal pressure.

Is a SOC 2 report sufficient for crypto security due diligence?

A SOC 2 Type II report is valuable evidence in a security due diligence process but is not sufficient on its own. SOC 2 addresses controls relevant to the security, availability, and confidentiality of customer data. It does not specifically address crypto-native risks such as key management governance, multi-signature custody controls, on-chain transaction monitoring, or DeFi-specific operational risks. Sophisticated investors and acquirers conducting crypto security due diligence will look at SOC 2 as one component of the evidence base alongside penetration test reports, key management documentation, incident response plans, and regulatory compliance evidence.