Accountability should sit with the process owner, not the tool owner. When service desk workflows can change access or governance records, organisations need named owners for policy, approvals, audit evidence, and exception handling. That prevents shared responsibility from becoming no responsibility, especially in hybrid environments where multiple teams touch the same workflow.
Why This Matters for Security Teams
When service desk workflows can change access, asset status, or identity governance records, the issue is not just operational convenience. It becomes a control point for privilege, auditability, and incident response. If ownership is vague, teams can approve changes without clear policy authority, and the resulting record becomes difficult to trust during investigations, recertification, or compliance reviews. That is why current guidance in the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 both point toward explicit accountability, least privilege, and traceable control ownership.
NHIMG research shows why this matters in practice. In the Ultimate Guide to NHIs, 97% of NHIs carry excessive privileges and only 20% of organisations have formal offboarding and revocation processes, which means workflow mistakes can linger long after the ticket is closed. In hybrid environments, service desk teams often touch identities faster than governance teams can verify the change. In practice, many security teams discover the ownership gap only after a bad approval, a stale entitlement, or an audit exception has already spread across multiple systems.
How It Works in Practice
The practical model is simple: the process owner is accountable for the workflow outcome, while the tool owner is accountable for the platform that executes it. The process owner defines what can be changed, who can approve it, what evidence must be retained, and when an exception is allowed. The service desk, IAM, or ITSM platform may automate the transaction, but automation does not transfer accountability.
For identity governance, that means access changes should map to a named business or control owner, not just a queue or assignment group. For asset status changes, accountability should sit with the service management process that defines when a device is retired, reassigned, or quarantined. For NHI-related records, such as service accounts, API keys, or workflow-connected automation identities, the control owner must decide whether a request aligns with policy and whether the change should trigger review, rotation, or revocation.
- Define one accountable owner for each workflow that changes access or governance state.
- Require approval rules to reflect policy, not just convenience or team routing.
- Keep audit evidence tied to the workflow outcome, including requester, approver, timestamp, and justification.
- Separate platform administration from control ownership so tool operators cannot silently redefine policy.
For implementation depth, pair this with lifecycle and audit guidance in the Ultimate Guide to NHIs - Lifecycle Processes for Managing NHIs and control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls. These controls tend to break down when service desk teams are allowed to approve state changes across multiple downstream systems without a single owner for the policy decision.
Common Variations and Edge Cases
Tighter accountability often increases operational overhead, requiring organisations to balance speed against control fidelity. That tradeoff becomes sharper in shared services, where one workflow may update IAM, CMDB, EDR, and governance records at once. Current guidance suggests the accountable owner should still be singular, even if several teams contribute to execution, but there is no universal standard for this yet. Some organisations split responsibility by record type, while others assign a single service owner across the full workflow.
Edge cases matter. If a managed service provider operates the service desk, the provider may be responsible for execution quality, but the client organisation still needs an internal owner for policy, approvals, and exceptions. If a workflow changes NHI records, such as token scope or automation permissions, the accountable owner should be the team that understands the business purpose of the identity, not the team that merely runs the ticketing system. For broader lifecycle context, NHIMG recommends reviewing the Top 10 NHI Issues alongside the 52 NHI Breaches Analysis to see how governance gaps become operational failures.
The rule of thumb is clear: if a workflow can change access, asset status, or identity governance records, someone must be accountable for the policy outcome, not just the ticket closure. When that is missing, service desks become silent privilege brokers rather than controlled operations.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers lifecycle control and revocation governance for identity changes. |
| NIST CSF 2.0 | PR.AC-4 | Access approvals need traceable authority and least-privilege enforcement. |
| NIST SP 800-53 Rev 5 | AC-2 | Accountability for account management is central to service desk-driven access changes. |
| NIST AI RMF | Governance of automated decisions benefits from clear accountability and oversight. | |
| CSA MAESTRO | Agentic and automated operations need explicit control ownership and auditability. |
Assign an owner to each NHI-changing workflow and verify revocation, rotation, and audit evidence.
Related resources from NHI Mgmt Group
- Who is accountable for access governance when engineers request privileged database access through self-service workflows?
- Who should be accountable for access governance when enterprises use a partner to implement identity controls?
- Who should be accountable for cloud identity governance when both developers and non-human identities need access?
- How should security teams run access certifications inside IT service management workflows without losing governance rigor?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
