Who should be accountable for unmanaged business accounts?

Why This Matters for Security Teams

Unmanaged business accounts become risky fast because they sit outside the normal ownership, review, and retirement process. When no accountable business owner is assigned, IAM can enforce controls, but it cannot decide whether the account still serves a legitimate purpose. That gap is where stale entitlements, orphaned access, and untracked privilege accumulate. NHI Management Group notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which is why lifecycle ownership must be explicit rather than assumed.

This is not just an identity hygiene issue. It is an operational governance problem that affects audit readiness, incident response, and access recertification. Guidance in the NIST Cybersecurity Framework 2.0 reinforces that identity-related controls need clear accountability and repeatable oversight, while NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs ties that accountability directly to lifecycle management. In practice, many security teams encounter unmanaged business accounts only after a decommissioned app, a failed audit, or a suspected misuse event has already exposed the gap.

How It Works in Practice

Accountability should be assigned to the business owner, product owner, or service sponsor who can answer a simple question: does this account still have a valid business purpose? Operational enforcement belongs with IAM and security, who manage provisioning, logging, approvals, access reviews, and offboarding controls. That split is important because technical teams can disable access, but they cannot own the business decision to keep or retire the account.

A practical model usually includes:

• a named business owner in the system of record for every service, shared, or delegated account;
• a technical custodian in IAM or platform security responsible for control execution;
• defined review intervals tied to the account’s purpose, privilege level, and last-use signal;
• offboarding triggers for application retirement, vendor exit, team restructuring, or tool replacement;
• escalation rules when ownership is missing or unresponsive.

NHIMG’s Top 10 NHI Issues and NHI Lifecycle Management Guide both reflect the same operational reality: if ownership is not linked to lifecycle events, accounts persist long after the business need disappears. Current guidance suggests this should be treated as a governance control, not a one-time cleanup task. These controls tend to break down in environments with many shared accounts, outsourced application ownership, or weak CMDB and IAM integration because no single team can reliably tell when the account should be retired.

Common Variations and Edge Cases

Tighter ownership controls often increase administrative overhead, so organisations have to balance accountability against the speed of change in fast-moving platforms. That tradeoff is real, especially where business units create tools quickly and expect operations to “figure it out” later. Best practice is evolving, but there is no universal standard for this yet.

Some accounts are effectively owned by a function rather than an individual, such as a finance automation platform or a shared procurement integration. In those cases, the accountable party should still be named at the department or system level, with a backup contact and a review date. For legacy environments, the first priority may be to assign provisional ownership and remove unknown accounts from standing privilege, then formalise the process during the next access review cycle.

When an account cannot be mapped to a business owner, it should be treated as a governance exception, not silently accepted. NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives is clear that missing ownership weakens auditability and complicates offboarding evidence. The practical answer is to combine exception handling with enforced expiry, because unmanaged accounts rarely become self-documenting over time.

Related resources from NHI Mgmt Group

• Who is accountable when mule accounts are used to launder stolen funds?
• Who is accountable when KYB fails to detect fraudulent business identity?
• Who is accountable when a business entity is approved with weak KYB evidence?
• Why do non-human identities create more audit risk than human accounts?