What should organisations do when access data and asset data do not match?

How to handle a mismatch between access data and asset data

When access records and asset records disagree, the first question is whether the organisation still has a live system, a live account, or a stale record. A mismatch usually means one control plane is out of date, so the right response is to reconcile ownership, confirm current system status, and treat the discrepancy as a control gap that can affect approvals, revocation, and auditability.

The practical test is whether the account can still exercise access against something the business believes exists. If the answer is unclear, the mismatch should be resolved before the next access review cycle, because unresolved drift tends to spread into PAM, IGA, and CMDB processes at the same time.

Why this is an operational control problem, not just a data-cleanup task

Access data tells you who can do what, while asset data tells you what exists and who is responsible for it. If those sources diverge, the organisation may be relying on an owner, entitlement, or decommissioning decision that is no longer true. That matters because CIS Controls v8 treats asset inventory, account management, and access control as connected operational safeguards, not separate clerical activities.

The mismatch also affects whether a record should drive action or merely reflect history. A stale asset record can leave access in place for something that should have been retired, while a stale access record can hide an active dependency that still needs review. Either way, the organisation loses confidence in its control evidence and in the decisions built on that evidence.

In practice, the most important distinction is between an obsolete record and an obsolete entitlement. The first needs correction; the second may need revocation, reassignment, or a wider review of linked approvals and exceptions. If the asset is still active but ownership is missing, the gap is a governance problem. If the asset is inactive but access remains, it is a privilege-control problem.

What to reconcile first so the mismatch does not spread

Start with the account-to-owner relationship, then confirm whether the system is active, retired, or repurposed. Once that is clear, align the access record, the asset record, and the authority to approve or revoke access. For machine or application access, OAuth 2.0 Authorization Framework matters because client-based access still depends on a correct target system and scope, even when no person is logging in.

Then check whether the three records are supposed to move together. If PAM holds privileged access, IGA holds the certified entitlement, and the CMDB holds the asset identity, a mismatch in one place often means the other two are stale as well. Treat the update as a single reconciliation event, not three unrelated tickets.

Where the record cannot be resolved quickly, mark it for exception handling rather than allowing the inconsistency to linger as “known noise.” Persistent noise becomes accepted drift, and accepted drift eventually weakens revocation, recertification, and incident response.

What good remediation looks like in practice

The best outcome is a single, defensible source of truth for the decision that matters most here: who owns the access, what it applies to, and whether the target still exists. That often means updating the account owner, closing out the retired asset, or remapping the entitlement to the replacement system. For control design, NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant because identification, access control, configuration management, and audit records all depend on consistent asset and identity data.

Good remediation also leaves evidence behind. The team should be able to show why one record changed, who approved the change, when the system was verified as active or inactive, and how linked records were updated. If the organisation cannot reconstruct that sequence, the mismatch was not fully controlled even if the visible data now looks aligned.

At scale, the same pattern helps distinguish isolated hygiene issues from structural drift. A few mismatches may be housekeeping. Repeated mismatches across the same platforms, teams, or account types usually indicate broken onboarding, weak decommissioning, or uncontrolled delegation paths.

Risk and Threat Considerations

Unresolved mismatches create a window where access can outlive the asset, the owner, or both. That can expose dormant privileged accounts, hide orphaned entitlements, and let stale records mask an active access path. The risk is not only bad reporting, it is that revocation and review controls stop reflecting reality.

Failure mechanism: One system says the account or asset is current while another says it is retired, unmanaged, or assigned elsewhere. That breaks the control chain for certification, deprovisioning, and incident investigation, and it can let access persist after business ownership has changed.

Impact: Excess access may remain in place, audit evidence becomes unreliable, and a compromise or misuse event becomes harder to detect and contain because the organisation no longer knows which record to trust.

Practitioner Guidance

What to verify: Confirm the live system status before updating records. If the asset is active, validate the named owner and the business purpose; if it is inactive, confirm that access can be removed without breaking a legitimate dependency. Where privileged access exists, ISO/IEC 27001:2022 Information Security Management is useful because access, privileged access, authentication, and asset control need coordinated governance, not isolated fixes.

Decision rule: If the account can still reach production or administrative functions, prioritise owner reconciliation and access correction before closing the record discrepancy. If the system is confirmed retired, prioritise deprovisioning and CMDB closure before treating the matter as data hygiene.

Practitioner takeaway: The safest operating model is to treat mismatched records as a control integrity issue, then force the ownership, access, and asset views to converge in one change set.

Related resources from NHI Mgmt Group

• What should organisations do when access reviews do not match real data exposure?
• 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?