ITOM in Insurance: Why Claims and Underwriting Systems Fail Quietly

In June 2025, Erie Indemnity disclosed an information security event that disrupted network systems used for quoting, servicing, billing, claims, and its mobile app. Agents and call centers had to take claims by phone while core platforms were offline, according to Insurance Journal. The same week, Philadelphia Insurance Companies reported a separate outage and said it could underwrite policies, review claims, and service customers only by falling back to manual channels.

For the people who keep the configuration record honest, those weeks look familiar. Monitoring tools fire alerts and tickets multiply while nobody can state, from a current record, which underwriting components sit downstream of the failing claims path. ITOM in insurance is supposed to keep operations stable. In practice, it often fails quietly when the dependency picture under claims and underwriting is stale, partial, or tribal.

What Is ITOM in Insurance?

IT operations management covers the practices that keep IT services available, change-aware, and recoverable. Grounded in ITIL 4 management practices, day-to-day ITOM work typically spans event handling, incident and problem management, access and capacity concerns, and the configuration data those practices consume. In insurance, the same practices sit under policy administration, rating engines, claims intake, document services, billing, and third-party data feeds such as credit, telematics, and MGA platforms.

Regulatory pressure widens what operations must cover. The NAIC Insurance Data Security Model Law (#668) expects licensees to maintain a written information security program, an incident response plan, and documented oversight of third-party service providers. A discovery-sourced CMDB and dependency map are upstream infrastructure for that visibility. They are not the compliance program itself, and they do not replace the insurer’s security controls or commissioner-facing process.

Core requirements for ITOM in an insurance context include:

• Authoritative CI visibility across claims and underwriting stacks
• Dependency mapping between policy admin, rating, document management, and external data providers
• Change-impact awareness before deployments hit shared platforms
• Incident correlation that joins ITSM records with the same CI graph monitoring tools already in place

Eliminate data decay with Virima’s discovery-sourced Trusted Runtime Truth™ across claims and underwriting configuration records.

Why Is ITOM Important for Insurance?

Claims and underwriting are where downtime is visible to policyholders, regulators, and the board at once. A claims outage delays payouts and catastrophe response. An underwriting outage delays new business and renewals. Monitoring still matters, yet without a trusted map of what those monitors attach to, ITOM stays a stack of alerts without a shared operational story.

Industry outlooks keep pointing at the same foundation. Deloitte’s 2026 Global Insurance Outlook ties practical AI work in fraud and underwriting support to improved data quality, legacy modernization, and cybersecurity. KPMG’s March 2026 analysis on modernizing legacy systems for insurers frames the larger risk as inaction: each year on aging cores grows technical debt, raises modernization cost, and tightens regulatory expectations.

Four Failure Modes That Keep Claims and Underwriting Quietly Fragile

These modes describe how the break starts inside the estate. Stakeholder dollars, commissioner pressure, and procurement fallout sit in the next section, not here.

1. Silent third-party hop on claims intake
   A document or imaging vendor ships a patch against an API that never appeared as a managed CI. Claims UI hosts still look healthy while FNOL packets stop landing in the intake queue.
2. Underwriting integrations absent from the trusted CI set
   Rules engines, rating endpoints, and bureau feeds live in runbooks and tribal memory instead of the CMDB. CAB packets list the release host and miss the quote-path hop that actually carries risk.
3. Hybrid claims inventory reconciled by spreadsheet
   On-prem cores and cloud batch workers update on different discovery calendars. Owners spend recurring hours each week stitching two inventories before anyone trusts a change window.
4. One data tier booked as two business services
   Claims and underwriting open separate severity-one tickets against the same database cluster. War rooms diverge until someone rebuilds the join on a whiteboard.

The Real Cost of Getting ITOM Wrong in Insurance

This section covers who pays when the failure modes above go unaddressed. It does not restate the four technical breaks.

For Leaders

Board exposure shows up when a claims blackout hits a catastrophe window, and executives cannot name systems and vendors in the blast path from a current record. Industry breach economics keep the conversation expensive: IBM’s Cost of a Data Breach research continues to price prolonged detection and response as a multi-million-dollar drag once operational systems and customer data sit in the same event. Commissioner and board briefings then start from reconstruction instead of evidence, which is a leadership cost the CMDB owner rarely owns on paper but always feels in the room.

For Underwriting and Claims Operations

Procurement and partner diligence now treat severe-incident history and restore discipline as selection criteria, not afterthoughts. The EU’s Digital Operational Resilience Act (DORA) overview from EIOPA makes ICT incident handling and third-party ICT risk part of the formal resilience story for in-scope financial entities. Carriers that cannot show clean incident trails and restore paths for claims and underwriting platforms lose ground in vendor RFPs and MGA diligence long before the next outage ticket closes.

For Regulated Environments

NAIC Insurance Data Security Model Law (#668) expects a written information security program, an incident response plan, and documented third-party oversight. When affected CIs and vendors cannot be listed quickly, market-conduct and commissioner questions land on the CMDB owner as weekend evidence hunts. Technology risk belongs in an operational register with living inventory behind it, not in a one-off binder rebuilt under deadline pressure after every exam notice.

Market-Scale Challenge

Deloitte’s 2026 Global Insurance Outlook already tied AI and modernization outcomes to data quality and legacy uplift earlier in this article. The unpaid bill is estate complexity itself: decades of sparsely documented rules, batch windows, custom interfaces, and data semantics inside P&C cores. Modernization and agentic programs inherit every undocumented hop the CMDB never held, so program budgets fund rediscovery work that should have been standing inventory.

How Dependency Visibility Fixes This

This is the CMDB owner’s daily work: fewer hours lost to reconciliation, fewer CAB surprises, fewer which-ticket-is-real debates when claims and underwriting fail together. The fix is not another monitor. It is a trusted visibility layer under the monitors and ITSM tools already in place. Carriers already run SolarWinds, Nagios, LogicMonitor, or an APM stack for signals. What those tools cannot supply alone is a current join between the alerted host and the claims or underwriting path the business actually sells.

1. High-Frequency Discovery Keeps the Asset Picture Current

IT discovery software refreshes CI records on a scheduled, high-frequency cadence across agent-based, agentless, and API paths. Claims and underwriting inventories stop drifting silently between audit seasons. Owners see source and last-verified context on the record instead of debating whose spreadsheet is newer. Discovery does not watch transaction latency; it keeps the asset and relationship picture current enough that monitoring and ITSM can agree on what failed.

2. A Live CMDB Gives Claims and Underwriting a Shared Record

A discovery-sourced CMDB stores the same trusted CI set for change, incident, and audit consumers. CAB and incident responders stop working from parallel truths. The hours saved show up as less manual join work before every major release and every regulatory ask. Source tags and last-verified timestamps travel with each CI so the owner can defend the record without opening three spreadsheets. When underwriting and claims both consume the same data tier, one CI graph prevents two owners from inventing two different inventories of the same cluster.

3. ViVID™ Maps Overlay Incidents, Changes, and Monitoring Alerts

Once service composition is defined, ViVID™ service mapping places ITSM incident and change records, plus monitoring alerts from the carrier’s existing tools, onto dependency maps. Responders see which underwriting components sit downstream of a claims failure without stitching that path on a war-room whiteboard. The map does not replace the monitor; it tells the monitor which business path is bleeding. Virima strengthens the ITOM and monitoring stack a carrier already runs. It does not replace APM or infrastructure monitoring, and it does not claim to watch claims transaction latency by itself.

ITOM in Insurance: Examples in Practice

These scenes show the map in use after the failure modes and cost stakes are already clear. They stay on outcomes, not on restating the four technical modes above.

• Catastrophe surge week. Dependency maps show which payment and document hops sit under FNOL so surge staffing routes tickets to the right CI owners instead of every claims queue at once. Call centers stop guessing which queue owns a stalled packet when the map names the hop.
• Rating calendar cutover. Discovery refreshes the bureau endpoint CI before the rating window, and CAB sees the quote-path consumers on the same packet. Underwriting avoids learning about a silent format change only after quotes fail in production.
• Market-conduct evidence pull. Owners export a timestamped vendor-dependency extract for the lines under review without rebuilding the inventory from chat threads. The extract carries last-verified context so exam prep starts from known CIs rather than tribal memory.

The Visibility Layer Under Claims and Underwriting

Virima sits under claims and underwriting stacks as discovery-sourced runtime truth, not as a second monitoring console. The layer feeds the same ITSM and monitoring tools carriers already trust, rather than asking operations to abandon them for a parallel stack. Service composition still has to be defined before maps render. Once it is defined, dependency overlays travel with the ITSM record the operator already lives in.

Immediate Operational Impact

When a claims outage overlaps a recent change, ViVID™ overlays help the CMDB owner and responders name affected CIs faster. Time returns as fewer hours are spent reconciling ticket trees and vendor bridges during the first hour of an incident. That is personal hours back for the owner, not only a cleaner MTTR slide for leadership.

Long-Term Accuracy

High-frequency scheduled discovery reduces drift between audits. Accuracy that holds between cycles is also what makes the next budget conversation easier for a role that often lacks a hard executive mandate. Standing inventory turns weekend evidence hunts into a query against known CIs and vendors.

Integration with Existing Workflows

Bi-directional ties to platforms such as ServiceNow, Ivanti, Jira Service Management, HaloITSM, and Xurrent keep maps inside tools teams already use. Partner names stay plain text in this section so the piece does not become a partner directory. The single hub for those connections is Virima’s integrations directory, so the article does not scatter partner deep-links. Operators keep their familiar ticket and change screens while the dependency layer fills in what those screens never stored cleanly.

Moving from Manual Tracking to Map-Driven Operations

Faster CAB Reviews

Reviewers see downstream claims and underwriting consumers before approval, not after a failed release. Packets stop treating the release host as the whole story when quote-path and document hops sit on the same view.

Faster Incident Root Cause

Shared maps cut duplicate bridges between claims and underwriting queues. One data-tier failure stays one root cause instead of two war rooms racing each other. The CMDB owner spends less of the outage window acting as a human join key between two service desks.

Stronger Evidence Trail

Query-ready CI and vendor relationship records support internal audits and third-party oversight questions once risk tracking has a living inventory behind it. Insurance already appears as a practical service-mapping use case when teams compare mapping approaches for regulated service lines. When the same evidence gap has to be priced for leadership, Virima’s CMDB TCO analysis gives the CMDB owner a structured way to turn reconciling hours and exam prep into a business case.

Getting Started

1. Inventory systems that support claims intake, underwriting, policy servicing, and payments, including the third-party hops those systems already call in production.
2. Mark where dependency knowledge lives only in people’s heads, runbooks, or outdated diagrams that never survived the last cloud migration.
3. Run discovery first against claims and underwriting estates so the highest-stakes CIs receive source tags and last-verified timestamps before lower-risk utilities.
4. Layer ITSM and monitoring overlays onto the service map once composition is defined, so alerts and changes land on the same graph operators already trust for tickets.
5. Use the current CMDB as the evidence base for the next internal NAIC-oriented review, and keep the extract queryable instead of freezing a one-time spreadsheet.

If the harder part is funding the fix after the gap is clear, Virima’s CMDB TCO analysis lays out the business-case structure owners often need for leadership. Walk hours already spent on reconciliation, CAB prep, and exam evidence against the cost of another year of manual joins, then decide whether discovery-sourced inventory is the cheaper path.

Frequently Asked Questions