Who is accountable when access reviews are delegated across compliance and resource owners?

Why This Matters for Security Teams

Delegating access reviews across compliance and resource owners is a governance test, not just an operational workflow. The risk is not that the review was automated; it is that no one can clearly explain who had authority to approve, reject, escalate, or remediate each decision. When that ownership is vague, exceptions linger, evidence becomes unreliable, and audit findings turn into production exposure.

This is especially important for NHIs, where review scope often spans service accounts, API keys, and machine-issued tokens that do not map cleanly to human job titles. NHIMG research shows that 97% of NHIs carry excessive privileges, which makes review accountability directly tied to blast radius rather than paperwork. Guidance in the Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10 both point to the same operational truth: reviews fail when ownership is not explicit before the campaign begins.

Security teams also need to remember that compliance can coordinate control execution without becoming the final approver for business access. NIST frames access governance as a repeatable control activity, but it still depends on role clarity and evidence quality, as reflected in the NIST Cybersecurity Framework 2.0 and the Ultimate Guide to NHIs — Regulatory and Audit Perspectives. In practice, many teams discover the accountability gap only after an access exception has already persisted through multiple review cycles.

How It Works in Practice

The cleanest model separates campaign governance from access authority. Compliance or GRC teams typically own the process: they define the review schedule, evidence requirements, escalation path, and closure criteria. Resource owners or system owners own the access decision itself because they understand whether a service account, API key, or privileged connector still has a valid business purpose. That division should be documented in the policy, the ticketing workflow, and the attestations collected for audit.

For NHI reviews, the process works best when the reviewer sees enough context to make a real decision. That means showing the secret owner, last-used date, system dependency, privilege level, and whether the credential supports a production path, an integration, or a dormant exception. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the Top 10 NHI Issues both emphasize that lifecycle visibility is what makes review decisions defensible.

• Compliance initiates the review, tracks completion, and escalates non-response.
• Resource owners validate whether the access is still needed and proportionate.
• Security defines the minimum evidence required for approval, rejection, or expiry.
• Automation executes reminders, deadlines, and revocation, but does not own the decision.

Alignment with NIST SP 800-53 Rev 5 Security and Privacy Controls helps translate this into auditable control ownership, especially for access review and least-privilege obligations. The practical measure is simple: every item in the campaign should have one accountable approver and one accountable follow-through owner. These controls tend to break down when access data is fragmented across IAM, CMDB, and ticketing tools because reviewers cannot tell whether they are approving business need or merely confirming stale records.

Common Variations and Edge Cases

Tighter review governance often increases operational overhead, requiring organisations to balance auditability against reviewer fatigue and delayed remediation. That tradeoff becomes sharper in large environments where a single resource owner may be asked to review dozens of accounts, many of which are inherited, shared, or poorly documented.

Current guidance suggests that delegated reviews should not be interpreted as delegated accountability. If compliance runs the campaign but the owner ignores the items, accountability usually returns to the documented control owner, not to the automation platform. The exception is when a formal RACI, policy, or service-level obligation assigns a separate escalation owner for overdue decisions. There is no universal standard for this yet, so the organisation must define it explicitly.

Edge cases show up when an application has no obvious business owner, when ownership has changed during a merger, or when a service account supports multiple systems. In those situations, the safe approach is to assign temporary stewardship, preserve evidence, and resolve ownership before reattestation. The Ultimate Guide to NHIs — Key Challenges and Risks is useful here because it frames poor ownership as a risk multiplier rather than a clerical issue. Practitioners should treat unresolved ownership as a control failure, not as a reason to auto-approve. In practice, teams usually find that unanswered reviews are a symptom of missing system stewardship, not of a broken workflow.

Related resources from NHI Mgmt Group

• Who is accountable for SAP compliance when risk dashboards reveal unresolved access conflicts?
• Who should be accountable for API policy and compliance when development moves faster than security reviews?
• Who is accountable when workflow access reviews and source-of-truth decisions are inconsistent?
• How should security teams run access reviews for non-human identities?