Who should be accountable for access decisions when requests span ITSM, HR, and collaboration tools?

Why This Matters for Security Teams

When access requests move across ITSM, HR, and collaboration tools, accountability can disappear into the workflow itself. The practical risk is not just delay, but misattribution: one system logs the request, another records the approver, and a third actually grants access. That creates weak audit trails, inconsistent enforcement, and an easy path for shadow approvals to become accepted practice. For NHI-heavy environments, this same pattern often appears in ticket-driven access to service accounts, API keys, and shared operational channels, where control gaps are harder to spot.

NHIMG’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which is why accountability must be explicit rather than inferred from tool ownership. The issue is not whether IT can route the request. It is whether the resource owner remains responsible for the decision and whether the governing process preserves that decision across systems. The OWASP Non-Human Identity Top 10 reinforces the same point: identity governance fails when control is fragmented across platforms instead of anchored to a clear authority. In practice, many security teams encounter weak approvals only after an audit, incident, or access dispute has already exposed the gap.

How It Works in Practice

The most defensible model is a split between workflow orchestration and decision ownership. ITSM can collect the request, check completeness, and route it. HR can validate employment status, role changes, and joiner-mover-leaver context. Collaboration tools can carry notifications and evidence. But the approval authority must remain tied to the resource owner or delegated approver who is accountable for that specific asset, role, or data domain.

That means the process should record four things consistently: who requested access, who approved it, what resource or entitlement was approved, and which policy justified the decision. If the request spans systems, the governing record should be system-independent, so the approval remains valid even if the ticket is copied into a chat thread or mirrored into a separate platform. NIST SP 800-53 Rev. 5 supports this style of traceability through access enforcement, audit logging, and least privilege controls. Current guidance suggests the approval should be evaluated once, at the authoritative control point, rather than re-decided differently in each tool.

• Use one source of truth for the approval decision, even if multiple systems handle the workflow.
• Map each resource to a named owner, not a generic queue or shared mailbox.
• Synchronize HR events with access reviews so role changes trigger revalidation.
• Preserve decision metadata in every downstream system to prevent conflicting records.
• Require exception handling for emergency access so the approver is still accountable after the fact.

This is especially important for secrets and non-human access. NHIMG’s Ultimate Guide to NHIs - Key Challenges and Risks shows that NHIs are often overprivileged and poorly governed, which makes cross-tool approvals particularly dangerous when the request involves API keys, service accounts, or shared operational tooling. These controls tend to break down when one system can grant access before the authoritative approver has signed off, because the audit trail no longer reflects a single accountable decision.

Common Variations and Edge Cases

Tighter approval routing often increases operational overhead, requiring organisations to balance speed against governance. That tradeoff becomes visible in urgent requests, matrixed organisations, and cases where HR, IT, and business ownership overlap. Current guidance suggests that there is no universal standard for every scenario, but accountability should always land with the party that owns the risk of the access, not the party that forwarded the request.

One common edge case is delegated approval. A manager or process owner may approve on behalf of the resource owner, but delegation must be explicit, time-bound, and recorded. Another is joiner-mover-leaver automation, where HR events can trigger access changes without a fresh ticket. That can be efficient, but the policy owner still needs a clear decision model for what is auto-approved versus what requires human review. For collaboration platforms, the risk is often informal approval in chat. NHIMG’s State of Secrets Sprawl 2025 highlights how collaboration and project management tools already carry critical exposure, so governance should not treat them as harmless side channels. The right question is not which tool logged the request first, but which accountable owner can justify the access if challenged later.

Related resources from NHI Mgmt Group

• Who should be accountable for enforcing context based access decisions across internal systems and third party tools?
• How should security teams handle access requests through collaboration tools without losing approval rigor?
• Why does privileged access become harder to control as organisations adopt more cloud and collaboration tools?
• Who should be accountable for approving access requests in a policy-driven model?