How do you know if recertification is actually working for data access?

Why This Matters for Security Teams

Recertification is one of the few controls that can expose whether data access governance is real or merely documented. If a review cycle keeps approving the same broad entitlements, or if no one can explain who owns a dataset, the process is not reducing risk. That matters because NHI-driven access patterns often persist long after the business need has changed, especially in analytics, ETL, and service-to-service workflows. NHI Management Group’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which is exactly the kind of gap that makes recertification superficial. The control should answer a simple question: would this access be regranted today, to this identity, for this purpose, with this owner?

Security teams often miss the point by measuring completion rates instead of decision quality. A review that is 100% completed but leaves stale access untouched is a reporting exercise, not governance. Current guidance from the OWASP Non-Human Identity Top 10 aligns with that concern by treating unmanaged identities and excessive access as persistent attack paths. In practice, many security teams discover recertification failure only after a data exposure, rather than through intentional access reduction.

How It Works in Practice

Working recertification starts with inventory, ownership, and scope. Every sensitive repository, warehouse, bucket, or BI workspace needs a named data owner who can answer whether the access still matches the use case. Without that owner, reviewers default to rubber-stamping. The workflow should present evidence, not just a checkbox: last use date, group membership, privilege level, downstream systems, and the business justification for each entitlement. For NHI-driven access, include the service account or API key that actually reaches the data, because the human approver is often not the principal consuming it.

Operationally, strong programmes separate two questions: “Does this access still need to exist?” and “If yes, is it appropriately constrained?” That distinction matters because many entitlements are technically valid but too broad. The Ultimate Guide to NHIs — Key Challenges and Risks highlights how excessive privileges and weak visibility compound exposure. Reviews should therefore trigger remediation, not just attestations. If access is retained, the record should show who approved it, why it remains necessary, and when it will be reviewed again.

• Use owner attestations tied to specific data assets, not blanket approvals for whole departments.
• Flag stale access by inactivity, failed usage rationale, or privilege that exceeds the current role or pipeline.
• Require a named exception with expiry when access cannot be removed immediately.
• Feed removals back into IAM, PAM, and secrets processes so recertification changes the real environment.

Where possible, pair recertification with logging and entitlement analytics so reviewers can see whether access is actually used. This is especially important for machine identities, where static group membership can hide broad reach across data systems. These controls tend to break down in highly distributed data platforms where ownership is split across teams and entitlement evidence is incomplete.

Common Variations and Edge Cases

Tighter recertification often increases reviewer workload, so organisations must balance assurance against operational friction. That tradeoff is real, especially for fast-moving analytics teams and platform-managed data stores. Guidance suggests prioritising the highest-risk assets first rather than attempting uniform depth everywhere. For low-risk datasets, lighter attestation may be acceptable; for regulated or customer-sensitive repositories, reviewers should validate use case, owner, and privilege individually.

There is no universal standard for recertification frequency. Best practice is evolving toward risk-based intervals, with more frequent review for privileged, shared, or externally exposed access. The Ultimate Guide to NHIs — Key Research and Survey Results shows how widespread secrets and identity mismanagement remain, which is why one-time cleanup is not enough. For organisations using shared service accounts, inherited roles, or nested groups, recertification can look successful while the real effective access remains untouched. In those environments, the review should test effective permissions, not just listed entitlements. If the programme cannot prove removal of stale access after the cycle closes, it is not yet working.

Related resources from NHI Mgmt Group

• How do you know if a cloud identity model is actually governing SAP access?
• How do you know if Oracle access governance is actually working?
• How do you know if AI access controls are actually working?
• How do you know if zero trust is actually working for data?