This article provides a practical template and explains how to use it. The assessment form and any rating approach are editorial syntheses requiring local risk appetite and approval authority.
| Stage | Question | Owner | Evidence | Output |
|---|---|---|---|---|
| Scope | What is the exact system and proposed use? | Use-case owner | Request, system description | Defined scope |
| Context | Who is affected, what data is involved, what is the provider? | Use-case owner | Data map, provider info | Context record |
| Risk identification | What are the plausible harms? | Risk owner, use-case owner | Risk register, scenario analysis | Identified risks |
| Inherent rating | How severe is the risk before additional controls? | Risk owner | Impact and likelihood assessment | Inherent risk rating |
| Control selection | What controls will reduce the risk? | Technical owner, control owner | Control specifications | Selected controls |
| Control implementation | Have the controls been put in place? | Technical owner, control owner | Configuration, procedure, implementation record | Implemented controls |
| Residual rating | What risk remains after specified controls? | Risk owner | Implementation and operating evidence, testing | Actual or clearly labelled expected residual risk |
| Decision | Should the use proceed, with conditions, or be declined? | Approval authority | Assessment record, conditions | Decision record |
| Conditions | What must be true for the use to remain approved? | Approval authority | Condition list, owners | Conditions register |
| Monitoring | Is the use staying within its approved conditions, and what outcomes are occurring? | Governance coordinator | Monitoring plan, metrics, incidents | Monitoring record |
What is an AI risk assessment?
An AI risk assessment is a structured record that supports a decision about a specific AI use case or system. It captures:
- The exact system or service and proposed use.
- Intended users, affected people and the human role.
- Information and document inputs, outputs and data flows.
- Provider, integrations and third-party dependencies.
- Plausible accuracy, bias, rights, safety, security, privacy, misuse and operational harms relevant to context.
- Inherent risk before additional controls.
- Controls, owners and supporting evidence.
- Residual risk after those controls.
- The decision, accountable authority, conditions and exception path.
- Monitoring metrics, incidents and change-based reassessment triggers.
The NIST AI Risk Management Framework 1.0 is a voluntary framework intended to help organisations manage AI risks. NIST says version 1.0 is under revision. The assessment should be contextual: the same use may carry different risks in different organisations.
Place the assessment inside the organisation's AI governance framework so its owner, decision and evidence feed the wider operating model.
When an AI risk assessment is needed
Define a triage rule that sends new or materially changed AI uses to the right level of review. A full assessment will not be proportionate for every low-impact experiment, but calling something a pilot should not exempt it when real people, confidential information or operational decisions are involved. The triage decision, its owner and its reasoning should be recorded.
Common assessment or reassessment triggers include:
- A new AI use case is proposed.
- An existing use case changes materially (new data, new users, new provider, new purpose).
- A provider or model changes.
- An incident reveals a gap in the existing assessment.
- A periodic review is due.
- A regulatory or contractual change affects the use.
The ICO's guidance on when a DPIA is needed clarifies that a DPIA is required when processing is likely to result in high risk to people's rights and freedoms. A DPIA addresses data-protection risk and may be one specialist workstream within a broader AI risk assessment. The ICO says this guidance is under review following the Data (Use and Access) Act 2025.
Define the system, use case and decision boundary
Before assessing risk, define:
- The exact system or service (name, version, provider).
- The proposed use (purpose, task, output).
- The intended users and affected people.
- The data and document inputs and outputs.
- The provider and any integrations or dependencies.
- The decision boundary: what is in scope for this assessment and what is not.
A clear scope prevents the assessment from becoming a generic "AI risk" document. It should be specific enough that the decision it supports is actionable.
A useful boundary can be written in one sentence: “[Named team] will use [named service and version] to [defined task], using [information classes], producing [output] for [user], with [human role].” Then list exclusions. If the service, purpose, information or affected group changes, the owner can see that the original decision may no longer apply.
Copy-and-adapt AI risk assessment template
The following template is an editorial synthesis requiring local adaptation. It is not an official regulator or standards body document.
Request and ownership
- Requested by: [name, role, date]
- Use-case owner: [name, role]
- Risk owner: [name, role]
- Approval authority: [name, role]
- Date of assessment: [date]
- Review due: [date or trigger]
Intended purpose and users
- Purpose: [describe the specific task or decision]
- Intended users: [who will use the output]
- Affected people: [who may be impacted by the output or decision]
- Human role: [what human oversight is provided]
People and rights
- What rights or interests of affected people are engaged?
- What is the potential impact on those rights?
- What safeguards are in place?
Data and document inputs
- What data enters the system?
- What is the classification of that data?
- What is the minimum necessary?
- What documents are uploaded or processed?
- What is the data flow (input, processing, output, storage)?
Model, provider and integrations
- What model or service is used?
- Who is the provider?
- What are the provider's data handling terms?
- What integrations or dependencies exist?
- What are the provider's limitations and failure modes?
To separate supplier diligence from use-case risk, see the AI vendor risk assessment checklist.
Accuracy, robustness and misuse
- What is the expected accuracy for the intended use?
- What are the known limitations?
- What are the plausible failure modes?
- What is the potential for misuse?
- What is the impact of an error?
For each plausible failure, describe the chain from system behaviour to a real effect. “The output may be inaccurate” is too vague to control. Record which part could be wrong, who might rely on it, what consequence could follow, and how the error could be detected before that point.
Security and third-party content
- What security controls apply to the system?
- What is the risk of unauthorised access?
- What is the risk of third-party content in the output?
- What is the risk of prompt injection or similar attacks?
Transparency and human oversight
- Is the use disclosed to affected people?
- What level of human review is provided?
- Can a human override or correct the output?
- What records are kept of the use and review?
Inherent risk
Rate the risk before additional controls. Use your organisation's defined scale. A simple qualitative approach:
- Impact: [low / moderate / high / critical]
- Likelihood: [unlikely / possible / likely / almost certain]
- Inherent risk: [combine using your organisation's matrix]
This is an illustrative approach. Your organisation must define its own scale, criteria and combination method. A numeric total does not make the approval decision.
Controls and evidence
For each identified risk, record:
- The control selected.
- The owner of the control.
- The evidence that the control is implemented.
- The evidence that the control operates as intended.
- The date of last test or review.
The NIST AI RMF Core supports documented requirements, risk tolerance, defined roles and third-party risk work. Controls should be proportionate to the risk and supported by evidence.
Residual risk
Rate residual risk after specified controls. Record whether each control is implemented and evidenced; if it is not, label the rating as expected and make implementation a precondition. Use the same scale as inherent risk.
- Impact after controls: [low / moderate / high / critical]
- Likelihood after controls: [unlikely / possible / likely / almost certain]
- Residual risk: [combine using your organisation's matrix]
Decision, conditions and review trigger
- Decision: [approve / approve with conditions / redesign / decline]
- Decision made by: [name, role, date]
- Conditions: [list any conditions attached to approval]
- Condition owners: [name each owner]
- Review trigger: [what event or interval requires reassessment]
How to rate risk without false precision
A risk rating is a structured judgement, even when a matrix is used to combine impact and likelihood. A simple matrix can help structure the conversation, but it should not create false precision. Key principles:
- Define your scale and criteria before rating.
- Use the same scale for inherent and residual risk.
- Document the reasoning, evidence and uncertainty, not just the score.
- A low score does not make the use safe or approved. It records the assessors' judgement against the chosen scale.
- A high score does not determine the decision by itself; it may prompt redesign, enhanced controls, senior approval or a decision to decline.
- The approval decision is made by a named authority, not by the score.
The ISO/IEC 23894:2023 guidance standard supports integrating AI-related risk management into organisational activity and tailoring it to context. It is guidance, not legislation or guaranteed compliance.
Choosing controls and recording evidence
Controls should be selected based on the risk they address. Common control categories:
- Technical: access controls, data minimisation, output filtering, logging, monitoring.
- Organisational: training, procedures, approval gates, review requirements.
- Contractual: provider terms, data processing agreements, incident notification.
- Human: review, verification, override, escalation.
For each control, record: what it is, who owns it, when it was implemented, and what evidence shows it operates. The NIST AI RMF Playbook provides suggested implementation actions and documentation for RMF outcomes. It is a living, voluntary resource.
Keep selection, implementation and operation distinct. “A reviewer will check every external answer” is a selected control. A configured workflow and named reviewer show implementation. A sample of completed reviews, exceptions and corrections provides evidence about operation. Outcome monitoring then asks whether harmful errors still reach users. None of those records proves the next stage by itself.
For a harmless example, imagine a tool that extracts dates from public policy documents. The risk record could name missed dates as the failure, delayed internal action as the consequence, source comparison as the control, sampled review records as operating evidence and detected misses as an outcome measure. The same structure can be adapted to more consequential uses with the relevant specialists involved.
Approve, approve with conditions, redesign or decline
The decision is made by the named approval authority, not by the risk score. The options are:
- Approve: the use may proceed as described.
- Approve with conditions: the use may proceed if specific conditions are met.
- Redesign: the use should be modified to reduce risk before reassessment.
- Decline: the use should not proceed.
The AI governance policy should name the approval authority and escalation path.
The decision and its reasoning should be recorded. Conditions should have named owners, evidence requirements and review dates. Mark which conditions are preconditions that must be verified before work starts and which are ongoing obligations. “Approve with conditions” should not become informal permission to implement the controls later.
Monitoring and reassessment
An assessment is not a one-time event. Monitoring should track:
- Whether controls are operating as intended.
- Whether outcomes are on track.
- Whether new risks are emerging.
- Whether the use has changed materially.
Choose signals that connect to the risks in the record. Depending on the use, that might include sampled error rates, overrides, complaints, incident reports, access exceptions or missed review steps. Define who receives each signal and what level triggers investigation, suspension or reassessment. These are local decisions; the template does not provide a universal threshold.
Reassessment triggers should include: material change in the use, provider or model; incident; periodic review; regulatory change; or audit finding.
The DSIT Introduction to AI Assurance distinguishes assessment, audit, conformity assessment and verification as distinct assurance techniques. It was published in February 2024 and is guidance, not law.
Document-level checks inside an approved use case
Within an approved use case, a document-level check can serve as one control. It provides evidence about a specific document version before it enters the AI workflow. This is a narrow, technical control that supports the wider assessment.
.mdSiren is a document security workspace for AI, coming soon. Its Standard Scan will check the exact document version before AI use, route that version to Approved, Needs review or Quarantine, and keep Approved versions in a private Library for dependable reuse. That document decision is limited to the reported checks and scan policy in force; it does not complete the use-case assessment, assign inherent or residual risk, approve the use, validate the provider, prevent an outcome or cover every document risk.
Where prompt injection is in scope, check a document for prompt-injection signals as one separate technical control.
For examples of where that control may fit, see document-focused AI use cases.
Frequently asked questions
What should an AI risk assessment include?
A practical assessment will usually include the exact system and use, affected people, data and document inputs, provider and dependencies, plausible harms, inherent risk, controls and evidence, residual risk, decision, conditions and review triggers. The specific content depends on your organisation's context and risk appetite.
Is it the same as a DPIA?
No. The ICO explains when a data protection impact assessment is required for likely high-risk processing. A DPIA addresses data-protection risk, while an AI risk assessment is broader: it can cover accuracy, bias, safety, security, privacy, misuse and operational harms. A DPIA may be one specialist workstream within a broader AI risk assessment. The ICO says this guidance is under review following the Data (Use and Access) Act 2025.
Who should approve an AI risk assessment?
The approval authority is defined by your organisation's governance policy. It may be a use-case owner, risk owner or executive, depending on the risk tier and delegated authority. A governance coordinator should approve only where that authority has been explicitly delegated; maintaining the assessment process does not itself confer authority to accept risk. The key is that the authority is named and the decision is recorded.
How do inherent and residual risk differ?
Inherent risk is the assessed risk before additional controls. Residual risk is the assessed risk after specified controls are implemented. The change records the expected effect of those controls; evidence and monitoring are still needed to see whether they operate and what outcomes occur. Both ratings should use the same locally defined scale.
When should an assessment be repeated?
An assessment should be repeated when: the use changes materially, the provider or model changes, an incident occurs, a periodic review is due, or a regulatory or contractual change affects the use. The specific triggers are defined in your governance policy.
