The short answer: An AI risk assessment is a structured review of every AI system your organisation builds, buys or quietly tolerates, identifying what could go wrong across data, models, deployment context, suppliers and people, then deciding what to do about each risk. ISO 42001 asks for two connected exercises: an AI risk assessment covering risk to the organisation, and an AI system impact assessment covering the individuals and groups on the receiving end. Both belong in one register with ratings, owners and review dates.

Most teams already know how to assess information security risk. AI breaks the habit. The asset is not a server, it is a model whose behaviour shifts when the data shifts. The harm is not only a breach; it can be a rejected job application or a support bot inventing a refund policy your finance team has to honour. And the risk is often not yours at all. It arrived inside a SaaS product you renewed last quarter. For the wider case on why this exists, read AI risk management.

AI risk assessment at a glance

Scope is per system, per use case. A CV screener and a marketing copy assistant share nothing but the acronym.
Six risk sources cover most of it: data, model, deployment context, third parties, people and process, and legal or regulatory exposure.
Two assessments, one register. ISO 42001 clause 6.1.2 covers risk to the organisation; clause 6.1.4 covers impact on individuals and society.
Treatment is a decision, not a hope. Apply Annex A controls, mitigate, avoid the use case, or accept with a named owner.
Triggers beat calendars. Reassess when the model changes, the data changes, the law changes or something goes wrong.

What an AI risk assessment is actually meant to catch

A security risk assessment asks who could reach your data and what happens if they do. An AI risk assessment keeps that and adds harder questions. Does the system work as intended for everyone it touches? Can anyone explain a decision it made six months ago? What happens when your vendor retrains the model and mentions it in a changelog nobody reads?

Splitting risks by source stops the exercise collapsing into one vague entry called "hallucination". Six sources cover most AI systems:

Data: provenance, licensing, quality, bias in training or reference data, personal data used without a lawful basis, retention.
Model: accuracy, drift, brittleness at the edges, fabricated output, prompt injection, thin explainability, no way to reproduce past decisions.
Deployment context: the same model is low risk summarising meeting notes and high risk triaging applicants. Context sets the stakes.
Third parties: foundation model providers, API resellers, fine-tuning partners, and every tool in your stack that grew an assistant.
People and process: over-reliance on output, no human review where it matters, staff pasting client data into public chatbots, no owner.
Legal and regulatory: UK GDPR duties on automated decision-making, sector rules, contract commitments, EU AI Act obligations if you operate in the EU.

If you already run structured security assessments, the machinery transfers. Our guide to ISO 27001 clause 8.2 follows the same rhythm: set criteria, identify, analyse, evaluate, treat. What changes is the inputs, and who gets hurt when you get it wrong.

How to run an AI risk assessment, step by step

1. Inventory the AI systems and use cases

You cannot assess what you have not listed. Cover four categories: AI you built, AI you bought, AI embedded in software you already pay for, and AI your employees use without telling anyone. The last two hold the surprises, and they are usually the largest.

Record the use case, not just the tool. One LLM subscription might cover marketing copy, support summaries and supplier shortlisting. Three assessments, not one entry called "ChatGPT".

2. Define risk criteria and the assessment scope

Decide before you start what "high impact" means, what likelihood scale you use, and where your acceptance line sits. Write it down. An auditor will ask how you reached a rating, and "it felt like a medium" is not a methodology.

Your criteria need a dimension for impact on people, not just financial and operational loss. Inherited security scales have no cell for "a person was treated unfairly and never found out", which is the harm AI governance exists to surface.

3. Identify risks per system, across all sources

Work the six sources for each system with the people who use it. Engineering, legal, the product owner and the frontline team will each name risks the others cannot see. Do this in a room, not by circulating a form.

Write risks as cause and consequence, not labels. "Bias" is not a risk. "Training data under-represents part-time work histories, so the model ranks those candidates lower and qualified applicants are rejected" is a risk you can treat.

4. Analyse likelihood and impact, including impact on individuals

Score each risk against your criteria, then answer a second question for every entry: who is affected? Users, employees, applicants, patients, or people who never chose to interact with the system at all. Name them in the register. This is where ISO 42001 parts company with a standard security assessment. The organisational assessment protects you; the impact assessment protects everyone else.

5. Evaluate against criteria and choose a treatment

Compare each rating to your acceptance line and make a call. Four honest options: apply controls, mitigate by redesigning the use case (human review before action, narrower scope, output grounded in approved sources), avoid it, or accept the risk with a named owner and a date.

ISO 42001 Annex A offers 38 controls across nine objectives, covering AI policy, roles, resources, impact assessment, lifecycle, data, third parties and more. Not every control applies. Justify what you exclude, in writing, at the time.

6. Document everything in an AI risk register

One register, every system, one methodology. Split registers across teams and you will spend the audit reconciling them instead of demonstrating control. Each entry needs an owner with authority to act, a treatment decision, the control delivering it, and a review date. Our ISO 42001 compliance checklist covers what else the auditor expects.

7. Monitor and reassess on triggers

Set periodic reviews, then let triggers override them. Reassess when the vendor ships a new model version, when you connect a new data source, when the use case expands beyond what you assessed, when regulation lands, and after any incident. Annual review on a system updated monthly is decoration.

An AI risk assessment template: the columns your register needs

Templates get abandoned because they ask for too much, or the wrong things. These fields survive contact with an auditor. Two of them do the heavy lifting: affected parties, which is where clause 6.1.4 lives, and owner, because departments have never once fixed a risk. A ready-made structure sits in our ISO 42001 checklist.

Column	What goes in it
AI system	Named system, version and vendor
Use case	What it is used for, by whom, in which process
Data	Training, grounding and inference data, including personal data
Risk source	Data, model, deployment context, third party, people and process, or legal
Risk description	Cause and consequence in one sentence
Affected parties	Individuals or groups bearing the consequence
Likelihood	Score against your defined scale
Impact	Score covering the organisation and affected individuals
Risk rating	Combined score, plus residual rating after treatment
Treatment	Control, mitigate, avoid, or accept
Control reference	Annex A control, policy or technical measure
Owner	Named person, not a department
Status	Open, in treatment, accepted, closed
Review date	Next review, plus the triggers forcing an earlier one

AI risk assessment or AI system impact assessment?

These get conflated constantly, so here is the plain version. The AI risk assessment asks what AI could do to your organisation: legal exposure, financial loss, service failure, reputational damage. The AI system impact assessment asks what the system could do to people and society, whether or not that rebounds on you.

A recruitment tool that quietly disadvantages a group of applicants might carry modest organisational risk for years. The impact on those applicants is severe from day one. Only one assessment catches that, which is why clause 6.1.4 is a separate requirement.

A DPIA is a third thing: a UK GDPR instrument focused on risk to data subjects from processing personal data. The ICO's guidance on AI and data protection is clear that one is often required for AI involving personal data. Where it overlaps with your impact assessment, reuse the analysis. It does not replace it.

How this maps to ISO 42001, NIST AI RMF and the EU AI Act

Under ISO/IEC 42001:2023, clause 6.1.2 requires a defined, repeatable AI risk assessment process, clause 6.1.3 requires risk treatment with a Statement of Applicability, and clause 6.1.4 requires the AI system impact assessment. Clauses 8.2, 8.3 and 8.4 make all three operational, things you perform rather than describe. Our breakdown of the core requirements of ISO 42001 clauses 4 to 10 shows how the rest hangs off this.

The NIST AI Risk Management Framework uses different vocabulary for compatible work: Map is inventory and context, Measure is analysis, Manage is treatment and monitoring. One register serves both with a framework reference column.

The EU AI Act adds obligations rather than replacing anything. Providers of high-risk systems face conformity assessment before those systems reach the market, and certain deployers must complete a fundamental rights impact assessment. Both draw on evidence your ISO 42001 assessment already produces. Set it inside a defined AI governance framework so the assessment has policies and roles to attach to.

Four ways AI risk assessments fall over

Treating "AI" as one line item. A single entry reading "risk of AI errors, mitigated by staff training" is a nil return in a suit.
Ignoring bought-in AI. Teams assess the two models they built and skip the fourteen AI features switched on inside their CRM, helpdesk and HR platform.
No impact-on-people lens. If every impact score reads as revenue or downtime, you have run a security assessment with new labels.
Assessing once, then filing it. An assessment written before a model upgrade describes a system that no longer exists. Auditors check dates.

The fix is structural rather than motivational. Hicomply's risk management module auto-populates risks from assets already in your inventory, guides assessors through likelihood and impact or takes your own methodology, and holds it all in a central register with audit-ready records. Assessors stop inventing scales, and you stop finding three competing spreadsheets a fortnight before the audit.

Organisations running ISO 27001 in Hicomply extend that same register to their AI systems rather than starting a parallel one. It matters most for firms now fielding AI questions in every security questionnaire, such as consultancies and professional services firms. CloudPass moved off OneDrive folders and passed audit with zero non-conformities, having previously spent around £5,000 a year on external consultants.

Hicomply's take

Teams open their AI risk assessment with the model and get stuck arguing about explainability. Start with the inventory instead. Almost every organisation we speak to underestimates how much AI is already running inside tools bought for other reasons, and that gap is where the ugly findings come from. Assess per use case, and give every entry an owner with a surname. The scoring debates settle themselves once people can see what they are scoring.

Get your AI risk register audit-ready without the spreadsheet sprawl

An AI risk assessment is less hard work than persistent work. The first pass takes a few weeks. Keeping it true as models change and use cases spread is what defeats spreadsheets, because a spreadsheet has never once reminded anyone that a review date passed.

To see where you stand, run the ISO 42001 readiness assessment and find which clauses you already meet through existing security work. When you want the register, the guided assessments and the evidence trail in one place, book a demo and bring your messiest AI use case.