Look for duplicate approvals, app requests that bypass lifecycle records, closed tickets with unchanged permissions, and high-risk applications visible in self-service portals without strict policy filters. Those symptoms show that the workflow is active but identity governance is not.
When workflow is busy but governance is not actually controlling access
The clearest warning sign is that change management appears active on paper while access decisions are being made outside the governance model. That usually shows up as approvals that do not resolve the underlying entitlement change, requests that never reconcile to a lifecycle record, or self-service paths that expose privileged options without the same policy checks as the formal workflow.
When that happens, the process may still create tickets, approvals, and audit trails, but it is no longer the control point for who can do what.
Signals that permissions are drifting away from the approved change record
Several patterns indicate the workflow is not governing access properly. Duplicate approvals can mean the same decision is being rubber-stamped in more than one system. Closed tickets with unchanged permissions suggest the ticketing process is disconnected from the actual entitlement state. App requests that bypass lifecycle records usually mean the request path is faster than the governance path, which breaks traceability and review.
Another common sign is inconsistent treatment of high-risk access. If a self-service portal exposes sensitive applications or privileged entitlements without strict policy filters, the interface is functioning as a request surface rather than a governed access gate. That is a basic IAM and IGA failure pattern, because access should be approved, recorded, and recertified as part of the same control chain.
Why these warning signs matter for identity governance
These symptoms matter because they usually indicate a split between workflow activity and entitlement reality. Once that split exists, managers may believe access was reviewed, revoked, or narrowed when it was not. Over time, that creates privilege creep, orphaned approvals, stale access, and weak audit evidence, especially where the process covers both human and machine accounts.
Lifecycle breaks are often the underlying cause. If the change process does not update provisioning, revocation, recertification, or ownership records consistently, the organisation loses confidence in its access inventory and may keep granting access based on old tickets rather than current business need. The problem is especially visible when changes are approved, but the target system still shows the old role or permission set.
Risk and Threat Considerations
Access governance failures create real exposure because they leave excess privilege in place after the business thinks it has been removed. That can turn a routine change into a persistent control gap, especially when high-risk systems are reachable through self-service or when tickets are treated as evidence instead of the source of truth.
Failure mechanism: The workflow records intent, but provisioning, deprovisioning, and recertification are not tightly bound to the actual access state, so permissions can remain excessive, duplicated, or untracked.
Impact: Users or services can retain access longer than intended, auditors lose reliable evidence of control operation, and an attacker who abuses a stale entitlement may move from a simple change gap to unauthorized access or privilege escalation.
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 | Controls access requests, provisioning, review, and removal that change management should reflect. |
| AC-6 — Least Privilege | Duplicate approvals and broad self-service access often signal privilege creep beyond need-to-know. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Closed tickets and stale permissions require independent verification against authoritative logs and records. | |
| Recommendation — Tie changes to AC-2 so approvals, provisioning, and revocation stay synchronized. Apply AC-6 to limit requests and approvals to the minimum access required. Use AU-6 to reconcile tickets, logs, and entitlement state after each change. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access governance failures are directly about whether access is approved, enforced, and reviewed correctly. |
| A.5.18 — Access rights | The warning signs point to access rights not being updated or recertified as change records close. | |
| Recommendation — Apply A.5.15 to ensure access approvals map to enforced permissions and reviews. Use A.5.18 to keep access rights current with the underlying business change. | ||
| CIS Controls v8 | CIS-5 — Account Management | The symptoms are classic account and entitlement management drift across request, approval, and removal. |
| CIS-6 — Access Control Management | Self-service portals exposing risky applications without policy filters are access-control failures. | |
| Recommendation — Use CIS-5 to govern account changes, approvals, and removals as one process. Apply CIS-6 to enforce policy-based access checks before entitlements are exposed. | ||
Practitioner Guidance
What to verify: Confirm that every access request has a unique lifecycle record, a corresponding entitlement change, and a post-change verification step. If the ticket is closed before the permission state changes, treat that as a control failure rather than a workflow success.
What to prioritise: Start with privileged applications, shared entitlements, and any self-service path that can grant access without policy filtering. Those are the places where process drift becomes material fastest, and where a missed linkage between approval and enforcement creates the largest blast radius.
Common mistake: Teams often measure whether the request was approved, not whether the permission actually changed and remained aligned with policy. The better test is whether the access state, record of approval, and ownership model all agree after the change.
Practitioner takeaway: Change management governs access properly only when it can prove that approval, provisioning, and review are the same control in three forms, not three separate activities.