Accountability usually falls on the parties that actually design, govern, market, or operate the protocol, even if the system presents itself as decentralised. Regulators will focus on where decisions are made and who can influence user outcomes. Organisations should document control ownership early, because unclear governance can become a compliance and enforcement risk.
Why This Matters for Security Teams
When a DeFi protocol sits in a grey area under EU rules, the first mistake is assuming decentralisation removes accountability. It usually does not. Regulators and investigators look for the people or entities that designed the protocol, control upgrades, set parameters, market the product, or profit from operation. That means governance decisions, not branding, determine exposure.
For security and compliance teams, the practical problem is evidence: who can change code, pause the system, list assets, redirect fees, or influence user flows? Those control points become the accountability map. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it frames ownership, monitoring, and change control as operational duties rather than legal abstractions. NHIMG’s research shows how often weak identity governance becomes a real-world risk: the Ultimate Guide to NHIs notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
In practice, many teams only discover where accountability sits after an exchange listing review, a token incident, or a regulator asks who had effective control.
How It Works in Practice
Accountability in grey-area DeFi usually follows effective control, not the project’s public narrative. The question is less “Is this decentralised?” and more “Who can make decisions that change user outcomes?” In operational terms, that includes the developers who can push upgrades, the multisig signers who can approve changes, the foundation that funds and directs the roadmap, and the marketing entity that solicits users.
A useful way to assess responsibility is to map control layers:
-
Protocol governance: who proposes, votes on, and executes changes.
-
Administrative control: who can pause, upgrade, or reroute assets.
-
Economic influence: who captures fees, incentives, or treasury value.
-
User-facing representation: who markets the protocol and makes promises to users.
-
Operational custody: who holds keys, administers front ends, or maintains infrastructure.
That mapping should be supported by artifacts: decision logs, role matrices, code ownership records, treasury controls, and incident playbooks. The goal is to show where authority exists at the time a decision is made. NHIMG’s Schneider Electric credentials breach is a reminder that control failures often begin with access paths that were assumed to be harmless until they were abused.
For EU-facing risk teams, current guidance suggests documenting these control points before enforcement or a dispute, because once a protocol is in market, a post hoc decentralisation claim is rarely enough on its own. These controls tend to break down when governance is spread across anonymous contributors and informal multisig arrangements because effective authority becomes hard to prove or disprove.
Common Variations and Edge Cases
Tighter accountability mapping often increases legal and operational overhead, requiring organisations to balance decentralisation claims against documentation, controls, and disclosure duties. That tradeoff is unavoidable in borderline DeFi structures.
There is no universal standard for this yet, but best practice is evolving toward substance-over-form analysis. A protocol may be “decentralised” in code while still having a clearly accountable operator in practice. That is especially true where a foundation funds development, a core team can ship upgrades, or a single front end channels most users into the same contracts.
Edge cases include DAO-style governance with broad token holder voting, partially immutable systems, and protocols that rely on third-party interfaces. In those models, accountability may be shared, but not dissolved. The more an organisation can influence design, promotion, access, or remediation, the harder it is to argue that no responsible party exists. Current guidance suggests preserving evidence of who controlled what, when, and under which authority, because liability questions often turn on time-bound influence rather than formal labels.
For teams building internal positions, it helps to separate protocol risk from entity risk. The protocol may not have a legal personhood problem, but the foundation, developer group, or commercial operator might. In grey-area cases, the safest assumption is that anyone with meaningful control should expect scrutiny.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the technical controls, while NIS2 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 | Grey-area DeFi accountability depends on identifying who has effective control. |
| NIST SP 800-63 | Identity proofing matters when deciding which parties truly control protocol actions. | |
| NIST Zero Trust (SP 800-207) | PR.AC | Control attribution is clearer when administrative access is least privilege and monitored. |
| NIST AI RMF | GOVERN | Accountability in ambiguous environments requires explicit governance ownership. |
| NIS2 | EU risk regimes focus on accountable entities, not just code architecture. |
Map the real operators, approvers, and beneficiaries before assigning governance ownership.
Related resources from NHI Mgmt Group
- Who is accountable for keeping sensitive investigations private under privacy and governance rules?
- Who is accountable when agentic AI standards and conferences move under a neutral foundation model?
- Who is accountable for security and compliance when teams operate under wartime or emergency conditions?
- Who is accountable when SAP HANA access rules drift away from business policy?
