Compliance should define the regulatory obligations, evidence requirements, and reporting thresholds, while security should prove that identity management, access control, and resilience mechanisms can satisfy them in practice. The shared responsibility is to make the controls auditable, repeatable, and tied to the specific services the firm offers.
Split the work by obligation, not by department
Crypto regulation works best when compliance owns the interpretation layer and security owns the control layer. Compliance translates statutes, supervisory guidance, and contractual obligations into clear requirements, such as what must be proven, how often it must be reviewed, and what evidence must exist. Security then implements the mechanisms that make those obligations real in production.
The practical test is whether the firm can show that the control exists, works consistently, and maps to the specific service or product scope the regulation covers. That means the teams need shared definitions for control ownership, evidence quality, and escalation thresholds, otherwise one team will treat a requirement as policy and the other as an engineering problem.
Why access, identity, and resilience are the shared proof points
Most crypto regulation is not satisfied by policy language alone. It becomes audit-ready only when identity management, access control, logging, segregation, and operational resilience are demonstrably tied to the regulated activity. For security teams, the key question is whether the system can enforce the approved access model and maintain traceable control over who or what can move funds, approve changes, or trigger sensitive workflows.
That is why evidence has to be concrete: access reviews, privileged account inventories, resilient recovery procedures, and records that show controls are operating over time, not just designed on paper. ISO/IEC 27001:2022 Information Security Management is useful here because it anchors the idea that access control, authentication, and cryptographic protection belong inside an auditable management system, not as isolated technical fixes.
For firms handling payments, custody, or exchange activity, PCI DSS v4.0 shows how access restriction, account governance, and interactive-use limits turn compliance requirements into operational controls. The same pattern applies across crypto regulation: the rule is rarely “have a policy”, it is “prove the service is constrained, monitored, and recoverable.”
Make evidence reusable across compliance, audit, and incident response
The most effective responsibility split is to treat evidence as a shared product. Compliance should define the evidence pack needed for each obligation, while security should design control output that can be collected repeatedly without manual reconstruction. If every audit request requires a one-off scramble, the control is probably not mature enough for regulatory scrutiny.
Shared evidence should be tied to named services, environments, and actor types. That includes which identities can initiate transfers, which systems hold privileged access, how secrets are rotated, how exceptions are approved, and what operational fallback exists if a critical control fails. NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful reference for structuring those expectations around access control, identification and authentication, auditability, and configuration discipline.
If the regulatory environment involves cloud services, external infrastructure, or shared platforms, CSA Cloud Controls Matrix is a practical mapping aid because it helps separate what the provider must evidence from what the firm must prove in its own governance chain. That distinction matters when compliance asks who is accountable for the control and security asks who can actually operate it.
Risk and Threat Considerations
The main risk is a split-brain control model, where compliance believes a requirement is covered and security believes the implementation is “close enough.” In crypto regulation, that gap can lead to failed audits, weak accountability over sensitive operations, and undetected privilege paths that undermine resilience or asset protection.
Failure mechanism: A control may exist in policy or tooling, but if access rights, key management, exception handling, or service scoping are not aligned, the organisation cannot prove that the regulated workflow is consistently constrained. That creates exposure when a reviewer asks for evidence of effective control rather than intent.
Impact: The firm may face regulatory findings, delayed approvals, increased remediation cost, and higher operational risk if privileged access or recovery processes are not demonstrably controlled. In the worst case, the same gap that breaks auditability also enlarges the blast radius of a compromised identity, misconfigured privilege, or failed recovery event.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 27001:2022 | A.5.15 — Access Control | Crypto regulation evidence depends on controlled access to regulated services and data. |
| Recommendation — Map regulated service access to A.5.15 and retain auditable access rules and reviews. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Regulatory control proof often hinges on restricting who can approve or move value. |
| AU-6 — Audit Review, Analysis, and Reporting | Shared responsibility requires evidence that controls are operating and reviewable. | |
| Recommendation — Apply AC-6 to restrict privileged actions to the minimum required set of identities. Use AU-6 to produce reviewable logs and reports for regulated control evidence. | ||
| CIS Controls v8 | CIS-5 — Account Management | Compliance and security must jointly govern accounts, roles, and access paths in scope. |
| Recommendation — Enforce CIS-5 to inventory, review, and remove unnecessary accounts and access paths. | ||
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | The question is about allocating accountability across compliance and security functions. |
| Recommendation — Define a shared risk strategy that assigns control ownership, evidence ownership, and escalation. | ||
Practitioner Guidance
What to prioritise: Define one control owner for each regulated obligation, one evidence owner for each control output, and one service owner for each production system in scope. If any requirement cannot be traced to a named service and a named evidence artefact, the control is still too abstract for audit use.
What to verify: Check that the evidence set proves both implementation and operation, for example access review records, privileged account scope, exception approvals, recovery test results, and change history. Do not accept screenshots or policy statements as the primary proof if the regulation expects repeatable operating evidence.
Decision rule: If the requirement affects who can act, who can approve, or how fast the firm must recover, security should own the control mechanics and compliance should own the obligation statement and reporting threshold. If the requirement only describes disclosure or filing, compliance leads and security supplies the substantiating control data.
Practitioner takeaway: The cleanest division of labour is compliance for meaning and reporting, security for enforceable reality, with both teams agreeing on the exact service boundary that the control must protect.
Related resources from NHI Mgmt Group
- How should security teams govern non-human identities for compliance?
- How should security teams govern non-human identities for SOC 2 compliance?
- How should security and compliance teams share responsibility for CSRD evidence?
- Who should own ISO 27001 compliance when security, GRC, and cloud teams all share responsibility?