Identity governance should own who can access, approve, or override compliance workflows, while financial crime teams should own the policy logic and case outcomes. The critical point is that both functions need shared evidence standards. If access rights are not controlled and logged, the compliance decision chain becomes hard to trust or audit.
How to split ownership without splitting accountability
Organisations should separate policy authority from access authority. Identity governance should control who may approve, override, or administer the workflow, while financial crime teams should own the decision logic, escalation criteria, and case disposition rules. That division works only when both teams rely on the same evidence trail and the same audit standard for decisions and exceptions.
The practical test is whether each team owns the part of the process it is best placed to judge. Identity governance is accountable for access, segregation of duties, and reviewer integrity. Financial crime teams are accountable for fraud, AML, sanctions, and suspicious activity logic. If one team starts redefining the other team’s decision model, the control boundary becomes blurred and review quality drops.
What each team should own in the operating model
Identity governance should manage access to the workflow itself, including request, approve, recertify, and override permissions. It should also control who can change roles, entitlements, and approver assignments, because those are access and governance decisions. Financial crime should own the business policy that determines what constitutes a hold, escalation, alert disposition, or exception.
That split avoids a common failure mode: letting investigators or compliance analysts directly administer the identity layer just because they use the workflow every day. The reverse is also risky, because identity teams should not be the ones deciding what suspicious activity looks like, or when a case can be closed. IAM and IGA Basics is useful here because it distinguishes governance of access from the business rules that sit behind the process.
Where workflow rules, approvals, and case dispositions interact, separate “who can do it” from “what outcome is allowed.” That gives you a clean model for ownership, testing, and escalation, especially when the process spans multiple systems or teams.
How shared evidence standards keep the process auditable
Both functions need the same minimum evidence standard for approvals, overrides, and closed cases. The evidence should show who acted, what data was reviewed, what rule or policy was applied, and why the decision was taken. Without that, you can have a correct outcome that is still impossible to defend in audit or investigation.
This is where access reviews, role design, and segregation of duties become operationally important, not just theoretical. Reviewers should not be able to certify their own access path, and approvers should not be able to silently rewrite the evidence basis for a case. Access Reviews and Certification Guide and Segregation of Duties (SoD) Guide both support that control pattern.
In practice, the strongest design is one where identity governance protects the decision trail and financial crime protects the decision content. If either side can edit the other side’s core evidence without traceability, trust in the process weakens quickly.
Why cross-functional ownership fails when the boundary is vague
Risk appears when teams treat the workflow as a shared service with no clear control owner. Then approvals become rubber-stamped, overrides become informal, and disputes over case outcomes are resolved after the fact rather than through a defined governance path. That is especially dangerous when access changes can influence fraud monitoring, sanctions screening, or investigations.
Another failure mode is policy drift. If financial crime teams change logic without identity governance review, you can end up with approvals that no longer match the current process. If identity governance changes access without the financial crime team validating workflow impact, reviewers may retain rights that no longer fit the control model. Financial Services Identity Security Guide is relevant because it ties identity controls to regulated financial processes.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CSA Cloud Controls Matrix and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | Covers ownership, approvals, and access governance in a controlled workflow |
| Recommendation — Assign workflow access and approval rights under IAM ownership and enforce least privilege. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Limits who can approve, override, or administer the compliance workflow |
| AU-2 — Audit Events | Supports a shared evidence trail for approvals, overrides, and case outcomes | |
| AU-12 — Audit Record Generation | Ensures the workflow produces records needed to trust and reconstruct decisions | |
| Recommendation — Restrict workflow administration to the minimum set of authorized roles. Log approvals, overrides, policy changes, and case dispositions as auditable events. Generate complete audit records for access and case actions. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Separates who may access or administer the workflow from the policy owners |
| Recommendation — Define and enforce access rules for workflow administration and review. | ||
Practitioner Guidance
What to verify: Verify that each workflow step has one named control owner, one evidence standard, and one change path. If a team can approve its own privileges or alter case logic without review, the operating model is too loose.
Decision rule: If the issue is access, approval authority, reviewer integrity, or logging, route it to identity governance. If the issue is policy logic, alert handling, or case outcome, route it to financial crime. If both are affected, require joint sign-off but preserve separate ownership of the two decision types.
What good looks like: The system can show who approved access, who changed policy, who overrode a decision, and what evidence supported each step. That is the minimum for a defensible control chain, not an optional reporting feature.
Practitioner takeaway: The goal is not shared control, it is clear control boundaries with shared evidence. When ownership is split cleanly, you reduce both privilege risk and audit ambiguity.
Related resources from NHI Mgmt Group
- How should organisations divide responsibility between internal teams and outside experts during a breach?
- How should identity teams divide responsibility between Entra ID and a phishing-resistant assurance layer?
- What is the difference between attack surface management and NHI governance?
- Why is it important to integrate identity and data governance?