Should access certification be tied to regulated data or to systems?

Why the Certification Control Belongs to the Data, Not Just the Application

access certification answers a governance question: who should retain access to regulated information, under what business need, and with what evidence. That is easiest to defend when the review is anchored to the regulated data set, because the control objective is about the entitlement to see or act on the data, not merely the existence of a permission inside a system. For GRC and IAM teams, data-centric certification also produces cleaner audit trails and fewer ambiguous exceptions.

When certification starts from the data, reviewers can see the business justification in context, rather than trying to infer it from a long list of systems and roles. That matters when the same person has access through multiple tools or when one application exposes several regulated data domains. IAM and IGA basics are useful here because the certification decision is really an entitlement governance decision, not just a system inventory exercise.

A practical rule is to certify at the lowest level that still matches the audit requirement. If the regulation names a category of regulated data, review access to that category directly, then use system-level review as a backstop where the data mapping is incomplete or the application is too coarse-grained to certify safely at the data layer. That is especially important when access is spread across multiple applications, shared platforms, or downstream reporting tools.

When System-Level Review Still Matters

System-level certification is still necessary when the control plane is the only place the organization can reliably prove access. Legacy platforms, coarse roles, embedded permissions, and shared service functions can all make data-only certification incomplete. In those cases, the system review is the mechanism that closes the gap between the regulated data intent and the real access implementation.

System-based reviews are also useful when a single system contains mixed data classes, or when the organization cannot yet maintain authoritative data-to-entitlement mappings. In practice, that often means the certification campaign has to be layered: first confirm the regulated data owner and data scope, then validate the systems and roles that can reach it. Access Reviews and Certification Guide is the right pattern because it focuses the review on removing access, not just re-approving it.

Where roles are already overloaded or poorly designed, a system-only campaign can become a rubber stamp. A data-tied model is harder to game because it forces the organization to explain why access to a sensitive dataset still exists, rather than assuming a role is acceptable because it was previously approved. If the answer to the review question cannot be tied to a business data need, the certification is too abstract.

How to Build a Review Model That Auditors Can Follow

The strongest operating model is usually data-first with system fallback. Start by classifying the regulated data scope, map it to owners and entitlement paths, and then certify the users or non-human identities that can reach it. Only use system-level certification as the primary control when the data mapping is unreliable, the system is the regulated boundary, or the application design prevents meaningful data-level review.

This approach also improves remediation. If a reviewer revokes access to a specific data domain, the downstream cleanup can be measured against a concrete business object instead of a vague application label. IGA Buyer’s Guide is relevant because the platform must support that mapping, not just send review tasks.

Good programs also reconcile certification with lifecycle controls. If the same person keeps appearing on access lists for regulated data across multiple reviews, that is a sign the joiner-mover-leaver process, role model, or ownership model is leaking risk into the certification workflow. The control should surface those defects, not hide them behind periodic approvals.

Practitioner Guidance

What to prioritise: Tie the certification object to the regulated data domain first, then add the systems that expose it. That sequence gives reviewers a business-relevant question and avoids over-reliance on application names that do not explain why access exists.

What to verify: Make sure each certified access path can be traced to an owner, a data class, and a revocation path. If you cannot show those three elements, the review evidence is probably too weak for audit or remediation.

Common mistake: Treating system recertification as a proxy for data governance. That often preserves broad access that looks controlled on paper but remains hard to justify against the regulated information actually in scope.

Practitioner takeaway: Use the data as the primary certification lens whenever possible, and use system reviews to close mapping gaps, not to replace the business question the audit is really asking.

Related resources from NHI Mgmt Group

• What should firms do when third-party providers have access to regulated cloud systems and customer data?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• When do NHI access reviews create more value than a one-time cleanup?