Ownership should sit with the business and application context, while identity teams provide the workflow, evidence, and enforcement. That separation keeps review decisions tied to real access need rather than letting technical teams approve entitlements without operational accountability.
Why This Matters for Security Teams
Recertification ownership is not a clerical detail. It determines whether access review validate real business need or simply confirm whatever was provisioned last quarter. When identity teams own the decision, reviews often become technically neat but operationally detached. Business and application owners have the context to judge whether a role, account, or integration is still needed, while identity teams should provide the workflow, evidence, and enforcement that make those decisions auditable.
This matters even more for non-human identities, where entitlement sprawl and hidden dependencies are common. NHIMG’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is exactly why review ownership must sit with the people who understand operational necessity, not just directory structure. OWASP’s OWASP Non-Human Identity Top 10 also highlights how identity misuse and overprivilege compound when governance is disconnected from runtime reality. In practice, many security teams encounter stale approvals only after an audit, incident, or failed deprovisioning has already exposed the gap.
How It Works in Practice
The cleanest operating model separates decision ownership from control execution. Business owners, application owners, and system custodians decide whether access is still required, whether it is still appropriate, and whether the risk remains acceptable. Identity governance and administration teams then orchestrate the campaign, route attestations, retain evidence, and enforce deadlines, escalation, and revocation when approvers do not respond.
That division works because access reviews are about business context, not just identity records. A service account may belong to a payroll application, a data pipeline, or a third-party integration, and each needs a different reviewer. The reviewer should be the person who can answer: Is this account still used? Does this entitlement match the function? Has the application been retired? Identity teams are better positioned to answer: Was the review completed on time? Was the decision captured? Was removal enforced?
Operationally, mature programmes often use a simple chain:
- Identity team defines review cadence, evidence requirements, and exception handling.
- Application owner validates whether access is still needed for the specific workload or system.
- Business owner confirms the entitlement still supports an approved process or service.
- PAM, IGA, or directory controls execute removal, downgrade, or re-approval.
For NHIs, this should be paired with asset inventory and lifecycle data. NHIMG’s NHI Lifecycle Management Guide reinforces that ownership, rotation, and offboarding must be tied together, not handled as separate workflows. NIST guidance on digital identity and least privilege supports the same principle: reviewers must have enough context to make a meaningful decision, while the platform enforces the outcome. These controls tend to break down when the review population is too broad, because approvers cannot distinguish legitimate service dependencies from abandoned entitlements.
Common Variations and Edge Cases
Tighter review ownership often increases administrative overhead, requiring organisations to balance stronger accountability against slower campaign cycles. That tradeoff is real, especially in large estates with many delegated applications, inherited entitlements, or shared service accounts. Current guidance suggests that convenience should not override decision quality, but there is no universal standard for how granular ownership mapping must be.
One common variation is delegated review. For example, a line manager may review human access while an application owner reviews a service account, with the business owner retained as the final accountable party. Another edge case is shared infrastructure where no single team can confidently attest to every entitlement. In those cases, best practice is evolving toward documented ownership matrices, explicit exceptions, and time-bound remediation rather than default approval.
NHIMG’s analysis in 52 NHI Breaches Analysis and the Sisense breach both illustrate a practical lesson: when ownership is vague, access persists because nobody feels accountable for removing it. The right model is not “identity team approves everything,” but “identity team governs the process while the business owns the decision.”
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 address the attack and risk surface, while NIST CSF 2.0 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 | Review ownership is central to preventing excessive NHI privilege. |
| NIST CSF 2.0 | PR.AC-4 | Access review decisions support least-privilege access governance. |
| NIST AI RMF | GOVERN | Clear accountability is needed for decision ownership and oversight. |
Define accountable owners for access decisions and track review outcomes as governed controls.
