Who should own orchestration when identities cross business, compliance, and platform teams?

Who should own orchestration when identity spans business, compliance, and platform operations?

Orchestration should be owned by the team that can make identity decisions, entitlement decisions, and evidence decisions stick across the full workflow, not by the team that only runs one hop of it. When approvals, logs, policy checks, and exception handling live in different places, the control plane becomes fragmented. The right owner is the one accountable for the transaction path end to end.

What the owner has to control, not just coordinate

Cross-team orchestration is more than ticket routing or workflow tooling. It has to define who can request access, who can approve it, what policy data the decision uses, what evidence is retained, and how revocation or review feeds back into the same path. If the owner cannot explain those links without handoffs, the operating model is too split to be reliable.

This is why orchestration ownership should follow the workflow that changes privilege, not the org chart that happens to host the platform. Business teams may know the process, compliance teams may define the evidence, and platform teams may operate the controls, but the owner must be able to bind those pieces into a single decision chain. That is especially true where IGA evaluation is about lifecycle, reviews, roles and access governance, not just system administration.

A useful test is whether the owner can answer three questions: who is allowed to approve, what proof is required, and what happens when the answer changes after the fact. If any one of those sits outside the orchestration boundary, the team is not really owning orchestration, only operating a tool. The same principle appears in identity security programme design, where RACI and governance only work when ownership is tied to the operating model, not a silo.

For organisations trying to reduce fragmentation, the best default is a central identity or access governance function with explicit participation from business approvers, compliance reviewers, and platform operators. That central owner should not replace domain accountability, but it should own the orchestration logic, decision records, and escalation path. If the model is truly distributed, then the ownership boundary still needs one accountable coordinator.

Where orchestration breaks when ownership is unclear

Most failures are not technical outages, they are ownership gaps. The process still “runs,” but policy drift, stale approvals, missing evidence, and disconnected logs make it impossible to prove who authorized what and why. That becomes a control failure when the workflow can create or extend access without a single party being able to reconcile the full record.

The biggest exposure is split accountability. Business teams may assume compliance owns the evidence, compliance may assume the platform captures it, and the platform may assume the business owns the decision. In that gap, exceptions linger, approvals age out, and revocation does not close the loop. A practical governance framework helps here, especially where identity control mapping must satisfy multiple regulatory and audit expectations at once.

At scale, the risk is not just one bad decision, it is repeated inconsistency. Once different teams use different approval thresholds or evidence standards, the organisation loses comparability and cannot demonstrate control effectiveness. That is where orchestration ownership shifts from convenience to accountability, because the owner must be able to enforce one policy interpretation across many requests.

Practitioner Guidance

What to prioritise: Assign orchestration to the team that can own the decision record, not merely the workflow engine. If a team cannot enforce approvals, logging, policy evaluation, and exception handling together, it should not be the final owner.

What to verify: Confirm that one owner can show the full chain from request to approval to entitlement change to evidence retention to review or revocation. If any step is outside that owner’s control, document the handoff and treat it as a control dependency, not a finished operating model.

Common mistake: Treating orchestration as a platform implementation detail. That usually leaves compliance with the evidence burden, business with the approval burden, and platform with the technical burden, but nobody with end-to-end accountability.

Practitioner takeaway: The best owner is the one closest to the control outcome, not the one closest to the tooling. Orchestration is sound only when one party can prove that policy, approval, and evidence remain connected throughout the full transaction path.

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 teams govern non-human identities at scale?
• How should security teams govern non-human identities in Salesforce?