ISO/IEC 42001 Controls for PHI and NPI in LLM Prompts

What ISO/IEC 42001 requires and what it leaves open

ISO/IEC 42001:2023 is a management system standard. It specifies requirements for establishing, implementing, maintaining and continually improving an Artificial Intelligence Management System (AIMS) within an organization that provides or uses AI-based products or services. An AIMS is the set of interrelated elements that establishes policies, objectives and processes for the responsible development, provision or use of AI systems. ISO's own explainer lists data governance and system lifecycle controls among its requirements.

That framing defines what the standard can and cannot tell you. It requires that you have policies, objectives and processes for data handling in AI systems. It does not tell you how to stop a clinician, a payer analyst or an agent from pasting a member identifier into a prompt at 2 a.m. That gap is where a stated control and runtime behavior diverge. A policy document and an after-the-fact review show intent. They do not show what happened on a given interaction.

Two scope points matter before mapping begins. First, ISO/IEC 42001 is voluntary, and conformance does not by itself satisfy HIPAA, whose obligations come from 45 CFR Part 164. Second, ISO/IEC 42003, guidance on implementing ISO/IEC 42001, is still a work item as of November 2026, so teams should expect to interpret the controls themselves.

Mapping control themes to prompt-level handling

Map by control theme first, then record the Annex A control identifiers from the standard's text against each row. The split below is a design pattern, not a requirement of the standard. The test for each row is whether a per-prompt decision exists, or whether the control is carried by people and procedure.

• Data governance: Runtime: classify prompt content as PHI, NPI or neither, and apply the matching rule. Organizational: data categories, permitted uses, policy owners. Evidence: the classification outcome and rule applied for each interaction.
• Privacy and data minimization: Runtime: redact identifiers that the use case does not need before the prompt reaches the model. Organizational: approval of each use case and its data scope. Evidence: what was redacted, under which policy version.
• Blocking prohibited data: Runtime: block prompts or tool calls that carry data a use case is not allowed to send. Organizational: definition of prohibited categories. Evidence: the blocked event and the reason.
• Human oversight: Runtime: escalate defined cases for human approval before the call proceeds. Organizational: reviewer roles and authority. Evidence: the escalation, the approver and the outcome.
• Operational monitoring: Runtime: continuous capture of enforcement decisions. Organizational: periodic review of that activity and corrective action. Evidence: records plus review minutes showing examination.
• Roles, lifecycle and change: Runtime: policy versions applied consistently across models and tools. Organizational: change approval, training, internal audit and management review. Evidence: version history tied to decisions.

Where HIPAA 164.312(b) intersects

The HIPAA Security Rule audit controls standard, 45 CFR 164.312(b), requires covered entities and business associates to implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information. OCR continues to cite it in its 2026 cybersecurity newsletters, so it remains an active reference as of November 2026.

An LLM interaction path that handles ePHI plausibly falls within that scope, including gateways and the stores that hold prompts and responses. Treat that as a scoping judgment to confirm with counsel and your security officer rather than a settled point. The wording permits procedural mechanisms, so after-the-fact review is textually allowed. The operational question is whether it is sufficient for your risk position. If an unredacted identifier has already reached a model, review can only report the exposure.

The standard has two verbs, and evidence should address both. Record means each relevant interaction and enforcement decision is captured. Examine means someone reviews that activity on a defined cadence and acts on findings. Enforcement decisions that are captured as records can serve both ISO 42001 monitoring evidence and HIPAA audit-control evidence, provided the review step is also documented.

Why NPI needs its own rules

PHI and NPI sit under different regimes: HIPAA for PHI, and the Gramm-Leach-Bliley Act for nonpublic personal information held by financial institutions. In healthcare, NPI tends to appear where payer, billing or financing data is in scope. Governance should assign separate policy owners and separate rules for each data type, and the enforcement layer should be able to apply different actions to each.

The difference is not only vocabulary. FTC guidance on the GLBA privacy rule says consumers and customers must have a reasonable opportunity to opt out, for example 30 days after the initial notice, before their information is shared with nonaffiliated third parties outside the exceptions. A rule for NPI in prompts therefore has to reflect sharing and opt-out constraints, and whether a particular model provider arrangement counts as such sharing is a determination for legal and privacy owners. Define the NPI categories and permitted flows before writing the prompt rule, not after.