Who is accountable when misrouted approvals or empty reviews lead to audit findings?

Why This Matters for Security Teams

Misrouted approvals and empty reviews are not clerical defects; they are governance failures that can invalidate access recertification, exception handling, and audit evidence. When schema mapping drives how approvals flow, a bad mapping can cause the right reviewer to be bypassed or a review to complete with no meaningful decision. That is why the accountability question lands with identity governance and application owners, not with the audit team.

The operational impact is amplified in non-human identity programmes, where approvals often govern service accounts, API keys, and workflow bots rather than people. NHI Mgmt Group research shows that 97% of NHIs carry excessive privileges, which makes any broken approval path more than a paperwork issue. The Top 10 NHI Issues and the Ultimate Guide to NHIs both frame misconfiguration and weak review discipline as recurring audit drivers. In practice, many security teams encounter the control failure only after an audit sample exposes that the approver never had the authority, or that the review logic never evaluated the real entitlement.

That is why current guidance treats schema quality, routing logic, and ownership as part of the control itself, not as implementation detail. Audit findings usually surface the symptom first, while the accountability issue was already embedded in the operating model.

How It Works in Practice

In a sound operating model, the identity governance team defines how attributes map to approvers, certification campaigns, and exception queues, while the application owner validates that the mapped fields reflect actual business control points. The review record must show who approved, what was reviewed, and whether the reviewer had enough context to make a defensible decision. If the system can route an approval but cannot prove the route was correct, the control is only partially operating.

For NHI and application entitlements, the review flow should be tied to authoritative data sources such as owner registers, asset inventories, and entitlement catalogs. NIST guidance on access control and continuous monitoring supports this model, while NIST CSF 2.0 emphasizes governance and control ownership as first-class security outcomes. The relevant question is not whether a system emitted an approval event, but whether the event maps to the correct identity, entitlement, and owner. The NHI Lifecycle Management Guide and the Lifecycle Processes for Managing NHIs are useful references because they place routing, rotation, and offboarding into one lifecycle.

• Define ownership fields that are mandatory, validated, and sourced from a system of record.
• Block certification completion when the approver lacks the assigned authority.
• Log empty reviews as failures, not successes, in audit evidence.
• Reconcile routing rules after every schema, org, or application change.

Where this breaks down is in federated environments with inconsistent owner data, because the approval path can be technically functional while still being organisationally wrong.

Common Variations and Edge Cases

Tighter routing controls often increase operational overhead, requiring organisations to balance audit precision against change-management friction. That tradeoff becomes visible when ownership is split across platform, application, and business teams, or when an application exposes only partial metadata for certification routing. Current guidance suggests treating those gaps as control deficiencies, but best practice is still evolving on how much manual override is acceptable.

There is no universal standard for this yet, but the pattern is clear: if a review is empty, stale, or auto-completed, the control should be considered suspect until a human with authority validates it. For NHI estates, this matters even more because service accounts and API keys often lack intuitive business owners. NIST Cybersecurity Framework 2.0 and SP 800-53 Rev. 5 both support assigning clear accountability for security controls and review evidence, while the Key Research and Survey Results show how often organisations lack full visibility into those identities.

The practical edge case is merger activity, outsourced operations, or rapid app onboarding, where mappings are copied forward faster than they are validated. In those environments, the safest assumption is that the control is incomplete until the data model is re-certified end to end.

Related resources from NHI Mgmt Group

• Who is accountable when cloud identity gaps lead to audit findings or breaches?
• Who is accountable when certificate control failures lead to audit findings?
• Who is accountable for vulnerability management when findings affect compliance?
• Why do non-human identities create more audit risk than human accounts?