ISO/IEC 42001 for Health Plans: Scoping Prior Authorization and Claims AI

Start from the management system, not the model

ISO/IEC 42001:2023 specifies requirements for establishing, implementing, maintaining and continually improving an Artificial Intelligence Management System (AIMS). It describes an AIMS as a set of interrelated elements of an organization that establish policies, objectives and processes for the responsible development, provision or use of AI systems. It is a management system standard, not a technical control catalog. Certification is voluntary, and ISO notes the standard applies to organizations of all sizes and sectors, including healthcare providers and financial institutions.

For a health plan, that framing changes the first question. The scoping exercise is not "which models do we have?" but "which parts of our organization develop, provide or use AI, and which of those activities do we want the management system to cover?" Clause 4.3 addresses the scope of the AIMS and clause 6.1 addresses actions on risks and opportunities. Scope decisions and risk decisions should be made together, because a system left out of scope is also left out of the risk process.

Decide early whether the goal is certification or alignment. Certification brings independent audit and a heavier evidence burden. Alignment lets you adopt the structure with more flexibility. Official implementation guidance, ISO/IEC AWI 42003, is still under development, so scoping judgments currently rest on your reading of the standard itself and your own risk context.

Build the in-scope inventory

The inventory is the working document behind your scope statement. Record it at the level of decision points, not only systems, because a single vendor platform can contain several AI functions with different consequences for members and providers.

• Use cases: List AI in prior authorization triage, medical necessity support, claims editing, payment integrity and fraud detection.
• Ownership: Name an accountable owner for each system and decision point, whether the team is internal or the model is vendor-supplied.
• Decision influence: Note whether the AI recommends, prioritizes or routes, and who makes the final determination.
• PHI handling: Record which models, agents and tools receive ePHI, since the HIPAA Security Rule applies to ePHI a covered entity or business associate creates, receives, maintains or transmits.
• Vendor boundary: For vendor-supplied AI, document what you use, what you configure and what the vendor operates.
• Exclusions: Record each excluded system with a written rationale, since an unexplained exclusion invites questions.

Runtime enforcement versus organizational process

Annex A control areas relevant to this scope include AI system impact assessment, data management, third-party relationships, human oversight, and system logging and monitoring. Not all of them can be satisfied the same way. Some are management decisions that produce documents and records. Others describe behavior that can be enforced when an interaction happens. The split below is an editorial mapping to check against the standard's control text, not a reproduction of it.

• Impact assessment and risk assessment: Organizational process. Requires judgment, stakeholder input and management review. Runtime tooling can supply interaction data as an input.
• Data management for PHI: Mixed. Data governance decisions are organizational. Redacting or blocking PHI before it reaches a model or tool can be enforced at runtime.
• Third-party relationships: Mostly organizational: contracts, vendor assessment, defined responsibilities. Policy can still be enforced on traffic to and from vendor-supplied models.
• Human oversight: Mixed. Reviewer roles and authority are organizational. Escalating a specific action for human approval, and recording the outcome, can be enforced at runtime.
• Logging and monitoring: Mixed. Retention and review procedures are organizational. Records of each interaction and tool call can be generated as enforcement happens.
• Roles, lifecycle and improvement: Organizational process: accountability, change management, internal audit, management review and corrective action.

Where health plan regulation intersects the scope

Prior authorization is a regulated, time-bound process. Under CMS-0057-F, released January 17, 2024, impacted payers must implement and maintain certain HL7 FHIR APIs and streamline prior authorization. Impacted payers other than QHP issuers on the FFEs must send decisions within 72 hours for expedited requests and seven calendar days for standard requests. When scoping, identify each AI decision point that influences those timelines, such as triage that determines how quickly a request reaches a clinician, and treat it as a higher-consequence item in your risk assessment.

HIPAA applies independently of ISO/IEC 42001. Subpart C of 45 CFR Part 164 requires confidentiality, integrity and availability of all ePHI, and audit controls under 164.312(b) are relevant wherever AI workflows touch ePHI. Your scope should state which workflows meet that test, so the AIMS and the HIPAA program describe the same systems. As of November 2026, the HIPAA Security Rule NPRM published January 6, 2025 and the CMS proposed rule on prior authorization for drugs (91 FR 19890) are proposals, not final requirements. Reference current regulatory text in governance documents and track the proposals as watch items.

NAIC expectations for insurer AI use also belong in your mapping. Keep one regulatory register that links each in-scope system to the obligations it touches, and update it as the status of proposals changes.

What an auditor will want to see operate

A policy states intent. An auditor assessing a management system looks for evidence that the documented processes and controls are implemented and effective. For organizational requirements, that typically means the scope statement, risk assessment records, role assignments, review minutes and corrective actions. These are produced by people on a defined cadence and are largely a matter of discipline.

The harder gap for health plans is at the level of individual AI interactions. A policy might say PHI must not leave approved boundaries, or that certain actions require human sign-off. Demonstrating that this held across thousands of daily interactions, including calls between agents and tools, requires records created when the interaction occurs. Reconstructing them afterward from application logs is slow and often incomplete, particularly where vendor-supplied components are involved.

For each runtime-enforceable control in your mapping, define in advance what record proves it: the policy applied, the action taken (allowed, redacted, blocked or escalated), the time, and the approver where a human was involved. Sample these records periodically as part of internal audit. Be equally clear about what runtime evidence does not cover. Model lineage, training data provenance and design-stage decisions must be evidenced through other processes.

Where runtime enforcement fits

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, at the level of individual interactions and tool calls. Policy can allow, redact, block, rate limit or escalate an action for human approval, and enforcement is applied at runtime, not reviewed after the fact. That enforcement generates audit-ready evidence mapped to frameworks including HIPAA and NAIC, and it can be deployed self-managed in the customer cloud with configurable retention and data residency. Trussed runs in production with healthcare organizations.

In an ISO/IEC 42001 program, this supports the runtime-enforceable rows of the mapping above, such as PHI handling and human oversight at specific decision points. It does not replace the management system itself: scope, risk assessment, accountability and review remain organizational work.