ISO/IEC 42005 Impact Assessment Template for Healthcare AI

What the assessment is and how to scope it

ISO/IEC 42005:2025, titled Information technology, Artificial intelligence (AI), AI system impact assessment, is published under ISO/IEC JTC 1/SC 42. It addresses the assessment of how an AI system may affect individuals and groups. For a healthcare organization, that means a documented, repeatable record for each AI system that touches PHI, clinical workflows or patient-facing interactions.

The assessment sits alongside ISO/IEC 42001, the AI management system standard. In practice, many teams treat the completed assessment as an input to their management system: it records the impacts that policies, controls and reviews are then expected to address. Confirm exact clause wording against your licensed copies of both standards before you cite them in audit materials.

The most useful structural decision is to keep two kinds of fields apart. Standard-derived fields follow the assessment elements listed below. Healthcare additions, such as PHI exposure, clinical decision support context and foreseeable misuse by clinicians, are organization-defined. Label them that way in the template so an auditor can see what comes from the standard and what your team chose to add.

Template sections and healthcare fields

The template follows six elements: system description, intended and foreseeable use, affected individuals and groups, potential benefits and harms, mitigations, and documentation and review. Each section below lists the standard-derived purpose first and the healthcare additions second. Assign a named owner to every section.

• 1. System description: Record the system's purpose, components, deployment context and data flows. Healthcare additions: which PHI elements enter prompts, retrieved context or tool calls; where outputs are stored; which clinical or administrative systems the AI can reach.
• 2. Intended and foreseeable use: State the intended use, then use that is reasonably foreseeable. Healthcare additions: whether output informs a clinical decision or only supports administrative work; who may use it; foreseeable misuse such as pasting identifiable records into a general assistant or treating a draft as a clinical recommendation.
• 3. Affected individuals and groups: Identify who the system can affect, directly or indirectly. Healthcare additions: patients, clinicians, care staff, caregivers and populations at risk of unequal performance. Include patients who never interact with the system but whose records it processes.
• 4. Potential benefits and harms: Record both, by group. Healthcare additions: harms such as PHI disclosure, inaccurate or unsafe content in a clinical setting, biased output across patient groups, and patient confusion when an AI interaction is not clearly identified.
• 5. Mitigations: For each harm, record the mitigation, its owner and its residual risk. Healthcare additions: state each mitigation as an enforceable action where possible, and name the evidence record expected to show it operated.
• 6. Documentation and review: Record version, date, approvers and review triggers. Healthcare additions: a link to the evidence reviewed at each cycle and a note on any change to PHI scope, clinical use or connected tools.

Treat the assessment as a living record

A one-time document ages quickly. Models are swapped, prompts change, new tools are connected and users find new uses. Version each assessment, date every review and record who approved it.

A practical review policy has two parts: a scheduled review and event-driven reviews. Typical triggers include a change of model, a new data source, a new tool or system the AI can call, expansion from administrative to clinical use, and an incident involving PHI. These triggers are suggested practice rather than requirements you should attribute to the standard.

At each review, compare what the assessment says should happen with what the evidence shows did happen. If blocked or escalated events cluster around one workflow, that is a signal that the impact analysis for that workflow was incomplete. Update the assessment and the control together.

Two SC 42 projects are in development and worth watching: a template for documenting ethical issues of an AI system (ISO/IEC CD TS 25571) and a project on identifying and treating unwanted bias in AI in healthcare (ISO/IEC AWI TS 26312). Neither is a published standard as of November 2026, so do not cite either as a requirement. The NIST AI RMF 1.0 and its Generative AI Profile are available as complementary reference frameworks.

Map each impact to a runtime control and an evidence record

The weak point in most assessments is the gap between the mitigation column and what happens in production. A statement such as "PHI will not be sent to external models" is a commitment. An auditor or regulator will ask how it is enforced and what shows it was.

Close the gap by adding three fields to every impact row: the enforced action, the scope at which it applies, and the evidence record. Use a small, fixed action vocabulary so each row is testable: allow, redact, block, or escalate for human approval. Evidence of these decisions is also what you would reference in your HIPAA 164.312(b) audit controls position, once you have confirmed the current regulation text and how your organization applies it to AI systems that handle ePHI.

• PHI in a prompt to an external model: Action: redact identifiers, or block if redaction is not possible. Evidence: a record of each decision with the policy that applied.
• Draft clinical text presented as a recommendation: Action: escalate for human approval before release. Evidence: the approval record, the approver and the outcome.
• AI tool call that writes to a patient record system: Action: block by default, allow for named roles and systems. Evidence: allow and block decisions per tool call.
• Use outside the documented intended use: Action: block or escalate. Evidence: the denied or escalated interaction, available for the next review.

Where runtime enforcement fits

Trussed enforces policy in the execution path of AI interactions, across models, agents, tools, MCP servers, AI sites and coding assistants. Policies are enforced at runtime, not reviewed after the fact, and the available actions include allow, redact, block, rate limit and escalate for human approval. The scope is individual interactions and tool calls. That is the level at which the table above operates, so the impact rows in your assessment can reference the same actions the platform applies.

This is relevant to healthcare because the mitigations in the assessment can be written as enforceable policy rather than guidance. Trussed runs in production with healthcare and pharma organizations, and it can be deployed self-managed in the customer cloud, with configurable retention and data residency, which matters when evidence itself may reference PHI-adjacent activity.

Audit-ready evidence for the review cycle

Enforcement produces continuous, audit-ready evidence, mapped to HIPAA and NIST among other regimes. In the assessment template, the evidence field for each mitigation points to this record. At review, the compliance owner can show that a stated mitigation was applied to actual interactions, not only that it was designed.

To be precise about scope: this evidence covers policy decisions on individual interactions and tool calls. It does not replace the human work of the assessment itself, such as identifying affected groups, judging clinical risk or deciding residual risk. It also does not address model or dataset provenance, which your assessment should treat as a separate documentation task.

For teams starting out, pick one system that handles PHI, complete the six sections, define the action and evidence record for each high-impact row, and run one review cycle against real evidence before extending the template to other systems.