ISO/IEC 42005 Impact Assessment Template: Sections, Fields, and Evidence to Attach

What the assessment is for and how it fits with other frameworks

ISO/IEC 42005:2025 gives organisations guidance for assessing how an AI system and its foreseeable applications may affect individuals, groups or society. ISO describes its purpose as supporting transparency, accountability and trust by helping organisations identify, evaluate and document potential impacts across the AI system lifecycle. It recommends performing assessments from design and development through deployment and post-market monitoring, and updating them as needed. It applies to any organisation that develops, provides or uses AI systems, regardless of sector or size. It is guidance, not a law, and not a certification scheme.

ISO positions ISO/IEC 42001 as the benchmark for managing AI responsibly and ISO/IEC 42005 as a methodology for identifying, analyzing and documenting the effects of individual AI systems. The two are complementary. In practice, the assessment is the per-system record that sits inside an ISO/IEC 42001 management system. It does not replace the management system.

The NIST AI RMF supplies useful cross-reference anchors. It treats impacts as positive, negative or both. For negative impacts, risk is a function of the magnitude of harm and the likelihood of occurrence. MAP 5.1 calls for the likelihood and magnitude of each identified impact, and MANAGE 1.2 calls for treatment of documented risks to be prioritized by impact, likelihood and available resources. NIST lists an INCITS/AI crosswalk between ISO/IEC 42005 and the AI RMF, which is a reasonable starting mapping once it has been checked against the standard text you hold.

A working template: sections, fields and evidence

The structure below is a practical template built around the standard's purpose. Map each field to the clause structure of the edition your organisation uses, and record that mapping in a cross-reference column. Every field should carry four attributes: the entry, the attached evidence, the owner and the last-updated date.

• 1. System description and context of use: Fields: purpose, intended users, deployment setting, foreseeable uses and misuse, lifecycle stage. Evidence: architecture description, approved use-case record, deployment scope.
• 2. Interested parties and stakeholder input: Fields: affected individuals and groups, how input was gathered, how it changed the design. Evidence: consultation records, review minutes, decisions taken.
• 3. Impact identification and characterization: Fields: each impact, whether positive or negative, affected party, likelihood, magnitude, context. Evidence: risk analysis, test and evaluation results, scenario reviews. Cross-reference MAP 5.1.
• 4. Treatment and operational controls: Fields: control per impact, priority, residual impact, enforcement point. Evidence: policy documents, control configuration, enforcement records. Cross-reference MANAGE 1.2.
• 5. Monitoring, human oversight and update triggers: Fields: metrics, review cadence, escalation path, approver roles, reassessment triggers. Evidence: monitoring reports, approval records, incident and change records.
• 6. Governance and cross-references: Fields: accountable owner, approval date, ISO/IEC 42001 and NIST AI RMF mappings, version history. Evidence: sign-off record, management system references.

Evidence from design and organizational processes

Sections 1 to 3 rest mostly on evidence created before and around operation. The system description should point to controlled documents rather than restate them. Stakeholder input needs dated records that show who was consulted and what changed as a result, because the AI RMF expects the decision to deploy to be informed by a broad set of interested parties.

Impact characterization is where narrative most often replaces substance. Each impact entry should state likelihood, magnitude and context of use, and link to the analysis or test result behind those ratings. Record positive impacts as well as harms, since the assessment is not limited to harm. A reviewer should be able to open any rating and find the analysis behind it.

The common failure is a template that describes intended behavior in fluent prose with nothing attached. That reads well and cannot be verified. An entry without attached evidence should be marked as an open item, not left looking complete.

Where runtime enforcement evidence substantiates the assessment

Sections 4 and 5 describe what the system is permitted to do and how that is watched. Documents can state the intended controls. They cannot show what happened on a given interaction. Records generated where policy is enforced in the execution path can. For each interaction or tool call, an assessor should expect a record of the policy applied and the decision taken: allow, redact, block, or escalate for human approval. Escalations should also show the approver's outcome.

That evidence maps to specific fields. A control entry such as "calls to this tool are blocked unless approved" can be paired with records showing the rule in force and the decisions it produced. A human oversight entry can be paired with escalation and approval records. The AI RMF notes that human intervention may be needed where a system cannot detect or correct its own errors, and approval records show that intervention happening. A monitoring entry can reference decision volumes and trends over a review period.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, and produces audit-ready evidence from that enforcement. Its scope is individual interactions and tool calls. This evidence supports the operational control and monitoring entries. It does not complete the assessment or establish conformance with the standard.

Retention and review need decisions in the template itself. Set the retention period for each evidence type so that it covers the reassessment cycle and any period in which an earlier assessment version may be questioned. Record where the evidence is stored and under which residency requirements. Trussed supports self-managed deployment in the customer cloud with configurable retention and data residency. Evidence volume at scale, which can reach tens of gigabytes per day, makes storage and sampling for review a design choice.

Evidence that must be sourced elsewhere

Runtime enforcement records say nothing about how a model was built or what data trained it. Model and dataset provenance, including lineage, belong in the template as separate evidence entries owned by the teams or suppliers that hold them. End-to-end tracing of an agentic workflow across tasks and agents is also a different kind of evidence from a per-interaction or per-tool-call record, and needs its own source. Trussed does not provide model provenance, dataset provenance or end-to-end workflow tracing.

The same applies to stakeholder consultation, impact analysis, pre-deployment test results and accountability sign-off. These come from design and organizational processes. A clear template marks each field with its evidence source type, so a reviewer can see at a glance which entries rest on runtime records and which rest on documents, and where nothing is attached yet.

The assessment should also work as a living record. Add an update trigger field tied to lifecycle stages and to events such as a change of model, a new tool, a changed policy, or an incident. When a trigger fires, the owner updates the entry and attaches current evidence, then the version history records the change.