Missouri Insurance Data Security Act: What Is Due and When?

Counsel has told you the company is a licensee under Missouri’s Act and that the program has to be running on January 1, 2027. The part most tenants get backwards is which duty is soft and which is hard. The statute lists multifactor authentication as a control the program may include, according to section 375.1405, while an insurer domiciled in Missouri has to keep five years of records behind its annual certification, and no Microsoft 365 audit default reaches five years. This guide maps the statute’s own words onto the tenant, marks where Microsoft’s defaults fall short, and sets out the order of work across both dates.

Before anyone scopes the tenant, the first decision is whether the entity is inside the Act at all, and the statute and the Department answer that in different places. The Act names itself plainly: section 375.1400 gives sections 375.1400 to 375.1427 the name Insurance Data Security Act and states that they “establish the exclusive state standards applicable to licensees for data security, the investigation of a cybersecurity event as defined in section 375.1402, and notification to the director.”

The definition of who it binds is broad. According to section 375.1402, a licensee is “any person licensed, authorized to operate, or registered, or required to be licensed, authorized, or registered under the insurance laws of this state, but shall not include a purchasing group or a risk retention group chartered and licensed in a state other than this state or a licensee that is acting as an assuming insurer that is domiciled in another state or jurisdiction.”

Missouri’s regulator has narrowed that in guidance. According to the Missouri Department of Commerce and Insurance in Insurance Bulletin 26-01, issued January 5, 2026, the Department does not consider the following to be licensees under the Act, in a list it describes as nonexhaustive: health services corporations, health maintenance organizations and prepaid dental plan corporations under chapter 354; captive insurance companies and special purpose life insurance captives under chapter 379; Missouri mutual insurance companies under chapter 380; associations licensed under chapter 383; and certain providers registered under chapter 385. The Department’s reasoning, in the same bulletin, is that the laws governing those entities provide that general insurance laws do not apply to them unless certain requirements are met. The bulletin states that it does not have the force of law, is not an evaluation of any specific facts, and is not binding on the Department.

The Act is already in force. According to section 375.1427, the sections took effect on January 1, 2026; January 1, 2027 and January 1, 2028 are implementation dates on top of a statute that is already law, not the Act’s own start date. Missouri’s Act is based on NAIC Model Law 668, and the Department’s Bulletin 26-01 names Alaska, Connecticut and Kentucky as other states that have implemented the same model law, in guidance the bulletin itself states is not binding.

Whether your own entity is a licensee, or sits on the Department’s list, is a question for counsel and the Department, not a determination this guide makes.

The failure mode here is a program written to the statute’s headings and configured to the tenant’s defaults, with no line joining the two. The duty itself is broad and risk-based: according to section 375.1405, “each licensee shall develop, implement, and maintain a comprehensive written information security program that is based on the licensee’s risk assessment and that contains administrative, technical, and physical safeguards for the protection of nonpublic information and the licensee’s information system.” The program is the licensee’s, built on its own risk assessment; no Microsoft product is certified to it.

A risk assessment written once and filed will not carry the program: the duty recurs. Under section 375.1405, the licensee must identify foreseeable threats, “including the security of information systems and nonpublic information that are accessible to, or held by, third-party service providers,” and must “no less than annually, assess the effectiveness of the safeguards’ key controls, systems, and procedures.” The same section asks the program to “Define and periodically reevaluate a schedule for retention of nonpublic information and a mechanism for its destruction when no longer needed,” which is the job Microsoft Purview Data Lifecycle Management is built for: according to Microsoft’s data lifecycle management overview, it “provides you with tools and capabilities to retain the content that you need to keep, and delete the content that you don’t.”

Subsection 4’s security measures are where the tenant does most of the work, and where the statute’s own wording matters most. Read each against the matching Microsoft capability:

• Access controls. The statute asks the licensee to “Place access controls on information systems, including controls to authenticate and permit access only to authorized persons to protect against the unauthorized acquisition of nonpublic information.” In Microsoft Entra ID that is Conditional Access, which Microsoft’s Conditional Access overview describes as “Microsoft’s Zero Trust policy engine taking signals from various sources into account when enforcing policy decisions.”
• Encryption, with its scope kept exact. The statute asks the licensee to “Protect by encryption or other appropriate means all nonpublic information while being transmitted over an external network and all nonpublic information stored on a laptop computer or other portable computing or storage device or media.” That is narrower than a blanket duty to encrypt every stored record. Microsoft’s encryption overview states that “With Microsoft 365, your data is encrypted at rest and in transit,” and names BitLocker for client machines, so the remaining decision for the licensee is the laptops and portable devices outside the Microsoft cloud. We recommend confirming encryption on each of those devices from the organization’s own device records rather than assuming it, because the statute’s encryption duty names them specifically.
• Multifactor authentication, with its wording kept exact. The statute asks the licensee to “Utilize effective controls, which may include multifactor authentication procedures for any individual accessing nonpublic information.” Multifactor authentication is one control the program may include, not a flat mandate in the statute’s text. The statute’s definition requires “at least two of the following types of authentication factors,” and Microsoft’s description of how Entra multifactor authentication works uses the same shape: it “works by requiring two or more of the following authentication methods.”
• Monitoring. The statute asks the licensee to “Regularly test and monitor systems and procedures to detect actual and attempted attacks on, or intrusions into, information systems,” which is the detection side of Microsoft Defender XDR, covered in the incident response section below.
• Audit trails. The statute asks for “audit trails within the information security program designed to detect and respond to cybersecurity events and designed to reconstruct material financial transactions sufficient to support normal operations and obligations of the licensee.” It sets no retention period for them in that clause; Microsoft Purview Audit is the tenant’s record, and its defaults are the subject of the next section.

Encryption matters for more than the control itself. According to section 375.1402, the term cybersecurity event “does not include the unauthorized acquisition of encrypted, nonpublic information if the encryption, process, or key is not also acquired, released, or used without authorization.” The condition travels with the exclusion: an encrypted laptop lost together with its key does not get it.

Two duties sit outside the tenant entirely. If the licensee has a board, section 375.1405 requires executive management to report to it in writing, at least annually, on the program’s status and on material matters including “third-party service provider arrangements, results of testing, cybersecurity events or violations and management’s responses thereto.” And the licensee must “monitor, evaluate, and adjust, as appropriate, the information security program” as technology, threats and its own business arrangements change. The tenant supplies the evidence for both; the reporting and the judgment are the licensee’s.

The gap that surfaces too late is the audit log. Missouri’s Act requires each insurer domiciled in the state to keep, for five years, the records supporting its annual certification: according to section 375.1405, “Each insurer shall maintain for examination by the department all records, schedules, and data supporting this certificate for a period of five years.” Microsoft Purview Audit, by default, keeps far less. Microsoft’s overview of auditing solutions in Microsoft Purview lists “180-day audit log retention” for Audit (Standard), “Up to 1-year audit log retention” for Audit (Premium), and “10-year audit log retention” only where “a user must be assigned a 10-Year Audit Log Retention add-on license to retain their audit records for 10 years.”

One further limit applies even with the add-on. The same Microsoft page states that “Audit records generated by non-user entities (such as service principal actions, system events, and application activities) are retained for a fixed period of one year,” and that “This retention period isn’t configurable and custom audit log retention policies don’t apply to these records.” Activity by an application, including a connected vendor’s application, is exactly the kind of record a five-year trail needs, and the audit log alone will not hold it for the five years section 375.1405 asks of a domiciled insurer.

The second default to check is the license behind access control. According to Microsoft’s Conditional Access overview, “Using this feature requires Microsoft Entra ID P1 licenses,” and “Risk-based Conditional Access policies (sign-in risk and user risk) require Microsoft Entra ID Protection, which is a Microsoft Entra ID P2 feature.” Where neither license is in place, the same page states that “Security defaults help protect against identity-related attacks and are available for all customers,” which is a baseline, not the risk-based control a program document can claim.

Two decisions follow for the five-year duty in section 375.1405. Confirm the Entra ID license tier before the program document assumes a risk-based access control exists. Then decide, before the first certification is due, how five years of supporting records will be kept: the add-on license for the users who need it, and a separate, retained export of the records the audit log will not hold for five years, including application and service principal activity. We recommend naming an owner for each decision before drafting begins: the IT Director or the tenant’s security lead confirms the license tier against the licenses actually assigned in the tenant and designs the retention, and compliance, with counsel, signs off that design before the program document relies on it.

When the annual certification is signed, the signature has to meet the evidence, and the duty belongs to a narrower group than the rest of the Act. According to section 375.1405, “Annually by April fifteenth, each insurer domiciled in this state shall submit to the director a written statement certifying that the insurer is in compliance with the requirements set forth in this section.” That subsection binds each insurer domiciled in Missouri, while the program duties bind every licensee; a licensee domiciled elsewhere still owes the program. The same subsection adds that where an insurer “has identified areas, systems, or processes that require material improvement, updating, or redesign, the insurer shall document the identification and the remedial efforts planned and underway to address such areas, systems, or processes.”

It is easy to assume the certification waits for the second date; it rides the first. It sits in section 375.1405 itself, which section 375.1427 gives licensees until January 1, 2027 to implement; only subsection 6 carries the January 1, 2028 date. The statute states the annual April 15 rule and does not name the first certification’s due date in words, and neither does the Department’s bulletin, so confirm the first due date with the Department rather than assuming it.

In practice the board report and the certification draw on the same evidence: the risk assessment, the annual test of key controls, the audit trail, the incident record and the third-party arrangements. Build that evidence trail as a January 1, 2027 deliverable, so the first certification has records behind it that can be kept for the five years section 375.1405 requires.

A cybersecurity event is the wrong day to discover the plan has no owner for external communications. According to section 375.1405, each licensee “shall establish a written incident response plan designed to promptly respond to, and recover from, any cybersecurity event,” and the plan must address these areas:

• The internal process for responding to a cybersecurity event.
• The goals of the incident response plan.
• The definition of clear roles, responsibilities, and levels of decision-making authority.
• External and internal communications and information sharing.
• Identification of requirements for the remediation of any identified weaknesses in information systems and associated controls.
• Documentation and reporting regarding cybersecurity events and related incident response activities.
• The evaluation and revision as necessary of the incident response plan following a cybersecurity event.

Detection is where the tenant carries real weight. Microsoft’s Defender XDR overview describes it as “a unified pre- and post-breach enterprise defense suite that natively coordinates detection, prevention, investigation, and response across endpoints, identities, email, and applications,” and states that “Microsoft Defender takes automatic action to prevent or stop the attack and self-heal affected mailboxes, endpoints, and user identities.” That is Microsoft’s documented capability for the statute’s monitoring and response duties. The plan itself, its roles and its decision authority, is written and owned by the licensee.

When a deadline sits a year further out, it is the duty that gets deferred, and this is the one no tenant setting completes. Section 375.1405 states it in two sentences: “(1) A licensee shall exercise due diligence in selecting its third-party service provider. (2) A licensee shall require a third-party service provider to implement appropriate administrative, technical, and physical measures to protect and secure the information systems and nonpublic information that are accessible to, or held by, the third-party service provider.” Section 375.1427 gives licensees until January 1, 2028 to implement that subsection.

Start with who counts. According to section 375.1402, a third-party service provider is “a person, not otherwise defined as a licensee, that contracts with a licensee to maintain, process, store, or otherwise is permitted access to nonpublic information through its provision of services to the licensee.” A claims processor, a policy administration service or an actuarial modeling service that reaches nonpublic information fits that description; the inventory comes from contracts and data flows, not from a product catalog.

Then separate the two halves of the duty, because they are answered in different places:

• Selection. Due diligence in selecting a provider is a documented, repeatable process the licensee runs itself: what it asks each provider, what evidence it accepts, who approves the choice, and where the record is kept. No tenant configuration performs or proves it, and no purchased score substitutes for it.
• Ongoing measures. Requiring a provider to protect the information it can reach is, first, a contract term. The tenant can then limit and show what that provider’s accounts and applications reach. Microsoft’s Defender for Cloud Apps overview states that it “identifies all the users and third-party apps able to sign in,” which is the discovery list to reconcile against the contract register. Microsoft’s External ID introduction describes B2B collaboration as the way to “Determine the level of access that guests have to the Microsoft Entra tenant that contains your employees and organizational resources.” And Microsoft’s data loss prevention overview states that a DLP policy can “block the sharing without the override option” when sensitive content is headed somewhere it should not go.

The tenant can show what a provider’s account reached. It cannot show that the provider was diligently selected, or what the provider’s own security program contains; those are the licensee’s governance and contract records. One related duty is already in force and is not covered here: according to the Department’s Bulletin 26-01, which states it is not binding and evaluates no specific facts, a cybersecurity event involving a licensee’s third-party service provider also requires notification to the Director under section 375.1410.

If the work starts with tenant settings, the parts with lead time come last: the certification’s records and the license decisions carry configuration lead time, and the vendor process carries contract time. This is the order we recommend, not a sequence the statute or Microsoft publishes, set against the dates in section 375.1427:

1. Confirm licensee status, and whether any Bulletin 26-01 exclusion applies, with counsel and the Department before scoping anything.
2. Run the risk assessment and inventory the nonpublic information and the systems that hold it, including what third-party service providers hold.
3. Close the subsection 4 gaps against what the tenant already has, starting with the Entra ID license-tier check and the five-year audit record decision, since both carry lead time.
4. Write the incident response plan and confirm the board report is running before January 1, 2027.
5. Treat the certification’s five-year evidence trail as a January 1, 2027 deliverable, not an April scramble, and before the first certification is signed, retrieve a sample of the supporting records, including application and service principal activity, from wherever they are kept, to confirm the design returns what the Department could ask to examine.
6. Start designing the vendor-selection process and contract terms for subsection 6 now, in parallel, even though its date is January 1, 2028.

Not every reader needs this work in full, and it is worth checking before starting it. If counsel confirms the entity sits on the Department’s own not-a-licensee list, the Act’s implementation duties do not bind it; confirm that with counsel and the Department, not from this page alone. If the company is licensed in Missouri but domiciled elsewhere, the program duties still apply and the annual certification in subsection 9 does not. If the company is also regulated by the New York Department of Financial Services, or also runs California’s cybersecurity audit, those are separate certifications on separate schedules under separate regimes, and neither substitutes for Missouri’s own. Alaska’s Insurance Data Security Act is a separate statute with its own duties and dates, and this guide does not cover it. If the program is already built on ISO 27001 or the NIST Cybersecurity Framework, the gaps most likely to remain are the Missouri specifics in section 375.1405: the portable-device encryption scope and five years of certification records. And if the real question is which third-party risk product to buy for subsection 6, that is a product decision this guide does not make; the statute asks for due diligence and contract terms, not a purchased score.

Whoever does this work with you, inside the organization or outside it, hold it to these criteria, drawn from section 375.1405 and stated as what they should be able to show you:

• Each subsection 4 security measure mapped to a named tenant control, with the encryption scope and the multifactor wording kept exactly as the statute states them.
• The Entra ID license tier confirmed, not assumed, before any risk-based access control is written into the program.
• A plan that keeps five years of certification records, including the records the audit log will not hold for five years.
• The incident response plan, covering every area the statute lists.
• The vendor-selection process as a documented, repeatable step, separate from any tenant configuration.
• The risk assessment, the program documentation and the evidence trail handed to your own team and to counsel.

No vendor-risk product, rating service or assessor is named or compared in that work.

i3solutions plans and runs governed Azure and Microsoft 365 migrations with senior, U.S.-based engineers. For Missouri’s Act, that means a project, with embedded specialists where your team needs them, that maps each program subsection to a named tenant control, closes the configuration gaps, builds the incident response plan and the certification evidence trail, and designs the vendor-selection process for the later date. i3solutions maps governance to named control families, enforces it in the platform through Entra ID, Purview, and Azure Policy, and evidences it continuously rather than reconstructing it at audit. i3solutions governs identity and access for regulated Microsoft estates with senior, U.S.-based engineers and leaves an audit-defensible record. i3solutions has been a Microsoft Partner with 30 years of enterprise technology delivery experience and has delivered 1,500+ Microsoft engagements across aerospace and defense, financial services, and health sciences.

The vendor-selection process is designed with your team and handed to it; the diligence on each provider, and the annual certification, stay with the licensee. An i3solutions engagement does not produce managed-service ownership, a replacement for the internal team, open-ended scope expansion, or vendor lock-in.