ISO/IEC 42005: AI Impact Assessments Explained

An organization can maintain an AI inventory, approve a policy, and establish a governance committee and still be unable to answer a more consequential question: who could be affected by a specific AI system, in what way, and what evidence shows that those impacts were considered before deployment?

That is the problem ISO/IEC 42005:2025 is designed to address. Published in May 2025, the standard provides guidance for assessing how AI systems and their foreseeable applications may affect individuals, groups, and society across the AI system lifecycle. Its value for auditors is not that it creates another checklist. It creates a traceable process for defining scope, assigning responsibility, examining impacts, documenting decisions, approving outcomes, and revisiting the assessment when the system or its operating context changes.

The practical thesis is straightforward: a strong AI impact assessment is not merely a compliance document. It is structured governance evidence and a direct input into decisions about audit scope and depth.

Impact assessment asks a different question from traditional risk assessment

Risk assessment often starts with the organization: what could prevent objectives from being achieved, how significant is the exposure, and what treatment is appropriate? AI impact assessment changes the vantage point. It also asks what the system could do to the people who use it, the people subject to its outputs, and other parties who may be affected.

ISO/IEC 42005:2025 focuses on those consequences and on foreseeable applications. Its structure covers the impact assessment process, timing, scope, responsibilities, thresholds, performance, analysis, recording, approval, monitoring, and review. It then addresses the information needed to document the AI system, its uses, data, models, deployment environment, relevant interested parties, and actual or reasonably foreseeable impacts.

That distinction matters because a system can look acceptable from an operational perspective while still creating material human or societal effects. A prioritization model might reduce response times while producing uneven outcomes for certain groups. A generative AI assistant might increase productivity while creating confidentiality, decision-quality, or contestability risks.

Impact assessment and risk management therefore are not competing processes. They should inform one another.

ISO/IEC 42005 and ISO/IEC 42001: guidance versus requirements

The relationship between the two standards is central. ISO/IEC 42001:2023 is an AI management system standard that specifies requirements for establishing, implementing, maintaining, and continually improving an AI management system. Clause 6.1.4 requires an organization to define a process for assessing potential consequences for individuals, groups, and societies arising from the development, provision, or use of AI systems. The assessment considers deployment, intended use, foreseeable misuse, technical and societal context, and applicable jurisdictions. Its results are documented and fed into AI risk assessment.

Clause 8.4 brings that process into operations: impact assessments are performed at planned intervals or when significant changes are proposed, with documented results retained.

ISO/IEC 42005 provides the how. It is guidance rather than a stand-alone certifiable management system equivalent to ISO/IEC 42001. Its informative annexes, including taxonomies and example templates, help organizations design and document the assessment process, but they should not be misrepresented as mandatory certification requirements.

For auditors, this distinction is critical. Audit criteria should clearly separate requirements arising from ISO/IEC 42001, legal or internal obligations, and practices adopted from ISO/IEC 42005 as guidance.

The evidence should tell the story of a decision

A mature assessment should allow a reviewer to reconstruct why the organization considered it acceptable to develop, acquire, modify, or deploy an AI system. The useful evidence is not a single completed form. It is a coherent trail from context to analysis to decision.

Evidence area	What the auditor should be able to reconstruct	Warning sign
Process governance	Owner, scope, version, approvals, and reassessment triggers	No accountable owner or approval trail
System and use	Purpose, functions, dependencies, intended and unintended use, deployment environment	Technology is described, but actual use is unclear
Data and model	Relevant information on data, quality, model or algorithm, and known limitations	Conclusions are disconnected from data or assumptions
Interested parties and impacts	Directly affected parties, other relevant parties, benefits, harms, failures, and foreseeable misuse	Only organizational impact is considered
Response and monitoring	Measures, decisions, risk-management links, and conditions for review	Assessment ends with a risk list and no action

The InterNational Committee for Information Technology Standards (INCITS) notes that Annex E of ISO/IEC 42005 provides example templates covering items such as system identifiers, revision history and approvals, purpose, intended and unintended uses, data and quality information, algorithm or model information, deployment environment, interested parties, potential benefits and harms, system failures, and possible misuse.

For internal audit, this documentation is evidence of management's governance process. It is not automatic evidence that management's conclusions are correct. Auditors still need to assess relevance, sufficiency, and reliability, challenge assumptions, corroborate key claims, and test whether stated controls and mitigation measures exist and operate as described.

An interested party is not the same as a user

One of the most useful disciplines created by impact assessment is that it broadens the field of view. The person operating an AI system may not be the person bearing its consequences.

Consider an AI tool used by employees to prioritize customer requests. Employees are direct users, but customers may be affected by the ranking; particular groups may experience disproportionate outcomes; technology providers may influence system behavior; and functions such as legal, privacy, compliance, risk, or security may have oversight responsibilities.

ISO/IEC 42005 includes dedicated consideration of relevant interested parties, distinguishing directly affected parties from other relevant parties. That does not turn every assessment into a public consultation, nor does it mean every stakeholder must participate in the same way. It means the organization needs a defensible rationale for determining who matters for this system and which expectations or impacts need to be considered.

For auditors, a stakeholder list is only a starting point. More useful questions are whether reasonably foreseeable affected groups were omitted, whether vulnerability or power imbalance was considered, whether assumptions reflect the actual deployment context, and whether post-deployment information can trigger reassessment.

Impact assessment should change audit scope

This is where ISO/IEC 42005 stops being only an AI governance topic and becomes an audit planning tool.

Under Standard 13.2 of the Global Internal Audit Standards, internal auditors must understand the activity under review, gather reliable, relevant, and sufficient information, consider applicable frameworks and criteria, and prioritize the risks to be reviewed. Standard 13.3 requires internal auditors to establish and document engagement objectives and scope.

A well-developed AI impact assessment can strengthen both steps. For example:

severe potential effects on individuals can justify scope over human oversight, review or appeal mechanisms, data quality, and outcome testing;
multiple suppliers or technical dependencies can justify procedures over third-party governance, model changes, contractual rights, and evidence access;
impacts that vary by country, language, or population can justify segmented samples or testing across deployment contexts;
reasonably foreseeable misuse can bring access controls, abuse monitoring, logging, and incident management into scope;
rapidly changing systems can shift audit attention toward reassessment triggers, monitoring, and change management.

Impact assessments can also help define the boundary between generalist and specialist assurance. Internal audit can assess governance, ownership, traceability, process quality, and evidence without independently performing advanced statistical validation, penetration testing, or specialist model assurance. When the impact profile indicates that deeper testing is necessary, the appropriate audit response may be to bring in specialist support.

Audit the decision process, not the template

Every methodology carries the same risk: documentary completeness can be mistaken for quality. An impact assessment may be fully populated and still be weak if it relies on outdated assumptions, overlooks affected groups, minimizes plausible harms, or is never revisited after significant change.

The better internal audit question is not simply, “Does an impact assessment exist?” It is: can the organization demonstrate that it consistently identifies relevant impacts, incorporates them into risk and control decisions, and reopens the assessment when the AI system or its context changes?

That is the most useful connection between ISO/IEC 42005 and internal auditing. The standard turns diffuse impacts into structured information. Internal audit turns that information into assurance priorities, evidence requests, and decisions about testing depth.

When both processes work together, AI impact assessment moves from being a governance appendix to becoming an early signal of where the organization needs stronger control, closer oversight, or deeper assurance.