AI Risk Management

AI Risk Assessment: A Step-by-Step Methodology

A rigorous, repeatable methodology for assessing AI system risk — from scoping and stakeholder mapping through scoring, treatment and documentation — with a worked example.

Jasper Claes

April 16, 2026 · 17 min read

AI Risk Management

"Risk assessment" gets used loosely — sometimes meaning a quick gut-check conversation, sometimes a formal document with legal review. A methodology is what makes assessments consistent regardless of who's running them. This is a rigorous, repeatable seven-step process, walked through end to end with a single worked example.

TL;DR

A repeatable AI risk assessment methodology has seven steps: scope, map stakeholders, identify scenarios, score, evaluate controls, determine treatment, and document with sign-off.
Scoping first prevents the most common failure — an assessment that tries to cover an entire product instead of a specific AI system with defined boundaries.
Stakeholder mapping should go beyond direct users to include indirectly affected parties, since AI harms often land on people who never interact with the system directly.
This methodology directly supports the EU AI Act's Article 9 risk management requirement, ISO 42001's clause 6, and the NIST AI RMF's Map and Measure functions — one solid process satisfies evidence needs across all three.
Assessments should be repeated on a schedule and whenever the system, its data, or its use case materially changes — not treated as a one-time exercise.

Why 'Risk Assessment' Means Different Things to Different Teams

This post is about the assessment methodology itself — the repeatable process for evaluating one AI system's risk. For how completed assessments feed into an ongoing tracking system, see How to Build an AI Risk Register. The two are related but distinct: methodology produces the assessment; the register tracks it over time.

The Methodology at a Glance

Seven steps, applied the same way every time — repeatability is what makes a methodology, not a one-off exercise.

Step 1: Scope the Assessment

Define exactly which system, which version, and which use case you're assessing — "our AI" is not a scope; "the credit-scoring model used for personal loan applications under $50,000" is. Unclear scoping is the most common reason assessments become unusable later.

Step 2: Map Stakeholders and Potential Harms

Identify everyone potentially affected — not just direct users. Map outward from the people the system decides about, to the people operating it, to broader society or regulators with an interest in the outcome.

Step 3: Identify Specific Risk Scenarios

Turn general categories (bias, drift, security) into specific, concrete scenarios: not "the model could be biased" but "the model could systematically score applicants from a specific zip code lower due to historical lending pattern bias in the training data."

Step 4: Score Likelihood and Impact

Score each scenario on likelihood and impact using a consistent scale (1-5 is common), with impact assessed across legal, safety, financial and reputational dimensions, scored against the worst dimension rather than an average.

Step 5: Identify and Evaluate Existing Controls

For each scenario, document what controls already reduce likelihood or impact — and critically, evaluate whether they're actually effective, not just present. A bias testing process that hasn't run in over a year is a control on paper, not in practice.

Step 6: Determine Residual Risk and Treatment

Decide, per scenario, whether to mitigate, transfer, avoid or accept the residual risk after existing controls — with an owner and deadline assigned to any action, and explicit sign-off recorded for anything accepted.

Step 7: Document and Obtain Sign-Off

A completed assessment needs a named approver, a date, and a defined next review date — an assessment without sign-off is a draft, not a completed risk assessment, regardless of how thorough the analysis was.

Worked Example End to End: Credit-Scoring AI

Worked example: stakeholder mapping for a credit-scoring AI system, from directly affected outward.

Step	Applied to the example
1. Scope	The credit-scoring model used for personal loan applications under $50,000
2. Stakeholders	Applicants (direct), loan officers (operators), regulators and consumer advocacy groups (societal interest)
3. Scenario	Systematic under-scoring of applicants from historically redlined zip codes
4. Score	Likelihood 4, Impact 5 (legal + reputational) — high severity
5. Controls	Quarterly bias audit exists but hasn't run in 14 months — control present but not effective
6. Treatment	Mitigate — resume quarterly audits immediately, add zip code as a monitored fairness dimension
7. Sign-off	Approved by compliance lead, next review in 90 days

How Often to Repeat the Assessment

At minimum on a fixed schedule (commonly every 6-12 months for moderate-risk systems, more frequently for high-risk ones), and immediately whenever the system, its training data, or its use case materially changes — a new deployment context can invalidate an otherwise-current assessment overnight.

Common Methodology Mistakes

Skipping scope definition. Assessing "the AI system" broadly instead of a specific, bounded use case.
Stopping at direct users. Missing indirectly affected parties who never interact with the system but bear its consequences.
Treating control existence as control effectiveness. A documented process that isn't actually running isn't a real mitigation.
No sign-off. An unapproved assessment carries no real accountability.

How This Maps to Regulatory Requirements

Framework	Requirement this methodology supports
EU AI Act	Article 9 risk management system for high-risk AI
ISO 42001	Clause 6 risk assessment and treatment
NIST AI RMF	Map (context and scenario identification) and Measure (scoring and evidence)

Primary Sources

NIST — AI Risk Management Framework
EUR-Lex — Regulation (EU) 2024/1689

Where Unorma Fits

A methodology, not just a template

Unorma’s gap analysis and evidence vault guide each assessment through this same structure and keep the resulting evidence mapped across frameworks. Once an assessment is complete, track it going forward with a proper AI risk register.

Frequently asked questions

What's the difference between a risk assessment and a risk register?

The assessment is the methodology for evaluating a specific AI system's risk at a point in time. The register is the ongoing record that tracks assessments, treatment decisions and review dates across all your AI systems.

How specific should risk scenarios be?

Very specific — 'the model could be biased' isn't actionable, while 'the model systematically under-scores applicants from a specific zip code due to historical training data patterns' is something you can test, treat and monitor.

Should stakeholder mapping go beyond direct users?

Yes — AI harms often affect people who never interact with the system directly, like applicants evaluated by a model they never see, or communities affected by a system's downstream decisions.

How do we know if a control is actually effective, not just documented?

Check whether it's actually been performed recently and on schedule — a bias audit process that exists on paper but hasn't run in over a year is a control in name only.

How often should a risk assessment be repeated?

On a set schedule (commonly every 6-12 months, more often for high-risk systems) and immediately after any material change to the system, its data, or its use case.

Does this methodology satisfy the EU AI Act's Article 9 requirement?

It directly supports it — Article 9 requires a continuous risk management process across an AI system's lifecycle, which this seven-step methodology, repeated on schedule, is designed to produce evidence for.

Who should approve a completed risk assessment?

A named individual with real authority over the decision — typically a compliance or risk lead — recorded with a date and next review date. An assessment without sign-off carries no real accountability.

Key terms in this article

About the author

Jasper Claes

Compliance Manager & AI Governance Consultant

Compliance Manager and consultant specializing in AI governance for high-scale technology companies operating in regulated markets.

View full profile

Keep reading