Separation of duties (SoD) is one of the most powerful and most consistently underused operational controls in the crypto industry. It is also one of the cheapest: in its purest form, it costs nothing to implement and requires only deliberate role design and process discipline. Yet the absence of SoD underlies a striking proportion of the major losses the industry has suffered, from insider theft at centralised exchanges to sophisticated nation-state supply chain attacks that bypass multisig protections entirely.
This guide sets out what separation of duties means, why it matters specifically in Web3 environments, and how to implement it practically across treasury operations, smart contract governance, access management, and financial controls. Whether you are a five-person DeFi protocol or a regulated crypto asset firm preparing for DORA or ISO 27001 certification, the principles here apply directly to your operations.
What Is Separation of Duties?
Separation of duties is the principle that no single individual should be able to control an entire high-risk or irreversible process from initiation through to completion and recording. It is a check-and-balance control that distributes the critical steps in a sensitive operation across multiple people, ensuring that at least one independent person must be involved before any significant action can be finalised.
The concept originated in financial controls and internal audit practice, where it has been a cornerstone of fraud prevention and error detection for well over a century. The classic example is the accounts payable process: the person who raises a purchase order should not be the same person who approves the invoice, and neither should be the person who authorises the payment from the bank account. Remove any one of those separations and you create an opportunity for undetected fraud or error. The same logic applies in defence and government contexts, where dual-key controls for high-consequence actions (missile launch authorisations being the most well-known example) are a physical instantiation of SoD at its most critical.
The core principle is straightforward: the initiator of an action and the authoriser of that action should be different people. In higher-risk scenarios, you may require a third party to review and record the completed action independently. This creates three functional roles that should not be held simultaneously by one individual: initiation, authorisation, and recording.
SoD and Conflict of Interest vs Collusion Risk
There are two distinct failure modes that SoD is designed to address. The first is accidental conflict of interest, where a single person's dual role creates an unintended opportunity for error or biased decision-making. The second is deliberate collusion, where multiple individuals cooperate to circumvent controls. SoD does not eliminate collusion risk but it raises the threshold dramatically: to commit fraud or execute an unauthorised action, an attacker must now compromise or suborn at least two independent individuals simultaneously. This is significantly harder, more expensive, and more likely to leave detectable evidence.
SoD vs Least Privilege
Separation of duties is frequently confused with the principle of least privilege, but the two are distinct and complementary controls. Least privilege limits what any individual can access or do within a system, restricting permissions to the minimum required for a given role. SoD goes further: it distributes the steps of a high-risk process across multiple people so that no single person can complete the entire process alone, even if each individual's permissions are entirely appropriate for their role. You need both. A person with appropriately scoped least-privilege access can still commit fraud if they hold every step of a process end to end. SoD ensures that is not possible for your most sensitive operations.
Why Separation of Duties Is Critical in Web3
Web3 organisations face a cluster of structural factors that make separation of duties not merely good practice but a genuine survival requirement. Understanding those factors helps make the case internally for investing in SoD controls.
Irreversibility
Blockchain transactions are, in almost all circumstances, irreversible. Once funds leave a wallet, there is no chargeback mechanism, no bank fraud team to call, and no dispute resolution process that can recover assets. This means the cost of a SoD failure in crypto is categorically higher than in traditional finance, where compensating controls downstream can often recover losses or limit damage. In crypto, the last line of defence is preventing the transaction from being signed in the first place. That is precisely what SoD achieves.
Pseudonymous and Remote Teams
Many Web3 teams operate with fully remote structures, pseudonymous contributors, and distributed governance. This creates specific SoD challenges: it is harder to verify the independence of approvers, easier for a single person to hold multiple pseudonymous roles, and more difficult to maintain the kind of physical separation of responsibilities that traditional organisations rely on. It is also easier for an attacker to impersonate a team member or manufacture social pressure in a digital-only environment.
Small Team Sizes and the Concentration of Authority
The most common SoD failure pattern in early-stage Web3 companies is what might be called the "founder signs everything" failure. A founder or technical lead who initiates transactions, holds signing keys, manages access provisioning, deploys smart contracts, and reconciles balances is a single point of failure for the entire organisation. If that person is targeted by social engineering, if their device is compromised, or if they act in bad faith, no other control stands between the attacker and the treasury. SoD distributes that concentration of authority before it becomes a liability.
The Insider Threat Vector
Insider threats are consistently underweighted in Web3 security discussions, which tend to focus on smart contract exploits and external attackers. But a significant proportion of crypto losses, including some of the largest exchange failures, trace directly to insiders with unchecked unilateral authority. Separation of duties is the primary control against insider theft precisely because it removes the ability for any one person to act unilaterally on high-value operations.
Social Engineering and SoD
Lazarus Group and other sophisticated threat actors have repeatedly demonstrated that social engineering is frequently the most cost-effective attack vector against crypto firms. Their campaigns, including those targeting treasury staff and technical leads, succeed because a single targeted individual typically has sufficient authority to both approve and execute a transfer or configuration change. When SoD is enforced, an attacker must compromise two or more independent people simultaneously, which is dramatically harder. For a deeper analysis of how these attacks are structured, see our post on Lazarus Group crypto operational security and attack patterns.
"The Bybit hack succeeded not because multisig failed cryptographically, but because the signers were not independently verifying what they were signing. All signers relied on the same compromised interface, and there was no independent approver whose role was to verify the raw transaction before keys were applied. That is a separation of duties failure: the initiation and the authorisation of a catastrophic operation flowed through a single controlled channel."
The full technical breakdown of the Bybit incident is covered in our analysis of the $1.5bn Bybit hack and the operational failures behind the exploit. The lesson for SoD is clear: cryptographic controls are necessary but not sufficient. Organisational controls must sit alongside them.
Separation of Duties in Treasury Operations
Treasury is the highest-stakes domain for SoD in most crypto organisations. A well-structured treasury SoD framework separates four functional roles across as many individuals as your team size permits.
The Four Treasury Roles
- Initiator: The person who creates the transaction request, specifies the destination address, amount, and purpose, and submits it for approval. The Initiator should never be a sole signer.
- Approver: An independent person who reviews the transaction request against business purpose, verifies the destination address, checks the amount against approved thresholds, and provides written or recorded authorisation before any key is applied. The Approver should not be the Initiator of any routine payment.
- Signer: The keyholder who applies their private key signature to the transaction after receiving confirmed approval. In a multisig arrangement, there may be multiple Signers, but at least one Signer should not have been the Initiator.
- Recorder: The person responsible for matching every on-chain execution to an approved payment request, booking the corresponding journal entry, and maintaining the immutable audit log. The Recorder should not also be the Initiator or primary Approver.
Any arrangement in which the same individual holds two or more of these roles for a given transaction represents a segregation gap and should be treated as a control finding requiring remediation or a documented compensating control.
Dual Authorisation for Large Transfers
Dual authorisation requires that a minimum of two independent people must confirm a transaction before it proceeds. For high-value transfers, this means an Initiator submitting a formal payment request through a documented channel (not just a verbal instruction or an informal message), followed by an Approver who independently reviews and confirms the request in writing before any Signer applies a key. The approval must precede the signing, and the approval record must be retained.
Multisig Wallets as Technical SoD Controls
Multi-signature wallets implement a cryptographic threshold that can enforce SoD at the transaction layer. A 2-of-3 multisig requires two of three designated keyholders to sign before a transaction executes. A 3-of-5 arrangement requires three of five. However, multisig alone is not SoD: if the same person initiates every transaction and the other keyholders habitually co-sign without independent verification, you have cryptographic redundancy but not organisational separation. The organisational controls must sit alongside the cryptographic threshold.
Threshold Policies
A tiered threshold approach scales the approval burden with the risk level of the transaction. A common framework for a mid-sized crypto treasury might look like this:
- Under $10,000: Single authorised Initiator plus automated system check against whitelist. No additional human approval required, provided the destination is a whitelisted address.
- $10,000 to $250,000: Initiator plus one independent Approver (Treasury Manager or CFO). 2-of-3 multisig signing required.
- $250,000 to $1,000,000: Initiator plus CFO plus CISO or legal counsel approval. 3-of-5 multisig signing required.
- Above $1,000,000 or any cold wallet movement: Initiator plus board-level or two executive approvals, plus 3-of-5 multisig. Written resolution required before signing commences.
Time-Delayed Transactions
Time-lock mechanisms introduce a delay between a transaction being submitted and it being executable on-chain. This window allows an independent reviewer to identify and halt suspicious or erroneous transactions before they complete. For large treasury movements or governance actions, a 24-to-72 hour timelock provides a meaningful review window, particularly useful when Approvers are in different time zones or when a transaction has been initiated outside normal working hours.
Warm vs Cold Wallet Policies
Any transfer from cold to warm wallet storage, or from any vault tier to a hot wallet, should be treated as a high-consequence action requiring full SoD compliance. The threshold for triggering the highest level of approval controls should default to the cold wallet tier, regardless of the nominal transaction size.
SoD in Smart Contract Deployment and Upgrades
Smart contract deployment and upgrades are high-irreversibility, high-consequence operations that require the same SoD discipline as treasury transfers. The developer who writes the code should not be the sole person who deploys it to mainnet, and the person who holds deployer keys should not be the same person who authored the contract logic.
The Development, Review, and Deployment Pipeline
A sound SoD framework for smart contract deployment separates three stages: development, independent review and approval, and deployment execution. The developer writes and unit-tests the contract code. An independent reviewer, ideally an internal security engineer or external auditor, reviews the code and approves it for deployment. A separate deployer role, with access to the deployment keys, then executes the deployment. No single person should hold all three roles for a production deployment.
For teams too small to achieve full three-person separation, the minimum viable SoD is to separate the code author from the person who holds the deployment key. The author submits code for review, another team member reviews and approves, and the deployment key is held under a separate access control that the author cannot use unilaterally.
Multi-Sig Governance for Contract Upgrades
Upgradeable smart contracts are a governance risk that must be covered by SoD controls. The admin or upgrade key for a proxy contract should be held under a multisig arrangement rather than by a single EOA (externally owned account). Upgrade proposals should follow a documented change management process: proposal, independent technical review, approval by the multisig governance group, and a timelock before execution. No developer should be able to push an upgrade to a live contract without an independent approval step.
For a comprehensive framework on operational risk management across smart contract and infrastructure change management, see our guide to operational risk management for crypto firms.
Timelocks as Process Controls
Timelocks on contract upgrade functions serve both as a technical SoD mechanism and as a transparency control for protocol users. A 48-to-72 hour timelock between an upgrade being queued and being executable on-chain gives token holders, auditors, and counterparties an opportunity to review and respond to changes. It also creates a window during which the organisation's own internal reviewers can raise a flag if a change was not properly authorised.
Access Control to Deployer Keys
Deployer keys should be stored separately from developer workstations and from the keys used for day-to-day development operations. Access to deployer keys should require a separate approval step, should be time-limited for each use, and should generate an immutable audit log entry every time they are accessed. Hardware security modules (HSMs) or hardware wallets held under custodial separation are appropriate for mainnet deployer keys of any significant protocol.
SoD in Access Management and Provisioning
Access management is both a beneficiary of SoD and a domain where SoD itself must be applied. The person who grants access to a system should not be the same person who uses that access routinely, and the IAM administrator role should not be combined with high-privilege operational roles.
The "Admin of Admins" Problem
A common failure pattern is the concentration of IAM administration with one person who also holds broad operational privileges. This person can grant themselves access to any system, provision new accounts without oversight, and remove their own actions from audit logs. The IAM administrator role should be separated from operational roles, reviewed at least annually, and held by someone whose primary function is access governance rather than day-to-day operations.
Access Provisioning: Three-Person Control
For high-privilege access provisioning, a three-person control is best practice. The new employee or contractor submits a request (or their manager raises it). An independent authoriser, typically the line manager plus a security or compliance function, approves the access based on role requirements and least-privilege principles. The IAM administrator then implements the approved access. No single person should be able to both approve and implement their own access or the access of a direct report without a second review.
The same structure applies in reverse for offboarding. A confirmed departure triggers a formal offboarding request. An independent team member approves the deprovisioning action. The IAM administrator implements it. The risk of delayed or incomplete offboarding is directly proportional to the concentration of the offboarding decision in a single person.
For a detailed framework on privileged access management including PAM tooling and access review cycles, see our guide to privileged access management for crypto firms. For broader IAM governance including role design and access certification, see our post on identity and access management for crypto organisations.
Periodic Access Reviews
Access rights drift over time as people change roles, projects complete, and teams restructure. SoD in access management requires a scheduled review process, typically quarterly for high-privilege access and annually for standard access, to confirm that existing permissions remain appropriate and that no individual has accumulated combinations of access that constitute a segregation conflict. Any access rights that cannot be justified against the current role description should be revoked.
SoD in Financial and Accounting Controls
Financial controls in crypto organisations require the same SoD discipline as traditional finance, with the added complexity that the execution layer is on-chain and largely irreversible.
Payment Authorisation vs Payment Execution
The person who authorises a payment should be different from the person who executes it. In traditional banking, these roles are often separated by the banking platform's approval workflow. In crypto, you must engineer this separation deliberately through your internal processes and multisig configuration. An approver who reviews and approves a transaction should not themselves be able to then execute that transaction without a separate signer.
Invoice Verification vs Payment Release
For vendor payments, the person who verifies that a service was received or an invoice is legitimate should not be the same person who releases the payment. This separation prevents both invoice fraud and situations where an employee approves payments to fictitious or related-party vendors. For crypto firms making payments in digital assets, this verification step is particularly important given the irreversibility of the transaction once signed.
Exchange Account Management
Employees with access to exchange accounts for trading or treasury management should not also hold the authority to add new withdrawal addresses or modify account security settings. Separating the trading function from the account administration function reduces both insider theft risk and the impact of account compromise.
Accounting Records and Transaction Signing Authority
The person responsible for maintaining accounting records and booking journal entries should not also hold signing authority over the assets being recorded. This separation ensures that the accounting record reflects reality rather than whatever a single individual decides to record, and that discrepancies between on-chain activity and the books are visible to someone with the independence to escalate them.
Implementing SoD with a Small Team
The most common objection to separation of duties in early-stage Web3 firms is team size. "We only have five people" or "we cannot afford to involve three people in every transaction" are understandable concerns. The response is that SoD does not require a large organisation: it requires deliberate role assignment and documented process discipline.
SoD for a Five-Person Team
Consider a founding team of five: a CEO, CTO, CFO, a developer, and an operations lead. A workable SoD framework for this team might assign treasury initiation to the operations lead, treasury approval to the CFO, and signing authority distributed 2-of-3 across the CEO, CFO, and an independent board member or external signatory. Smart contract deployments are authored by the developer, reviewed by the CTO, and require both to sign off before the CTO executes deployment using keys the developer cannot access. Access provisioning requires the line manager to request, the CEO to approve, and the CTO to implement. This is not perfect three-way separation for every function, but it removes single-person unilateral control from every high-consequence operation.
Rotating Roles
Where team size genuinely prevents full separation, rotating responsibilities periodically creates a form of retrospective oversight. If the person who approves this month's transactions is different from the person who approved last month's, there is at least a periodic independent review of the activity. Rotation also reduces the risk of a single individual building unchecked familiarity with a process over time.
Board-Level and Advisory Oversight
For the highest-risk operations, board-level or advisory oversight can provide an SoD layer that does not require a large internal team. A board resolution requirement for transactions above a defined threshold, or a mandatory notification to an independent board member before a cold wallet movement, creates genuine independence without requiring additional full-time staff. Many institutional custodians also offer co-signing services that provide an external SoD layer for treasury operations.
External Auditors and Custodians
Engaging an external custodian for a portion of treasury holdings, or commissioning periodic independent access reviews and SoD audits, adds an external layer of separation that compensates for limitations in internal team size. This is particularly relevant for firms approaching DORA or ISO 27001 compliance, where auditors will look for evidence of genuine independence in high-risk process controls.
Documenting and Auditing SoD Controls
SoD controls that exist only in conversation or in an unreviewed policy document do not provide meaningful protection and will not satisfy external auditors. Documentation and periodic review are essential components of a functioning SoD framework.
The SoD Matrix
An SoD matrix is the foundational artefact for any SoD programme. It maps every sensitive function or process step to the roles or named individuals assigned to perform it, and identifies any combinations that represent a segregation conflict. The matrix should cover at minimum: treasury initiation, treasury approval, treasury signing, smart contract deployment, access provisioning, access approval, payment authorisation, payment execution, and financial recording.
For each function, the matrix should record who currently holds that role, whether any individual holds two conflicting roles, and where compensating controls have been documented for approved exceptions. The matrix must be updated at every personnel change and reviewed at least annually.
Conflict Identification and Remediation
Conflicts identified in the SoD matrix fall into two categories: toxic combinations, which must be separated immediately and cannot be accepted under any compensating control, and manageable overlaps, which can be accepted with documented compensating controls and exception authorisation. Toxic combinations include the same person both initiating and unilaterally authorising a high-value transfer, or the same person both requesting and granting their own elevated access. Manageable overlaps might include a small-team scenario where a developer and code reviewer are the same person for a low-value, low-risk deployment, provided independent post-deployment review is documented.
Audit Trail Requirements
Every high-risk action covered by your SoD framework should generate an immutable, timestamped audit trail record showing: who initiated the action, who approved it, when approval was granted, who executed it, and the relevant transaction or access change details. For on-chain activity, the blockchain itself provides part of this record. For off-chain approval steps, you need a separate immutable log, which may be a document management system, an audit trail in your treasury platform, or a signed email chain in a preserved archive.
Exception Handling
Not every SoD deviation can be eliminated immediately. Where temporary exceptions are required, they should be formally documented in an exception register, approved by senior management, time-limited, and subject to enhanced monitoring during the exception period. An exception that has been in place for more than three months without a remediation plan should be escalated for board visibility.
Annual SoD Review Programme
Once per year at minimum, the entire SoD framework should be reviewed from first principles: the matrix updated for any role changes, new processes added, the exception register reviewed for aged items, and the audit trail sampled to confirm that approvals are being properly documented in practice. This review should produce a written report presented to senior management.
Regulatory Requirements
Separation of duties is no longer merely a best practice recommendation: it is explicitly or implicitly required by the major regulatory frameworks affecting crypto firms operating in or towards European and international markets.
DORA (Digital Operational Resilience Act)
DORA's RTS on ICT risk management explicitly requires that financial entities implement segregation of duties when assigning ICT roles and responsibilities, to limit the risk of conflicts of interest. It further requires that changes to critical systems and infrastructure should not be requested, approved, and implemented by the same person. DORA applies to a broad range of financial entities including crypto asset service providers (CASPs) under MiCA. For a full breakdown of DORA obligations, see our guide to DORA compliance for crypto and digital asset firms.
MiCA Governance Requirements
MiCA requires crypto asset service providers to have robust governance arrangements including clear organisational structures with well-defined, transparent, and consistent lines of responsibility. Separation of duties between conflicting functions is a necessary element of demonstrating that governance structure to national competent authorities.
ISO 27001 Annex A.5.3 (Segregation of Duties)
ISO 27001:2022 Annex A Control 5.3 directly mandates the segregation of conflicting duties and areas of responsibility to reduce opportunities for unauthorised or unintentional modification or misuse of the organisation's assets. The control requires that organisations identify where conflicts exist, separate the relevant duties, and maintain evidence of that separation for audit purposes. Where full separation is not possible due to team size, the standard allows for compensating controls, provided they are documented and risk-assessed. For guidance on the full ISO 27001 certification pathway, see our post on ISO 27001 certification for crypto organisations.
SOC 2 Trust Services Criteria CC6.3
SOC 2 CC6.3 requires that entities authorise, modify, or remove access to data and systems giving consideration to the concepts of least privilege and segregation of duties. Auditors under CC6.3 will specifically look for evidence that the developer who writes code cannot deploy directly to production without review, that users cannot approve their own access, and that the person who processes transactions is not the same person who reconciles them. Role-based access control policies and documented SoD matrices are the primary evidence artefacts for this criterion.
Business Continuity and SoD
SoD frameworks must also account for business continuity scenarios where key individuals are unavailable. An SoD policy that relies on a single approver being available to sign off every transaction creates a continuity risk if that person is incapacitated or unreachable. Documented escalation paths and named deputy approvers for each SoD role are a necessary component of a resilient framework. For a comprehensive approach to business continuity planning, see our guide to business continuity planning for crypto firms.
Frequently Asked Questions
What is the minimum team size needed to implement separation of duties?
There is no minimum team size. Even a two-person founding team can implement meaningful separation of duties by ensuring that neither person can both initiate and unilaterally approve a high-value transaction. In practice, a team of three to five people is sufficient to implement robust SoD across treasury, access management, and smart contract deployment, provided roles are clearly assigned and written approval workflows are in place.
Does a multisig wallet automatically give you separation of duties?
No. A multisig wallet enforces a cryptographic threshold, not an organisational separation. If the same individual initiates every transaction and also holds a signing key, and the other signers routinely co-sign whatever is presented to them without independent verification, you have cryptographic redundancy but not genuine SoD. True separation requires that the person who initiates a transaction is different from at least one approver, and that approvers independently verify the transaction details before signing. The Bybit incident is a direct example of cryptographic multisig failing to substitute for proper organisational SoD.
How does separation of duties reduce social engineering risk?
Social engineering attacks, including those conducted by Lazarus Group, frequently succeed because one targeted individual has sufficient authority to both authorise and execute a transfer or configuration change. When SoD is enforced, an attacker must compromise two or more independent individuals simultaneously, which is dramatically harder. Even if one person is deceived, a separate approver with independent verification responsibilities creates a second line of defence that can catch and block the fraudulent action.
What is the difference between separation of duties and least privilege?
Least privilege restricts what any single individual can access or do, limiting permissions to the minimum required for a given role. Separation of duties goes further: it distributes the steps in a high-risk process across multiple individuals so that no single person can complete the entire process alone, even if their individual permissions are appropriate. Both controls are complementary and should be implemented together as part of a layered access control strategy.
What records do we need to maintain to demonstrate SoD compliance?
To satisfy auditors under ISO 27001, SOC 2, DORA, or internal governance requirements, you should maintain: a current SoD matrix mapping roles to functions and identifying any overlaps; approval and transaction logs with timestamps, initiator names, and approver names; access provisioning and deprovisioning records showing the request, approval, and implementation steps; an exception register documenting any approved departures from the SoD matrix; and records of periodic SoD reviews, at minimum annually.