ISO/IEC 42005 AI System Impact Assessment | Step-by-Step
step-by-step approach to conducting an ISO/IEC 42005-aligned AI system impact assessment.
In this Article
- June 5, 2026
- CyberZoni
1. What an AI System Impact Assessment Is
An AI system impact assessment asks: What effects could this AI system have, on whom, under what operating conditions, and what should the organization do before, during, and after deployment?
ISO/IEC 42005:2025 is the ISO standard for AI system impact assessment. ISO’s public summary describes it as guidance for organizations conducting AI system impact assessments focused on how AI systems and foreseeable applications may affect individuals, groups, or society. The standard is system-level: it is concerned with a particular AI system in a particular context of use, rather than with an organization’s entire AI governance program.
The assessment is broader than a model validation exercise. It covers technical behavior, data, user workflow, affected groups, foreseeable misuse, accountability, controls, monitoring, and reassessment across the AI lifecycle.
Common misconception | Better framing |
“We assessed the model accuracy, so the impact assessment is done.” | Assess the full system, including data, users, decisions, affected groups, and operating context. |
“Human in the loop means the risk is low.” | Human oversight must be meaningful, trained, empowered, timed correctly, and monitored. |
“The system is internal, so people are not affected.” | Internal AI can affect employees, customers, applicants, vendors, and downstream decisions. |
“One assessment at launch is enough.” | Refresh the assessment when the system, data, use context, supplier, or legal environment changes. |
2. When to Perform the Assessment
Do not wait until launch. Conduct a screening assessment at concept stage, deepen it during design and development, use it as a pre-deployment approval gate, and maintain it during operation. ISO’s public summary notes that ISO/IEC 42005 supports impact assessments throughout the AI system lifecycle and updates as needed.
Trigger | Why it matters |
New AI system is proposed | Early screening prevents unacceptable or mis-scoped use cases. |
Pilot moves to production | Real-world populations, incentives, workload, and consequences often differ from pilot assumptions. |
New population, country, customer, or sector is added | A safe use in one context can become harmful or unlawful in another. |
Model, data source, vendor, retrieval corpus, prompt, or workflow changes | The previous assessment may no longer reflect actual behavior or impact pathways. |
Autonomy level increases | Higher automation can reduce contestability and increase accountability concerns. |
Incidents, complaints, bias signals, or performance drift occur | Monitoring evidence can invalidate the original assessment. |
Legal, contractual, policy, or sector obligations change | Compliance assumptions may need revision. |
3. Step-by-Step Method
Step 1: Establish the Assessment Mandate
Start by defining who owns the assessment, what decision it supports, and what evidence will be required. An impact assessment without a decision mandate often becomes a checklist exercise rather than a governance control.
Item | What to define |
Assessment owner | The person responsible for coordinating the assessment and maintaining the record. |
Business owner | The accountable owner of the use case, expected benefits, and deployment decision. |
Technical owner | The accountable owner of the model, data pipeline, architecture, and technical controls. |
Decision authority | The person or committee that can approve, condition, escalate, pause, reject, or retire the system. |
Scope | The specific AI system, use case, population, geography, and deployment environment covered. |
Reviewers | Legal, privacy, security, risk, data science, product, domain experts, and affected-user representation where appropriate. |
Approval gate | The lifecycle point at which approval is required. |
Review cadence | The ordinary reassessment cycle and event-based reassessment triggers. |
Step 2: Describe the AI System Clearly
A weak system description leads to weak impact analysis. Describe the AI system in operational terms that a business, technical, legal, and domain reviewer can all understand.
Area | Questions to answer |
Purpose | What is the system intended to do, and what problem is it supposed to solve? |
Decision role | Does it recommend, classify, generate, predict, rank, route, decide, or act? |
Users | Who operates, configures, reviews, or relies on the output? |
Affected persons | Who may be affected even if they never use the system? |
Model type | Rules, machine-learning model, large language model, recommender, computer vision, agentic system, or hybrid system. |
Data inputs | What data enters the system? Is it personal, sensitive, proprietary, inferred, scraped, synthetic, or third-party? |
Outputs | What does the system produce, and in what form? |
Downstream action | What human or automated action follows the output? |
Autonomy | Is a human in the loop, on the loop, or out of the loop? |
Deployment context | Internal, customer-facing, public-sector, safety-critical, employment, education, healthcare, finance, or another context. |
Supplier role | Built in-house, vendor product, foundation model API, open-source component, or embedded third-party capability. |
Monitoring | What logs, metrics, alerts, review processes, and incident pathways exist? |
Step 3: Define Intended Use, Foreseeable Misuse, and Prohibited Use
The same AI capability can be acceptable in one context and unacceptable in another. Impact assessment must therefore be use-context specific.
Category | Description | Example |
Intended use | Approved purpose, user, population, geography, and operating conditions. | Summarize customer support tickets for internal triage. |
Foreseeable misuse | Plausible off-label, careless, mistaken, or malicious use. | Use the summary as the sole basis for denying a refund. |
Prohibited use | Use banned by law, contract, internal policy, or ethical boundary. | Infer protected characteristics or use the output for automated exclusion. |
Misuse prompts
- Could users over-rely on the AI output?
- Could the AI be applied to populations it was not validated for?
- Could decision support become de facto automated decision-making?
- Could outputs expose personal, confidential, or copyrighted data?
- Could a malicious user manipulate prompts, inputs, labels, retrieval sources, or tools?
- Could the system be repurposed for surveillance, profiling, exclusion, or manipulation?
- Could automation hide responsibility or make appeal difficult?
Step 4: Identify Stakeholders and Affected Groups
Impact assessment should include direct users, decision subjects, indirectly affected people, vulnerable groups, internal operators, oversight functions, suppliers, and broader public-interest stakeholders. The point is to avoid designing controls only around the organization’s own convenience.
Stakeholder category | Examples |
Direct users | Employees, analysts, clinicians, support agents, teachers, reviewers. |
Decision subjects | Applicants, patients, customers, students, workers, citizens. |
Indirectly affected people | Family members, communities, bystanders, people in downstream records. |
Vulnerable or protected groups | Children, older people, disabled people, minority groups, low-income users, people with limited ability to opt out. |
Operators | Product, engineering, data science, customer support, operations. |
Oversight functions | Legal, privacy, security, compliance, risk, audit. |
External actors | Vendors, regulators, unions, advocacy groups, customers, civil society. |
Society and environment | Labor markets, information ecosystem, democratic processes, public trust, energy and resource use. |
Practical methods
- Stakeholder interviews and facilitated workshops.
- User-journey and service-blueprint mapping.
- Expert review by domain, legal, privacy, security, and human-rights specialists.
- Review of complaints, incidents, appeals, and historical service-denial patterns.
- Community or affected-group consultation for public-sector or high-impact systems.
Step 5: Select Impact Categories
Use a broad taxonomy first, then tailor it to the specific AI system. Mark categories as relevant, not relevant, unknown, or requiring expert review. Do not delete a category merely because it is inconvenient; document the rationale.
Impact category | What to examine |
Safety | Physical harm, unsafe recommendations, unsafe automation, failure under abnormal conditions. |
Health and wellbeing | Stress, mental harm, reduced access to care or support, emotional burden. |
Fairness and discrimination | Disparate error rates, exclusion, stereotyping, proxy discrimination, unequal access. |
Privacy and data protection | Excessive collection, inference, re-identification, retention, leakage, secondary use. |
Autonomy and human agency | Manipulation, dark patterns, over-reliance, inability to opt out, loss of meaningful choice. |
Transparency and explainability | Whether people understand AI use, limitations, and the basis for decisions. |
Contestability and due process | Ability to challenge, appeal, correct, or escalate. |
Security and misuse | Prompt injection, adversarial inputs, unauthorized access, fraud, abuse, model theft. |
Reliability and robustness | Errors, hallucination, poor generalization, calibration, drift, instability. |
Economic impact | Job displacement, unfair pricing, denial of opportunity, economic dependency. |
Social and democratic impact | Misinformation, surveillance, chilling effects, polarization, inequitable service delivery. |
Environmental impact | Compute use, energy consumption, hardware, emissions, waste. |
Organizational impact | Reputation, legal exposure, operational dependency, vendor lock-in. |
Step 6: Build Impact Scenarios
An impact scenario describes how a harm or benefit could actually occur. Good scenarios are causal and concrete. They connect a source or condition to AI behavior, a human or automated action, a consequence, and an affected group.
Field | Description |
Scenario ID | A stable identifier, such as IMP-001. |
Impact category | The category or categories implicated. |
Affected stakeholder or group | The people, group, organization, or public interest affected. |
Source or cause | The data, design, user, supplier, threat, or contextual condition that creates the pathway. |
AI behavior | The model output, failure mode, system behavior, or interaction pattern. |
Consequence | The real-world effect that follows the output or system behavior. |
Existing controls | Controls already in place before additional treatment. |
Evidence | Data, test results, workflow review, interview notes, supplier evidence, or incident history. |
Initial rating | Severity, likelihood, scale, reversibility, detectability, and vulnerability before new controls. |
Required action | Mitigation, redesign, restriction, escalation, rejection, or monitoring. |
Scenario discovery techniques
Technique | Best for |
Data-flow review | Privacy, leakage, inference, lineage, and retention impacts. |
User-journey mapping | Human oversight, appeal, transparency, and accountability issues. |
Failure mode analysis | Reliability, safety, operational, and workflow harms. |
Bias and fairness testing | Disparate performance and outcome analysis. |
Threat modeling | Security, misuse, adversarial manipulation, abuse pathways. |
Red teaming | Generative AI misuse, jailbreaks, harmful outputs, tool abuse. |
Human-rights review | Public-sector, high-impact, vulnerable-group, or rights-affecting systems. |
Environmental review | High-compute training or large-scale inference. |
Supplier assessment | Third-party model, AI service, data provider, or embedded component dependencies. |
Step 7: Analyze Severity, Likelihood, Scale, and Reversibility
Impact assessment should not collapse every issue into a simplistic average risk score. Some impacts are rare but severe; others are individually modest but affect many people. Assess each dimension separately before assigning a priority.
Dimension | Question | Suggested scale |
Severity | How serious is the consequence for affected people or society? | 1 to 5 |
Likelihood | How likely is the scenario under intended use and foreseeable misuse? | 1 to 5 |
Scale | How many people, groups, services, or systems could be affected? | 1 to 5 |
Reversibility | Can the impact be corrected after it occurs? | 1 to 5, where 5 means hard to reverse |
Detectability | Would the organization know the impact occurred? | 1 to 5, where 5 means hard to detect |
Vulnerability | Are affected groups especially vulnerable or unable to opt out? | 1 to 5 |
Severity score | Illustrative meaning |
1 | Minimal inconvenience or easily corrected issue. |
2 | Minor adverse effect with low lasting consequence. |
3 | Material adverse effect, service denial, financial loss, or reputational harm. |
4 | Serious harm, discriminatory exclusion, legal rights affected, or safety risk. |
5 | Severe, irreversible, systemic, life-impacting, or rights-threatening harm. |
Important scoring rule
Do not average away severe impacts on small or vulnerable groups. A system that works well on average can still be unacceptable if it creates serious harm for a protected, marginalized, or otherwise vulnerable group.
Step 8: Evaluate Acceptability
After identifying and rating impact scenarios, decide whether each impact is acceptable, unacceptable, or acceptable only with treatment. This is a governance judgment, not merely a technical calculation.
- Is the impact lawful in the deployment context?
- Is it consistent with organizational AI policy and risk appetite?
- Is it consistent with human rights, safety, fairness, and human-centered design commitments?
- Are affected people informed in a meaningful way?
- Can affected people contest, appeal, correct, or escalate?
- Is there meaningful human oversight where required?
- Are the expected benefits proportional to the potential harm?
- Are impacts distributed fairly across groups?
- Are vulnerable groups exposed to greater harm?
- Is the impact reversible and detectable?
- Could the impact become systemic or cumulative over time?
Decision option | Meaning |
Accept | Residual impact is within tolerance and justified by documented rationale. |
Mitigate | Add controls before approval. |
Redesign | Change system purpose, data, model, interface, workflow, or autonomy. |
Restrict | Limit users, geography, population, autonomy, or use case. |
Transfer or share | Use contractual, supplier, insurance, or shared-control mechanisms where appropriate. |
Escalate | Send to senior risk, legal, ethics, or executive authority. |
Reject | Do not deploy, discontinue the use case, or retire the system. |
Step 9: Select Controls and Mitigations
Controls must be tied to specific impact scenarios. Avoid generic statements such as “human in the loop” unless the assessment explains exactly what the human reviewer does, when they do it, what information they receive, what authority they have, and how effectiveness is monitored.
Control type | Examples |
Design controls | Narrow intended use, reduce autonomy, add friction for high-impact actions, require confirmation. |
Data controls | Data minimization, representativeness testing, lineage review, retention controls, consent checks. |
Model controls | Validation, robustness testing, calibration, disaggregated performance testing, model comparison. |
Human oversight | Review thresholds, escalation rights, override authority, reviewer training, workload controls. |
User interface controls | Warnings, explanations, source citations, confidence indicators, limitation notices. |
Transparency controls | AI notices, system cards, model cards, user documentation, affected-person explanations. |
Contestability controls | Appeal channel, correction process, human reconsideration, evidence preservation. |
Security controls | Access control, prompt-injection defenses, abuse monitoring, audit logs, data-loss prevention. |
Operational controls | Incident response, rollback, change control, monitoring dashboards, release gates. |
Supplier controls | Due diligence, audit rights, change notification, evaluation evidence, service-level obligations. |
Environmental controls | Model-size optimization, compute monitoring, inference-volume controls, emissions reporting where material. |
Step 10: Determine Residual Impact
After controls are selected, reassess each scenario. The purpose is to determine whether the remaining impact is acceptable, whether more work is required, or whether the deployment must be restricted, escalated, or rejected.
Scenario | Initial rating | Controls | Residual rating | Decision |
Subgroup false negatives | High | Subgroup testing, threshold review, human appeal, monthly monitoring | Medium | Approve with monitoring |
Sensitive data leakage | Critical | Data minimization, redaction, access control, logging, security test | Medium | Approve after security evidence |
User over-reliance | High | Reviewer training, UI limitations notice, mandatory review for high-impact cases | Medium | Conditional approval |
Approval rule
For high-impact systems, approval should include documented sign-off from accountable business, technical, risk, legal, privacy, security, and domain authorities. Critical residual impacts should be escalated to senior executive or board-level authority.
Step 11: Prepare the AI System Impact Assessment Report
The report should be readable by non-technical reviewers but detailed enough for audit, assurance, and future reassessment. It should explain not only what was decided, but why the decision was justified based on evidence.
Report section | Purpose |
Executive summary | Decision, highest residual impacts, required mitigations, deployment conditions, next review. |
System description | Purpose, model, data, workflow, users, affected groups, suppliers, boundaries. |
Intended and excluded use | Approved use, foreseeable misuse, prohibited use, escalation path for new use. |
Assessment scope and method | Assessment team, evidence reviewed, workshops, test methods, limitations. |
Stakeholder and affected-group analysis | Who may be affected and how they were identified or consulted. |
Impact categories considered | Relevant, not relevant, unknown, and rationale. |
Impact scenarios | Causal scenario register and assumptions. |
Initial impact analysis | Ratings before additional controls. |
Controls and mitigations | Linked controls, owners, due dates, evidence, effectiveness tests. |
Residual impact analysis | Ratings after controls and decision rationale. |
Monitoring and reassessment plan | Metrics, triggers, thresholds, review cadence, incident pathway. |
Transparency and communication plan | Internal and external notices, user instructions, appeal information. |
Open issues and action tracker | Unresolved items, responsible owners, due dates. |
Step 12: Communicate Findings Appropriately
Transparency does not mean publishing everything. It means giving the right stakeholders the right information in a usable form, while protecting security, privacy, trade secrets, and legal privilege where appropriate.
Audience | Information to provide |
Internal users | Approved and prohibited uses; known limitations; required human oversight steps; escalation path; incident reporting; examples of bad outputs. |
Affected people | Notice that AI is used; purpose; decision role; human oversight; appeal or correction path; contact channel. |
Suppliers | Evidence requests; change-notification obligations; incident-notification obligations; service levels; audit rights. |
Oversight functions | Assessment record, residual impacts, controls, open issues, monitoring plan, approval rationale. |
Step 13: Monitor Impacts in Operation
A pre-deployment assessment is only a baseline. Monitoring determines whether the assumptions remain true in operation. NIST’s AI Risk Management Framework is a useful complementary reference because it frames AI risk management as a govern-map-measure-manage cycle and is intended for voluntary use.
Monitoring area | Example metrics |
Model performance | Accuracy, precision, recall, false positives, false negatives, calibration. |
Fairness | Disaggregated error rates, selection rates, adverse impact indicators. |
Data quality | Missingness, drift, outliers, stale data, source changes. |
Human oversight | Override rates, review time, escalation frequency, reviewer disagreement. |
User behavior | Over-reliance signals, ignored warnings, misuse attempts, policy violations. |
Complaints and appeals | Appeals, corrections, disputes, user feedback, case reversals. |
Security | Abuse attempts, prompt injection, unauthorized access, suspicious query patterns. |
Reliability | Downtime, failed outputs, hallucination rates, incident counts. |
Environmental impact | Compute usage, inference volume, energy estimates where material. |
Reassessment triggers
Reassess when the model changes, data source changes, system is used for a new purpose, new affected group is introduced, geography or legal context changes, autonomy increases, a serious incident occurs, complaint trends emerge, monitoring shows drift, suppliers materially change functionality, or law/policy changes.
Step 14: Manage Retirement or Decommissioning
AI systems can create impacts when they are withdrawn, replaced, archived, or left in informal use. Decommissioning should therefore be part of the lifecycle assessment.
Question | Why it matters |
Will people lose access to a service? | Withdrawal can create service gaps or unequal access. |
Will past AI-supported decisions remain in force? | Affected people may still need appeal or correction rights. |
Do affected people need notice? | Transparency obligations may continue after discontinuation. |
Must data be deleted, retained, or archived? | Retention must satisfy legal, privacy, audit, and appeal needs. |
Will logs remain available? | Audit and incident investigation may depend on evidence preservation. |
Could the retired model still be used informally? | Shadow use can bypass controls and monitoring. |
Are downstream systems dependent on its outputs? | Retirement can break workflows or propagate stale data. |
4. Example: AI Hiring Screening Tool
This simplified example shows how the method can be applied to a high-impact employment use case. The example is illustrative only; employment systems require jurisdiction-specific legal review and domain-specific validation.
Assessment area | Example finding |
System | AI system ranks job applicants for recruiter review. |
Intended use | Decision support for recruiter prioritization. |
Prohibited use | Fully automated rejection or sole basis for adverse employment decision. |
Affected groups | Job applicants, including protected and underrepresented groups. |
Key impact | Discriminatory exclusion or denial of employment opportunity. |
Evidence needed | Subgroup performance metrics, selection-rate analysis, workflow review, recruiter behavior review, appeal data. |
Initial rating | Critical if ranking materially affects who receives human review. |
Controls | No auto-rejection; minimum qualification review; subgroup testing; audit sampling; recruiter training; appeal path; monitoring. |
Residual rating | Medium or high depending on evidence and control effectiveness. |
Decision | Approve only if fairness, oversight, contestability, and monitoring controls pass. |
5. Minimum Evidence
A credible impact assessment is evidence-based. Assertions such as “the model is fair” or “users will review everything” should be backed by test results, workflow design, monitoring data, or accountable procedures.
Evidence | Purpose |
System architecture | Shows boundaries, dependencies, and control points. |
Data inventory | Identifies sensitive, personal, proprietary, or high-impact data. |
Data lineage | Shows where data came from and how it was transformed. |
Model documentation | Explains model type, purpose, limitations, evaluation, and versioning. |
Supplier documentation | Supports third-party accountability and change management. |
User workflow | Shows how AI output affects real decisions. |
Stakeholder register | Shows who may be affected. |
Impact scenario register | Shows identified benefits, harms, assumptions, and pathways. |
Test results | Supports performance, robustness, fairness, safety, and reliability claims. |
Security review | Supports misuse and adversarial-risk analysis. |
Privacy assessment | Supports data protection, inference, retention, and lawful-use analysis. |
Human oversight procedure | Shows how humans intervene, override, or escalate. |
Incident response plan | Shows how harm will be detected, investigated, corrected, and reported. |
Approval record | Shows accountable decision-making and deployment conditions. |
Monitoring dashboard | Supports ongoing lifecycle assessment and reassessment triggers. |
6. Templates That Can Be Used for an AI System Impact Assessment
Templates can make an AI system impact assessment more consistent, repeatable, and easier to review. They should not replace legal review, stakeholder consultation, or technical validation. Instead, they should act as structured working documents that help the assessment team collect evidence, assign responsibilities, document decisions, and maintain records over the AI system lifecycle.
CyberZoni offers several ISO/IEC 42005 and ISO/IEC 42001-related templates that can support different parts of the AI system impact assessment process.
AI System Impact Assessment Template
The primary template for documenting the assessment is the AI System Impact Assessment Template.
This template can be used as the main working file for the assessment. It captures the AI system description, purpose, intended uses, foreseeable misuse, affected groups, data and model information, expected benefits and harms, impact scoring, controls, approvals, monitoring actions, and evidence.
Use this template when the organization needs a practical assessment record for a specific AI system or use case.
AI System Impact Assessment Procedure Template
The AI System Impact Assessment Procedure Template should be used to define how the organization performs impact assessments as a controlled governance process.
This procedure template is different from the assessment workbook. The procedure explains the process: when assessments are required, who is involved, how impacts are identified and assessed, how decisions are approved, and how results are recorded, reported, monitored, and reviewed. The workbook records the results of an individual assessment. Used together, the procedure and workbook provide both the governance method and the operational evidence record.
ISO 42001 AI Policy Template
The ISO 42001 AI Policy Template can be used to establish the governance foundation for AI impact assessments.
This policy should sit above the impact assessment process. It defines the organization’s commitments and expectations for responsible AI use. The assessment procedure then explains how those commitments are implemented, and the assessment workbook records how they are applied to a specific AI system.
ISO 42001 AIMS Scope Document Template
The ISO 42001 AIMS Scope Document Template can be used to define the boundaries of the AI management system before impact assessments are performed.
This template is useful because an impact assessment should not be performed in isolation. The assessment team needs to know which AI systems, business units, technologies, geographies, data flows, suppliers, and stakeholders are within the governance boundary.
Use this template before or during the setup of the assessment program, especially when the organization is implementing ISO/IEC 42001 alongside ISO/IEC 42005.
ISO 42001 RACI Matrix Template
The ISO 42001 RACI Matrix Template can be used to assign ownership for the assessment process.
This template helps avoid one of the most common weaknesses in AI impact assessments: unclear accountability. Each assessment should identify who is responsible, accountable, consulted, and informed for system documentation, data review, model validation, stakeholder consultation, legal review, privacy review, security review, approval, monitoring, and reassessment.
ISO 42001 Risk Assessment Template
The ISO 42001 Risk Assessment Template can be used alongside the impact assessment to manage AI-related risks.
The risk assessment and the impact assessment should be connected but not treated as the same document. The impact assessment focuses on how the AI system may affect individuals, groups, organizations, and society. The risk assessment focuses on uncertainty, risk sources, controls, treatment decisions, and residual risk. Findings from the impact assessment should feed into the AI risk register, and risk treatment actions should be reflected back in the impact assessment’s mitigation plan.
AI System Life Cycle Process Template
The AI System Life Cycle Process Template can be used to connect impact assessment activities to lifecycle gates.
This template is useful because an AI system impact assessment should not be a one-time document created shortly before launch. It should be triggered during design, updated before deployment, reviewed during operation, refreshed after major changes, and considered during retirement.
ISO 42001 Controls List – Implementation Guidance
The ISO 42001 Controls List – Implementation Guidance can be used to identify controls that may address impacts discovered during the assessment.
This template is useful after the assessment team identifies harms, benefits, misuse scenarios, and control gaps. The team can use the controls list to decide which AI governance, lifecycle, transparency, data, monitoring, oversight, or supplier controls should be implemented or improved.
ISO 42001 Statement of Applicability Template
The ISO 42001 SoA Template can be used to document which ISO 42001 controls apply and why.
The Statement of Applicability is useful when the impact assessment identifies controls that should be adopted, strengthened, or excluded with justification. For example, if the assessment identifies a need for stronger human oversight, monitoring, stakeholder communication, or supplier governance, the SoA can help document the relevant control applicability and implementation status.
ISO 42001 Checklist – GAP Analysis
The ISO 42001 Checklist – GAP Analysis can be used to assess whether the broader AI management system is mature enough to support reliable impact assessments.
This template can be used before launching the AI impact assessment program or during improvement cycles. If the gap analysis shows missing policies, unclear roles, weak risk management, poor documentation, or insufficient monitoring, those weaknesses should be addressed because they can undermine the quality of the impact assessment.
ISO 42001 Internal Audit Checklist
The ISO 42001 Internal Audit Checklist can be used after the assessment process is implemented to verify whether the process is working effectively.
This template is useful for reviewing whether impact assessments are actually being performed, whether evidence is complete, whether approvals are documented, whether reassessment triggers are followed, and whether controls are operating as intended.
ISO 42001 Reporting of Concerns Records
The ISO 42001 Reporting of Concerns Records template can be used to document AI-related concerns, complaints, incidents, or escalation signals discovered during operation.
This template supports the monitoring and reassessment part of the impact assessment lifecycle. Complaints, concerns, appeals, and incident reports can reveal impacts that were missed during the original assessment or that emerged after deployment.
Procurement Supplier Risk Assessment Template
The Procurement Supplier Risk Assessment Template can be used when the AI system depends on a third-party model, cloud provider, SaaS tool, data provider, or outsourced service.
This template is especially relevant for AI systems built on external APIs, foundation models, embedded AI features, third-party datasets, or managed AI platforms. The impact assessment should not assume that supplier risks are outside the organization’s responsibility. Supplier evidence should be collected and reviewed as part of the assessment.
7. Common Mistakes to Avoid
Mistake | Why it weakens the assessment |
Assessing only the model | Impacts usually arise when model output drives a human or automated action. |
Treating human review as a magic fix | Human review works only if reviewers have time, authority, training, and useful information. |
Ignoring indirect stakeholders | People can be affected even if they never use the system. |
Averaging subgroup performance | Overall accuracy can hide serious disparate impacts. |
Assessing only intended use | Foreseeable misuse is often where major harm occurs. |
Failing to update after deployment | Model drift, user behavior, and context changes can invalidate the original assessment. |
Using generic controls | Controls must be tied to specific impact scenarios and tested. |
No decision record | Without sign-off and rationale, accountability is unclear. |
No appeal or contestability | Affected people may have no path to correct harmful outcomes. |
No supplier evidence | Third-party AI still creates accountability for the deploying organization. |
8. Final Deliverables Checklist
|
Deliverable |
Deliverable |
|
[ ] Assessment charter |
[ ] AI system profile |
|
[ ] Intended-use and prohibited-use statement |
[ ] Stakeholder and affected-group register |
|
[ ] Impact category checklist |
[ ] Impact scenario register |
|
[ ] Initial impact ratings |
[ ] Control and mitigation plan |
|
[ ] Residual impact ratings |
[ ] Deployment decision record |
|
[ ] Transparency and communication plan |
[ ] Monitoring and reassessment plan |
|
[ ] Incident and escalation process |
[ ] Decommissioning considerations |
|
[ ] Final assessment report |
Related Templates & Documents
AI System Impact Assessment Template
✓ Editable Excel Template for AI System Impact Assessments
✓ Includes ISO/IEC 42005 Guidance
AI System Impact Assessment Procedure Template
✓ Editable AI System Impact Assessment Procedure Template
✓ ISO/IEC 42001 Clause 6.1.4 & 8.4