Compliance gaps in insurance software

Ask an insurance engineering team whether their application is compliant, and the honest teams will usually say yes, backed by a policy document and a security review from some point in the past. Ask what in the running system actually enforces any of it today, and the confidence tends to drop. That gap between the document and the system is the subject of this page.

Why a working application hides its own gaps

An application does what its team built it to do. When that team reviews the application, they review it against the design they had in mind, and the design usually looks reasonable, because it was built by people trying to do the job correctly. The gaps are not in the part somebody designed. They sit in the part nobody thought to design, which is exactly why looking at the system from the inside so rarely finds them.

This is a structural problem, not a competence problem. You cannot review a system against a specification that was never written down, and most of the requirements covered across this guide, translated in detail on translating NAIC model law into engineering requirements, were never written down as a specification the team could review against in the first place.

The four places we would look first

State configuration coverage. Compare the list of states the company actually holds an active license in against the list of states with a configured notification rule in the application. A mismatch here, usually a newly licensed state added by the business side with nobody telling engineering, is one of the most common gaps and one of the easiest to check. This is covered in depth on state-by-state data security requirements for insurance software.

Read-path logging. Nearly every application logs writes, because writes were built with an undo history or a change record in mind from the start. Reads are logged far less consistently, because reads happen everywhere and logging all of them was never anyone's explicit goal. A claims adjuster or support agent opening a large number of policyholder records in an afternoon produces no writes at all, and it is exactly the pattern an examiner or a genuine investigation would want visibility into. If your logging only covers writes, that afternoon is invisible.

Data lifecycle across every copy. A record removed from the primary database on schedule can still exist in a backup snapshot, an analytics replica, an export a team member generated for a report, or a log aggregator that captured more of a request body than anyone intended. Retention and disposal obligations apply to every one of these copies, and most retention jobs were only ever built against the primary store because that is the one anyone thinks about.

Whether the incident response plan still matches reality. A plan naming a specific person as the point of contact for a breach is only useful if that person is still in that role. This is checked by trying it: contact the person named in the plan and confirm they know they are still the contact, and confirm the plan's described sequence actually works against the current system, not the system that existed when the plan was written.

Why administrative and internal tools are where gaps concentrate

Customer-facing systems tend to get more scrutiny than internal tools, because customer-facing systems are the ones product and security teams look at regularly. Internal tools, an underwriting dashboard, a claims investigation tool, an internal reporting dashboard, get built quickly to solve an internal problem and rarely get revisited with the same rigor.

If an internal tool transmits, accesses, or stores policyholder information, which most of them do, the same data security requirements apply to it regardless of how few people use it or how quickly it was built. A tool five people use carries the same obligations as a large one, and is simply less likely to have been checked.

Impersonation and bulk access deserve specific attention

Two patterns recur across insurance applications specifically because they are common operational needs. A support or claims tool that lets staff view the system as a policyholder would, for troubleshooting or assistance, very often records the policyholder as the actor in the audit trail rather than the staff member, which is a defect worth checking directly rather than assuming is handled correctly. And a bulk export or reporting feature, built to answer a business question, frequently reads far more policyholder data than any single customer interaction would, without the same logging rigor applied to individual record access.

What a real audit looks like, versus a checklist

A generic compliance checklist tends to ask yes-or-no questions that a team can answer optimistically without verifying anything: "do you have an incident response plan," "is data encrypted." A real audit tests the actual behavior: can the notification workflow correctly identify and notify affected policyholders in a simulated multi-state incident, does calling a restricted endpoint directly with the wrong role actually get refused, does the retention job that ages out records after the required period actually reach the backup copies as well as the primary table.

That distinction, testing behavior instead of collecting yes-or-no answers, is the same argument that runs through the pillar page for this guide and every sub-page in it. A policy that says the right thing is not the same as a system that does the right thing, and the only way to know which one you have is to check.

If you suspect gaps in your own application but are not sure where to look first, get in touch and we will run an audit against your actual obligations rather than a generic checklist.