AI Impact Assessment (ISO/IEC 42005): A Template That Changes Decisions
An AI impact assessment should end in go, change or stop. Here is a copyable nine-part template, five screening questions, and a rule for who should sign.
Two weeks before go-live, the question on the table is simple: launch the AI system as planned, change it first, or stop. An AI impact assessment exists to change that answer when the evidence calls for it. If the finished document could not move the decision from go to change or stop, it is a file in a folder, not an assessment.
Below is a copyable AI impact assessment outline, with rules for when to run one and who should sign it. The outline is our own, informed by ISO's published summary of ISO/IEC 42005; it does not reproduce the standard's structure, so check it against the standard itself. This is general information, not legal advice; your obligations depend on your sector, your data and the countries you operate in.
What decision should an AI impact assessment change?
Every assessment should end in one of three decisions, written in one line at the top of the document:
- Go: the impacts on people are understood, the controls are in place, and someone with authority has accepted the risk that remains.
- Change: the system may go live only after named changes, each with a responsible person and a date. Examples: a person reviews every decline, the Arabic answers are tested, or the scope shrinks to one branch.
- Stop: a serious harm cannot be reduced enough, or the purpose does not justify the risk to the people affected.
We recommend writing these three options, and the evidence that would lead to each, on page one before anyone fills in the rest. It takes ten minutes, and it makes the assessor look for evidence that could stop the project, not only evidence that supports it. The trade-off is that project teams may see the assessment as a gate rather than a help. That is partly the point, so keep the assessment short for low-impact systems and save the full effort for the ones that affect people's money, jobs, health or access to services.
When should you run an AI impact assessment?
ISO's page for ISO/IEC 42005 recommends assessments throughout the AI system lifecycle, from design and development to deployment and post-market monitoring, updated as needed. In practice, that means a short screen for every new AI use, and a full assessment when the screen says so.
Five screening questions
- Does the system make or shape a decision about a person (credit, hiring, benefits, treatment, discipline)?
- Does it use personal data, or data about health, finances or children?
- Does it speak to customers or the public without a person checking first?
- Could an error cost someone money, a service, a job or their safety?
- Can it act on its own: send messages, make payments or change records?
One "yes" means a full assessment. All "no" means a one-page record of the answers, signed by the system owner.
Triggers to run it again
- A new purpose, or a new group of users or affected people.
- A new data source, a new model or a change of supplier.
- A serious complaint or incident involving the system.
- The review date written in the last assessment.
The AI impact assessment template (copy this outline)
Copy the nine sections below into your own document. Keep the answers short and specific; a section that says "not applicable" should say why.
- System and purpose. Name of the system, the supplier and model if known, the business owner, the task it performs, and the decision it supports. State what happens today without AI.
- People affected. Who uses it, who is affected by its results, and who is affected without knowing it is involved. Note groups who may be affected differently: Arabic and English speakers, older customers, people outside the capital, people with disabilities.
- Data. What data goes in, where it comes from, whether it includes personal or sensitive data, where it is processed and stored, and how long it is kept. Link the data protection review if there is one.
- Possible harms and benefits. List the realistic benefits (faster answers, fewer errors) and the realistic harms (a wrong decline, a wrong answer about a fee, a leak of personal data, unfair treatment of one group). Include foreseeable misuse.
- Severity and likelihood. Rate each harm with the table below before any controls, then again after them.
- Controls. For each serious harm, the control that reduces it, who runs it and how you will know it works: testing before launch, limits on what the system can do, monitoring after launch.
- Human oversight. Which results a person reviews before they take effect, who that person is, what they can overrule, and how an affected person can ask for a human review or complain.
- Decision and sign-off. Go, change or stop; the conditions attached; the names and roles of the people signing; the date.
- Review date. A fixed date (three to twelve months, shorter for higher impact) plus the triggers listed above.
Rating severity and likelihood
| Severity | What it looks like | If likely or possible | If rare |
|---|---|---|---|
| High | Affects rights, income, health or safety, or is hard to reverse | Change or stop | Change, or go with written acceptance by the approver |
| Medium | Costs time or money but can be fixed with effort | Change | Go with monitoring |
| Low | Inconvenience, easily corrected | Go with monitoring | Go |
Rating benefits as well as harms matters. NIST's Generative AI Profile (NIST AI 600-1, July 2024) repeats the AI Risk Management Framework subcategory MAP 5.1: identify and document the likelihood and magnitude of each impact, "both potentially beneficial and harmful". A stop decision is easier to defend when the benefit given up is written down too.
Who signs an AI impact assessment?
The rule we recommend: the person who signs must be able to say no, and the people who built or sold the system cannot sign alone.
| Role | What they do |
|---|---|
| System owner (business) | Describes the purpose and the people affected, and carries out the conditions |
| Assessor | Writes the findings and ratings; someone from risk, compliance or another team outside the project |
| Data protection and legal | Consulted where personal data or regulated decisions are involved |
| Frontline voice | A staff member who deals with the affected people and can say how errors would land |
| Approver | Signs the decision; has authority over the go-live date and the budget for changes |
For high-severity systems, the approver should be the executive or AI committee that owns AI risk, not the project sponsor alone. Your decision rights belong in your governance framework; our guide to an AI governance framework for Saudi Arabia, the UAE and Jordan covers how to set them.
Three illustrative examples from Jordan and the Gulf
Change: a microfinance lender in Jordan (illustrative). The lender plans a model that pre-screens loan applications. The assessment finds the training data comes mostly from city branches, so applicants with irregular rural income may be declined more often. Severity is high (access to credit) and likelihood possible. Decision: change. The model may recommend approvals, but every decline goes to a loan officer, decline rates are compared by branch each month, and the review date is three months after launch.
Go with conditions: a government service centre in the UAE (illustrative). A public chatbot answers questions on fees and required documents in Arabic and English. The main harm is a wrong answer that sends someone on a wasted trip: medium severity, likely if the bot draws on old pages. Controls: answer only from approved pages and show the link, hand over to staff when unsure, and test 100 real questions in both languages before launch. Decision: go once the test passes.
Stop: a retailer in Riyadh (illustrative). A vendor offers a tool that scores employees' "attitude" from their internal chat messages. The assessment finds no clear link between the score and job performance, a high risk of unfair treatment, and a purpose that does not justify reading staff messages. Decision: stop, recorded with the reasons.
How ISO/IEC 42005 relates to ISO/IEC 42001
ISO/IEC 42005:2025, first edition, published in May 2025, gives guidance to organisations conducting AI system impact assessments: how an AI system and its foreseeable uses may affect individuals, groups or society. ISO says it applies to any organisation that develops, provides or uses AI, and that it complements ISO/IEC 42001 (AI management systems), ISO/IEC 23894 (AI risk management) and ISO/IEC 38507 (AI governance).
ISO/IEC 42001:2023 is the management system standard. Its table of contents, shown in the IEC Webstore preview, includes "AI system impact assessment" twice: clause 6.1.4 under planning and clause 8.4 under operation. So if you are preparing for 42001 certification, expect to show impact assessment records; the template above can be a starting point, but check it against the clause text in your copy of the standard. Our article on ISO 42001 certification readiness covers the rest of that work. Independent certification bodies certify; we help organisations prepare.
How to start
Pick one AI system that goes live in the next quarter. Run the five screening questions, and if any answer is yes, fill in the template in a 90-minute session with the system owner, an assessor from outside the project and one frontline staff member. Write the decision on page one before you leave the room.
If you want help, our Governance Lab runs the AI Governance & Compliance Foundation, which covers policy, decision rights, AI and risk registers, PDPL alignment and ISO/IEC 42001 readiness. For data protection and regulator questions, see PDPL and regulators. Or start with the AI Exposure Scan, a free 45-minute conversation that ends in a written next step.
Frequently asked questions
What is ISO/IEC 42005?
ISO/IEC 42005:2025 is an international standard, first published in May 2025, that gives guidance to organisations conducting AI system impact assessments. It covers how an AI system and its foreseeable uses may affect individuals, groups or society, and ISO says it applies to any organisation that develops, provides or uses AI. It complements ISO/IEC 42001, the AI management system standard.
Is an AI impact assessment required by ISO/IEC 42001?
ISO/IEC 42001:2023 includes AI system impact assessment as clause 6.1.4 under planning and clause 8.4 under operation, according to its published table of contents. If you are preparing for 42001 certification, you should expect to show impact assessment records. ISO/IEC 42005 gives guidance on how to carry them out. Independent certification bodies decide on certification.
When should an organisation run an AI impact assessment?
Run a short screen for every new AI use and a full assessment when the system shapes decisions about people, uses personal or sensitive data, speaks to the public unchecked, could cost someone money, a service or a job, or can act on its own. Repeat it when the purpose, users, data, model or supplier changes, after a serious incident, and on the review date.
Who should sign an AI impact assessment?
The approver should be someone with authority over the go-live date and the budget for changes, so they can actually say no. The system owner, an assessor from outside the project and, where personal data is involved, data protection or legal colleagues contribute. For high-impact systems, the executive or AI committee that owns AI risk should sign, not the project sponsor alone.
What is the difference between an AI risk assessment and an AI impact assessment?
A risk assessment tends to look at risks to the organisation and its objectives, while an impact assessment looks at how the system may affect people and society: customers, staff, applicants and groups who may be treated differently. ISO lists ISO/IEC 23894 for AI risk management and ISO/IEC 42005 for impact assessment as complementary standards. In practice the findings of one feed the other.
Get new insights by email
One email when we publish something useful. No spam; leave any time.
Services in this article
Related lab: Governance Lab ↗
