AI Risk Assessment Guide: Method, Scoring and Tiers

Most AI risk assessments fail in one of two ways: a generic questionnaire that rates every chatbot "medium", or a review of the model that never asks what data it can reach, who relies on its output and what it is allowed to do. An AI risk assessment should answer a narrower question: for this use case, in this context, what can go wrong, how likely and how bad is it, and is the remaining risk acceptable to a named person. This guide sets out a repeatable method, from scoping and risk identification to scoring, treatment, documentation, approval gates and reassessment, shows where NIST AI RMF, ISO/IEC 23894, ISO/IEC 42005, the EU AI Act FRIA and the UK ICO toolkit fit, and treats agentic AI separately. It is written for security, risk, privacy and AI platform teams who run or review these assessments.

Key takeaways

Assess the use case, not the model. The same model is low risk drafting internal notes and high risk screening job applicants; scope by the decision influenced, the data reached and the actions permitted.
Use one method and map the rest. NIST AI RMF MAP and MEASURE, ISO/IEC 23894 and ISO/IEC 42001 clause 6.1 overlap heavily; legal assessments such as the GDPR DPIA and the EU AI Act FRIA are triggered by specific conditions and can reference the core assessment.
Autonomy is a risk multiplier. An agent with write access and no approval step turns a wrong output into an action; score tools, permissions and reversibility explicitly.
Residual risk needs an owner and a signature. OMB M-25-21 requires a signature from "the individual accepting the risk" and an independent reviewer; private organisations should copy both.
An assessment is a baseline, not a certificate. Reassess on defined triggers: new model version, new data source, new tool, new user group or a monitoring threshold breach.

Which method to use

Most organisations need one core method that sets scoping, scales and register fields, plus the legal assessments that apply.

Method	Type	Use it for	Mandatory when
NIST AI RMF 1.0 MAP and MEASURE	Voluntary framework	Context, impacts and metrics; MAP 5.1 asks for the "likelihood and magnitude" of each impact	Never; widely used as the backbone
ISO/IEC 23894:2023	Guidance standard	Applying ISO 31000 risk management to AI across the lifecycle	Never; often paired with ISO/IEC 42001
ISO/IEC 42001:2023 clauses 6.1.2 to 6.1.4	Certifiable requirement	AI risk assessment, risk treatment and AI system impact assessment inside an AI management system	When you certify to ISO/IEC 42001
ISO/IEC 42005:2025	Guidance standard	Impacts on "individuals, groups, or society at large" through the lifecycle	Never; supports 42001 clause 6.1.4
EU AI Act Article 9	Law (providers)	Risk management system for high-risk AI, including "reasonably foreseeable misuse"	Providers of high-risk systems
EU AI Act Article 27 FRIA	Law (certain deployers)	Fundamental rights impact of a high-risk system in your process	Public bodies, private entities providing public services, and deployers of credit scoring and life and health insurance pricing systems, before first use
GDPR Article 35 DPIA	Law (controllers)	High risk to individuals from personal data processing	Likely high risk processing; AI often meets the criteria
ICO AI and data protection risk toolkit	Regulator spreadsheet	Data protection risks across an AI project, as practical support	Never; the guidance is under review following the Data (Use and Access) Act
SR 11-7 model risk management	US banking supervisory guidance	Validation, effective challenge and outcomes analysis for models	Supervised US banks; widely copied in financial services

Build once, reference many: Article 27(4) lets a FRIA cross-reference an existing DPIA; design your core record so its sections can be referenced by the DPIA, FRIA and any ISO/IEC 42001 impact assessment. See the DPIA Guide: Running a Data Protection Impact Assessment.
Providers and deployers differ: builders own Article 9-style design risk and testing; buyers own context, oversight, data and integration risk. Record the role per use case. See the AI Governance Guide for role mapping and the EU AI Act timeline.

Step 1: Scope the use case

NIST MAP 1.1 asks for intended purposes, deployment settings, expected users, impacts and assumptions; MAP 3.3 for the targeted scope. A scope that cannot answer the questions below is not ready to assess.

Use case and decision: what task the AI performs, what decision or action it informs, and whether a human makes the final call. M-25-21 also asks for "the intended purpose for the AI and its expected benefit" compared with the current process.
Model: provider, model and version, hosting (provider API, cloud platform, self-hosted), fine-tuning, and whether the provider may change the model without notice.
Data: training or fine-tuning data, retrieval sources, prompt inputs, outputs and logs, with classification, personal or special category data and retention.
Users and affected people: who operates it, who is affected by its output, and whether they include under-18s or other vulnerable groups, which Article 9 requires providers to consider.
Autonomy and tools: read-only, drafts for review, or acts directly; which tools, APIs and credentials it holds; whether actions are reversible.
Exposure: internal or public, number of users, volume of decisions, and what happens if it is switched off.
Legal triggers: EU AI Act category, GDPR DPIA screening, sector rules, and whether a FRIA applies.

A short screening form routes most internal productivity use cases to a register entry and standard controls, saving full assessments for the cases that need them.

Step 2: Identify the risks

Work through each category with the people who know the system. MAP 4.1 asks you to map legal and technology risks of every component, including third-party data, software and intellectual property; MEASURE 1.1 asks you to document risks you cannot yet measure rather than drop them.

Category	Typical risks	Evidence to gather
Security	Prompt injection, insecure output handling, excessive agency, poisoned models, stolen API keys	Threat model against the LLM Security Guide controls, red team results, key inventory
Privacy	Personal data in prompts, training or logs; inference of sensitive attributes; rights handling	DPIA screening, data flow map, retention settings, provider terms
Safety	Harmful advice, physical or financial harm, unsafe actions	Use case harm analysis, safety evaluations, fallback design (MEASURE 2.6)
Bias and fairness	Unequal error rates across groups, discriminatory outcomes	Disaggregated performance results (MEASURE 2.11), representative test data
Intellectual property	Infringing outputs, licence breaches in training data or open models, leakage of trade secrets	Model and dataset licences, provider indemnities, input restrictions
Reliability	Hallucination, drift, performance outside tested conditions, provider model changes	Tests in deployment-like conditions (MEASURE 2.3), golden question sets, change notice terms
Third party	Provider outage, data reuse, sub-processors, model deprecation, concentration on one supplier	Due diligence, contract terms, exit plan, provider system or model cards
Agentic	Goal hijack, tool misuse, privilege abuse, cascading failures across agents	Tool and permission inventory, approval design, kill switch test

Write each risk as a cause, event and consequence ("because retrieval runs as a service account with access to all HR files, a user could receive another employee's salary data, causing a personal data breach"). Vague entries such as "data leakage" cannot be scored. See the AI and Privacy Guide for privacy attacks on models and lawful basis questions.

Step 3: Score and tier

NIST defines risk as a composite of likelihood and magnitude, and notes that the AI RMF "does not prescribe risk tolerance": MAP 1.5 asks you to set and document your own. Use your enterprise risk scales so AI risks can sit in the same register as other risks, then add AI-specific impact descriptors.

Score	Impact on people	Impact on the organisation	Likelihood
1 Minimal	Inconvenience, easily corrected	No external visibility	Not expected in the system's life
2 Minor	Short-term harm, reversible without help	Internal rework	Possible under unusual conditions
3 Moderate	Financial loss, distress or unfair treatment for some people	Complaint, contractual breach	Could occur under normal use
4 Major	Denial of a service, significant financial or legal effect	Regulator notification, material loss	Expected occasionally
5 Severe	Physical harm, irreversible effects, large-scale rights impact	Enforcement, litigation, sustained outage	Expected frequently or already observed

Score inherent, then residual: inherent risk before AI-specific controls, residual after. MEASURE 2.6 asks you to show residual risk is within tolerance.
Apply modifiers rather than averaging: raise likelihood or impact one step for autonomous action without approval, irreversible actions, public exposure, vulnerable groups or high volume. Averaging across categories hides the one risk that matters.
Set a stop line: the AI RMF says that where a system presents "unacceptable negative risk levels", development and deployment should cease safely until risks are managed. Define that line in advance.
A worked public example: Canada's Algorithmic Impact Assessment uses 65 risk and 41 mitigation questions, a raw impact score out of 169, a 15% reduction when mitigation reaches 80% of its maximum, and four impact levels (I at 0 to 25% up to IV at 76 to 100%) that set mandatory requirements.

Tier	Typical triggers	Assessment depth and approver
Prohibited	EU AI Act Article 5 practices, or residual risk above the stop line	Not approved
High	Any residual score of 15 or more, EU high-risk category, legal or similarly significant effects, agents with write access to critical systems	Full assessment, independent review, DPIA and FRIA where triggered, AI governance committee sign-off
Elevated	Residual 8 to 14, customer-facing output, confidential data, tools with write access	Full assessment, security and privacy sign-off, red teaming, business owner accepts residual risk
Standard	Residual below 8, internal use, approved platform, no write tools	Screening form, register entry, standard controls

These thresholds assume a five by five matrix; calibrate them against past use cases before adopting them.

Step 4: Treat, accept and record

NIST MANAGE 1.3 lists the response options: mitigate, transfer, avoid or accept. ISO/IEC 42001 clause 6.1.3 asks you to determine the controls needed for the chosen treatment and compare them with Annex A.

Mitigate in design first: Article 9(5) favours eliminating or reducing risk through design. Removing a write tool, narrowing a retrieval scope or adding human approval usually beats adding a filter.
Transfer with care: indemnities move financial risk, not harm to people or regulatory duty.
Avoid: narrow the use case, exclude a user group or data source, or stop.
Accept explicitly: M-25-21 requires "results of independent review" by someone not involved in development, shared with the official accepting the risk, and that official's signature. Set acceptance authority by tier and an expiry date.

Each risk register entry should hold: risk ID and use case ID, cause, event and consequence, category, inherent likelihood and impact, controls with owners and status, residual score, treatment decision, acceptor and date, review date and the monitoring metric that would show the risk materialising.

Documentation: model cards, system cards and the assessment record

Model cards: introduced by Mitchell et al. as short documents giving "benchmarked evaluation in a variety of conditions", including across demographic groups, the intended use context and evaluation procedures. Ask providers for them; write your own for models you train or fine-tune.
System cards: Meta describes an AI system as "a group of ML models, AI and non-AI technologies that work together" and uses system cards to look "holistically across an AI system, versus one-off models". Your assessment is about the system: model, retrieval, tools, guardrails, user interface and human review together.
The assessment record: scope, risk register extract, test evidence, linked DPIA or FRIA, decision, conditions of approval, reassessment triggers and date. NIST MEASURE 2.1 asks for test sets, metrics and tool details to be documented.
Keep it versioned: store it with the register entry so a model or tool change creates a new version.

Running the process: gates and rollout

Agree scales and tiers: adopt enterprise likelihood and impact scales, add AI descriptors, define the stop line and acceptance authority per tier, and get them approved by the risk committee.
Pilot on known cases: assess five to ten existing use cases of different types to calibrate scoring before publishing the method.
Gate 1, intake and screening: register the use case and route it by tier; standard tier exits here with standard controls.
Gate 2, design review: scope, risk identification and inherent scoring before build or purchase, while design changes are cheap; trigger DPIA and FRIA screening here.
Gate 3, pre-deployment: test evidence in deployment-like conditions (MEASURE 2.3), red team results for elevated and high tiers, residual scoring, independent review and signed acceptance.
Staged release: pilot users first, with a documented fallback process and a kill switch that disables tools or the whole feature; rollback means reverting to the previous model, prompt or process version, tested before launch.
Back-assess existing systems: tier everything already in production, highest exposure first, and restrict use cases that cannot meet their tier's controls.

Small organisations: one screening form, a three-tier model, a shared register and the business owner plus one security or privacy reviewer as approvers.
Large or regulated organisations: integrate with model risk management and effective challenge as SR 11-7 describes, "critical analysis by objective, informed parties", and with procurement so purchases cannot bypass Gate 2.

Agentic AI: what changes and where identity fits

Agents act with credentials, so the main risks shift from what the model says to what it can do. The OWASP Top 10 for Agentic Applications for 2026 names them, including ASI01 Agent Goal Hijack, ASI02 Tool Misuse and Exploitation, ASI03 Identity and Privilege Abuse, ASI06 Memory and Context Poisoning, ASI08 Cascading Failures and ASI10 Rogue Agents.

Inventory permissions, not just tools: for each tool record the identity it runs as (its own service account, the user's delegated token or a shared key), its scopes and whether actions are reversible. An agent holding a broad token inherits every risk that token carries. See the AI Agent Authorisation Guide.
Score blast radius: impact is the worst thing the agent's credentials allow, not the worst thing it is instructed to do. The PocketOS database deletion happened because an over-privileged token let a coding agent wipe production.
Treat approvals as controls to test: human approval for irreversible or external actions, enforced by permissions rather than instructions; the Replit agent ignored a code freeze stated in its instructions.
Assess memory and delegation: persistent memory and agent-to-agent calls carry poisoned context and authority across sessions and systems. See the AI Agent Threat Modelling Guide.
Give each agent an owner and an identity: unique, scoped, short-lived credentials make the risk measurable and revocable. See the Agentic AI Identity Guide.

Monitoring and reassessment

NIST MEASURE 3.1 asks you to track existing, unanticipated and emergent risks from deployed performance, and MEASURE 3.3 for feedback and appeal channels. M-25-21 requires reassessment after significant modifications, and Article 27 requires a deployer to update a FRIA when an element has changed. Define triggers in the assessment record:

Change triggers: new model or version (including provider-initiated updates), new fine-tune, new retrieval source, new tool or wider scopes, new user group or market, new purpose.
Signal triggers: a metric crosses its threshold, a serious incident or near miss, a rise in complaints or appeals, a red team finding rated high.
Time trigger: annual reassessment for high tier, every two years for elevated, at register review for standard.

Metrics that show the process is working:

Assessment coverage: production AI use cases with a current assessment at the right tier; target 100% for high and elevated.
Assessment currency: high-tier assessments reviewed within 12 months or since the last change trigger.
Accepted risk past expiry: residual risk acceptances past their review date; target zero.
Agents with shared or unscoped credentials: target zero.
Post-deployment surprises: incidents or high findings in categories the assessment rated low; a rising count means scoring is miscalibrated.
Cycle time by tier: median days from intake to decision; long waits drive shadow AI.

Framework mapping

Assessment step	NIST AI RMF	ISO/IEC 42001 / 23894	EU AI Act	NIST CSF 2.0 / SP 800-53
Risk tolerance and scales	MAP 1.5, GOVERN 1.3	42001 6.1.1; 23894 risk criteria	Article 9(5) acceptable residual risk	GV.RM; PM-9
Scoping and context	MAP 1.1, 3.3	42001 4.1, 6.1.4	Article 27(1)(a) to (c)	ID.AM; RA-2
Risk identification and scoring	MAP 4.1, 5.1	42001 6.1.2; 23894	Article 9(2)	ID.RA; RA-3
Testing and evidence	MEASURE 2.3, 2.6, 2.7, 2.11	42001 Annex A.6	Article 9(6) to (8)	ID.RA; CA-2, CA-8
Treatment and acceptance	MANAGE 1.3	42001 6.1.3	Article 9(5)	ID.RA-06; PM-9
Impact on people	MAP 5.1	42001 6.1.4, Annex A.5; 42005	Article 27 FRIA	Not covered
Monitoring and reassessment	MEASURE 3.1, 3.3; MANAGE 4.1	42001 9.1	Articles 9(2)(c), 27(2)	DE.CM; CA-7

Common failure patterns

Assessing the vendor, not the use: a supplier questionnaire stands in for the assessment, so the data reached and decisions influenced in your context are never examined. The Vercel Context.ai OAuth breach came through a third-party AI app's stolen token.
Everything is medium: averaged scores across categories hide a single severe risk; use the highest residual score to set the tier.
Ignoring output reliance: nobody assessed what happens when a customer acts on a wrong answer, as in the Air Canada chatbot ruling.
Agents assessed as chatbots: the assessment covers content risks and never lists the actions the agent can take, as with the Meta AI support assistant that sent recovery links to attackers.
No reassessment trigger: a use case approved as read-only later gains tools or a new data source with no new review.
Unowned acceptance: residual risk "accepted by the project" with no named person, expiry or independent review.

Practitioner checklist

Choose one core method (NIST AI RMF or ISO/IEC 23894 with 42001) and map DPIA, FRIA and sector requirements to it.
Define likelihood and impact scales, AI modifiers, tier thresholds and a stop line, approved by the risk committee.
Use a screening form so low-risk use cases get a register entry, not a full assessment.
Scope every assessment by decision, model, data, users, autonomy, tools and legal triggers.
Write risks as cause, event and consequence across all eight categories, including agentic and third party.
Score inherent and residual risk; set the tier from the highest residual score.
Require independent review and a named, signed risk acceptance with an expiry date for elevated and high tiers.
Record the identity, scopes and reversibility of every tool an agent can call.
Keep model or system cards and test evidence with a versioned assessment record.
Define change, signal and time triggers for reassessment and track them.

AI Risk Assessment Guide