Document the potential consequences of an AI system's deployment, intended use, and foreseeable misuse for individuals, groups, and societies in the relevant technical, societal, and jurisdictional context.
Use the result as an input to AI risk assessment and repeat the assessment at planned intervals or when significant changes are proposed. This Sorena template is not an official ISO form or a substitute for a legally required assessment.
Structured answer sets in this page tree.
Cited legal and guidance references.
Use this template to document potential consequences for individuals, groups, and societies across the system lifecycle. ISO/IEC 42001:2023 Clauses 6.1.4 and 8.4 connect the assessment to AI risk assessment, require reassessment at planned intervals or when significant changes are proposed, and require the results to be retained as documented information.
Determine the potential consequences of the AI system's deployment, intended use, and foreseeable misuse. Use the result in the AI risk assessment. The organisation's process can also use it to inform whether the proposed or operating AI system can proceed, needs design or control changes, requires conditions or escalation, or should stop. The assessment should identify positive and negative consequences, who can experience them, their likelihood and severity where the chosen method uses those measures, and how the organisation will address them.
Assess deployment, intended use, reasonable foreseeable misuse, predictable failures, human involvement, data and technology, and the technical, societal, and jurisdictional context. Consider individuals, relevant demographic or other groups, and societal effects rather than limiting the assessment to model accuracy or organisational loss.
Define who performs the assessment, who supplies specialist or affected-party input, who approves the resulting decision, and what counts as a significant change. Preserve assumptions and evidence gaps so the approval authority can distinguish a supported conclusion from an unresolved question.
Use evidence that describes the deployed system and its actual context: inventory and architecture records, intended-use and misuse scenarios, data and evaluation records, user research, accessibility or human-factors work, supplier information, incident and complaint history, legal or contractual requirements, and comparable non-AI processes where relevant.
Evidence quality can vary by lifecycle stage. A pre-deployment assessment may rely on test results and justified assumptions; an operating-system review should also use production monitoring, complaints, incidents, overrides, outcomes, and affected-party feedback. State the period, population, environment, and limitations of every important input.
Capture owners, evidence, decisions, and review dates in one workflow record so AI governance controls and escalation points stay auditable over time.
Convert ISO/IEC 42001 AI Impact Assessment Template into accountable tasks, evidence requests, and review checkpoints.
Review your current scope, evidence gaps, and next implementation steps.
Maintain one controlled assessment record with the fields below. Adapt the scoring method and approval levels to the organisation's context; ISO/IEC 42001 does not prescribe this wording, a universal score, or a single acceptance threshold.
Each field should identify its owner and evidence source. Where facts are missing, record an open issue and decide whether the uncertainty blocks approval, requires a condition, or can be monitored after deployment.
Record the people, decision, evidence, and safe intervention for each use case. Use the scenarios below to test whether the organisation's assessment method captures the relevant deployment facts. These Sorena examples do not assign the same impact or legal classification to every system in a named sector.
For each scenario, identify the organisation's lifecycle role, the person or group affected, the consequence pathway, the human decision point, the evidence needed before release, the monitoring signal, the authority that can pause use, and the change that triggers reassessment. Apply separate legal, safety, privacy, employment, medical, financial, education, or public-sector requirements where they govern the actual deployment.
At intake, confirm the system, use, lifecycle stage, assessor, approver, evidence owners, method, and decision deadline. Identify impacts and affected parties, analyse and evaluate them using the chosen criteria, decide treatment, then route the result into AI risk assessment and the release or operating decision.
Do not close the assessment while blocking evidence gaps or actions remain unresolved. For conditional approval, record the operating limits, monitoring signals, escalation thresholds, action owners, and expiry or review point.
Common failures are assessing only technical model performance, listing harms without a causal path or affected population, omitting beneficial impacts and foreseeable misuse, hiding uncertainty, and using one residual-risk score without the underlying evidence or decision criteria.
A privacy, safety, security, human-rights, or regulatory assessment can supply evidence, but it is not automatically sufficient for every ISO/IEC 42001 impact topic. Map what the specialist assessment covers, identify gaps, and keep separate legal forms or mandatory wording where applicable.
Repeat the assessment at the organisation's planned intervals and when a significant change is proposed. Relevant triggers can include changes to intended purpose or use context, automation, data sensitivity or sources, technology, supplier, affected population, human oversight, performance, incidents, or applicable requirements.
When reassessment changes the decision, update the risk assessment and treatment, controls, release or operating conditions, monitoring criteria, user information, inventory record, and any required external communication.