Web3 Security Governance Framework Guide

The Governance Vacuum in Web3

The phrase "security is everyone's responsibility" is one of the most dangerous statements in organisational security. When everyone owns something, nobody owns it. There is no escalation path, no decision-maker, no accountability when the control fails. In Web3, this problem is structural: the industry has attracted technically capable people who have built sophisticated systems, then organised around them with no formal accountability for security outcomes.

Consider the question that should have a clear, named answer in every Web3 organisation: who decides whether a newly discovered smart contract vulnerability is material enough to pause the protocol? In most cases, that decision is made ad hoc, by whoever happens to be available, under time pressure, without reference to a documented process or a defined risk appetite. That is not a security programme; it is improvisation, and improvisation under pressure produces the conditions in which attackers thrive.

Security governance is the structural answer to this problem. It is the set of accountabilities, decision rights, policies, and oversight mechanisms that determine how security decisions are made, by whom, on what basis, and with what escalation path when the stakes are high enough to require it. Without governance, every security control is optional, every policy is advisory, and every incident response depends on the judgment of whoever happens to be in the room.

The scale of the problem is visible in incident data. The majority of significant crypto losses in the past five years involved some form of governance failure, whether in signing authority controls, employee access management, third-party vendor oversight, or incident response decision-making. The technical exploits are the visible mechanism, but governance failures are frequently the enabling condition that made those exploits possible or undetected for long enough to cause maximum damage.

What Security Governance Means in Practice

Security governance is not a single document or a committee that meets quarterly. It is a system of interlocking structures that translate the organisation's risk appetite into operational behaviour. The key components are the CISO function, the security committee, board-level accountability, and the policy framework.

The CISO Role in Web3

The Chief Information Security Officer (CISO) is the person accountable for the organisation's security posture. In a Web3 context, the CISO role requires competence across both traditional enterprise security domains and blockchain-specific risks: custody security, smart contract attack vectors, on-chain monitoring, and DeFi-specific threat models. Many early-stage Web3 firms operate without a CISO, which is the primary structural cause of the governance vacuum described above.

The CISO's responsibilities include: owning the security policy framework; advising the board and executive team on security risk and risk appetite; overseeing the design and implementation of security controls; maintaining the incident response programme; managing the relationship with external security partners and auditors; and reporting on security posture to leadership on a regular cadence. Without a named individual accountable for these functions, they do not get done consistently.

For organisations too early-stage to justify a full-time CISO, a virtual CISO (vCISO) arrangement with a specialist partner provides the governance structure without the full-time cost. The important principle is that the accountability exists as a named function, not that it requires a specific employment structure.

The Security Committee

A security committee is a cross-functional body that owns security decision-making at the organisational level, above the day-to-day operations of the security team. In a Web3 firm, an effective security committee typically includes the CISO, the CTO or Head of Engineering, the CFO or Head of Finance, and a representative from Legal and Compliance. For firms with a board, the committee should report to the board through a defined escalation path.

The security committee is responsible for: approving the security policy framework and any material changes to it; reviewing the organisation's risk register and risk treatment decisions; overseeing the results of security audits and penetration tests; approving the incident response plan and any post-incident remediation commitments; and making risk acceptance decisions that exceed the CISO's individual authority.

The cadence of security committee meetings should be defined in governance documentation: quarterly as a minimum, with provision for emergency sessions in the event of a significant incident or emerging threat. Decisions made by the committee should be documented and the record maintained as part of the governance audit trail.

Board-Level Accountability

In Web3, board-level security accountability is frequently absent. Boards that were formed around tokenomics, fundraising, and growth metrics often lack a member with security expertise, and the topic appears on the agenda only after a breach. This is inadequate for any firm holding material assets or operating infrastructure that users depend on.

Effective board-level security governance requires: at least one board member or observer with security expertise; regular reporting from the CISO or security committee to the board on security posture, material risks, and audit findings; board approval of the security risk appetite statement; and board oversight of major security investment decisions. Regulatory frameworks including DORA explicitly require board accountability for ICT risk; boards that have not engaged with security are not only exposed to operational risk but increasingly to regulatory risk as well.

Security Policy Framework

Policies are the mechanism through which governance translates into operational behaviour. A security policy framework is not a single document; it is a hierarchy of documents, from a high-level security policy approved by the board down to specific operational procedures for individual processes. Each document in the framework has a named owner, a defined review cycle, and a defined approval authority.

The framework structure matters because it determines which decisions can be made at which level. A policy approved at board level takes precedence over an operational procedure approved at management level. When a conflict arises between operational convenience and a policy requirement, the policy takes precedence unless the conflict is escalated to the appropriate approval authority. This structure is what makes policies enforceable rather than advisory.

Governance Failures That Enabled Real Hacks

The most instructive analysis of what security governance needs to prevent comes from examining cases where its absence contributed directly to a successful attack. Three categories of governance failure recur in Web3 incident post-mortems: inadequate signing process controls, poor governance over employee access, and multisig key management failures.

Bybit: Signing Process Governance

The February 2025 Bybit hack, in which approximately $1.5 billion in Ethereum-based assets were stolen, has been attributed to a sophisticated attack on the signing process for a multisig wallet. The attackers, widely attributed to the Lazarus Group, were able to manipulate what signers saw when approving a transaction, causing them to sign a malicious transaction believing it to be a routine transfer.

The governance failure here was not primarily technical. It was a failure to have adequate procedures governing the signing process itself: procedures that would have required independent verification of transaction details through multiple channels before signing; that would have flagged the use of an upgraded smart contract as requiring elevated scrutiny; and that would have mandated a pause and verification process when multiple signers were approving the same transaction in rapid succession. The technical attack was sophisticated, but it succeeded because the governance framework did not impose the friction that would have exposed it.

This is precisely the territory that separation of duties controls are designed to address. Governance mandates those controls and defines the consequences when they are not followed. Without that mandate, the controls are optional, and optional controls are consistently bypassed when they create friction.

Lazarus Group: Employee Access Governance

The Lazarus Group's social engineering campaigns against crypto firms have succeeded repeatedly by targeting employees rather than systems. The attack pattern is well documented: targeted employees receive highly convincing outreach, often via LinkedIn, resulting in the delivery of malware through what appears to be a recruitment or job evaluation process. Once a foothold is established, the attackers move laterally to reach high-value systems and key material.

What makes these attacks so consistently effective is not their technical sophistication; it is the absence of governance over employee access changes. In a well-governed organisation, an employee's access to sensitive systems is reviewed regularly, not just at onboarding. Changes to access are logged and reviewed. The addition of new software to an employee's workstation requires authorisation. Communications channels used to authorise sensitive operations are defined in advance, and requests through unofficial channels are treated as suspicious by policy.

None of these controls require advanced technology. They require governance: clear policies, defined procedures, named owners, and enforcement mechanisms. Their absence is a governance failure, not a technology failure. Identity and access management frameworks provide the technical infrastructure, but governance determines whether that infrastructure is used consistently and enforced when it creates inconvenience.

Multisig Governance Failures

Multisig wallet arrangements are widely adopted in Web3 as a technical control to prevent single points of failure in key management. However, a multisig that is technically configured correctly can still fail catastrophically due to governance deficiencies around how it is operated. The most common failure modes include: key holders who are co-located or part of the same reporting structure, eliminating the independence that multisig is meant to provide; inadequate key-holder vetting processes that allow an attacker posing as an employee or contractor to obtain a signing position; no documented process for key refresh or key holder rotation; and no independent verification step before transaction approval.

Governance addresses each of these failure modes through policy: a multisig governance policy defines who may be a key holder and under what conditions, how key holders are vetted and onboarded, what the process is for approving transactions above defined thresholds, and how key holder changes are authorised and executed. Without that governance layer, the multisig is a technical control that provides a false sense of security rather than genuine risk reduction.

The technical controls worked as designed. The governance framework that was supposed to mandate their correct use did not exist. This is the pattern that repeats in major Web3 incidents: not technology failure, but governance failure enabling technology bypass.

Core Governance Documents Every Web3 Firm Needs

A governance framework without documentation is not a framework; it is an informal understanding that will produce inconsistent outcomes and provide no audit trail. The following documents form the minimum policy framework for a Web3 firm with any meaningful security exposure.

Security Policy

The security policy is the apex document of the framework. It states the organisation's security objectives, defines the scope of the security programme, establishes the security risk appetite, assigns top-level accountability for security (typically the CISO and the board), and provides the authority under which all subordinate policies and procedures are issued. It should be brief, clear, and approved at board level. It does not contain operational procedures; those belong in subordinate documents.

Acceptable Use Policy

The acceptable use policy (AUP) governs how employees and contractors may use organisational systems, devices, and networks. In a Web3 context, the AUP must address the use of personal devices for work purposes (a significant attack vector in remote-first teams), the installation of software on organisational devices, the use of personal wallets on work systems, and the handling of private key material outside of approved custody infrastructure. All staff must acknowledge the AUP as a condition of access, and the acknowledgement must be recorded.

Access Control Policy

The access control policy defines the principles governing who may access what, under what conditions, and with what authorisation. It should mandate least-privilege access as the default, define the process for access provisioning and de-provisioning, require regular access reviews, and specify elevated controls for privileged access to sensitive systems. The policy should directly reference the identity and access management systems used to implement it, and should define what constitutes a privileged account in the organisation's specific context.

Separation of duties requirements for sensitive processes, including transaction signing, key management, and access provisioning itself, should be explicitly defined in this policy or a closely linked operational procedure.

Incident Response Policy

The incident response policy defines what constitutes a security incident, who is responsible for managing the response, how incidents are classified by severity, what actions are authorised at each severity level, and how communications are managed internally and externally during an incident. In Web3, this policy must address the specific decision points relevant to the organisation's operations: when to pause a protocol or halt withdrawals, how to communicate with affected users, how to engage with blockchain security firms and white-hat researchers, and how to manage law enforcement and regulatory notifications.

The policy must be accompanied by a tested incident response plan that translates the policy into concrete procedures. A policy that has never been tested will not perform reliably under the pressure of a real incident.

Third-Party Risk Policy

Third-party risk is one of the most under-governed areas in Web3. Firms rely extensively on external providers: node infrastructure, oracle providers, custody partners, audit firms, exchange integrations, and software libraries. Each represents a potential attack vector. The third-party risk policy defines how vendors are assessed before onboarding, what security requirements they must meet as a condition of the relationship, how ongoing compliance is monitored, and how incidents originating from a third party are managed.

The policy should mandate a formal vendor risk management process for all third parties with access to the organisation's systems, data, or key infrastructure, with risk-tiered requirements based on the criticality of the access. Critical infrastructure providers should be subject to the most rigorous ongoing oversight.

Governance for DAOs and Decentralised Protocols

DAOs present a genuinely distinct governance challenge. The principles of decentralisation that define a DAO's operation, distributed decision-making, token-based voting, pseudonymous participation, are structurally incompatible with traditional corporate governance models that rely on named individuals, legal accountability, and hierarchical decision-making. Yet security governance requires exactly those things: named owners, clear accountability, and the ability to make rapid binding decisions under pressure.

The Core Tension

A DAO in which all security decisions require an on-chain governance vote is ungovernable from a security perspective. Governance votes take days or weeks. Security incidents require responses in minutes to hours. A protocol that must convene a token holder vote before it can pause following discovery of a critical vulnerability will sustain avoidable losses during the voting period. The decentralisation maxim cannot be applied uniformly across all decision types without creating catastrophic operational vulnerabilities.

The solution is not to abandon decentralisation, but to define clearly which categories of decision require on-chain governance and which can and must be delegated to a designated security function with appropriate oversight and accountability.

Security Multisig and Security Committee

Most mature DAOs that have addressed security governance have adopted a variant of the same model: a security multisig, a small group of identified, vetted individuals with the authority to take specified emergency actions (typically: pause the protocol, execute emergency upgrades, drain funds to a safe address), subject to defined conditions and with mandatory post-action governance review.

The security multisig is complemented by a security committee, a named group accountable for the security programme on an ongoing basis, including commissioning audits, reviewing vulnerability disclosures, maintaining security documentation, and proposing security-related governance changes for token holder vote. The committee's members should be publicly identified, their scope of authority clearly defined, and their activities reported to the broader DAO community on a regular basis.

Key holder selection for the security multisig must be treated as one of the highest-risk governance decisions the DAO makes. The vetting process should be documented, key holders should be geographically and organisationally diverse, and the rotation process should be defined in advance. The governance failure that has characterised several DAO-related incidents has been precisely the absence of this rigour in selecting and managing the individuals who hold the protocol's most sensitive keys.

Legal Wrappers and Accountability

A DAO without a legal wrapper has no formal mechanism for legal accountability, which creates problems both for enforcing security obligations internally and for interacting with regulators and law enforcement following an incident. Jurisdictions including the Cayman Islands, the British Virgin Islands, Wyoming, and the Marshall Islands have developed legal entity structures that can be used to wrap DAO operations while preserving meaningful decentralisation in governance.

The legal wrapper does not resolve the governance challenge, but it provides the structural basis for formal accountability that makes governance enforceable. For any DAO managing material value or operating infrastructure that users depend on, the absence of a legal wrapper is a governance risk that should be addressed as part of the security governance programme.

Transparency as a Governance Tool

DAOs have a genuine advantage over traditional firms in one dimension of governance: transparency. On-chain visibility of treasury movements, governance votes, and protocol changes provides a degree of accountability that traditional organisations cannot match. Effective DAO security governance leverages this transparency as a monitoring mechanism: anomalous treasury movements are visible to all participants, governance votes are auditable, and smart contract upgrades are trackable. Supplementing on-chain transparency with off-chain reporting and regular security updates to the community reinforces the governance culture that makes security controls effective.

Regulatory Expectations: DORA and MiCA

The regulatory landscape for Web3 has changed materially over the past three years. DORA compliance requirements and MiCA compliance both impose explicit governance obligations on firms within their scope that go significantly beyond generic security best practice. Understanding these obligations is essential for any Web3 firm operating in or serving customers in the European Union.

DORA: ICT Risk Governance

The Digital Operational Resilience Act (DORA) applies to a broad range of financial entities including crypto-asset service providers (CASPs) under MiCA, and imposes detailed requirements for ICT risk governance. Key governance requirements include: the management body (board) must bear ultimate responsibility for managing ICT risk; a documented ICT risk management framework must be maintained and reviewed at least annually; roles and responsibilities for ICT risk must be clearly defined and assigned; and a dedicated ICT risk management function must exist with sufficient independence and authority.

DORA also requires that the management body receive regular reporting on ICT risk, approve ICT risk tolerance levels, and ensure adequate resources are allocated to the ICT risk management function. These requirements are not satisfied by a nominal board-level review once a year; they require an active, documented governance process with evidence of board engagement.

Third-party ICT risk is a particular focus of DORA. Firms must maintain a register of all ICT third-party service providers, classify them by criticality, and apply enhanced oversight to critical providers. Contracts with ICT third-party providers must meet specified minimum requirements, and firms must conduct regular assessments of their critical providers' security and resilience.

MiCA: Governance Requirements for CASPs

The Markets in Crypto-Assets Regulation (MiCA) imposes governance requirements on CASPs that are distinct from but complementary to DORA. Under MiCA, CASPs must have robust governance arrangements including a clear organisational structure with well-defined and transparent lines of responsibility, effective processes to identify, manage, monitor and report risks, and adequate internal control mechanisms.

MiCA specifically requires that the management body of a CASP be responsible for and accountable to regulators for the implementation of these governance arrangements. This includes approving and overseeing the risk management framework, ensuring adequate resources for compliance functions, and reviewing policies at appropriate intervals. For CASPs holding client assets, additional custody-specific governance requirements apply, including documentation of segregation arrangements and the controls governing client asset movements.

Connecting Regulation to Governance Practice

The regulatory requirements imposed by DORA and MiCA are not separate from good security governance practice; they are a codification of it. A firm that has built a genuine security governance framework, with board accountability, a documented policy framework, named owners for each policy, a functioning CISO role, and active security committee oversight, is well positioned to demonstrate regulatory compliance. A firm that has done none of those things faces both operational risk and regulatory exposure simultaneously.

The practical implication is that building security governance is not just a security investment; it is a regulatory compliance investment that delivers returns across both dimensions. Organisations that defer governance work on the grounds that they are "too early stage" for formal structures are simultaneously accepting operational risk and regulatory exposure that will only become more expensive to remediate as the organisation grows.

Governance as the Foundation Everything Else Sits On

The People, Process, Technology (PPT) framework for security identifies three dimensions that must work together to produce effective security outcomes. Technology provides the tools: firewalls, HSMs, multi-sig wallets, monitoring systems. Process defines how those tools are used: procedures, runbooks, policies. People operate the processes and configure the tools. Each dimension depends on the others.

Governance is not a fourth dimension in this framework. It is the structural layer that enables the other three to function. Technology controls do not protect assets unless governance mandates their implementation and prohibits bypasses. Processes do not reduce risk unless governance defines who is accountable for following them and what the consequences are for non-compliance. People do not behave securely unless governance creates the expectations, incentives, and accountability that make secure behaviour the path of least resistance.

Why Technology Controls Fail Without Governance

The most common failure mode in crypto security is not the absence of technical controls. Most firms that have suffered major losses had technical controls in place: multi-sig wallets, hardware wallets, access controls on critical systems. The failure was that those controls were not mandated, not enforced, and not monitored. When they created friction, they were bypassed. When they were bypassed, there was no governance mechanism to detect the bypass and require remediation.

A multi-sig wallet governed by a policy that defines the quorum required, the transaction threshold at which it applies, the verification steps required before signing, and the process for rotating keys is a genuinely effective control. The same wallet configured by an engineer following a verbal agreement with no written policy, no defined quorum for different transaction types, and no process for key rotation is a security theatre: it looks like a control but does not reliably function as one under pressure.

This is why governance investment must precede or accompany technology investment, not follow it. Procuring expensive custody infrastructure without the governance framework to mandate its correct operation does not reduce risk proportionally to its cost. The governance framework is what makes the technology investment deliver its intended security outcome.

Building the Governance Foundation

For a Web3 firm starting from scratch, or seeking to bring informal governance arrangements into a formal structure, the sequence matters. Begin with accountability: designate a CISO or equivalent function with clear authority and reporting lines. Then establish the policy framework: draft the five core documents described above, get them approved at the appropriate authority level, and assign owners. Then build the oversight mechanisms: security committee, board reporting cadence, audit programme. Then connect technology controls to the governance framework: each control should be mandated by a specific policy, and the policy should define how compliance with the control is monitored and enforced.

Vendor relationships should be governed through the third-party risk policy from the outset. Vendor risk management is one of the most consistently under-developed governance areas in Web3, yet it represents a major attack surface: compromised development dependencies, malicious node providers, and insider threats at custody partners have all featured in significant incidents.

The governance framework should be treated as a living system, reviewed at least annually and updated whenever material changes occur: new product lines, new jurisdictions, new regulatory requirements, or lessons from security incidents. The review process itself is a governance activity, requiring defined ownership, a structured agenda, and documentation of decisions made.

The Investment Case for Security Governance

Security governance investment is frequently treated as overhead: a cost with no direct revenue return, justified primarily by compliance requirements or the residual fear of a high-profile breach. This framing underestimates the return on governance investment significantly.

Governance reduces the probability of incidents that carry catastrophic financial and reputational consequences. It improves insurability, as documented above in the context of crypto insurance underwriting. It reduces regulatory exposure under DORA and MiCA. It provides the audit trail that demonstrates due diligence in the event of litigation following an incident. It creates the conditions under which institutional capital, which requires evidence of governance maturity as a condition of investment, can be secured.

For a Web3 firm seeking institutional investment, exchange listings, or regulated operating licences, the security governance framework is not peripheral due diligence preparation. It is a core element of the value proposition: evidence that the organisation is built to operate at institutional standards, not just to launch a product.