Building compliant software in insurance / Building it right
Designated security officer and access control
The NAIC model law requires designating an employee responsible for the information security program, which is a governance requirement most companies satisfy easily on paper. The harder, more consequential part is that the program this person is accountable for has to actually control who can reach policyholder data, and access models decay quietly in ways that make a named officer's job much harder than a title implies.
Key takeaways
- Naming a responsible person is a process requirement, easy to satisfy, and it does not by itself constrain who can access data.
- Access decays in one direction: people accumulate permissions as roles change, and removing old access rarely has a deadline or an owner.
- Authorization needs to be tested at the system boundary, not the interface, since a hidden button is not the same as an enforced restriction.
- The designated officer needs tools that show effective access across every system, not a role definition that looks clean on paper.
The NAIC model law requires designating one or more employees responsible for the information security program [1]. This is a governance requirement, and most insurance companies satisfy it without much difficulty: someone gets the title, the title goes in the policy document, and the requirement is met.
What that title is actually accountable for is harder, and it is where the model law's data security requirements connect directly to the shape of a piece of software.
What the designated officer is really accountable for
The security program the officer oversees exists to protect policyholder data, which in practice means controlling who can access it and knowing when they do. If the officer's title is real rather than nominal, they need to be able to answer a specific question honestly: who can currently reach any given policyholder's claims history, and does that match who should be able to. Most companies cannot answer that question quickly, not because the officer is not doing their job, but because the systems were not built to make the answer visible.
Why access models decay even when nobody does anything wrong
Access accumulates in one direction. Someone joins the claims department and gets the claims role. Two years later they move to underwriting and get the underwriting role. Removing the claims role is a task with no deadline, no requester, and a real risk of breaking something if it turns out they still needed a piece of that access for a lingering responsibility. The safe choice for whoever would do the removing is not to, and that choice repeats across every role change in the company.
A review that looks at role definitions will find nothing wrong with this pattern, because the role definitions were never the problem. The check that actually reveals it is different: enumerate every person, list what they can currently reach across every system, and compare that against their current job function rather than their job title. This tends to produce an uncomfortable list of people with more access than their current role requires, and it is the only version of the review that reflects reality.
The harder version of the same problem is that effective access is frequently the sum of several separate grants: an application-level role, a database permission, a cloud identity policy, membership in a shared group nobody remembers configuring. Any one of these looked reasonable when it was granted. The combination is what determines what a person can actually do, and almost nobody computes the combination.
Testing authorization where it actually matters
A common and serious gap is authorization enforced in the interface rather than in the system underneath it. A button is hidden from users who should not have a capability, a menu item does not render, but the underlying endpoint answers anyone who calls it directly, because the restriction was implemented as a display decision rather than a genuine access control.
The test that catches this has to operate at the system boundary, calling the endpoint directly with a role that should not have access, bypassing the interface entirely. Most teams verify that the permitted role succeeds. Fewer verify that every other role, including an authenticated user with no assigned role, a user from a different agency or region, and a role whose account was recently disabled, is correctly refused. That second half is the one that actually constrains an attacker or a curious employee, and it is the one worth building the check for first.
Impersonation and shared access need their own logging
Insurance operations frequently involve a support representative or claims adjuster acting on a policyholder's behalf, sometimes through a tool that lets staff view the system as the customer would see it. This kind of impersonation feature is genuinely useful, and it is also a common place where the audit trail records the wrong actor.
The requirement is straightforward to state: an action taken by a staff member while impersonating a policyholder should record the staff member as the actor, not the policyholder, and impersonation sessions should be logged as their own distinct event, separate from ordinary customer activity. Getting this wrong means the audit trail asserts that a customer took an action a staff member actually took, which undermines the trail's value exactly where a security officer would need it most.
Giving the designated officer real visibility
The most useful thing a software team can build for the person the model law makes accountable is a working view of effective access, computed automatically: who can reach what, across every system, updated continuously rather than reconstructed manually once a year before an audit.
That view should flag the combinations that matter most: any account with access spanning more systems than its role suggests it needs, any elevated or break-glass access that was granted temporarily and has not expired on schedule, and any service account whose granted permissions exceed what it has actually used over a recent period. Building this as an ongoing, checked capability, rather than a spreadsheet assembled under time pressure before an exam, is what turns the designated officer's title into a role that can actually be exercised.
Where this connects to the rest of the build
None of this replaces the governance side of the requirement: the company still needs to formally designate the person and document the program. What the engineering side contributes is making sure that person's job is actually possible, by building access control that can be inspected and tested rather than assumed. This connects directly to compliance gaps in insurance software, which covers the broader pattern of gaps that exist precisely because nobody built the visibility to see them.
If your company has a designated security officer who currently has no reliable way to answer "who can access this policyholder's data right now," that gap is worth closing before an examination forces the question. Get in touch if you want help building that visibility.
Common questions
What does the NAIC model law require regarding a designated security officer?
It requires designating one or more employees responsible for the company's information security program. This is a governance requirement that most companies satisfy by assigning the title and documenting it, though the harder part is making sure the systems that person oversees actually support answering who can access policyholder data.
Why do access permissions decay over time even without any mistakes?
Because access accumulates in one direction. People gain new roles when their job changes and rarely lose the previous role's permissions, since removing access has no deadline, no requester, and a real risk of breaking something if the removal turns out to be premature. This pattern repeats across every role change and gradually detaches the permission model from actual job function.
How should a company check whether its access model still matches reality?
By enumerating every person's effective access across every system and comparing it against their current job function rather than their job title or role definition. Reviewing role definitions alone finds nothing wrong, because the roles themselves were never the source of the gap.
Why is hiding a button in the user interface not sufficient access control?
Because the underlying system endpoint may still respond to anyone who calls it directly, even if the interface hides the option from users who should not have access. Authorization has to be enforced and tested at the system boundary, because what the interface chooses to display is a separate layer an attacker can bypass.
What is the risk with impersonation features in insurance applications?
Impersonation tools, which let staff view the system as a policyholder would, commonly record the policyholder as the actor in the audit trail rather than the staff member performing the action. This means the trail can incorrectly show a customer took an action a staff member actually took, which undermines the trail exactly where accountability matters most.
What tools does a designated security officer need to do the job effectively?
A working, continuously updated view of effective access across every system, refreshed automatically rather than reconstructed once a year before an exam. That view should surface accounts with unusually broad access, elevated permissions that were granted temporarily but never expired, and service accounts holding permissions beyond what they actually use.
Is service account access subject to the same scrutiny as employee access?
Yes. Service accounts and integration credentials are frequently provisioned with broad access at the start of a project and never revisited, often ending up with the widest effective access in the whole system. They should be reviewed against what they actually use over a recent period, the same way employee access is reviewed against current job function.
Does naming a designated security officer by itself improve data security?
Not on its own. Naming the officer satisfies a governance requirement, but the actual security depends on whether the systems that person oversees can be inspected and tested, including access control, audit logging, and impersonation handling. A title without that underlying visibility does not change what data is actually exposed.
Related reading
Why permissions are the hardest part of an AI feature
A normal feature shows one user one screen. An AI feature reads across everything it can reach and writes a summary, and a summary has no permission model.
A practical pre-launch security review for a small team
You do not need perfect security to launch. You need to check the handful of basics that catch most real problems, and to know when the risk is big enough to bring in a specialist.