Most AI risk work asks what could go wrong for the organisation; an AI system impact assessment asks what the system could do to the people and communities it touches, and few teams have a repeatable way to answer that. ISO/IEC 42005:2025 is the international standard that gives guidance on how to conduct AI system impact assessments. It sits beside ISO/IEC 42001 (AI management systems) and ISO/IEC 23894 (AI risk management), and it is increasingly the method organisations reach for when regulators, customers or treaties ask for an impact assessment. This guide summarises what the standard is for, based on ISO's public description, how it relates to legal assessment duties, and how to build an assessment practice that also covers AI agents. It does not reproduce or paraphrase clause text: buy the standard for that. It is for AI governance leads, privacy and security practitioners, and executives who sign off AI deployments.
Key takeaways
- Guidance, not requirements. ISO/IEC 42005:2025 gives guidance for conducting AI system impact assessments; it is not a certifiable management system standard in its own right.
- People and society are the focus. ISO says the standard focuses on how AI systems and their foreseeable applications may affect individuals, groups of individuals and society, which sets it apart from organisational risk management.
- Lifecycle, not launch. Impacts are to be identified, evaluated and documented across the AI system lifecycle, so the assessment is a living record with triggers for review.
- It connects to laws without being one. A 42005-style assessment can feed the EU AI Act fundamental rights impact assessment, a GDPR DPIA and Council of Europe Convention risk and impact duties, but each legal duty has its own required content.
- Agents widen the impact surface. An agent with tool access and credentials can affect people through actions, not just outputs, so its permissions belong in the scope of the assessment.
Scope: who and what is covered
| Attribute | Detail (from the ISO catalogue page) |
|---|---|
| Reference | ISO/IEC 42005:2025, edition 1 |
| Title | Information technology, Artificial intelligence (AI), AI system impact assessment |
| Published | May 2025 (stage 60.60, International Standard published) |
| Length | 39 pages |
| Committee | ISO/IEC JTC 1/SC 42 Artificial intelligence |
| Purpose | Guidance for organisations conducting AI system impact assessments, supporting transparency, accountability and trust |
| Related standards named by ISO | ISO/IEC 42001 (complements), ISO/IEC 23894 (complements), ISO/IEC 38507 (governance of AI) |
- Who it is for: any organisation that develops, provides or uses AI systems. It is not limited by sector or size.
- What is assessed: the AI system and its foreseeable applications, including uses beyond the intended one that an organisation could reasonably anticipate.
- Who is considered: individuals, groups of individuals and society. That includes people who never use the system but are affected by its outputs, such as applicants scored by a model or residents affected by an automated public service.
- What it is not: it is not an organisational risk register (that is ISO/IEC 23894 territory), and it is not a management system (that is ISO/IEC 42001). See the ISO/IEC 42001 Guide and the ISO/IEC 23894 AI Risk Management Guide.
Impact assessment vs risk assessment
| Question | AI system impact assessment (42005) | AI risk management (23894) | DPIA (GDPR Art. 35) |
|---|---|---|---|
| Whose harm? | Individuals, groups, society | The organisation's objectives | Data subjects' rights and freedoms |
| Benefits considered? | Yes, positive and negative impacts | Opportunities as well as threats | Necessity and proportionality of processing |
| Trigger | Organisation's policy, contract or law | Risk management process | Processing likely to result in high risk |
| Legal force | Voluntary unless referenced by law or contract | Voluntary | Mandatory where triggered |
| Output | Documented impacts, mitigations, decisions | Risk treatment plan | DPIA record, prior consultation if high residual risk |
For the organisational risk view see the AI Risk Assessment Guide; for privacy see the DPIA Guide.
Key obligations
As a guidance standard, ISO/IEC 42005 creates no obligations by itself. Obligations arise when an organisation adopts it, when a contract requires it, or when it is used to meet a legal duty. Based on ISO's description, an assessment practice built on it should deliver four things.
- Identify impacts: describe the system, its intended purpose and foreseeable applications, and the people and groups it may affect, directly or indirectly.
- Evaluate impacts: judge the significance of actual and potential effects, positive and negative, on those people and on society.
- Document: keep a record that supports transparency and accountability, so decisions about the system can be explained to overseers and affected people.
- Repeat across the lifecycle: revisit the assessment as the system, its data, its users and its context change.
Secondary summaries of the standard, such as a CMS legal update of September 2025, describe it as also covering triage of which systems need a full assessment, reassessment triggers, stakeholder consultation, an impact taxonomy, an example template and informative mappings to ISO/IEC 42001 and ISO/IEC 23894. Those descriptions are the law firm's, not ISO's; check them against your own copy before building on them.
Impact areas worth covering
| Impact area | Example question | Typical evidence |
|---|---|---|
| Fairness and non-discrimination | Do outcomes differ for protected groups? | Disaggregated performance metrics, bias testing results |
| Privacy | What personal data is inferred, retained or exposed? | DPIA, data flow map, retention settings |
| Safety | Can an output or action cause physical or financial harm? | Failure mode analysis, red team findings |
| Transparency and explainability | Can an affected person understand and contest a decision? | Explanation method, notice text, appeal route |
| Autonomy and human oversight | Who can override the system, and how quickly? | Approval gates, override logs |
| Societal and environmental | Does wide deployment shift behaviour, access or resource use? | Usage scale, energy figures, public consultation notes |
| Security and misuse | Can the system or its credentials be abused to harm people? | Threat model, privilege review, abuse monitoring |
For fairness and explanation methods, see the Explainable and Fair AI Guide.
Timeline and current status
- December 2023: ISO/IEC 42001:2023 published, the AI management system standard that 42005 complements.
- 28 May 2025: ISO/IEC 42005:2025 published as edition 1 (status checked on iso.org, 24 October 2026: published, stage 60.60).
- Review cycle: ISO standards are reviewed periodically; watch the catalogue page for a confirmation, amendment or revision.
- Legal context moving around it: the EU AI Act fundamental rights impact assessment (Article 27) applies, according to the AI Act Explorer's current text, from 2 December 2027 for Annex III high-risk systems and 2 August 2028 for Annex I. The Council of Europe Framework Convention requires Parties to put risk and impact management in place once it is in force. See the Council of Europe AI Convention Guide.
Enforcement and penalties
There are no penalties for not following ISO/IEC 42005. Pressure to use it comes from elsewhere.
| Lever | How 42005 is used | Consequence of a weak assessment |
|---|---|---|
| ISO/IEC 42001 certification | As the method behind the AI management system's impact assessment work | Audit nonconformity |
| EU AI Act Article 27 | As the method for a deployer's FRIA, which must cover processes, period and frequency of use, affected groups, specific risks of harm, human oversight and measures if risks materialise | Regulatory enforcement under the AI Act; notification of results to the market surveillance authority is required |
| GDPR Article 35 | Shared evidence with the DPIA; the AI Act allows a FRIA to build on an existing DPIA | Supervisory authority action |
| Council of Europe Convention | As a method consistent with Article 16 duties, alongside HUDERIA | Depends on each Party's national law |
| Contracts and procurement | Customers ask for assessments as a condition of purchase | Lost deals, contractual breach |
See the EU AI Act Compliance Guide and the EU AI Act High-Risk AI Systems Guide.
What it means for AI agents and non-human identities
An impact assessment written for a model that only produces text misses most of what an agent can do. Agents call tools, move data and change records using API keys, OAuth grants and service accounts. The effect on a person can come from an action (a refund refused, a record deleted, an email sent) rather than from a prediction. Bring the agent's identity and permissions into the assessment scope.
- Describe reach, not just purpose: list every tool, API and data store the agent's credentials allow, and assess impacts against that reach, because a foreseeable application includes what the agent can do even if it was not asked to.
- Tie impact to privilege: high-impact actions should need narrower scopes, short-lived tokens and a human approval step. See the AI Agent Authorisation Guide.
- Make it traceable: each agent needs its own identity and an accountable human owner so a decision affecting a person can be traced to a system, a version and a credential.
- Trigger reassessment on new permissions: granting an agent a new tool or scope is a significant change and should reopen the assessment.
- Plan for misuse: stolen agent credentials can harm people at scale; include credential compromise in the impact analysis. The Spain AEPD AI agent data breach shows that regulators already treat agent incidents involving personal data as notifiable breaches.
See the Identity Governance for AI Agents Guide.
Compliance steps
- Get the standard and set policy. Buy ISO/IEC 42005 and write a short internal policy stating when an AI system impact assessment is required, who owns it and who approves it.
- Inventory and triage. Record every AI system and agent, then triage with a short screening form: does it inform decisions about people, act autonomously, process sensitive data or operate at scale? Only systems that screen in need a full assessment. See the AI Register and AI Inventory Template.
- Pilot on two or three systems. Choose a mix, for example one decision-support model and one agent with tool access. Use the AI Impact Assessment Template, involve the business owner, a privacy lead, a security lead and someone who represents affected users.
- Review and calibrate. Compare pilot results: were the impact ratings consistent, was the effort proportionate, did mitigations get funded? Adjust the template before scaling.
- Link to legal assessments. Map assessment fields to FRIA elements and DPIA content so one evidence base serves all three, and record which legal duty each assessment satisfies.
- Integrate with change control. Make assessment status a release gate for new AI systems and for significant changes: new model version, new data source, new user group, new agent permissions.
- Roll back when needed. If an assessment finds an unacceptable impact on people after deployment, the rollback is to suspend the use, revoke or narrow the system's credentials, and revert to the previous version or manual process until mitigations are verified.
- Monitor and reassess. Feed incident reports, complaints and fairness monitoring back into the assessment on a fixed review cycle.
Decision guidance
- Use 42005 alone when you need a credible, documented method and have no ISO management system: smaller organisations or single AI products.
- Use 42005 with 42001 when you are building or certifying an AI management system and need its impact assessment work to be consistent and auditable.
- Use HUDERIA alongside when you supply public authorities in Council of Europe states and expect human rights and democracy questions.
- Small vs large: small teams can run one combined DPIA and impact assessment per system; large organisations need a central register, a review board and standard impact scales so ratings are comparable across business units.
Detection and measurement
- Coverage: percentage of in-scope AI systems and agents with a current impact assessment.
- Freshness: percentage of assessments reviewed since the last significant change.
- Mitigation closure: median days from identified impact to implemented mitigation.
- Privilege alignment: number of agents whose granted scopes exceed those assessed.
- Outcome signals: complaints, appeals and overturned decisions per AI system, and fairness metric drift.
Log agent actions and approvals (NIST SP 800-53 AU-2) and monitor drift continuously (CA-7) so reassessment triggers fire on evidence rather than on the calendar alone.
Framework mapping
| Assessment activity | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | Other |
|---|---|---|---|
| Context, purpose, affected groups | GV.OC Organizational Context | RA-3 Risk Assessment | EU AI Act Art. 27(1)(a) to (c) |
| Impact evaluation | ID.RA Risk Assessment | RA-3, RA-8 Privacy Impact Assessments | GDPR Art. 35, HUDERIA RIA |
| Governance and approval | GV.RM Risk Management Strategy, GV.OV Oversight | RA-3 | ISO/IEC 42001 |
| Sensitive data | ID.RA | PT-7 Specific Categories of PII | GDPR Art. 9 |
| Agent privileges | GV.RM | AC-6 Least Privilege | NHI governance |
| Ongoing monitoring | GV.OV | CA-7 Continuous Monitoring, AU-2 Event Logging | Reassessment triggers |
Common failure patterns
- Relabelled risk register: listing harms to the organisation (fines, reputation) instead of effects on people.
- Assessing the model, not the deployment: the same model has different impacts in a chatbot and in a benefits eligibility workflow.
- Ignoring agent permissions: scope stops at outputs while the agent's credentials allow write access to customer records.
- No affected-person voice: assessments written only by engineers miss impacts that users or advocacy groups would raise.
- Shelfware: assessments completed for approval and never reopened after model, data or permission changes.
- Quoting the standard without owning it: building templates from summaries instead of the purchased text, which leads to claims of conformity that do not hold up in audit.
Practitioner checklist
- Purchase ISO/IEC 42005:2025 and assign an owner for the assessment method.
- Write a policy defining when an AI system impact assessment is required.
- Screen every AI system and agent in the inventory with a triage form.
- Include agent tools, scopes and credentials in assessment scope.
- Consult people who represent affected groups for high-impact systems.
- Map assessment fields to EU AI Act FRIA and GDPR DPIA content.
- Make assessment status a release gate and set reassessment triggers.
- Define a rollback: suspend, revoke credentials, revert.
- Report coverage, freshness and mitigation metrics to the AI governance board.
Standards and references
- ISO: ISO/IEC 42005:2025 Information technology, Artificial intelligence, AI system impact assessment
- ISO: ISO/IEC 42001:2023 Information technology, Artificial intelligence, Management system
- Council of Europe: HUDERIA Risk and Impact Assessment of AI Systems
- Council of Europe: The Framework Convention on Artificial Intelligence
- AI Act Explorer: Article 27, Fundamental Rights Impact Assessment for High-Risk AI Systems
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
- CMS: ISO/IEC 42005:2025, A New Blueprint for Legal and Commercial Leaders
Related NHI Mgmt Group resources: AI Risk Assessment Guide · DPIA Guide · EU AI Act Compliance Guide · Explainable and Fair AI Guide · AI Impact Assessment Template. This guide summarises ISO/IEC 42005:2025 and related legal duties and is not legal advice.