Ownership should sit with the team that can enforce identity, entitlement, and evidence requirements across the full transaction path. If no single owner can explain how approvals, logs, and policy decisions connect, then the control layer is already fragmented. Accountability has to match the workflow, not the org chart.
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.
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 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Orchestration ownership determines who can enforce privilege boundaries across access workflows. |
| AU-2 — Event Logging | The owner must ensure approvals and policy decisions are logged as part of one workflow. | |
| IA-5 — Authenticator Management | Identity workflows often depend on credential lifecycle control across teams and platforms. | |
| Recommendation — Tie orchestration to least-privilege enforcement across request, approval, and entitlement change. Capture orchestration events in a single auditable record that links decisions to actions. Centralise control of credential issuance, rotation, and revocation in the orchestration path. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Cross-team orchestration is fundamentally about consistent access decisions and enforcement. |
| A.5.28 — Collection of evidence | The question explicitly depends on evidence continuity across compliance and platform workflows. | |
| Recommendation — Define one accountable owner for access decisions and their enforcement across teams. Ensure orchestration preserves evidence from approval through implementation and review. | ||
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.