ServiceNow Discovery for Insurance

An insurer's discovery inventory is the record of servers, workstations, cloud workloads and vendor systems across its claims centres and head office, built by scanning and reconciling the estate. This page helps an infrastructure or CMDB lead decide which business service to scan first, which zones need their own path and what to leave out of the first wave.

Distributed IT Infrastructure and Multi-Site Visibility

Insurance organisations operate claims processing centres across multiple cities, each with its own servers, workstations, and local applications. Regional offices process claims, issue payments, and manage policyholder communications independently, yet all connect to central systems for policy storage, underwriting, and financial consolidation. Discovery must capture this distributed infrastructure accurately, tracking which systems run at headquarters, which at regional centres, and which in cloud environments.

Insurance IT teams struggle with shadow IT—applications deployed by regional teams without central approval or documentation. Claims processors use small databases and spreadsheets to track local work. Discovery helps identify these undocumented systems so they can be evaluated for integration, security compliance, or decommissioning. Insurance organisations often find that enabling comprehensive Discovery reveals systems the central IT team did not know existed.

Policyholder Data Protection and Compliance

Insurance organisations hold sensitive personal and financial data: policyholder names, addresses, social security numbers, claims history, and health information. State insurance commissioners and privacy regulators require organisations to know which systems store this data and maintain inventories of endpoints that access it. Discovery feeds this compliance obligation by capturing which servers and workstations process policyholder information.

Insurance compliance teams use Discovery inventory to verify that systems handling policyholder data are encrypted, patched, and monitored. Discovery results identify systems that may lack required security controls. For example, an older claims system discovered on a regional network might not have disk encryption; compliance flags it for remediation or decommissioning.

Third-Party Systems and Vendor Management

Insurance organisations contract with underwriting vendors, claims adjusters, and service providers. These vendors access policyholder data through secure connections. Discovery must account for these third-party integrations—identifying which external systems connect to the insurance organisation’s network and what data flows across these integrations. Vendor management teams use this information to ensure that only authorised third-party systems have access.

Some insurance vendors run software on customer premises—a claims adjustment system installed on a regional office network. Discovery captures these vendor systems and flags them for ongoing monitoring. Insurance compliance teams verify that vendor systems meet the same security and audit standards as internal systems. Change management processes ensure that vendor software updates do not disrupt policyholder workflows.

Underwriting and Rate Engine Infrastructure

Rate engines and underwriting systems are core insurance applications. These systems calculate premiums, assess risk, and determine eligibility. They run on centralised servers and connect to regional workstations where underwriters and rate specialists work. Discovery must identify all systems that feed rate engines—external data sources, validation systems, and reporting platforms. This dependency mapping is critical for recovery planning and impact assessment.

Insurance organisations often rely on legacy underwriting systems running on mainframes or older platforms. Discovery must be tuned to capture these systems accurately. Some insurance IT teams supplement automated Discovery with manual inventory for mainframe applications, ensuring that legacy systems are represented alongside modern cloud infrastructure.

Discovery Implementation Checklist

• Map all insurance organisation locations—headquarters, regional offices, claims centres—and plan discovery for each.
• Identify systems that handle policyholder data and prioritise their discovery and documentation.
• Document third-party vendor systems and data integrations.
• Catalogue mainframe applications and legacy systems separately if they are not automatically discoverable.
• Verify that discovery respects data privacy—scans should not exfiltrate policyholder data.
• Establish baseline inventory through initial discovery run.
• Schedule ongoing discovery runs to capture new systems and track decommissioning.
• Configure discovery exclusions for systems that cannot tolerate scanning.
• Validate that discovered assets match vendor and system documentation.
• Train claims and underwriting staff on how to request new systems through change management.

Common Pitfalls

Insurance organisations sometimes fail to discover systems in regional offices, assuming that all critical systems are at headquarters. Distributed discovery runs across all locations is necessary. Another mistake is incomplete vendor system documentation—third-party software may run on customer premises without central IT knowing all instances. Some insurance IT teams discover overly broad asset classes, creating confusion between the systems that matter for compliance and the full list of network-connected devices.

Deciding what Discovery should scan first in a regulated estate

Many insurance discovery projects do not fail because the scanning technology is weak. They fail because the first run covers the wrong part of the estate, produces a result nobody trusts, and the CMDB team then spends the next quarter arguing about duplicates. The reader for this section is the infrastructure or CMDB lead who has been handed a discovery mandate and has to choose the order of work. Before any probe is installed, decide which business service goes into the first wave. A sensible first wave is one claims or policy service with a named owner, a written architecture and a host list the team can check by hand. The CMDB approach for insurance covers the inventory of business-critical systems that each wave’s results are recorded against. A narrow wave gives you a baseline you can verify, and it exposes credential and network problems while the blast radius is small.

Two decisions come before anything is scheduled. The first is which MID server group reaches which network zone. A regional claims office behind its own firewall needs its own path and its own credential set, and that path is often the thing that delays the project. The second is who approves the scan window for each zone. Insurance estates carry old policy administration hosts that were never designed to be probed, and a sweep that is harmless on a modern server can stall an old box until someone intervenes. Treat a scan window as a change, not as a default setting.

Choosing a discovery approach for each kind of asset

The table shows why one scan setting cannot cover an insurance estate. The distributed hosts respond well to credentialed scanning. The mainframe does not, and a discovery run that returns almost nothing for it can look like a clean result on a dashboard. Record legacy platforms from the owner’s inventory, link them to the hosts they call, and mark them as a different evidence type so nobody mistakes them for scanned records.

What usually goes wrong in the first three discovery cycles

Duplicates often appear first. Private addressing is reused across regional sites, so one address can point at two machines in two offices, and a single physical host can be recorded under two names when the hostname and serial number disagree. Identification rules are the control here. If they are left at defaults, the reconciliation engine either creates duplicates or merges records that should stay apart. The false merge is the worse outcome. Two regional claims servers with similar hostnames collapse into one configuration item, and the dependency map then shows one server supporting two services. A problem can go unnoticed until an impact assessment is wrong.

Credential failures are the second pattern. A scan that works for the central data center can fail silently for a regional office because the service account was never created there, or because a password rotation missed a local domain. Build a credential test for each host type before any cycle, and read the failure report as carefully as the success report. The credential governance guidance explains who should own those accounts.

An ordered procedure for the first wave

1. Name the business service and its accountable owner, and list the hosts the service documentation already mentions.
2. Confirm the MID server group and the network path for each zone, then test one credential per host type before anything is scheduled.
3. Agree the scan window for each zone with the people who run the fragile hosts, and record every exclusion with a reason.
4. Run one discovery cycle and export the result.
5. Compare the export against the known host list line by line, and classify each difference as missing, extra, duplicate or wrong attribute.
6. Tune identification rules and credentials for the differences that repeat, then run the cycle again.
7. Extend the scope to the next service once its owner accepts the first one.

How to tell the inventory can be trusted

The stronger test is a sample taken by the people who run the service. Pick a handful of records at random from each zone and ask the owner whether each one exists, whether the operating system is right, and whether the listed relationships are real. A sample that the owner signs off gives you evidence for the next wave, and a sample that fails tells you which identification rule to fix before the number of records grows.

When to leave a segment out of discovery

Not every segment should be scanned. The first-scope planning guidance covers deciding what discovery should identify, from which environments and under whose authority. A network zone that carries regulated policyholder data may need a security approval before any probe is allowed, and a device that cannot tolerate probing should be recorded by hand. The mistake is to leave these out silently. Put them on the exclusion list with the approver, the reason and a date for review. An exclusion list that is current is a control. One that nobody reads is a gap an auditor is likely to find.

Questions about running Discovery in an insurance estate

Should scanning pause while a catastrophe response is under way?

Usually yes, for the zones that carry the response work. The discovery schedule page explains how the schedule controls when and how often scans run, which is where such a freeze would be applied. Claims intake and adjuster systems are under heavy load during a surge, and a scan adds traffic at the moment the business can least absorb it. Agree a freeze with the claims operations lead in advance, record it as a standing exclusion, and restart the scan only after the operations lead confirms that load has returned to normal.

Can Discovery replace the manual asset register?

It can replace the parts of the register that describe hosts and software on the network. It cannot replace records for equipment that never joins the network, such as spare laptops in storage or devices held by field staff who work offline. Keep the register for those, and reconcile the two so that each device has one owner of record. The IT asset management page for insurance covers how insurers manage their technology assets, which is the register side of this reconciliation.

Who should own the exclusion list?

The CMDB owner should hold the list, but each exclusion needs a business or technical approver who can explain why it exists. Review the list on a fixed cycle, and remove an exclusion as soon as the reason has gone, because an old exclusion quietly hides a real part of the estate.

What do we do when a regional office has no usable network path?

Record the office as a known gap with a planned fix, not as a successful zone. Options include a dedicated probe at the site, a collector placed in a shared location, or a manual inventory for a short period. Each option has a cost and a security question, and the choice belongs to the infrastructure lead with the security team involved.

Next step

For the wider sector context, see financial services.