Use asset data as the inventory layer and identity workflows as the decision layer. Asset records should feed entitlement review, approval, and revocation, while IAM or IGA remains the system that decides who keeps access and when it is removed.
How to run access governance when the data lives in two systems
The split itself is the design problem. Asset systems usually know what exists, who owns it, and which applications or entitlements are in scope; identity systems know who can act, approve, and revoke. Good governance uses the asset record as the inventory and evidence source, then routes decisions through IAM or IGA so access remains tied to an accountable workflow rather than a static spreadsheet.
A practical model is to keep ownership and entitlement context in the asset layer, but treat approval, recertification, and removal as identity-controlled actions. That prevents duplicate truth sources from drifting while still preserving a clean decision trail for auditors and operators.
Where teams get into trouble is when they let either system become the full authority. If the asset platform can grant or revoke access on its own, governance becomes inconsistent. If the identity platform lacks authoritative asset context, reviewers approve or remove access without understanding the target application, owner, or business purpose.
What each system should own, and what it should never own
The cleanest split is functional, not political. Asset management should own inventory completeness, application ownership, classification, and the entitlement catalogue. Identity workflows should own request, approval, recertification, revocation, and evidence of who made the decision and when.
That means the asset side should publish stable identifiers, owners, environment, and access-relevant metadata, while IAM or IGA decides whether access is appropriate for a given user, role, or service. The asset system can inform the decision, but it should not be the final policy engine unless you deliberately centralise that function.
This pattern works best when the two systems share a common key for the application or resource and a controlled mapping for entitlements. Without that mapping, entitlement review tends to degrade into manual reconciliation, which is slow, error-prone, and hard to evidence.
How the control flow should work in practice
In a sound operating model, the asset record triggers the workflow, but the identity workflow closes the loop. New applications should be registered in the asset system, mapped to access owners, then surfaced to IAM or IGA so request, approval, and review logic can operate on a current entitlement set.
When an entitlement changes, the identity platform should record the decision and push the resulting grant or revocation to the target system. The asset system should then reflect the updated state for inventory and reporting, not re-decide the access outcome.
This is especially important for access review, because reviewers need enough context to answer one question: should this person still have access to this application, now? Asset metadata gives the reviewer that context, while the identity workflow provides the governed decision path and the revocation action.
For teams building the supporting data model, Identity Data Quality and Identity Fabric Guide is useful because the review process only works when authoritative sources, correlation, and attribute quality are stable enough to trust.
When the environment includes service accounts, API credentials, or other non-human access paths, IAM and IGA Basics helps anchor the same governance pattern across both human and non-human access decisions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Application access governance depends on controlled granting, review, and removal of access. |
| AC-6 — Least Privilege | The answer centers on limiting who keeps access and when it is removed. | |
| IA-5 — Authenticator Management | Identity workflows often enforce the credentials and tokens used to maintain application access. | |
| Recommendation — Use AC-2 to drive access requests, approvals, review, and timely revocation. Apply AC-6 to keep application access limited to the minimum needed. Use IA-5 to manage credential lifecycle so access changes take effect cleanly. | ||
| CIS Controls v8 | CIS-5 — Account Management | The subject is access governance across application inventories and identity workflows. |
| CIS-6 — Access Control Management | The question is about deciding and enforcing who keeps application access. | |
| Recommendation — Centralise account and entitlement management so review and revocation stay consistent. Enforce access control with approved workflows and remove stale privileges promptly. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Application access governance requires controlled allocation and removal of access rights. |
| A.5.18 — Access rights | The answer relies on review and revocation of application access entitlements. | |
| Recommendation — Apply A.5.15 to define and enforce rules for granting and removing access. Use A.5.18 to review, amend, and revoke access rights on a controlled schedule. | ||
Practitioner Guidance
What to verify: Confirm that every governed application has a single owner, a stable application identifier, and a mapped entitlement catalogue before you start recertification. If the review workflow cannot reliably identify the target entitlement, the process is not yet audit-ready.
Implementation sequence: Start by normalising application inventory and ownership in the asset layer, then connect those records to request, approval, and revocation workflows in IAM or IGA. Only after that should you automate periodic review and removal, because automation without a trusted map simply scales bad data.
Common mistake: Treating the asset system as the place where access decisions are made. That creates hidden policy drift, weak evidence, and inconsistent revocation timing, especially when different teams maintain different records of the same application.
Practitioner takeaway: Use the asset system to describe the thing being protected, and the identity system to decide and enforce access. If those roles blur, governance becomes a reconciliation exercise instead of a control.
Related resources from NHI Mgmt Group
- How should security teams govern non-human identities that have persistent access?
- How should security teams govern API keys used for generative AI access?
- How should security teams govern access when sensitive data is spread across multiple systems?
- How should IAM teams govern conversational access review tools for identity data?