Alaska Insurance Data Security Act: What Must Insurers Do?

Most of what this Act asks of an Alaska-licensed insurer has been in force since January 1, 2026, according to Alaska’s enacted Insurance Data Security Act text. The program exists, the board report runs, and a domestic insurer’s February 15 certification duty already applies. The part that is not yet in force is the one most tenants have never written a process for: choosing third-party service providers with documented due diligence, and deciding which of them must be required to protect the data they reach.

If your program has been running since January, the date that still decides this year’s work is the second one. The enacting act split its start dates: its section 10 makes AS 21.23.250 and most of AS 21.23.260, including the program, its security measures, board reporting and the annual certification, effective January 1, 2026, and its section 11 sets a later date for AS 21.23.260(c)(7) and (8), according to Alaska’s enacted Insurance Data Security Act text. The Alaska Statutes print “[Effective January 1, 2027.]” at the start of each of those two paragraphs. No later date for these duties appears in Alaska’s law.

The program duty itself reads, in the Alaska Statutes: “A licensee shall develop, implement, and maintain a comprehensive written information security program based on the licensee’s risk assessment conducted under AS 21.23.250(a).” The same subsection lets a licensee designate “one or more employees, an outside vendor, or a third-party service provider” to be responsible for that program, according to Alaska’s enacted Insurance Data Security Act text. That is one reason the selection duty matters: the provider you must select with due diligence can be the one running the program.

The Act’s definitions sit at AS 21.23.399. A “licensee” is a person “licensed, authorized to operate, or registered, or required to be licensed, authorized, or registered, under this title,” and the definition excludes “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,” according to Alaska’s enacted Insurance Data Security Act text. Whether your own entity is a licensee, or sits inside one of those exclusions or the applicability exceptions in AS 21.23.300, is a question for counsel and the Alaska Division of Insurance. This guide relies on the statute’s own words and on no Division guidance.

The failure mode here is treating the two clauses as one obligation carrying one condition. Paragraph (7) requires a licensee to “exercise due diligence in selecting a third-party service provider” and carries no qualifier, according to Alaska’s enacted Insurance Data Security Act text. Paragraph (8) opens differently: “where appropriate, 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.”

So there are two decisions, not one. Selecting diligently is not optional for any provider the definition reaches. Requiring a provider to implement specific measures depends on the licensee’s own judgment of where that is appropriate, and that judgment is itself something to write down. The statute defines the provider it means: a “third-party service provider” is “a person that is not a licensee that, through a contract with a licensee, is permitted access to and maintains, processes, or stores nonpublic information through its provision of services to the licensee,” according to Alaska’s enacted Insurance Data Security Act text.

The same permissive shape appears one level up, in the security measures list. Paragraph (1) tells a licensee to “implement the following security measures if the licensee determines that the security measure is appropriate,” and its access-control item says “the controls may include multi-factor authentication procedures,” according to Alaska’s enacted Insurance Data Security Act text. Alaska’s text therefore does not make multifactor authentication an unconditional mandate: the measure is subject first to the licensee’s own appropriateness determination and then to “may include.” Neither condition should be dropped when the point is repeated in a policy, a board report or a vendor contract.

Before you build a measures-requirement process for a provider, check whether that provider can read the data at all. Paragraph (8) ends with its own carve-out: “for purposes of this paragraph, encrypted nonpublic information is not considered accessible to, or held by, the third-party service provider if the associated protective process or key necessary to assign meaning to the nonpublic information is not within the possession of the third-party service provider,” according to Alaska’s enacted Insurance Data Security Act text.

The condition is key custody, not the mere presence of encryption. Microsoft’s Encryption in Microsoft 365 page states that “your data is encrypted at rest and in transit, using several strong encryption protocols,” and that is true of the platform broadly; it does not, by itself, answer who holds the key or the protective process relative to a particular provider. That is a configuration and key-management fact about each relationship, and it has to be established and written down relationship by relationship, never assumed from default encryption.

This guide’s own decision rule, a recommendation and not the statute’s wording: for each provider that reaches nonpublic information, record whether the data it touches is encrypted with the key kept outside that provider’s possession. Where it is, record that finding as the paragraph (8) answer for that relationship rather than building a separate measures-requirement process for it. The carve-out is written “for purposes of this paragraph,” so it narrows paragraph (8) only; the paragraph (7) duty to select that provider with due diligence still applies, according to Alaska’s enacted Insurance Data Security Act text.

The trap, when the Division of Insurance asks how a provider was chosen, is a folder of tenant screenshots offered as the answer. The tenant can show how a connected provider’s access is limited and what the tenant can see of it, which is evidence for the technical side of paragraph (8). It cannot show that the provider was selected with due diligence under paragraph (7), because selection is a process record, not a configuration.

Guest access is the first control point. Microsoft Learn’s overview of Microsoft Entra External ID states: “If you want to enable your employees to collaborate with business partners and guests, use B2B collaboration in External ID.” The same page describes how you “Determine the level of access that guests have to the Microsoft Entra tenant that contains your employees and organizational resources” in the workforce tenant. The access level a provider’s guest accounts receive is a tenant decision you can evidence; it says nothing about the provider’s own security program.

Conditional Access governs what those accounts must do to get in. Microsoft Learn’s Conditional Access overview states that “Conditional Access is Microsoft’s Zero Trust policy engine taking signals from various sources into account when enforcing policy decisions,” and gives an example rather than a default: “If a user wants to access an application or service like Microsoft 365, then they must perform multifactor authentication to gain access.” Licensing is a condition to confirm for your tenant: the same page states that “Using this feature requires Microsoft Entra ID P1 licenses,” that risk-based policies rely on a Microsoft Entra ID P2 feature, and that “Security defaults help protect against identity-related attacks and are available for all customers.”

Purview DLP limits what leaves. Microsoft Learn’s data loss prevention overview states: “In Microsoft Purview, you implement data loss prevention by defining and applying DLP policies.” According to that page, a DLP policy can help “identify, monitor, and automatically protect sensitive” items, and for data at rest “sensitive items can be locked and moved to a secure quarantine location.” That constrains what a connected provider’s account can take out of the tenant, another piece of paragraph (8) evidence.

Defender for Cloud Apps answers a narrower question: which cloud apps and third-party apps are in use at all. Microsoft Learn’s Defender for Cloud Apps overview states, in its section on discovering SaaS applications: “Defender for Cloud Apps detects all your cloud services, assigns each a risk ranking, and also identifies all the users and third-party apps able to sign in.” That is a discovery list, useful for finding providers your selection record has not yet covered; it is not an assessment of any provider’s own program.

Purview Compliance Manager, described on Microsoft Learn’s Compliance Manager page as a solution that “helps you automatically assess and manage compliance across your multicloud environment,” assesses your own Microsoft cloud configuration. It can be one place to keep your own evidence of the selection and measures process; it does not vet or score another company’s security program, and this guide does not present it as doing so.

If your board has never seen a line about third-party service provider arrangements, that gap is older than January 1, 2027. The board-reporting subsection, effective since January 1, 2026, requires executive management to report in writing at least once a year on “material matters related to the information security program, including risk assessment, risk management and control decisions, third-party service provider arrangements, results of testing,” among other items, according to Alaska’s enacted Insurance Data Security Act text and the Alaska Statutes.

The certification is narrower in who it binds. Subsection (f) begins “Each licensee who is an insurer domiciled in this state shall” and requires that insurer to “submit to the director a written statement by February 15 of each year certifying that the insurer is in compliance with the requirements under AS 21.23.250 and this section”, to keep the supporting records available to the director for five years, and to document areas needing material improvement with the remedial efforts planned and underway, according to Alaska’s enacted Insurance Data Security Act text and the Alaska Statutes. The words “this section” include paragraphs (7) and (8), which apply from January 1, 2027, while the certification duty itself has applied since January 1, 2026. Which February 15 statement is the first that must reflect paragraphs (7) and (8) is not stated in the statute’s text; confirm it with the Alaska Division of Insurance.

Some readers should stop here and take a different question first, each case read against Alaska’s enacted Insurance Data Security Act text:

• Your entity may not be a licensee, or may fall under an exclusion in AS 21.23.399 or an applicability exception in AS 21.23.300, including the exception for a licensee subject to HIPAA that meets its conditions: confirm that with counsel, not from this page, according to Alaska’s enacted Insurance Data Security Act text.
• Your company is licensed in Alaska but not domiciled there: the program and the paragraph (7) and (8) duties are written for every licensee, while the February 15 certification in subsection (f) is written for an insurer domiciled in Alaska.
• Your company is also licensed in Missouri: that state runs a similar but separately dated duty under its own statute, which is not a substitute for this one and is not described here. Alaska’s Act follows the same NAIC model law, and a bulletin from Missouri’s Department of Commerce and Insurance cites Alaska’s statute among the state implementations of that model.
• Your provider relationships already run on encrypted data with the key held in-house: the paragraph (8) carve-out may mean the measures-requiring half of this duty does not reach those relationships, which is worth recording before you build process around them.
• Your real question is which third-party risk product to buy: that is a purchasing decision this guide does not make, and no product meets paragraph (7) on its own.
• Your question is about a provider’s duty to notify you of its own cybersecurity event: that is paragraph (9), a separate duty in force since January 1, 2026, and it is not covered here.

Before you assign the work to anyone, internal or external, hold them to evidence rather than assurances, and to the statute’s own two clauses in Alaska’s enacted Insurance Data Security Act text:

• Show a documented, repeatable third-party service provider selection process, separate from any tenant configuration, with a record for each provider it has been applied to.
• Show, for each provider relationship, whether the encryption and key carve-out applies before a measures-requirement process is built for it.
• Show where the licensee judged it appropriate to require measures from a provider, and the measures required.
• Show the Entra External ID guest-access level, the Conditional Access policy and its licence tier, and the Purview DLP protective actions that apply to each connected provider, evidenced from the tenant rather than described.
• Show the Defender for Cloud Apps discovery list reconciled against the selection record, so a provider in use but never selected is visible.
• Show the board report’s line on third-party service provider arrangements and the five-year record behind the February 15 statement already running for the parts of the program in force since January 1, 2026.

i3solutions plans and runs governed Azure and Microsoft 365 migrations with senior, U.S.-based engineers. For this duty, the work is a project, with embedded specialists where your team needs them: document the provider selection process and its record, map the tenant-side paragraph (8) evidence across Entra External ID, Conditional Access, Purview DLP, Compliance Manager and Defender for Cloud Apps discovery, and resolve the encryption and key carve-out relationship by relationship. 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 selection decisions, the provider relationships and the certification stay yours. i3solutions does not assess or vouch for a specific provider’s own security program, does not sign or prepare the annual certification statement for you, and does not run your provider selection as an ongoing service. An i3solutions engagement does not produce managed-service ownership, a replacement for the internal team, open-ended scope expansion, or vendor lock-in.

If your company is licensed in Alaska and has been running its information security program since January 1, 2026, start by listing every third-party service provider that reaches nonpublic information, record for each one whether the encryption and key carve-out applies, and write down the selection process you will apply to all of them before January 1, 2027, according to Alaska’s enacted Insurance Data Security Act text.

This guide’s parent topic is Embedding Governance into How the Enterprise Operates and Scales.