Accountability usually sits with the protocol operator, the compliance owner, and any integration team responsible for the control design and oversight. Regulators and business partners will expect documented policies, testing, exception handling, and evidence that the control operated as intended. Shared infrastructure does not remove the need for clear ownership and audit trails.
Why This Matters for Security Teams
A failed blockchain compliance control is not just a technical miss. It can become an audit, legal, and partner trust issue when a prohibited transaction slips through because the control owner could not prove what was checked, when it was checked, or why it passed. That is why accountability must be explicit across policy, operations, and integration, as reflected in the NIST Cybersecurity Framework 2.0 and the control expectations in ISO/IEC 27001:2022 Information Security Management. For NHI programs, the same problem appears when access logic exists but governance does not, which is why NHIMG’s Top 10 NHI Issues and Ultimate Guide to NHIs — Regulatory and Audit Perspectives emphasise ownership, evidence, and lifecycle discipline. The hard part is not naming a control, but proving it was effective under real operating conditions. In practice, many security teams discover the accountability gap only after a failed review, not during design or testing.
How It Works in Practice
Accountability usually follows the control chain, not a single system component. The protocol operator owns the runtime environment and the transaction policy enforcement point. The compliance owner defines what is prohibited, how exceptions are handled, and what evidence must be retained. The integration team is accountable for embedding the control correctly, including test coverage, logging, and fail-closed behaviour. If a control depends on upstream identity, sanctions, or wallet-risk signals, those dependencies must also be documented because a downstream false negative often starts with bad input rather than a bad decision engine.
In practice, teams should separate policy, enforcement, and assurance:
- Policy defines the prohibited transaction types, thresholds, and exemptions.
- Enforcement checks each transaction at runtime and records the decision path.
- Assurance validates that the control is working through tests, monitoring, and periodic review.
For implementation, current guidance suggests treating the decision engine like any other high-risk control plane. That means immutable logs, named control owners, exception approvals, and recurring evidence collection aligned to frameworks such as NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls. NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here because the same lifecycle logic applies to automated controls: define, issue, monitor, rotate, and retire. These controls tend to break down when enforcement is delegated across multiple vendors because no single party can reconstruct the full decision trail.
Common Variations and Edge Cases
Tighter compliance control often increases operational overhead, requiring organisations to balance stronger prevention against latency, false positives, and exception handling burden. That tradeoff is especially visible on blockchains, where transaction finality, cross-chain routing, and smart-contract automation can make “block” decisions expensive or impossible to reverse. Best practice is evolving, but there is no universal standard for this yet on how much decision authority should sit on-chain versus off-chain, especially when regulated entities, custodians, and middleware providers all touch the same flow.
Edge cases usually center on ambiguous ownership:
- If the control is outsourced, the provider may operate the mechanism, but the regulated business still owns the risk.
- If a smart contract enforces the rule, developers may own the implementation while compliance owns the policy.
- If monitoring only alerts rather than blocks, the accountable party must prove who reviews alerts and how fast.
- If an exception is approved, the approver becomes part of the audit trail and may share accountability.
NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks is a useful reference for this kind of distributed control failure, where fragmented ownership creates blind spots. The operational lesson is simple: if no one can show the control design, tests, and override path, then accountability was never actually assigned.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 | Accountability requires explicit governance, ownership, and risk ownership. |
| NIST SP 800-53 Rev 5 | AU-2 | Failed detection must be traceable through logs and audit evidence. |
| OWASP Non-Human Identity Top 10 | NHI-05 | Non-human control failures often stem from weak ownership and lifecycle oversight. |
| CSA MAESTRO | GOV-2 | Agentic control governance depends on clear responsibility across actors. |
| NIST AI RMF | AI risk governance applies when automated decisioning may miss prohibited activity. |
Assign named control owners and review their evidence against governance requirements on a fixed cadence.
Related resources from NHI Mgmt Group
- Who is accountable when a crypto platform fails to detect illicit wallet risk before a transaction goes on-chain?
- Who is accountable when Travel Rule compliance fails in a digital asset transfer workflow?
- Who is accountable when a tokenized asset platform fails to detect fraud or suspicious activity in customer transactions?
- Who is accountable when a customer verification workflow fails to detect synthetic or duplicate accounts?
