Treat ITOM as a telemetry and response layer, not as the system of record for access decisions. Identity governance should own account inventory, approvals, entitlement reviews, ownership, and offboarding. That separation prevents organisations from assuming that because they can observe a service or workload, they can also govern the identity behind it.
Keep ITOM Observability and Identity Governance on Separate Rails
ITOM and identity governance solve different problems, even when they touch the same systems. ITOM tells you that a service, workload, or endpoint is present, healthy, or degraded. Identity governance decides who owns that account, who approved it, what it can do, and when it must be reviewed or removed. Confusing those layers usually turns monitoring data into a false source of access truth.
The boundary matters because operational visibility is not the same as authority. An ITOM tool can help discover an account or detect drift, but it should not become the approval engine or the record that a permission is legitimate. Identity governance needs a controlled process for requests, entitlements, recertification, and revocation, which is why teams often pair IAM and IGA Basics with lifecycle-focused controls rather than relying on monitoring workflows alone.
In practice, this separation also helps with auditability. If the same platform is asked to both observe and authorise, teams tend to accept stale ownership, partial inventories, or inferred access as good enough. A better model is to let ITOM flag what exists and what changed, while identity governance remains the system that confirms whether the account belongs, whether the entitlement is still justified, and whether the offboarding action has actually been completed. That is the same discipline reflected in Identity Security Posture Management (ISPM) Guide, where visibility feeds governance but does not replace it.
What ITOM Should Own, and What It Should Not
ITOM should own telemetry, service state, alerts, dependency mapping, and response workflows that keep operations stable. It can surface orphaned accounts, unexpected changes, or agents that appear on a host or in a cloud environment. What it should not own is entitlement approval, access recertification, or the authoritative decision that an account remains valid. Those are identity governance functions, and treating them as an ops concern blurs accountability.
This division becomes especially important for privileged or shared technical accounts. ITOM may see that a service is alive and that a credential was used, but it cannot determine whether that use was approved, least privilege, or tied to a current business owner. For that, teams need governance artefacts such as entitlement ownership, periodic review, and role design. The Access Reviews and Certification Guide and Role Mining and Role Design Guide are useful anchors for that separation of duties.
ITOM can still support governance by supplying evidence. It can tell you whether an account is active, whether a workload is still deployed, or whether an integration has gone dormant. But the governance decision must be made in the identity system, using ownership and entitlement logic, not by inferring legitimacy from operational uptime. When teams collapse those functions, they usually preserve access far longer than intended.
How the Boundary Works in Real Governance Processes
The cleanest operating model is a one-way relationship: ITOM discovers and reports, identity governance decides and records. Discovery data can enrich inventory, but the system of record for account lifecycle remains the identity process. That means joiner, mover, and leaver events, ownership assignment, recertification, and offboarding should flow through identity governance, not through incident tickets or monitoring alerts. Joiner-Mover-Leaver (JML) Guide and NHI Lifecycle Management Guide both reinforce that lifecycle control is a governance problem first.
Security teams should also be careful about what counts as a valid approval trail. A monitoring event that says “this account was used” does not equal “this account is approved.” Likewise, a service map that shows an integration exists does not prove that its access is still required. If the organisation needs to answer “who owns this” or “why is this entitlement still present,” the answer must come from governance records that can be reviewed, challenged, and revoked.
That is why separation of duties matters. A monitoring platform can tell you where a control failed, but it should not be able to legitimise the access it is observing. If the ops stack can also self-authorise entitlements, the organisation loses independent review. Segregation of Duties (SoD) Guide is the natural companion for teams that need to keep observation, approval, and enforcement distinct.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Separating monitoring from governance depends on authoritative account lifecycle control. |
| Recommendation — Use account management controls to own approvals, reviews, and removals outside ITOM. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | The question is about who owns account lifecycle decisions and revocation authority. |
| IA-5 — Authenticator Management | Identity governance must manage credential lifecycle, not just observe use in ITOM. | |
| Recommendation — Assign account lifecycle authority to the identity governance process and keep ITOM evidentiary. Manage authenticators through governance workflows, including rotation and revocation. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The separation concerns controlled access decisions versus operational visibility. |
| Recommendation — Define access control ownership in governance and prevent monitoring tools from self-authorising access. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | The page discusses offboarding and removal of accounts that ITOM can observe but should not govern. |
| NHI-05 — Overprivileged NHI | Identity governance must prevent excessive access that monitoring alone will not catch. | |
| Recommendation — Tie offboarding to governance so observed accounts are actually deprovisioned. Review entitlements centrally to remove excess privilege before it becomes persistent. | ||
Practitioner Guidance
What to prioritise: Define a single system of record for ownership, approval, entitlement reviews, and offboarding, then make ITOM a source of evidence only. If a control decision can change access, it belongs in identity governance, not in monitoring.
What to verify: Check that every account or workload surfaced by ITOM has an owning business or technical accountable party in the governance process, plus a documented reason for existence. Any item that cannot be tied to ownership should be treated as an exception until resolved.
Common mistake: Teams often let “visible in ITOM” become shorthand for “managed.” Visibility is useful, but it does not establish legitimacy, least privilege, or continued need.
Practitioner takeaway: The boundary is healthiest when ITOM proves something exists and identity governance proves it deserves to exist.
Related resources from NHI Mgmt Group
- How should security teams use IAST and RASP in NHI governance?
- How should security teams separate AI runtime protection from identity governance?
- How should security teams connect fraud monitoring with identity governance?
- What do security teams get wrong when they treat channel enablement as separate from identity governance?