SDOS Runtime Governance Framework — NAIC Insurance Data Security Model Law Alignment¶
SDOS Version: 1.9
Standard: NAIC Insurance Data Security Model Law — MDL-668 (adopted October 2017; state enactments ongoing)
Adopting States: As of 2026, enacted in 26+ states including Alabama, Connecticut, Delaware, Georgia, Hawaii, Indiana, Iowa, Louisiana, Maine, Maryland, Michigan, Minnesota, Mississippi, Missouri, New Hampshire, New Jersey, New York, North Carolina, North Dakota, Ohio, Oklahoma, Oregon, South Carolina, Tennessee, Virginia, and Wisconsin. Specific requirements vary by enacting state. Verify current status and state-specific modifications with legal counsel.
Document Date: 2026-05-12
Authoring Organization: AAM Cyber (aamcyber.com)
Inventor: Pharns Genece
SDOS Control Catalog: View full control definitions
Purpose¶
This document maps the controls of the SDOS Runtime Governance Framework to the requirements of the NAIC Insurance Data Security Model Law (MDL-668). It is intended to assist insurance carriers, licensed producers, third-party administrators, and GRC teams evaluating SDOS as a technical control layer for AI systems that operate within insurance licensee information security programs.
MDL-668 requires covered licensees to develop and maintain a comprehensive information security program. As AI agents become integral to underwriting, claims processing, fraud detection, customer service, and internal operations, the AI dispatch layer — where SDOS operates — becomes a material component of that program.
This is an informative alignment document. It does not constitute a regulatory opinion, a compliance certification, or legal advice. Requirements vary by enacting state. Organizations should engage qualified legal counsel and insurance regulators to determine how MDL-668 obligations apply to their specific AI deployments.
Applicability¶
This document applies to insurance licensees deploying agentic AI workflows within systems subject to MDL-668 information security program requirements. It is relevant when:
- An AI agent operates within or adjacent to systems that process nonpublic information (NPI) as defined under MDL-668, or
- A licensee is evaluating whether runtime governance controls satisfy Section 4 (Information Security Program) or Section 5 (Third-Party Service Provider Oversight) requirements, or
- An information security team is documenting AI agent governance controls as part of the annual certification or board reporting process required under MDL-668 Section 4(F).
Important scope clarification: SDOS governs AI agent dispatch — the decision of whether and how an agent operates. It does not access, store, or process NPI content directly. SDOS controls the governance layer above the data layer. This distinction is material to understanding where SDOS satisfies MDL-668 requirements and where complementary controls are required.
SDOS Control Catalog Summary¶
The full control catalog with per-control descriptions, evidence types, and related control dependencies is published at /sdos/reference/v1/. The 24 SDOS controls comprising the public runtime control set are:
| Control ID | Title |
|---|---|
| SDOS-GV-01 | Configuration-Governed Module Activation |
| SDOS-GV-02 | Governance-Tiered Model Selection |
| SDOS-GV-03 | Default-Deny Pre-Admission Policy |
| SDOS-GV-04 | Cross-Module Governance Continuity |
| SDOS-GV-05 | Model-Alignment-Independent Policy Enforcement |
| SDOS-RM-01 | Dispatch-Time Risk Classification |
| SDOS-RM-02 | Complexity-Tiered Resource Allocation |
| SDOS-RM-03 | Risk-Floor Model Binding |
| SDOS-AD-01 | Default-Deny Agent Pre-Admission |
| SDOS-IA-01 | Attested Agent Identity |
| SDOS-IA-02 | Attested Module Identity |
| SDOS-IN-01 | Governance Baseline Integrity Verification |
| SDOS-IN-02 | Baseline Drift Detection and System Halt |
| SDOS-IN-03 | Module Manifest Integrity |
| SDOS-EN-01 | Pre-Egress Policy Enforcement |
| SDOS-EN-02 | Subordinate-Side Enforcement Gate |
| SDOS-EN-03 | Fail-Closed Degradation |
| SDOS-EN-04 | Governed Egress with Tamper-Evident Audit |
| SDOS-AU-01 | Per-Invocation Audit Record |
| SDOS-AU-02 | Append-Only Audit Log Integrity |
| SDOS-AU-03 | Dual Audit Trail |
| SDOS-DE-01 | Governed Multi-Agent Deliberation |
| SDOS-DE-02 | Convergence-Based Decision Record |
| SDOS-RS-01 | Governed Return on Safety Investment (ROSI) Evaluation |
How to Use This Document¶
Assessor Use Notice¶
Mapping strength reflects the framework's design coverage of the cited requirement. Operating effectiveness is a property of a specific deployment and must be tested per engagement. State-level enactments of MDL-668 may modify or extend base requirements. Assessors should treat all mappings as control-design assertions requiring implementation verification — including evidence collection, sample selection, and testing against the assessor's own audit objective. The strength rating is the starting point for a compliance analysis, not a substitute for it.
Mapping Strength Legend¶
| Rating | Meaning |
|---|---|
| Strong | SDOS provides a direct, mechanism-specific technical implementation of the cited requirement through observable runtime behavior. |
| Partial — [qualifier] | SDOS addresses a defined subset of the requirement. The qualifier identifies which subset is covered and which requires additional controls. |
| Weak — Substrate Only | SDOS produces data or infrastructure that enables compliance but does not itself satisfy the requirement. |
| Out of Scope | The requirement falls entirely outside the operational boundary of a runtime governance framework. |
Glossary¶
MDL-668 Terms¶
| Term | Definition as Used in This Document |
|---|---|
| Nonpublic information (NPI) | Information defined in MDL-668 Section 3(L): business-related information, personal information, and health information not generally publicly available |
| Licensee | A person licensed, authorized, or registered under insurance statutes subject to MDL-668 |
| Information security program | The comprehensive program required under MDL-668 Section 4 to protect NPI |
| Third-party service provider | A person not affiliated with the licensee that provides services involving access to NPI |
| Cybersecurity event | An act or attempt, successful or unsuccessful, to gain unauthorized access to, disrupt, or misuse the licensee's information systems |
SDOS Terms¶
| Term | Definition |
|---|---|
| Point of dispatch | The moment a task is assigned to an agent and before any tool execution occurs; the primary SDOS enforcement boundary |
| Governed egress | Outbound operations subject to pre-execution policy enforcement before results are returned |
| Fail-closed degradation | SDOS-EN-03 defines three failure modes: (1) governance infrastructure unavailability — pre-authorized operations may continue under a documented degradation policy; (2) governance baseline integrity failure — all operations halt without exception; (3) partial-degradation states — governed by a documented degradation policy that is itself integrity-verified per IN-01. See control catalog for the full definition. |
| Governance baseline | The authorized configuration state against which SDOS verifies integrity at startup and on demand |
MDL-668 Structure Reference¶
MDL-668 is organized into eleven sections. The sections with the strongest intersection with AI agent governance are:
| Section | Title | SDOS Relevance |
|---|---|---|
| Section 4 | Information Security Program | Primary — risk assessment, access controls, audit, encryption, incident response |
| Section 5 | Third-Party Service Provider Oversight | Relevant — AI service providers and model vendors as third parties |
| Section 6 | Investigation of Cybersecurity Events | Partial — audit trail supports forensic investigation |
| Section 7 | Notification of Cybersecurity Events | Out of scope — organizational notification obligation |
| Section 8 | Exemptions | Informational — size-based exemptions affect applicability |
Mapping Table — Section 4 (Information Security Program)¶
MDL-668 Section 4 requires licensees to develop, implement, and maintain a comprehensive written information security program. The program must be based on a risk assessment and address the following elements. SDOS controls map to the technical implementation layer within this program.
| MDL-668 Section 4 Requirement | SDOS Controls | Strength | Notes |
|---|---|---|---|
| 4(B)(1) Risk assessment — identify reasonably foreseeable internal and external threats that could result in unauthorized access to or misuse of NPI | RM-01, RM-02, RM-03 | Partial — Risk Assessment Input | Dispatch-time risk classification, complexity-tiered resource allocation, and risk-floor model binding produce per-invocation risk data at the AI agent layer — a continuous runtime input to the NPI threat assessment. The formal risk assessment obligation (identifying threat categories, documenting likelihood and damage, engaging qualified personnel) is an organizational process that consumes SDOS data but is not itself satisfied by runtime classification. |
| 4(B)(2) Assess the likelihood and potential damage of identified threats | RM-01, RM-02 | Partial — Risk Assessment Input | Risk tier classification and complexity assessment provide likelihood-and-consequence scoring at dispatch time; per-invocation records accumulate into a longitudinal risk dataset. The formal assessment — documenting findings, determining potential damage, and maintaining an assessment record for regulatory purposes — is an organizational obligation that SDOS supports but does not constitute. |
| 4(C)(1) Implement access controls, including technical and physical security, to limit access to NPI to authorized individuals | GV-03, AD-01, IA-01 | Strong | Default-deny pre-admission policy + agent pre-admission gate + attested agent identity = access limited to explicitly admitted, cryptographically verified agents |
| 4(C)(2) Identify and manage data, personnel, devices, systems, and facilities | GV-01, IA-02 | Strong | Configuration-governed module activation enumerates and controls which modules (and thus which capabilities) are active; attested module identity verifies the declared capability surface before any module is activated |
| 4(C)(3) Protect through encryption or other appropriate means all NPI held or transmitted | EN-01, EN-04 | Partial — Governance Layer Only | SDOS governs whether governed egress operations are permitted and records them with tamper-evident audit; NPI content-level encryption is a data-layer obligation outside the SDOS operational boundary |
| 4(C)(4) Adopt secure development practices for in-house developed applications used to access NPI | IN-01, IN-02, IN-03 | Partial — Runtime Only | SDOS provides runtime integrity verification of governance configuration and module manifests; secure SDLC practices for the AI models and application software that produce agent outputs are an organizational obligation outside the governance framework |
| 4(C)(5) Modify the information security program if a security test or audit identifies a material deficiency | IN-01, IN-02, GV-01 | Strong | Governance baseline integrity verification + drift detection and halt + configuration-governed module activation = policy state is integrity-controlled and requires explicit re-authorization after any modification |
| 4(C)(6) Implement measures to detect, prevent, and respond to attacks or intrusions | EN-01, EN-02, EN-03, AU-01 | Partial — Dispatch Layer Detection and Prevention | Pre-egress enforcement + subordinate-side gate + fail-closed degradation + per-invocation audit record implement detection and prevention at the AI agent dispatch boundary. Response obligations — incident coordination, remediation actions, notification processes — are organizational obligations outside the dispatch boundary that SDOS supports through audit records but does not satisfy. |
| 4(C)(7) Implement measures to protect against destruction, loss, or damage of NPI due to environmental hazards or technological failure | EN-03, AU-03 | Partial — AI Dispatch Layer Only | SDOS-EN-03 fail-closed degradation governs AI dispatch continuity; SDOS-AU-03 dual audit trail provides audit redundancy. Infrastructure-level resilience (backup, recovery, BCP) is outside the SDOS operational boundary |
| 4(C)(8) Train staff to implement the information security program | GV-04, AU-01 | Weak — Substrate Only | SDOS cross-module governance continuity and audit records support training effectiveness measurement but do not substitute for workforce training programs — an organizational obligation |
| 4(C)(9) Test key controls, systems, and procedures of the information security program | IN-01, IN-02, IN-03, RS-01 | Strong | Governance baseline integrity verification + drift detection + module manifest integrity constitute automated control testing at every startup. SDOS-RS-01 ROSI evaluation provides ongoing measurement of governance control effectiveness |
| 4(C)(10) Implement measures to protect against destruction, loss, or damage due to environmental hazards | EN-03, AU-03 | Partial — Substrate-Dependent | See 4(C)(7) note — SDOS provides AI-layer continuity; physical infrastructure resilience is outside scope |
| 4(C)(11) Include cybersecurity risks in the enterprise risk management process | RM-01, RM-02, RM-03, RS-01 | Strong | Dispatch-time risk classification, risk-floor binding, and ROSI evaluation collectively produce the AI-layer risk data that feeds enterprise risk management; SDOS quantifies governance overhead and risk reduction at the AI agent boundary |
| 4(C)(12) Stay informed regarding emerging threats or vulnerabilities | GV-01, IN-01 | Partial — Policy Update Mechanism Only | Configuration-governed module activation and governance baseline integrity verification create the mechanism by which threat-response policy updates take effect with integrity control; threat intelligence sourcing is an organizational function |
| 4(D) Oversee third-party service providers that have access to NPI | IA-01, IA-02, EN-01, EN-02 | Partial — Runtime Enforcement Layer | Attested agent identity + attested module identity + pre-egress enforcement + subordinate-side gate enforce governance constraints on AI agents from any provider — third-party agents operate under the same identity verification and default-deny admission policy as first-party agents. The oversight program obligations — vendor risk assessment, contract provisions, periodic performance evaluation, and due diligence on provider security programs — are organizational obligations that SDOS technical enforcement supports but does not satisfy. |
| 4(F) Report to the board of directors annually on the information security program | RS-01, AU-01, AU-02 | Partial — Evidence Input Only | SDOS-RS-01 ROSI evaluation generates a structured governance effectiveness report with quantified metrics (cost avoidance, exposure reduction, resilience gain); per-invocation audit records and append-only audit log integrity provide the evidentiary substrate for board reporting. The board report itself is an organizational governance obligation |
Mapping Table — Section 5 (Third-Party Service Provider Oversight)¶
MDL-668 Section 5 requires licensees to select and retain third-party service providers capable of maintaining appropriate safeguards, and to require those providers to implement and maintain such safeguards.
| MDL-668 Section 5 Requirement | SDOS Controls | Strength | Notes |
|---|---|---|---|
| 5(A) Select and retain third-party service providers capable of maintaining appropriate safeguards | IA-01, IA-02, GV-03 | Strong | Attested agent identity and module identity requirements mean that only providers whose agents can present verifiable identity artifacts are operationally compatible with the governed execution layer; default-deny admission enforces this at runtime |
| 5(B) Require third-party service providers to implement and maintain appropriate safeguards | EN-01, EN-02, GV-05 | Strong | Pre-egress enforcement + subordinate-side gate + model-alignment-independent policy enforcement apply the same governance constraints to third-party AI agents as to first-party agents; governance is not a contractual assertion — it is a runtime enforcement condition |
| 5(C) Include provisions in third-party contracts requiring safeguards | GV-03, GV-05 | Partial — Technical Enforcement Only | SDOS enforces safeguards at the technical boundary; contractual provisions are an organizational and legal obligation. The combination — contractual obligation backed by runtime enforcement — constitutes a stronger control than either alone |
Mapping Table — Section 6 (Investigation of Cybersecurity Events)¶
| MDL-668 Section 6 Requirement | SDOS Controls | Strength | Notes |
|---|---|---|---|
| 6(A) Investigate and document the nature and scope of a cybersecurity event | AU-01, AU-02, AU-03, EN-04 | Strong | Per-invocation audit record + append-only integrity + dual audit trail + tamper-evident governed egress audit = a complete, ordered, tamper-protected record of every AI dispatch decision and outcome; supports forensic reconstruction of the sequence of AI agent operations in a cybersecurity event |
Outside SDOS Operational Boundary¶
The following MDL-668 obligations fall outside the SDOS runtime governance boundary and require complementary organizational controls:
| MDL-668 Requirement | Why Outside SDOS Scope |
|---|---|
| Section 7 — Notification of Cybersecurity Events | Organizational and regulatory reporting obligation; SDOS audit records support the factual basis but notification is a governance process |
| Section 4(C)(3) — NPI content encryption | Data-layer encryption is outside the AI dispatch governance layer |
| Section 4(C)(4) — Secure development practices | SDLC controls for AI models and applications; SDOS governs runtime, not development processes |
| Section 4(C)(8) — Workforce training | Organizational training obligation; SDOS generates evidence but does not deliver training |
| Section 8 — Exemptions | Size-based and organizational exemptions; applicability determination is a legal function |
| Physical safeguards | Infrastructure and facility security; outside the software governance boundary |
Strongest SDOS Alignment — MDL-668¶
Three MDL-668 requirement areas where SDOS alignment is structurally strongest:
1. Risk Assessment and Ongoing Threat Evaluation (Section 4(B)) MDL-668 requires risk assessment and ongoing evaluation of threats. SDOS-RM-01 (Dispatch-Time Risk Classification), SDOS-RM-02 (Complexity-Tiered Resource Allocation), and SDOS-RM-03 (Risk-Floor Model Binding) implement continuous, per-invocation risk assessment at the AI dispatch boundary — every agent operation is classified before execution, producing a longitudinal risk record. This is not a point-in-time assessment; it is runtime risk evaluation at every decision point.
2. Access Control and Default-Deny Admission (Section 4(C)(1)) The MDL-668 access control requirement is satisfied at the AI agent layer by SDOS-GV-03 (Default-Deny Pre-Admission Policy) and SDOS-AD-01 (Default-Deny Agent Pre-Admission). No AI agent may access governed operations without explicit admission. Identity is cryptographically verified (SDOS-IA-01) before admission is evaluated. This structural default-deny posture exceeds a role-based access control model — admission is an affirmative grant, not an absence of denial.
3. Third-Party Service Provider Governance (Section 5) As insurers deploy AI agents from multiple vendors — LLM providers, workflow platforms, specialized model providers — MDL-668 Section 5 oversight obligations extend to the AI layer. SDOS-IA-01 and SDOS-IA-02 require cryptographic identity verification for every agent and module regardless of provider origin. SDOS-GV-05 model-alignment-independent policy enforcement ensures that governance constraints apply structurally, not through reliance on the third-party provider's alignment claims. This creates a technically enforceable third-party governance layer that operates independently of contractual obligations.
Insurance AI Context¶
Why the AI Dispatch Layer Matters for MDL-668¶
Insurance carriers are deploying AI agents at scale across underwriting (risk scoring, appetite determination), claims (automated processing, fraud scoring, subrogation routing), customer service (policy explanation, billing, FNOL intake), and internal operations (regulatory filing, actuarial support). Each means AI agents invoking tools, accessing data, and producing outputs that trigger operational consequences.
MDL-668's information security program requirement was written for the data layer. The AI dispatch layer — where SDOS operates — is the decision layer above the data layer. An AI agent that invokes a claims processing tool without governance is a different risk profile than the same tool invoked under a governance framework with dispatch-time classification, verified identity, pre-egress enforcement, and tamper-evident audit. SDOS makes the difference between those two profiles visible and auditable.
NAIC Model Bulletin on AI (2023)¶
In December 2023, the NAIC adopted a Model Bulletin on the Use of Artificial Intelligence Systems by Insurers. The Bulletin addresses insurer accountability for AI-driven decisions — particularly in underwriting and claims — and is not enforceable as a standalone regulation but signals the direction of state insurance department expectations. The Bulletin's accountability principles (documentation, explainability, ongoing monitoring) are reinforced by SDOS controls: SDOS-AU-01 through SDOS-AU-03 produce the evidentiary substrate that supports AI decision documentation; SDOS-DE-01 and SDOS-DE-02 support structured deliberation and decision records for AI-driven determinations.
Relationship to Other Frameworks¶
Insurance organizations subject to MDL-668 frequently operate under multiple overlapping compliance obligations. SDOS maps to the frameworks most relevant to multi-framework insurance environments:
| Framework | Overlap Area |
|---|---|
| SOC 2 | Common Criteria CC6 (logical access), CC7 (system monitoring), CC9 (risk mitigation); relevant for service organization audits |
| HIPAA | ePHI technical safeguards; relevant for health insurers and Medicare/Medicaid organizations |
| NIST AI RMF | AI risk management; SDOS is the control catalog mapped to NIST AI RMF as primary focal document |
| CMMC | For defense-adjacent insurance programs or DoD-adjacent subsidiaries |
Full framework library: SDOS Reference Library
Architectural Positioning¶
SDOS operates at the dispatch-time enforcement layer — the moment immediately before an AI agent invokes a tool, makes a decision, or produces an output. The SDOS framework does not replace organizational, physical, or personnel cybersecurity controls. It provides a runtime layer that enforces governance policy at the boundary where AI agents act, adding an architectural layer of cybersecurity assurance for AI-augmented operations.
For alignment purposes, SDOS supports the operational and technical requirements addressing how AI-driven cyber operations are deployed, monitored, and audited. Requirements addressing the organizational, physical, or personnel layer fall outside the SDOS scope and require separate controls.
Maintenance¶
This document is maintained by AAM Cyber as part of the SDOS Reference Library. The library currently covers 17 framework alignments: NIST AI RMF 1.0, NIST CSF 2.0, NIST SP 800-53 Rev 5.2.0, NIST AI 600-1, EU AI Act, DORA, HIPAA, PCI-DSS v4.0, CIS Controls v8, ISO 42001, FedRAMP Rev 5, CMMC 2.0, SOC 2, NAIC MDL-668, NERC CIP, IEEE P2863 (draft), and FAA UAS/AAM (principles-mapped). Version history for every framework alignment is published at /sdos/reference/changelog/.
Subsequent updates to this alignment page will be issued when: (1) screening feedback from a recognized standards body requires revision, (2) the focal framework releases a revision requiring mapping review, or (3) SDOS controls are added or retired affecting the alignment.
Intellectual Property¶
The SDOS Runtime Governance Framework was invented by Pharns Genece. Aspects of the framework are the subject of pending U.S. Provisional Patent Applications 64/029,300, 64/049,300, 64/067,427, 64/069,200, and 64/076,620. The scope of pending claims is defined by the as-filed specifications and is not coextensive with the descriptions in this document. AAM Cyber, all rights reserved unless otherwise indicated.
Patent inquiries should be directed to AAM Cyber at aamcyber.com.
Contact¶
AAM Cyber
aamcyber.com
Insurance organizations developing AI governance programs for MDL-668 compliance, or state insurance departments evaluating AI governance frameworks for regulatory guidance purposes: [email protected]
SDOS Runtime Governance Framework — NAIC Insurance Data Security Model Law Alignment. Version 1.1. Published 2026-05-12.