Who should approve access to sensitive data when certification enrichment is in place?

Why This Matters for Security Teams

certification enrichment changes the approval question from “who requested it?” to “who can actually judge the risk of granting it?” For sensitive data, that matters because a manager may understand the business use case but not the exposure created by regulated records, export-controlled content, or customer data sets. Current guidance suggests approvals should reflect both entitlement intent and data classification, especially where audit trails and segregation of duties are required.

This is where teams often miss the real control point. If certification workflows only route to the requester’s manager, the approval can become a paperwork exercise that confirms employment context but not access legitimacy. NHI Mgmt Group’s research shows that 97% of NHIs carry excessive privileges, which is a reminder that weak approval logic usually expands the blast radius rather than containing it; see the Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10 for the broader governance context.

In practice, many security teams encounter approval failures only after a review cycle has already signed off inappropriate access, rather than through intentional policy design.

How It Works in Practice

The practical model is role-based plus context-aware. The line manager can remain part of the workflow, but certification enrichment should add the people who can evaluate data sensitivity, legal exposure, and control ownership. For regulated content, that often means the data owner, privacy steward, compliance owner, or system control owner becomes an approver or required reviewer. That division of responsibility is important because the question is not just whether the employee needs access, but whether the organisation can defend the access in an audit.

A workable implementation usually looks like this:

• Use certification enrichment to attach classification, regulatory tags, application context, and business purpose to each access item.
• Route approvals based on the asset, not just the person, so sensitive data invokes a stronger review path.
• Require explicit sign-off from the data owner or delegate when the item includes regulated, restricted, or high-impact data.
• Keep the manager as an approver for business need, but do not make managerial approval the only control for sensitive access.
• Record the reason code, approver role, and classification context to support auditability and later attestation.

This approach is consistent with how identity governance and NHI controls are trending: approval should map to exposure and control ownership, not convenience. The NIST Cybersecurity Framework emphasises access control and governance discipline, while NIST’s Digital Identity guidance reinforces that assurance decisions must be tied to the risk of the transaction. For the identity and access side of the problem, the NIST SP 800-63 Digital Identity Guidelines are a useful reference point, and the Ultimate Guide to NHIs — Key Challenges and Risks explains why governance fails when approvals are disconnected from actual privilege and data exposure.

These controls tend to break down when certification systems cannot reliably map the asset to a clear owner or when enriched metadata is incomplete, stale, or inconsistently tagged across applications.

Common Variations and Edge Cases

Tighter approval routing often increases cycle time and reviewer burden, so organisations have to balance fast business access against the cost of stronger control. That tradeoff becomes most visible in high-volume certification campaigns, where every extra approver can slow remediation and create review fatigue.

There is no universal standard for this yet, but current guidance suggests a tiered model works best. Low-risk internal data may only need managerial approval, while sensitive, regulated, or customer-facing data should add a data owner or control owner. For shared datasets, the right approver may be the platform owner plus the business data steward. For third-party access, approval should also consider contractual constraints and vendor oversight. Where certification enrichment is mature, the workflow can even vary by sensitivity label, dataset lineage, or jurisdiction.

One practical guardrail is to separate “can approve business need” from “can accept data risk.” That keeps the manager in the loop without pretending managerial authority equals control authority. It also avoids false confidence in approvals that look complete but lack the only reviewer who understands the implications of disclosure. The broader pattern aligns with the NHI research on privilege and exposure, especially the Ultimate Guide to NHIs — Key Research and Survey Results and the 52 NHI Breaches Analysis, which show how weak review discipline turns access governance into an after-the-fact response process.

Related resources from NHI Mgmt Group

• What breaks when managed-service admin access is left in place too long?
• Who should approve just-in-time access requests for agents?
• How should teams use AI to improve access certification without weakening accountability?
• Data-level access