Who is accountable when access review data is not accurate at the time of certification?

Why This Matters for Security Teams

Certification only works when the underlying entitlement data is accurate at the moment of review. If upstream records are stale, incomplete, or mismatched, the review becomes a documentation exercise rather than a real control. That matters because access recertification is often used to prove least privilege, support audit readiness, and close governance gaps across human and non-human identities.

For NHI-heavy environments, the risk is amplified because service accounts, API keys, and tokens often outnumber human identities by orders of magnitude. NHI Mgmt Group notes that NHIs outnumber human identities by 25x to 50x in modern enterprises in the Ultimate Guide to NHIs, which means even small data-quality problems can scale into major control failures. When the review source is wrong, approvers may unknowingly bless privileges that no longer reflect operational need or ownership. That is why guidance from OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls both emphasize governance, accountability, and evidence quality rather than treating certification as a one-time checkbox.

In practice, many security teams discover inaccurate certification inputs only after an audit exception, not through intentional validation before approval.

How It Works in Practice

Accountability starts with process ownership, not with the individual approver. Security and GRC teams typically own the certification workflow, define the attestation criteria, and decide what evidence is required before a review can be marked complete. Data source owners, meanwhile, are accountable for keeping upstream systems current, such as HR, CMDB, IAM, ticketing, secrets inventory, or cloud entitlement sources. If those sources are stale, the certification is already compromised before a reviewer opens it.

A sound process usually includes pre-certification validation, exception handling, and closure evidence. That means the review should reconcile identities, entitlements, owners, and business justification before the attestation window opens. Where possible, teams should automate data freshness checks and flag records with missing ownership, expired justifications, duplicate identities, or orphaned privileges. This is especially important for non-human identities because static access records often drift from runtime reality. The Ultimate Guide to NHIs — Key Challenges and Risks highlights how visibility gaps and excessive privilege create persistent exposure, and the same pattern undermines certification quality.

• Validate source systems before the review begins.
• Require named data owners for each entitlement source.
• Block certification completion when records are stale or unmapped.
• Retain evidence of remediation, not just reviewer approval.

For governance teams, the practical test is whether the process can prove the data was accurate at time of certification, not merely that someone clicked approve. Controls tend to break down in federated environments with multiple entitlement sources because no single team owns end-to-end data quality.

Common Variations and Edge Cases

Tighter certification controls often increase operational overhead, requiring organisations to balance reviewer efficiency against evidence quality. In mature environments, that tradeoff is usually worth it; in fast-moving cloud and DevOps pipelines, it can be harder because entitlements change faster than manual review cycles.

There is no universal standard for this yet, but current guidance suggests that organisations should treat inaccurate source data as a control defect, not a reviewer error. If the owner list is wrong, the access graph is incomplete, or the entitlement source is delayed, the certification should be paused or marked invalid until remediation is complete. This is particularly important for service accounts and other NHIs, where access is often machine-issued, ephemeral, or inherited through automation. NHI Mgmt Group’s NHI Lifecycle Management Guide is relevant here because lifecycle controls and offboarding discipline directly affect whether review data remains trustworthy.

The cleanest operational model is shared accountability with explicit control boundaries: GRC owns the process, security owns enforcement, and system owners own source accuracy. In real incidents, the failure is rarely the final approver alone. It is usually the absence of a validation gate that allowed inaccurate data to reach certification in the first place, often alongside broader identity weaknesses described in the 52 NHI Breaches Analysis.

Related resources from NHI Mgmt Group

• Who is accountable for protecting identity data when access is granted across partners and internal business units?
• How should security teams implement just-in-time access for observability data sources in Grafana environments?
• What is the difference between just-in-time access and always-on IAM group membership for Grafana data sources?
• Who is accountable when elevated access is used for time sensitive business operations?