Compliance owns the evidence, fraud owns the abuse cases, and legal owns the licence obligations, but none of those functions can succeed alone. In a regime like New Zealand’s, accountability sits across the launch path, from who can approve the operator to who can verify customers and stop suspicious activity.
How accountability is split across compliance, fraud and legal
In a new licensing regime, those teams are not separate owners of separate problems. They are different stewards of the same control chain. Compliance typically holds the evidentiary record, fraud monitors misuse and suspicious behaviour, and legal interprets the licence conditions and approval boundaries. The practical question is whether the operating model makes those handoffs explicit enough to avoid gaps.
The cleanest way to think about it is by decision point. Who can launch, who can on-board, who can investigate, and who can stop activity when the regime is not being met? If those decisions sit in different teams without a shared process, the licence can be “owned” in theory while no one actually owns the moments that matter.
Accountability therefore works best when the regime is mapped to a small number of control points: approval before launch, customer verification, monitoring for suspicious activity, escalation for breaches, and evidence retention for review. Each function may contribute evidence or judgement, but the operating model has to show which team is accountable at each point and which team only supplies support.
Where each team’s responsibility starts and ends
Compliance is usually the custodian of proof. It should be able to show that the organisation can demonstrate adherence to the licence, including policies, records, attestation, and decision logs. That is different from owning every operational control. A weak model is one where compliance becomes the de facto process owner for everything simply because it has to defend the file later.
Fraud owns the abuse lens. That includes indicators of suspicious onboarding, patterns of misuse, and escalation when customer activity suggests the regime is being gamed. The team should be accountable for detection and case handling, but not for rewriting licence obligations or deciding legal interpretation. When that boundary is unclear, response slows and ownership of the actual abuse signal becomes contested.
Legal owns the meaning of the licence. It should interpret the obligations, conditions, exclusions, and approval thresholds, then translate those into operational requirements that the other teams can execute. Legal does not usually own the daily control operation, but it does own the question of what the regime requires when there is ambiguity, a breach risk, or a change in scope.
How the shared model works in practice
The strongest operating pattern is a single accountability map that follows the lifecycle from approval to monitoring. Legal defines the obligation, compliance turns it into auditable evidence, and fraud confirms that controls are working against real abuse patterns. That shared model should be visible in approval workflows, issue escalation paths, and reporting lines, not just in a policy document.
It also needs clear escalation triggers. If customer verification fails, fraud should escalate the case and compliance should preserve the record. If the licence language is unclear, legal should be pulled in before the business improvises. If suspicious activity suggests the regime is being bypassed, the question is no longer only operational, it becomes evidentiary and potentially legal. For customer onboarding and identity verification controls, Identity Proofing and KYC Guide is a useful reference point, and fraud-oriented operating models are strengthened by Identity Fraud Prevention Guide.
The other important pattern is ownership continuity. A regime launch often fails when everyone owns a fragment of the process but nobody owns the end-to-end outcome. That is why the accountability model should name one function as the business owner for the control chain, while the others remain clearly responsible for their specialist decisions. The answer is not to merge the teams, but to make the seams explicit.
Risk and Threat Considerations
The main risk is control drift: the organisation believes it is compliant because each team is doing its part, but no one is responsible for the complete path from licence obligation to operational enforcement. That creates gaps at onboarding, weak escalation, and inconsistent evidence when regulators or auditors ask how decisions were made.
Failure mechanism: Fragmented accountability lets legal interpret the regime, compliance document it, and fraud detect abuse, while no single owner ensures the controls are joined up. The result is a regime that looks covered on paper but fails at the points where approvals, verification and escalation need to operate together.
Impact: The business can admit customers it should not, miss suspicious activity, or be unable to prove that it acted properly after a breach or investigation. In a licensing environment, that can turn an operational weakness into an enforcement problem.
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 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 27001:2022 | A.5.31 — Legal, statutory, regulatory and contractual requirements | The regime hinges on interpreting licence obligations correctly. |
| A.5.37 — Documented operating procedures | Shared accountability depends on clear procedures across compliance, fraud and legal. | |
| Recommendation — Map licence duties to operational controls and retain evidence of compliance decisions. Document the handoffs, escalation points and approval steps for the licensing workflow. | ||
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | A new licensing regime needs clear ownership and accountability boundaries. |
| GV.RM-01 — Risk Management Strategy | Fraud, compliance and legal need a shared approach to regulatory and abuse risk. | |
| PR.AA-01 — Identities and Credentials Are Issued, Managed, Verified, Revoked, and Audited | The regime depends on knowing who can approve, verify and stop activity. | |
| Recommendation — Define which function owns each control outcome and how responsibilities connect. Align the three teams to one risk strategy for approvals, monitoring and escalation. Ensure approval and verification roles are assigned, auditable and revocable. | ||
Practitioner Guidance
What to verify: Build a control-to-owner map for the launch path, not just a RACI for the policy. For each step, verify who approves, who detects exceptions, who preserves evidence, and who has stop authority when the regime is breached or unclear.
Decision rule: If a task affects licence interpretation, legal owns the interpretation; if it affects abuse detection or customer misuse, fraud owns the case logic; if it affects demonstrable compliance, compliance owns the evidence trail. Do not let one function absorb the other two just because it is the last team to see the issue.
Practitioner takeaway: Shared accountability only works when each team owns a distinct part of the control chain and the handoffs are explicit enough that no decision, case, or record falls between functions.
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 do security, legal, and privacy teams share accountability for web archives?
- What happens when iGaming operators build trust and compliance controls without aligning legal, product, and fraud teams?