Who should be accountable when a device action or onboarding workflow needs a manual exception?

Accountability should sit with the team that owns the control and the workflow outcome, not with the requester alone. Manual exceptions need assigned owners, documented approval paths, and a clear audit trail so the organisation can prove why the exception existed, who approved it, and when it was resolved.

Why This Matters for Security Teams

Manual exceptions are not a paperwork issue. They are a control decision that temporarily changes who is allowed to do what, under what conditions, and for how long. If accountability sits only with the requester, the organisation loses the ability to prove that the exception was risk-accepted by the control owner, reviewed by the right approver, and removed on time. That creates gaps in auditability, escalation, and incident response.

This is especially important where device actions or onboarding workflows can trigger downstream access, privileged enrollment, or policy bypass. NHI Management Group notes that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which shows how often lifecycle controls fail once exceptions become routine, not exceptional. The baseline controls expected by NIST SP 800-53 Rev 5 Security and Privacy Controls reinforce the need for defined approval, accountability, and evidence handling around changes to control operation.

In practice, many security teams discover exception drift only after a review, an audit finding, or a failed deprovisioning event has already exposed the gap.

How It Works in Practice

The accountable party should be the team that owns the control and understands the operational risk of overriding it. For device actions, that is often the endpoint, platform, or IAM control owner. For onboarding workflows, it may be the identity, provisioning, or application owner. The requester can raise the exception, but they should not be the sole decision-maker because they do not own the control outcome.

A defensible exception process usually includes four elements:

• A named control owner who can approve or reject the exception based on business need and risk.
• A documented approver path, often requiring separation between requester, approver, and implementer.
• A time-bounded exception with explicit expiry, review date, and compensating controls.
• An audit trail that records who requested it, who approved it, what was bypassed, and when it was closed.

That pattern aligns with the lifecycle discipline discussed in Ultimate Guide to NHIs, especially where exceptions touch provisioning, offboarding, or secrets handling. It is also consistent with the control discipline seen in the GitHub Action tj-actions Supply Chain Attack, where weak workflow trust boundaries amplified credential exposure. In practice, good teams attach exceptions to a ticket, require a named risk owner, and revoke the exception automatically when the stated condition ends.

Where possible, the exception should also be mapped to a compensating control such as additional logging, tighter TTLs, or a narrower scope of action. These controls tend to break down when exceptions are approved informally in chat, because no system of record exists to prove who accepted the risk or whether the exception was later removed.

Common Variations and Edge Cases

Tighter exception governance often increases operational friction, requiring organisations to balance speed against accountability. That tradeoff becomes visible when a workflow is blocking production, a device cannot onboard because of a temporary incompatibility, or a third-party integration needs limited bypass access. Current guidance suggests the control owner should remain accountable even when the business sponsor is the one requesting urgency.

There is no universal standard for who must sign off in every case. Some organisations use a two-step model where the business owner accepts risk and the technical owner approves the control bypass. Others require security or compliance review for exceptions involving privileged access, regulated data, or external connectivity. The key is consistency: the same type of exception should follow the same approval path.

Where exceptions involve third parties, shared service accounts, or automated onboarding pipelines, accountability should also include the team responsible for monitoring expiry and validating closure. NHI Management Group’s guidance on NHI lifecycle management is useful here because exceptions often become permanent when no one owns the follow-up. For financial crime, sanctions, or customer due diligence workflows, regulatory expectations may also require preserved evidence and traceability, which is why control owners should document the business justification as carefully as the technical change.

Manual exceptions are safest when they are rare, visible, time-limited, and owned by the team that can actually restore the control afterward.

Related resources from NHI Mgmt Group

• Who is accountable when a workflow secret is exposed through a GitHub Action?
• Who is accountable if an MSP onboarding workflow creates excessive access?
• Who is accountable when a support workflow adds an attacker-controlled MFA device?
• Who is accountable when impersonation succeeds in a service desk or onboarding workflow?