ITOM for Utilities: Map Dependencies, Cut Grid Risk

A shared network service goes down for scheduled maintenance, and nobody can say which utility applications depend on it until the help desk starts ringing. That’s the failure ITOM for utilities exists to prevent: IT operations management (ITOM) for utilities is the practice of connecting infrastructure records to the services, owners, and OT boundaries a team needs before approving a change or opening an incident — not after. ITOM covers that infrastructure and operations work; IT service management (ITSM) covers the tickets, approvals, and workflows built on top of it. The work starts with an agreed view of assets, ownership, and the boundary between information technology (IT) and operational technology (OT).

Why utilities need service context alongside asset inventories

Electric utilities rely on interconnected systems across control centers, field operations, data centers, and corporate environments. Some support physical grid operations directly. Others help staff exchange information, manage work, or coordinate restoration.

This is the core of ITOM for utilities: an inventory can identify a server, network switch, or application, but a dependency record adds the operational context needed to assess its importance. It can show which application uses the server, who owns the service, and which teams should review a proposed change.

Consider an outage management application that relies on a database and an identity service. Its infrastructure team may track each component in a separate system. If the relationship between them is missing, a change reviewer might assess the identity service without recognizing the application dependency.

For utility IT teams, the goal is to make those relationships available before a decision. A useful record includes the source of each observation and the date it was last verified. It also distinguishes confirmed relationships from dependencies that still need review.

The U.S. Department of Energy’s guidance on energy-system OT cybersecurity describes how OT systems can include IT components or connections. Those connections require coordination because operational requirements and consequences can differ across environments.

Major U.S. power outages cost electricity customers an estimated $121 billion in 2024, according to an Oak Ridge National Laboratory analysis. A CMDB reconciled against what IT discovery for utilities observes on the network gives reviewers that documented baseline before an outage, not during one.

Start with a critical utility service

A utility-wide inventory project can lose momentum when teams try to document every environment at once. Start instead with one service that has a clear operational owner and an established support process.

An outage management application, field workforce platform, or operations reporting service may be a suitable starting point. Select a service whose owners can identify its important applications and review its dependencies. Confirm the boundaries of the exercise with IT, OT, and security stakeholders.

Utilities already triage systems this way for compliance. NERC’s CIP standards classify bulk electric system cyber assets into high, medium, and low impact tiers, and that same tiering is a practical filter for choosing which service to map first for ITOM for utilities purposes.

For the selected service, document:

• The business or operational function it supports.
• The application owner and the teams responsible for infrastructure.
• Its known servers, databases, network connections, and identity dependencies.
• The sources used to verify each record.
• The last review date and any unresolved gaps.

Ask service owners which dependencies are essential during degraded operations. For example, a field workforce application may remain available while an integration or communications path is impaired. Its owner should document what staff can still do and which workaround they would use.

Virima’s Trusted Runtime Truth approach connects discovery-sourced records with relationships and ownership. It helps teams assess what exists, how components connect, what changed, and what could be affected by a change.

Build an inventory with clear ownership and coverage

Discovery provides useful observations about approved IT environments. Those observations become more valuable when teams reconcile them with existing utility CMDB records and identify gaps.

Virima’s IT discovery supports scheduled discovery cycles across supported infrastructure, including servers and network devices. It can bring discovered configuration items and relationships into a CMDB for review, a reconciliation step covered further in Virima’s CMDB for utilities guide. Teams should configure access, scope, and schedules around the utility’s operating requirements.

Bring other authorized sources into the review, including asset registers, architecture records, and service-owner input. A source may report a server’s hardware details while another holds its support owner, so reconciliation helps combine those records, though conflicting attributes still need governance.

Use durable identifiers where available. A serial number can help match a physical device across systems, and a cloud instance ID can help distinguish a cloud asset from another record with a similar hostname.

For each source, define:

1. Coverage — which sites, networks, and asset types are included?
2. Authority — which source supplies each important attribute?
3. Freshness — when was the record last observed or reviewed?
4. Ownership — who resolves missing or conflicting information?
5. Exceptions — which systems require manual records or another approved source?

This is also what NERC’s CIP-010 standard expects for in-scope assets: a documented baseline configuration. That baseline gets checked against what discovery and other sources actually find, with discrepancies tracked rather than assumed away.

A device absent from an approved discovery scope should remain visible as a coverage gap, not evidence that the entire utility environment is covered.

Treat OT discovery as a separate safety decision

OT teams must approve how inventory information is collected from operational environments. Sensitive control systems may have availability, safety, vendor-support, or regulatory requirements that limit active scanning. Agentless methods are typically preferred near OT-adjacent networks because they avoid installing software on systems where vendor support agreements restrict it.

Before any discovery activity, agree on the target scope and method with OT engineering. Test the approach in an approved environment, establish a maintenance window where required, and define stop conditions. Where active discovery is unsuitable, use an approved OT inventory or a manually maintained record.

Virima’s fit for a specific OT device, protocol, or collection method should be validated during evaluation. Utility teams should retain their established controls for grid operations and use approved sources to supply the relevant dependency information.

Map dependencies across the IT and OT boundary

A service map helps a reviewer move from an infrastructure component to the services and teams that may depend on it. For utilities, the value often lies in the handoff between an IT-managed service and an operational system — this is where OT and IT convergence creates the most risk, since a dependency that crosses the boundary is often the one nobody owns.

A map might connect an operations reporting application to its database, hosting environment, and network path. An OT-owned system supplying data to that application may be represented using information approved by its owner. Each relationship should identify whether it was observed, imported, or confirmed manually.

In Virima, teams first provide the definition of the service. They can supply the applications and websites that make up that service manually or through an approved import. Virima’s ViVID™ service maps then build a dependency map from the supplied definition and available relationship data.

A map needs review when a service changes. If a new integration is added, the application owner should confirm its purpose and dependencies. If a relationship cannot be verified, record that uncertainty rather than presenting it as a confirmed connection.

The Cybersecurity and Infrastructure Security Agency’s advisory recommends identifying OT and IT network interdependencies as part of resilience planning. That guidance supports a practical review: identify what each team needs from the other before an incident occurs.

Use dependency context before approving changes

A change record often identifies the component being modified. The review should also identify which services depend on that component and whether the available records are current enough to support a decision — skipping that step is where grid operations risk tends to hide.

Before approving a change to shared infrastructure, the change manager can follow this sequence:

1. Identify the affected configuration item and its owner.
2. Review connected applications and services in the CMDB.
3. Check when the relevant records were last verified.
4. Ask service owners to confirm the expected operational impact.
5. Include OT stakeholders when an operational boundary may be affected.
6. Record the rollback plan and the people authorized to execute it.

Utility teams run into this pattern often: a planned update to a firewall rule used by an operations reporting application touches a connection nobody flagged on the change ticket. The map can help identify the application and its supporting connection, but the application and network owners still need to confirm the rule’s purpose and test the proposed change.

Where a dependency is uncertain, assign an owner to verify it before the change window. If verification is unavailable, document the uncertainty in the change record and follow the utility’s risk-acceptance process.

Skipping that step carries compliance exposure too: five CIP standards accounted for more than 800 reported noncompliances in 2025, the most of any reliability standard category. Records current enough for a change decision are current enough for the next compliance review.

Virima’s CMDB and service maps provide relationship context for this review. The utility’s change authority remains responsible for approval, operational testing, and the decision to proceed.

Give incident responders a shared starting point

During an incident, teams need to know which service is affected and where to begin investigating. A shared service map can help connect an incident record to relevant configuration items and owners.

Start with the affected service rather than assuming that the first alert identifies the root cause. Review its known dependencies, recent changes, and ownership records, then compare those records against monitoring and operational evidence from the systems involved. Each of those checks takes time before the real cause surfaces, and that lag has a cost: the same ORNL analysis found commercial and industrial customers lost an average of $6,031 per outage event in 2024. Virima’s ITOM for logistics analysis covers the same pattern in a different industry, where dashboards look healthy while a dependency has already stalled.

For example, an application may become unavailable after a network change. The service map can identify the network components associated with the application. Engineers can use monitoring data and configuration records to test whether the change contributed to the interruption.

Incident teams should record newly confirmed relationships and correct inaccurate ones after resolution. An incident review can also identify missing ownership information or a dependency that was outside the latest discovery scope.

Useful incident measures include the time needed to identify the responsible owner and the percentage of priority incidents linked to a service record. Establish a baseline before setting improvement targets. Review exceptions with the teams that use the information.

Connect service maps to continuity and recovery plans

A business continuity plan keeps critical work running during disruption; a disaster recovery plan restores the supporting technology and data. Both need an agreed view of service owners and dependencies, which is what IT records support.

For a priority application, compare the service map with its recovery runbook:

• Does the runbook identify the infrastructure required to restore the application?
• Are identity services and network connections included in the recovery sequence?
• Are external providers and their contact paths documented?
• Can the service operate in a reduced mode while a dependency is unavailable?
• Has the operational owner reviewed the sequence?

A map does not prove that a backup can be restored. Recovery teams must test backups, access, and procedures against their own recovery objectives. When a test reveals a missing dependency, update the runbook and the underlying record.

Include communications paths when they support the selected service — the U.S. Department of Energy’s analysis of power and communications interdependencies illustrates why these infrastructure dependencies deserve attention during resilience planning.

Measure coverage before expanding the program

Once the first service is mapped, review the quality of the records before extending the approach. A larger inventory has limited operational value if owners cannot tell which records are current.

Choose measures that reflect the decisions your teams need to make:

Tracking matters because backlogs move: NERC’s own violation backlog, from the same 2025 compliance data cited earlier, dropped by nearly 50% after sustained attention to unresolved items. Virima’s ITOM visibility patterns using CMDB and service context guide covers measures for tracking that kind of progress in an ITOM program.

Set review intervals according to the service’s criticality and rate of change. Share unresolved gaps with the relevant owner — a missing server identifier, an unverified network relationship, an OT dependency awaiting review — and track each one to a decision, correction, or documented exception.

Build a more reliable view of utility services

Utility IT teams can improve decisions by starting with a critical service and tracing its supporting infrastructure. Scheduled discovery, reconciled records, and reviewed service definitions give change and incident teams a stronger starting point — that’s the practical payoff of ITOM for utilities.

Keep OT teams responsible for approving collection methods and validating operational dependencies. Use recovery exercises and incident reviews to correct gaps as they appear.

Frequently Asked Questions