Who is accountable when custom identity workflows span multiple teams and business processes?

Why This Matters for Security Teams

When custom identity workflows span business units, application teams, and identity operations, accountability often becomes blurred at the exact point where failures become exploitable. The risk is not just administrative drift. It is mis-scoped approvals, delayed revocation, incomplete testing, and exceptions that quietly outlive the business need. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, which makes ownership clarity a control, not a courtesy, and the Ultimate Guide to NHIs highlights how often visibility gaps coexist with excessive privilege. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces that access control must have explicit accountability, because controls only work when someone can be held responsible for their design and operation. In practice, many security teams discover ownership gaps only after an access request is approved incorrectly or a workflow breaks during an audit.

How It Works in Practice

Accountability should be assigned by decision point, not by the fact that a workflow is shared. Identity governance owns the overall control model, but each business owner and technical owner is accountable for the accuracy of the rules they define, the exceptions they approve, and the systems they operate. That means the people who define who should get access are not necessarily the same people who implement the integration, but both must be named and measurable.

A practical operating model usually separates responsibilities into a few layers:

• Governance defines policy, risk tolerance, and review cadence.
• Business owners certify that access rules match business need.
• Technical owners validate workflow logic, connectors, and downstream enforcement.
• Security or IAM teams monitor exceptions, logging, and control effectiveness.

This distinction matters because custom workflows often cross systems that do not fail together. A request may be approved in one tool, provisioned in another, and logged somewhere else entirely. The workflow is only accountable if there is a named owner for each transition. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is a useful reference for thinking about lifecycle control as a repeatable responsibility, not a one-time setup task. For implementation discipline, the NIST SP 800-53 Rev 5 Security and Privacy Controls provides a baseline for access governance, review, and auditability.

Strong teams also define how failures are traced. If a request is approved incorrectly, the question should resolve quickly to whether the business rule was wrong, the technical mapping was wrong, or the exception process was abused. That is the difference between shared process participation and true accountability. These controls tend to break down when workflow ownership is split across outsourced integrators and internal teams because no single party owns end-to-end rule accuracy.

Common Variations and Edge Cases

Tighter ownership mapping often increases coordination overhead, requiring organisations to balance clear accountability against the speed benefits of shared workflows. That tradeoff is real, especially in federated enterprises, merger environments, and platform teams that support many applications. Best practice is evolving, but current guidance suggests that a single process owner should not be confused with a single approver. Multiple teams can participate, yet each control point still needs an explicit owner.

Edge cases usually appear where workflows are generated dynamically, where one team builds the form and another team owns the approval logic, or where access decisions depend on external data such as job role, project status, or contract state. In those cases, accountability should follow the rule source, not the user interface. If a rule changes because a business process changes, the business owner must be accountable for the new rule. If a connector fails and access is mis-provisioned, the technical owner must own the failure path. NHIMG’s Top 10 NHI Issues shows how operational gaps often concentrate in the places where ownership is least explicit, while the 52 NHI Breaches Analysis is a reminder that weak process ownership routinely becomes a security issue rather than just a process defect.

When accountability is genuinely unclear, the right answer is not to merge all responsibility into IAM. It is to document decision ownership, establish named backups, and make exception handling auditable so that every workflow step can be traced to a specific decision maker.

Related resources from NHI Mgmt Group

• Who is accountable for CMMC readiness when machine identity controls span multiple teams?
• Who is accountable for identity governance outcomes when a global rollout spans multiple regions and teams?
• How should teams govern localization and notification changes in enterprise identity workflows?
• Who should be accountable for workload identity security across platform, identity, and security teams?