AI Impact Assessment Made Simple: A Practical Guide to ISO/IEC 42005

What is an AI impact assessment?

An AI system impact assessment is a formal, documented process. It asks one question: how could this AI system affect people?

That means individuals, groups of individuals, and whole societies. The question applies whether your organization builds AI, sells it, or simply uses it in its daily work.

AI brings real benefits, but it also brings real risks. An impact assessment helps you use AI in a way that is:

• Responsible, because you think about consequences before they happen
• Transparent, because your reasoning is written down and can be shared
• Compliant, because new AI laws increasingly expect this kind of analysis

It also goes further than technical testing. A model can be accurate and robust and still cause harm. A good impact assessment looks at business, environmental, financial, human rights, privacy, security, and health and safety impacts. It then feeds those findings into your wider risk management and governance.

The international standard for doing this well is ISO/IEC 42005. It was developed by SC 42, the joint ISO and IEC committee that writes AI standards. This guide walks through the whole standard in plain language, based on a six-part expert webinar series on mastering AI impact assessment.

One technology, very different impacts

Facial recognition is a good way to see why impact assessment matters. The underlying technology is the same in each case below, but the impact on people changes completely depending on how it is used.

The lesson is simple. You cannot judge an AI system by its technology alone. You have to look at each use case, who it touches, and what could go wrong. That is exactly what an impact assessment does.

Meet ISO/IEC 42005

ISO/IEC 42005 is a guidance standard, not a certification standard. It does not say "you must." It explains how to understand and document the ways an AI system may affect individuals, groups, societies, and in some cases the environment.

It is most useful alongside ISO/IEC 42001, the AI management system standard. ISO/IEC 42001 sets requirements you can be certified against, and one of those requirements is to carry out AI system impact assessments. ISO/IEC 42005 shows you how to do that well.

How the standard is organized

• Clause 5: how to build and run your impact assessment process
• Clause 6: what to document in each assessment, often called the heart of the standard
• Annex A: how it maps to ISO/IEC 42001
• Annex B: how it relates to ISO/IEC 23894 (AI risk management)
• Annex C: a taxonomy of harms and benefits
• Annex D: how to align it with other impact assessments
• Annex E: an example template

All the annexes are informative. They offer help and examples, not mandatory rules.

Five terms worth knowing

A shared vocabulary makes everything else easier. These are the terms you will meet most often:

For a fuller glossary of AI terms, the series recommends ISO/IEC 22989:2022, the standard on AI concepts and terminology.

Impact assessment vs. risk assessment

People often confuse these two. They are related, but they answer different questions at different levels. ISO/IEC 42001 requires both.

The two connect in one direction. The impact assessment feeds the risk assessment. Harms you find for people at the system level become inputs to the organization's overall risk picture. This keeps high-level risk strategy grounded in what AI systems actually do to real people.

If you come from ISO/IEC 27001 (information security), the impact assessment may feel new. Most management system standards do not include one. Environmental management is the main exception.

Clause 5: Building your impact assessment process

Clause 5 is about the process itself, not any single assessment. It has 12 sub-clauses that follow the familiar Plan-Do-Check-Act cycle used across ISO management systems. Every organization's version will look different, because it depends on your own context.

1. Create the process (5.1). Design a process that fits your organization. Consider internal factors such as your structure and contracts with customers. Also consider external factors, such as the stakeholders and scope you have already mapped.
2. Document it (5.2). Write the process down so it runs the same way every time. Make information about it available to internal and external stakeholders. Use it for management reviews and for training, so people know when an assessment is needed.
3. Integrate it (5.3). Do not let it sit in a silo. Connect it to your existing business processes so it becomes part of how the organization normally works.
4. Decide when to run it (5.4). Use two kinds of triggers:
• Time-based: regular cycles, such as an annual review
• Event-based: a change to the system, its data, or how it is used
5. Define the scope (5.5). Be clear about what you are evaluating and where the boundaries are. Remember that a change to one component can ripple through the whole system.
6. Assign responsibilities (5.6). As the saying goes, if two people are accountable, no one is. Name who gathers documentation, who coordinates between departments, who shares results, and who approves. Choose people with the right experience for sign-off.
7. Set thresholds (5.7). Define limits for sensitive uses, restricted uses, and impact scales. These tell you when action is needed. Consider legal and contractual obligations, and cultural, labor, and societal norms. Annex C's harms and benefits taxonomy is a useful structure here.
8. Perform the assessment (5.8). Now the real work happens. Identify reasonably foreseeable impacts of the AI system. Then connect them to organizational risk, alongside other assessments such as human rights or data protection reviews.
9. Analyze the results (5.9). Look at them from two angles:
• Technical: what controls will protect people from the harms you found?
• Management: do these results point to a bigger pattern? Look across assessments over time so you prevent problems instead of fighting small fires.
10. Record and report (5.10). Share results with the right internal and external parties. External reports should be written for non-technical readers. Be as transparent as possible without revealing sensitive company information.
11. Get approvals (5.11). Build in sign-off points. Examples include when a metric goes out of range, or when significant harm is possible. Also formally close each assessment, so none of them runs forever without concluding.
12. Monitor and review (5.12). Keep improving. Decide who reviews the process and how often. Business goals change over time, so check that your scope, objectives, and thresholds still fit.

Clause 6: What to document in each assessment

If Clause 5 is the process, Clause 6 is the content. Its nine sub-clauses tell you exactly what each assessment should capture. The goal is not only compliance. It is to make AI systems transparent, traceable, and explainable, which builds accountability and trust.

6.1 Your organization's role and context

Document the assessment in a way that reflects who you are. Look at two kinds of factors:

• Internal factors (within your control): governance structure, policies, objectives, contracts, and risk appetite, meaning how much uncertainty you are willing to accept
• External factors (outside your direct control): laws and regulations, local values and ethics, and the competitive landscape

Also state your role. Are you an AI producer, provider, or customer? ISO/IEC 22989 defines these roles. Other frameworks, such as the EU AI Act, use similar but slightly broader definitions.

6.2 Scope of the assessment

Be clear about which AI system or systems you are assessing, and who they could affect. List the intended uses, use-case types, foreseeable misuses, and any exceptions. If you already run other impact assessments, such as for HR, environment, or business continuity, note any links between them.

6.3 AI system information

This part describes the system itself, in five layers:

• Description: a high-level summary of what the system does and how it works, like an executive summary
• Functionalities and capabilities: functionalities are the visible tasks it performs, such as forecasting yield or detecting fraud. Capabilities are the technical abilities behind them, such as learning from data or understanding language. Note any reliance on other systems or outside models.
• Purpose: why the system exists, who it serves, and what value it offers. Record trade-offs too. Why use AI rather than a simpler solution?
• Intended uses: what it is for, for whom, in what settings, and under what limits
• Reasonably foreseeable misuse and unintended uses: how it could be used wrongly, plus any unplanned uses that might turn out to be beneficial

Example: crop yield forecasting. A farm-planning tool uses gradient boosting on crop history and weather data to forecast yield per field. The team chose a complex model to improve accuracy. That made it harder for farmers to understand how it reached its answers. Recording this accuracy-versus-explainability trade-off helps the team revisit the decision later.

Example: a bank's facial recognition. The bank uses face ID to log into its app and to personalize branch visits. Documented limits include: it only works in branches with the right cameras, only during business hours, and may fail with face coverings or in poor lighting. Writing these limits down sets realistic expectations and prevents misapplication.

6.4 Data information and quality

Data drives AI behavior. Incomplete, inaccurate, or unrepresentative data produces wrong outputs, and those errors affect real people. If training data reflects historical discrimination, the model can learn and repeat that bias. This is especially risky when AI decides who gets access to services, opportunities, or rights.

The standard lists 11 data considerations. Key questions include:

• Can humans actually read and understand the data documentation?
• Was the data collected legally, ethically, and in line with policy?
• Is there enough data for the purpose?
• Where did the data come from, and who created it?
• Are there known or foreseeable risks of unwanted bias?

For data quality, document five things:

1. Which quality traits matter for your system, such as completeness, timeliness, accuracy, or consistency
2. Which quality requirements have been met
3. Plans to close any gaps
4. How quality is monitored across the whole life cycle
5. Whether the right internal or external parties approved the data's use

Data quality is an ongoing process, not a one-time check. ISO/IEC 5259 parts 1 and 2 give more detailed guidance, and further parts are in development.

6.5 Algorithms and models

Document as much as you can about the algorithms and models, even if you did not build them. Developers, deployers, and users all carry this duty.

• Algorithms used: where they came from, any changes made, evidence they are valid, past real-world use, data needs, and weaknesses such as overfitting or bias
• Algorithm development: how they meet legal, technical, and organizational requirements, and how they were approved
• Models used: how they were trained, tested, and validated, along with robustness, bias risks, any generation of personal data, and how retraining and data drift are handled
• Model development: how development was tracked over time, so the assessment rests on records rather than assumptions

6.6 Deployment environment

Impact depends on where and how the system runs.

• Geography and language: Which countries and laws apply, now and in future? Which cultural values matter? Are vulnerable groups present? Are local languages supported? A model trained on one region's data can fail badly in another, so test with local data before deploying.
• Technical setup: Is it a cloud service, a standalone app, or embedded in a device? What infrastructure and open-source components does it depend on? Are there security concerns? Are users familiar with this kind of technology? A self-driving car may help older people who can no longer drive, but only if they know how to use it safely.

6.7 Relevant interested parties

An impact assessment is about people, not just systems. Identify two groups:

• Directly affected parties: users, vulnerable individuals, workers affected by automation, and people whose data is processed, even if they never touch the system
• Other relevant parties: AI developers, regulators, and professional associations

Consult affected people or groups that represent them, in proportion to the system's risk. You do not need to survey a whole population. Make consultation safe: protect confidentiality, prevent retaliation (especially for employees), and give people a way to challenge decisions. Document what you heard.

6.8 Benefits and harms

This is the core of the assessment. For each relevant party, identify the reasonably foreseeable benefits and harms, both positive and negative. The standard lists objectives to check, including accountability, transparency, fairness, reliability, safety, explainability, and privacy. You can add your own.

Then think like a pessimist. Murphy's law applies: if something can go wrong, it will. Analyze:

• System failures, such as bad inputs, human error, hardware breakdowns, or clashes with other systems
• Foreseeable misuse, both accidental and deliberate. Think like a bad actor: how could someone abuse this system, and what would they gain?

You cannot foresee everything, which is why the standard says "reasonably foreseeable." But you do need to be diligent.

6.9 Measures to address harms and benefits

Finally, decide what you will do about what you found. There are two levels:

• Technical measures: for example, encrypting user data when a privacy risk appears, or updating, recalling, or retiring a system that underperforms. These proposals go through your approval process.
• Management measures: decisions by leadership. If a text-generation model could be misused to fake documents, leadership might decide not to sell it. If users lack awareness, it might launch training across the organization and its supply chain.

All measures should feed into the AI system's risk treatment plan. That creates a clear line from "what we found" to "what we are doing about it."

If you are seeking ISO/IEC 42001 certification, expect to document an impact assessment for every AI system within the scope of your management system.

How it fits with ISO/IEC 42001 and ISO/IEC 23894

ISO/IEC 42005 is one part of a family of AI standards. ISO/IEC 42001 is the foundation, and two annexes explain how the pieces connect.

Annex A: Working with ISO/IEC 42001

ISO/IEC 42001 asks for AI system impact assessments in two places. It is a requirement in the main clauses (6.1.4), and it is also a system-level control in its Annex A. ISO/IEC 42005 expands both into practical guidance.

Annex A of ISO/IEC 42005 is a lookup table. For each relevant ISO/IEC 42001 clause or control, it gives:

• A short summary of what is required
• Where ISO/IEC 42005 covers it
• How ISO/IEC 42005 supports it

Two examples:

• Clause 6.1.4 (perform an impact assessment): the whole of ISO/IEC 42005 supports this. It helps you build processes and documentation, and individual assessments together become inputs to this requirement.
• The impact assessment process control: this is about designing the process, not just producing a report. Organizations often struggle here, because there is no single right way to do it. Clause 5 of ISO/IEC 42005 helps you ask the right questions. Who approves assessments? How often do you run them? Who makes sure they are built into system design?

Annex B: Working with ISO/IEC 23894

Outside the standards world, "risk" and "impact" are often used to mean the same thing, including in laws and policy. Inside these standards they mean different things, and Annex B explains the difference.

• ISO/IEC 23894 (risk management) looks at risk to the organization: legal, reputational, and security. It works both at the organizational level and at the level of individual systems.
• ISO/IEC 42005 (impact assessment) looks only at impacts on individuals and societies. It does not cover impacts on the organization.

This focus on people matters, because it is what AI laws such as the EU AI Act care about most.

Annex B includes a diagram showing how the two link up. It works as a chain:

1. A potential event occurs at the system level.
2. That event affects individuals and societies, which the impact assessment captures.
3. Those impacts, and how likely they are, roll up into the AI system's risk assessment.
4. System risks roll up into organizational risk management.
5. Organizational risk is reported to leadership through the AI management system and shapes organizational objectives.

You don't have to follow this exact model. It is a helpful picture of how the three standards can work together in one organization.

Annex C: Mapping harms and benefits

Annex C helps you document benefits and concerns for Clause 6.8. Its centerpiece is Table C.1, which lists example objectives under headings such as accountability, transparency, fairness, reliability, safety, explainability, privacy, and security.

The key point: Table C.1 is an example, not a checklist. Keep what applies, remove what doesn't, and add rows or columns your system needs. You can even build your own table from scratch.

Example: poisoned training data

The series walks through a realistic security scenario:

1. A malicious actor, inside or outside a company, slips bad data into a training data set. They design it to exploit how the model is rewarded during training.
2. Company A collects training data, for example for traffic sign recognition. It monitors for bad data, but some slips through.
3. Company A sells the data set to Company B, which trains a model on it.
4. Company B releases a product containing the model.
5. Later, the attacker sends a hidden signal that people cannot easily spot, such as a QR-code-like pattern.
6. The AI recognizes the signal, treats it as a priority, and carries out a harmful action.

This looks like a security problem. But when you tailor Table C.1 to the scenario, it touches much more:

• Accountability: someone must be responsible for vetting purchased training data
• Reliability: periodic audits are needed to confirm the system still behaves within its defined limits
• Security: the training data is a weak point attackers can exploit

Some default objectives, such as those about personal data, may not apply if the system doesn't use personal data. That is fine. Drop them.

Annex D: Aligning with other impact assessments

Many organizations already run privacy, human rights, security, or financial impact assessments. AI overlaps with all of them. Without coordination, you risk duplicating work or missing issues that fall between assessments.

Annex D offers three tools:

• A coordination guide (D.2). Map where your assessments overlap, bring in people from each discipline, and identify dependencies. Names vary between teams, so let experts from each area confirm what actually counts as an assessment.
• A cross-reference table (D.3, Table D.1). List ISO/IEC 42005 sub-clauses down one side and your other assessments across the top. Then mark which sub-clauses each assessment already covers. This shows clearly where work is shared and where gaps remain.
• A risk link (D.4, Figure D.1). This builds on Annex B's diagram. It shows that each system-level event can cause impacts across several disciplines, each with some likelihood. Together, those make up the results of the risk assessment. It all happens at the product or service level, below the organizational level, which makes the AI assessment easy to compare with other assessment types.

Annex E: A ready-made template

Annex E gives an example of what a finished assessment could look like. Like the other annexes, it is informative, so treat it as a starting point. Its sections follow Clause 6 closely, which makes it easy to use.

One practical tip: balance detail against disclosure. Give reviewers enough technical detail to understand the system, but not so much that the document itself could help someone misuse it.

At minimum, plan one assessment per AI system. You may need several for one system, depending on your role and its life-cycle stage. The template also works as a stand-alone document, or as part of a combined assessment alongside your other reviews.

Your getting-started checklist

• List every AI system you build, provide, or use
• Define your role (producer, provider, or customer) and your context
• Design, document, and integrate your impact assessment process (Clause 5)
• Set time-based and event-based triggers
• Name owners and approvers
• Set thresholds for sensitive uses, restricted uses, and impact scales
• Complete the Clause 6 documentation for each system, using Annex E as a template
• Consult affected people in proportion to the risk
• Map benefits and harms using Annex C
• Feed results into your risk treatment plan and organizational risk management
• Coordinate with privacy, security, and other assessments using Annex D
• Review and improve the process regularly

Frequently asked questions

Is ISO/IEC 42005 mandatory? No. It is a guidance document, and you cannot be certified against it. However, ISO/IEC 42001, which is certifiable, requires AI system impact assessments, and ISO/IEC 42005 is the best guide to meeting that requirement.

Do I need an assessment if I only use AI and don't build it? Yes. The standard applies to organizations that develop, provide, or use AI. Document what you can, even if a vendor does not share every technical detail.

How many assessments do I need? At least one per AI system. Similar systems can sometimes be grouped, but that takes careful analysis.

Is an impact assessment the same as a risk assessment? No. A risk assessment looks at risks to your organization. An impact assessment looks at effects on people and society, and its results feed into your risk assessment.

When should I redo an assessment? On a regular schedule, and whenever something important changes, such as the model, the data, the users, or where the system is deployed.

Final thoughts

A well-run AI impact assessment does more than tick a compliance box. It shows due diligence, builds trust through transparency, and keeps responsible governance in place across the AI life cycle. ISO/IEC 42005 gives you a clear, practical path to get there. Start small, document honestly, and improve as you go.

Put this guide into practice. 

Download the AI Impact Assessment Toolkit: 

8 editable Word templates aligned with ISO/IEC 42001 and ISO/IEC 42005. It covers everything from screening and the full assessment form to the benefits-and-harms analysis, treatment plan, and final sign-off. Each template includes guidance and worked examples, so you never start from scratch. 

Connect with me today on LinkedIn or drop a message via our contact form to explore hands-on training paths, custom AI security assessments, and specialized certification roadmaps.

Subscribe to "AI Governance - Decoded" Newsletter to Master AI Governance With Just 15 Minutes Read Per Week.