Insurance Shadow IT Is Usually Old Acquisitions, Not Rogue SaaS
Insurance carriers rarely build IT from scratch. They grow by acquiring books of business, agencies, and regional carriers. Every acquisition arrives with its own policy administration system, claims platform, data center footprint, and integrations already running. That growth model is also how shadow IT accumulates.
Finding shadow IT at an insurance carrier has to start from that structure, not from the generic “employees bought unsanctioned SaaS” story. At a P&C, life, or health carrier, the unmanaged stack is often inherited infrastructure left after deal integration ran out of capacity. This piece covers why those systems survive long after migration decks say “done,” what inventory expectations under NAIC model-law programs and NYDFS Part 500 put on the table, and how recurring, multi-source IT discovery for insurance carriers keeps finding what a one-time M&A audit forgets.
What shadow IT means at an insurance carrier
In most industries, shadow IT means unsanctioned SaaS or personal devices outside IT’s list. At a carrier that grew through acquisition, the pattern is different.
Shadow IT is often:
- A policy administration system from an acquired regional carrier still serving one legacy line
- A claims platform kept for open long-tail files after the “main” migration closed
- An agency portal or rating engine tied to a book of business nobody re-homed
- On-prem servers or a small data center footprint that came with the deal and never entered the parent CMDB — unmanaged the moment ownership changed hands
- Vendor-hosted environments still billed under an inherited contract the parent never re-reviewed
These systems were usually known at close. Project plans named them. Integration backlogs ranked them. They became shadow gradually: owners changed roles, the deal team disbanded, the next acquisition consumed capacity, and the inventory stopped listing what still answered pings.
Forgotten is a better word than rogue. The risk is the same. You cannot patch, segment, or certify what you no longer list.
What does shadow IT look like at an insurance carrier?
At carriers that grow through mergers and acquisitions, shadow IT is often inherited systems: policy admin, claims platforms, agency portals, and infrastructure from prior deals that never fully decommissioned. Those assets were usually known at close and faded from inventory as owners and roadmaps moved on, not as employee-chosen rogue SaaS.
Why these systems never fully decommission
Two structural forces keep them alive after the slide deck says “migration complete.”
Long-tail liability. Environmental and product liability claims can surface years or decades after the underlying event. A policy written long ago can still generate work today. Records, and sometimes the applications that hold them, cannot be wiped when a migration project ends. Closing the box means resolving exposure first. Until then, the system stays online “for now.”
Integration capacity runs out. Core development and integration teams get pulled to the must-have platforms in a merger. Lower-priority systems land on a “later” list. Later rarely comes. Modernization budgets do not close that gap either: North American insurers are on track to spend $10.5 billion on core IT modernization between 2024 and 2026, according to an analysis cited by Duck Creek. That money is aimed at flagship platforms, not decade-old acquisition residue. Institutional knowledge of what those legacy platforms do erodes as people leave. The parent still pays power, licenses, or a vendor retainer for something the architecture diagram no longer shows.
Illustrative pattern (not a named carrier): a policy administration system from an acquired regional book stays up for one legacy casualty line years after the official cutover. The reason is not nostalgia. Closing it requires a claims and legal path through open and potential long-tail exposure. Until that path exists, discovery still needs to see the box as a live asset with an owner, not as folklore.
Disposal and retirement discipline only works after you know what still exists. Adjacent guidance on IT asset disposal assumes that inventory step is already honest.
The regulatory clock is already running
This section is general awareness, not legal or compliance advice. State adoption, scope, and deadlines vary. Confirm current obligations with your compliance and legal counsel before you rely on any date or control detail.
NAIC Model Law expectations
The National Association of Insurance Commissioners (NAIC) Insurance Data Security Model Law (#668) has been adopted in some form across many states. In broad terms, model-law programs expect carriers to maintain a complete, accurate information technology asset inventory as part of the information security program. They also expect visibility into third-party service providers, with certification and documentation practices examiners can review. Exact text and adoption status differ by jurisdiction. The practical IT implication is stable: an inventory that only covers the systems the current architecture team loves will not match what risk and GRC need to defend.
NYDFS Part 500’s inventory requirements
The New York Department of Financial Services (NYDFS) cybersecurity regulation, 23 NYCRR Part 500, applies to many New York-licensed insurers and other covered entities. Amended requirements under Section 500.13 tightened asset inventory expectations, including attributes such as ownership; location; classification; support expiration; and recovery time objectives. A material effective date for those inventory-related obligations was November 1, 2025, and covered entities must also certify compliance with these requirements in annual Part 500 filings due April 15, 2026. As of this writing, the effective date has passed and the certification deadline is the next milestone on the calendar. For covered entities, gaps left by unfinished M&A residue are a present inventory problem, not a future project theme.
What is the NYDFS Part 500 asset inventory certification deadline?
New York-regulated insurers covered under 23 NYCRR Part 500 must certify compliance with the amended asset inventory requirements in annual filings due April 15, 2026 — a deadline that follows the November 1, 2025 effective date for the underlying inventory obligations under Section 500.13. Confirm your entity’s specific obligations with counsel.
Compliance, Risk, and GRC leaders feel this first at certification time. IT Directors feel it when an examiner or internal audit asks for evidence the CMDB cannot produce. Neither group needs another one-off spreadsheet sprint. They need a discovery and inventory process that keeps finding what deal teams left behind.
See how Virima approaches trusted runtime truth for discovery-sourced asset and configuration context teams can explain in operations and exam conversations.
What does the NAIC Insurance Data Security Model Law expect for asset inventory?
Model Law #668 frames a risk-based information security program that includes a complete, accurate IT asset inventory and attention to third-party providers, with certification and documentation practices examiners can review. State adoption varies. Treat this as awareness and confirm your jurisdiction’s adopted text with counsel.
The trap: one-time deal audit instead of a continuous problem
Insurance already has a discipline for reconstructing historical coverage and records around a transaction. Practitioners sometimes call it insurance archaeology: forensic work to rebuild what covered what, when. That work is valuable for claims and legal outcomes. It is a point-in-time exercise run around a deal.
IT inventory is a different job. Systems the archaeology or due-diligence team never formally closed out drift back into invisibility when the deal team disbands and the next acquisition absorbs attention. Treating asset visibility as a project you re-run only at deal time is how a carrier accumulates three, four, or five generations of unaccounted M&A residue.
A one-time audit answers what you bought last quarter. Recurring discovery answers what still runs from everything you ever bought.
Why IT discovery for insurance carriers has to be recurring, not one-time
The fix is multi-source IT discovery on a scheduled cadence, not only around a transaction. Agent-based discovery covers endpoints and devices that move. Agentless network discovery reaches legacy on-prem segments acquisitions often leave behind. Cloud and virtualization discovery covers workloads that landed in AWS or Azure after partial migrations.
Results feed a CMDB that reconciles conflicting records from different eras and acquired tools using defined source rules, instead of a blind “latest scan wins” overwrite. That discipline preserves the deal-era identifiers you still need.
Virima’s role is asset discovery and inventory, plus configuration history for ownership and change evidence. It is not a legal service, not insurance archaeology, and not a certification product for NAIC or NYDFS. Discovery runs on scheduled cycles, not passive real-time event streams. Multi-source reconciliation merges agent, agentless, and cloud inputs into CI records with audit history Compliance and Risk can show. Integrations with ServiceNow, Jira Service Management, Ivanti, HaloITSM, Xurrent, and Hornbill keep inventory where tickets already live.
For broader discovery failure modes, see Virima’s guide to seven asset discovery challenges. Once assets are named, gaps feed an IT risk register practice.
How is continuous IT discovery different from a one-time M&A due-diligence audit?
M&A due diligence and insurance archaeology are point-in-time forensic exercises around a transaction. Recurring IT discovery keeps scanning networks, endpoints, and cloud estates on a schedule so systems left unfinished after prior deals stay visible in the CMDB after the deal team leaves. One answers what you bought; the other answers what still runs.
Where to start: scope discovery against acquisition history
| Starting move | What to do | Why it surfaces M&A shadow IT |
|---|---|---|
| Acquisition map | List every acquisition, agency absorption, and book purchase, including “fully migrated” deals | Legacy systems cluster on unfinished deal footprints |
| Long-tail lines first | Prioritize casualty, environmental, and product liability paths where old records stay load-bearing | Liability keeps systems alive after cutover slides end |
| Third-party cross-check | Match discovered systems to vendor relationships inherited at close | NAIC-style programs expect provider visibility; orphaned vendor stacks are common residue |
| Owner gap flag | Treat “no current owner” on a live CI as a first-class finding | Missing ownership is the signature of deal-era drift |
Work sequence that stays honest about roles:
- Build the acquisition timeline with IT and corporate development, not only current architecture.
- Point discovery at segments and credentials still associated with those footprints.
- Reconcile discovery output into the CMDB with clear source priority rules.
- Assign owners for every live CI on regulated or customer-data paths; escalate blanks to Risk.
- Align inventory exports with Compliance evidence needs without treating discovery as certification.
- Keep discovery on a schedule so inventory does not freeze after the last deal closes.
ITAM lifecycle tracking helps once discovery has named the hardware and software still in play.
Keep finding what acquisitions left behind
Shadow IT at an insurance carrier is rarely about what employees added last month. It is about what decades of consolidations left running. Long-tail liability and exhausted integration capacity keep those systems alive. Inventory mandates under NAIC model-law programs and NYDFS Part 500 raise the cost of pretending the spreadsheet is complete. A one-time M&A audit cannot substitute for discovery that keeps running after the deal team leaves — that’s what continuous IT discovery for insurance carriers is built to catch.
See how Virima’s multi-source IT discovery surfaces systems prior acquisitions left behind, with CMDB history built for ongoing visibility rather than a single forensic scramble. When you’re ready to walk through your specific environment, request a demo.
Frequently Asked Questions
Why do legacy systems from past insurance acquisitions stay online?
Long-tail liability can require records and sometimes applications years after a policy is written. Integration teams also prioritize must-have platforms in a merger, so lower-priority systems slip off the roadmap while they still answer on the network. Both forces leave live assets outside the current architecture diagram.
Does NYDFS 23 NYCRR 500 require a complete asset inventory?
Amended Part 500 includes strengthened asset inventory expectations under Section 500.13 for covered entities, with a material November 1, 2025 effective date for those inventory-related requirements and an annual certification deadline of April 15, 2026. Scope and applicability depend on entity type. Confirm current text and your coverage with counsel; this is not legal advice.
How should Compliance and IT share ownership of insurance IT inventory?
IT runs discovery, CMDB hygiene, and ownership assignment on live assets. Compliance and Risk define evidence standards for certification and exams. A shared inventory of what still runs from prior acquisitions is the handshake: IT finds and maintains; GRC uses the record without treating the discovery tool as a legal opinion.
Does Virima certify NAIC or NYDFS compliance or replace M&A due diligence?
No. Virima provides scheduled multi-source discovery, CMDB inventory, and configuration history. Certification, legal due diligence, and insurance archaeology remain with the carrier’s counsel, compliance program, and deal advisors.
