Whenever it is high-risk, audit-impacting, or capable of changing access through administrative channels, service desks, or direct application controls without appearing in the governed workflow. At that point it is no longer a local exception but a named control gap.
What makes an out-of-band system a governance gap, not just an exception?
A system outside SailPoint becomes a governance gap when it can create, change, approve, or remove access without the governed lifecycle seeing it. The practical test is not whether the tool is useful, but whether it can alter entitlement state, bypass review, or leave no reliable audit trail in the control plane that owns access decisions.
That distinction matters because local convenience tools, admin consoles, and service desk shortcuts often start as process workarounds and end as shadow control points. Once they can change access independently, they are part of the access model whether or not they are listed in the IAM platform.
Which capabilities usually push a system into gap territory?
The highest-risk pattern is any system that can directly grant, modify, or revoke access through administrative channels. That includes direct application administration, ticket-driven access changes that bypass approval logic, and service desk actions that override the authoritative workflow. If the system can change entitlements outside the normal governance path, it should be treated as a control boundary, not an exception.
Administrative capability is not the only trigger. A system can also create a gap when it holds authoritative reference data, sync logic, or manual override rights that determine who has access in practice. In other words, if the system can change the outcome of access governance, it is part of governance even if it is not the system of record.
High-risk exceptions are usually the ones with broad blast radius, weak logging, or inconsistent ownership. A narrow, well-audited utility with no ability to alter access state is an operational dependency; a tool that can silently change production access is a governance control point.
How should teams decide whether to close the gap or formally govern it?
The decision should start with control authority. If the system can affect privileged access, production entitlements, segregation of duties, or audit evidence, it needs an explicit owner, documented process, and reconciled reporting back to the governed workflow. If those conditions cannot be met, the organisation should narrow the system’s power rather than simply accept it as a permanent side channel.
Where the system is necessary, the goal is not to eliminate every non-SailPoint function. The goal is to make the outside system visible, bounded, and reconcilable so that every access change can be attributed and reviewed. That usually means tighter role definitions, stronger approvals, periodic access reconciliation, and a clear rule for what kinds of changes may never happen outside the primary workflow.
Risk and Threat Considerations
Systems outside the governed workflow create a familiar failure mode: access changes happen, but the control evidence does not. That exposes the organisation to audit findings, privilege creep, missed revocations, and unauthorized access paths that are hard to detect because the authoritative record and the operational reality have diverged.
Failure mechanism: An admin channel, service desk process, or application control changes access without flowing through the governed approval, provisioning, and logging path, so entitlement state drifts away from the inventory and review model.
Impact: The organisation loses confidence in recertification, least-privilege enforcement, and audit completeness, and a malicious or careless operator can exploit the gap to grant access that should have been blocked or reviewed.
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 sets 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 | Governance gaps involve unmanaged account and entitlement changes outside the authoritative workflow. |
| AU-2 — Event Logging | Out-of-band access changes are only governable when the system leaves durable audit evidence. | |
| AC-6 — Least Privilege | Systems that can modify access outside governance often imply excess privilege or delegated authority. | |
| Recommendation — Route every access change through approved account management and reconcile exceptions quickly. Log every access-affecting action in a reviewable audit trail. Restrict admin and service-desk paths to the minimum authority needed. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The issue is whether access decisions are consistently governed across all control points. |
| A.8.15 — Logging | Audit-impacting exceptions require logs that capture who changed access and when. | |
| Recommendation — Define and enforce one access-control policy across all systems that can change entitlements. Ensure access-changing systems produce logs that support review and investigation. | ||
Practitioner Guidance
What to verify: Confirm whether the system can independently create, modify, or revoke access, and whether those changes are reconciled back to the authoritative workflow within a defined time window. If reconciliation depends on manual review, treat that as a control weakness, not a compensating control.
Decision rule: If the system can change production access, privileged roles, or approval outcomes without leaving a durable record in the governed process, classify it as a governance gap and assign formal control ownership. If it only consumes approved decisions and cannot alter entitlement state, it may remain a supporting dependency.
Practitioner takeaway: The key question is not whether SailPoint is the only tool in use, but whether every access-changing path is visible to the same governance model. If one path can change access outside that model, the organisation has a control gap, not a harmless exception.
Related resources from NHI Mgmt Group
- When should organisations treat an NHI as a high-priority risk?
- Should organisations prioritise external exposure or internal credential governance first?
- What breaks when organisations treat ISO 42001 as a documentation exercise instead of an operating system for AI governance?
- What makes agentic AI an NHI governance issue?