ISO/IEC 42005 Explained: AI Impact Assessment vs DPIA

ISO/IEC 42005:2025, "Information technology — Artificial intelligence (AI) — AI system impact assessment," gives organizations a structured, repeatable process for assessing how an AI system affects the people and groups it touches. It is guidance, not a certifiable standard by itself, and it applies to any organization developing, providing, or using AI systems — not just AI vendors. This post covers what it actually requires and how it differs from the two impact-assessment obligations engineers are more likely to have already heard of: the GDPR Data Protection Impact Assessment and the EU AI Act's Fundamental Rights Impact Assessment.

This is not legal advice. Whether any of these three assessment obligations applies to your organization, and how to satisfy it, depends on your jurisdiction, your role as provider or deployer, and counsel's reading of your specific system.

What ISO 42005 actually is

ISO/IEC 42005 sits inside the broader ISO/IEC 42001 family of AI standards, but it is narrower and more specific than the management-system standard itself. Where ISO 42001 defines the overall management system an organization runs for AI (policies, roles, risk processes, continuous improvement), ISO 42005 defines the methodology for one specific activity inside that system: assessing the impact a given AI system has on individuals, groups, and society.

Two things distinguish it from a certification standard. First, it is guidance — there is no ISO 42005 certificate an organization can obtain the way it can pursue ISO 42001 certification. Second, its scope is deliberately broad: it applies to any organization in any role relative to an AI system — developing it, providing it, or simply using it — rather than being written narrowly for providers the way some regulatory impact-assessment obligations are.

What the standard actually requires

ISO 42005 treats impact assessment as a process that runs across the AI system's lifecycle rather than a single pre-launch checkbox. It expects organizations to conduct and revisit assessments at three points:

• Planning. Before significant investment in a system, assess likely impacts based on the intended purpose and deployment context.
• Pre-deployment. Before the system goes live, reassess based on what has actually been built, not just what was originally planned — designs change during development.
• In-use. After deployment, revisit the assessment as usage patterns, scale, or context shift. A system used as originally scoped can still develop new impacts as its user base or integration surface grows.

This ongoing framing is the standard's most practical departure from how many organizations currently handle impact assessment — as a document produced once, filed, and rarely revisited. For AI agents specifically, where capabilities and integrations tend to expand after initial deployment, the in-use reassessment expectation is the one most likely to catch drift that a one-time assessment would miss.

ISO 42005 vs DPIA vs FRIA

Engineers doing compliance work for the first time often conflate these three because they share a structural shape — describe the system, describe who it affects, describe the risk, describe mitigations — but they differ sharply in who must do them and when.

The practical implication: none of the three substitutes for the others. A DPIA satisfies GDPR's privacy-specific obligation but does not cover non-privacy impacts ISO 42005 asks you to consider — fairness, safety, or broader societal effects, for example. An EU AI Act FRIA is a legal obligation for a specific, narrower set of deployers and a specific set of high-risk use cases — see the EU AI Act explained for engineering teams for the provider/deployer distinction that determines who owes which obligation — and it can be complemented by a DPIA where personal data is also involved, but neither is a general-purpose AI impact methodology the way ISO 42005 is designed to be. An organization outside the FRIA's scope, or outside the EU entirely, can still adopt ISO 42005's methodology voluntarily as a general due-diligence practice.

How it integrates with ISO 42001

ISO 42005 is explicitly designed to plug into an ISO/IEC 42001 AI management system rather than operate as a standalone process. If your organization already maintains or is building toward an ISO 42001 AIMS, ISO 42005 gives you a concrete methodology for the impact-assessment obligations that standard already expects in general terms. See ISO/IEC 42001 for AI management systems for how the broader management-system requirements — risk assessment, Annex A controls, evidence and audit readiness — fit around this specific assessment activity.

For agent-based systems specifically, this pairing matters because agents tend to accumulate capability and integration surface after initial deployment. An impact assessment methodology that expects reassessment at the in-use stage, wired into a management system that already tracks agent risk classification over the agent's lifetime, closes a gap that a one-time pre-launch review leaves open.

What else lives in the ISO 42000 family

ISO/IEC 42005 is not the only new standard in this family. A separate standard, ISO/IEC 42006, also exists alongside it — but its precise scope is not something this post asserts beyond that it is a distinct standard in the same family, addressing a different part of the AI-management-system ecosystem than the impact-assessment methodology covered here. If you are evaluating which ISO 4200x standard applies to a specific compliance question, confirm the current scope directly against the ISO catalogue rather than a secondary summary, since standard scopes in this family are still being clarified as adoption grows.

A practical starting point for agent teams

Even organizations with no regulatory obligation to conduct any of the three assessments above get a useful structure from ISO 42005's approach. A minimal version, adapted for AI agents:

1. At planning: document the agent's intended purpose, the population it will interact with or affect, and the categories of decision or action it will be permitted to take.
2. At pre-deployment: reassess against what was actually built — permission scope, data access, and tool integrations frequently expand during development.
3. At in-use, on a defined cadence: reassess when the agent's capabilities, integrations, or user base change materially, not only on a fixed annual schedule.
4. Link the assessment to the agent's actual configuration, so a reviewer can trace a specific permission or data-access grant back to the risk reasoning that justified it — a link that is easy to lose once an agent has been in production for a while. This is the same discipline behind building an AI agent inventory and the risk-classification tracking described in an AI governance maturity model.

A structured AI agent compliance checklist for 2026 is a useful companion for turning this into an inventory-wide practice rather than a one-off exercise for a single agent, and the AI governance pillar guide covers where impact assessment fits inside a broader governance program.

Praesidia is an AI agent security and governance control plane — agent identity and access, guardrails, audit evidence, and cost controls in one place — and the per-agent risk classification and history it can maintain gives an ISO 42005-style assessment somewhere to live rather than a document that goes stale after the agent's first release. For the vendor-facing controls side of this same governance picture, see the CSA AI Controls Matrix explained.

Common questions

Is ISO 42005 mandatory? No. It is voluntary international guidance. Nothing in ISO 42005 itself creates a legal obligation; organizations adopt it because it gives a structured methodology for impact assessment, and because it integrates cleanly with ISO 42001 if they are pursuing that management-system standard.

Can an ISO 42005 assessment replace a GDPR DPIA? No. They cover different scopes — ISO 42005 addresses broader AI system impacts, while a DPIA is specifically about privacy and personal-data risk under GDPR Article 35. Where your processing meets GDPR's DPIA trigger, you still need a DPIA; ISO 42005's assessment can run alongside it but does not substitute for it. See GDPR erasure and EU AI Act readiness for the GDPR-specific obligations agent-handling organizations face.

Does ISO 42005 apply if we are only a deployer, not a developer, of an AI system? Yes. The standard is explicitly scoped to any organization developing, providing, or using an AI system — deployment-only use is squarely in scope, which is different from some regulatory obligations that are narrower about who must comply.

How is ISO 42005 different from ISO 42006? Both are separate standards in the ISO/IEC 42000 AI-management family, addressing different parts of that ecosystem. This post covers ISO 42005's impact-assessment scope specifically; if you need ISO 42006's exact scope for a compliance decision, confirm it directly against the current ISO catalogue entry rather than a secondary summary.

Do we need to redo the assessment every time the agent changes? Not every change warrants a full reassessment, but ISO 42005's in-use expectation means you need a trigger for when one is warranted — materially expanded permissions, new data access, a new user population, or a new integration are reasonable triggers. Treating the assessment as permanently valid after initial deployment is the failure mode the standard is specifically designed to prevent.