Last updated: September 17, 2026
An AI risk assessment template is a structured worksheet for identifying, scoring, and treating the risks of a specific AI system before and after deployment. The template below is free to copy, needs no form to access, and is built to satisfy the AI risk assessment and AI system impact assessment requirements in ISO 42001 (clauses 6.1.2 and 6.1.4, plus Annex A controls A.5.2 through A.5.5), the Map and Measure functions of the NIST AI RMF, and the risk documentation that regulators and auditors increasingly expect. Complete one assessment per AI system, and revisit it whenever the system, its data, or its use case changes.
This template is part of our AI governance guide. If you need the method behind the worksheet (how to scope a system, choose a scoring scale, and decide what “acceptable risk” means for your organization), read the AI risk assessment guide first, then come back and fill this in.
Key takeaways
- One assessment per AI system, tied to an entry in your AI system inventory. Portfolio-level risk summaries are built from these, not written in place of them.
- Score two things separately: risk to the organization (security, legal, financial, operational) and impact on people and society. ISO 42001 treats these as distinct assessments, and conflating them is the most common audit finding.
- Every risk rated above your tolerance needs a named treatment, a named owner, and a due date. An assessment with no treatment plan is a survey, not a control.
- The template maps to ISO 42001, the NIST AI RMF, and the EU AI Act so one document serves all three. The mapping table at the end shows where each section lands.
- Reassess on a trigger (model change, new data source, new user group, incident) and on a schedule (at least annually for anything rated medium or above).
What should an AI risk assessment cover?
A complete AI risk assessment answers five questions in order. What is the system and what decisions does it touch? Who could be affected and how badly? What could go wrong across data, model, security, legal, and operational dimensions? How likely and how severe is each of those failures? And what are you going to do about the ones that exceed your tolerance? The sections below follow that sequence. Fill in every bracketed field, delete rows that do not apply, and keep the completed document with the inventory record for the system it describes.
AI risk assessment template
Section 1: System identification
| Field | Entry |
|---|---|
| System name and inventory ID | [Name] / [INV-0000] |
| Business owner | [Name, title] |
| Technical owner | [Name, title] |
| Assessment date and version | [Date] / v[1.0] |
| Assessor(s) | [Names and roles] |
| Assessment trigger | [New system / periodic review / material change / incident] |
| Lifecycle stage | [Concept / pilot / production / retirement] |
Section 2: System description and intended use
2.1 Purpose. [Describe the business problem the system solves and the decision or output it produces in two or three sentences.]
2.2 Intended users and deployment context. [Who uses it, in what workflow, and in which jurisdictions.]
2.3 Model and provenance. [Built in-house, fine-tuned from a foundation model, or procured from a vendor. Name the model family and version. If procured, reference the completed vendor questionnaire.]
2.4 Data. [Training data sources and licensing, input data at inference, whether personal data or special categories are processed, retention period.]
2.5 Degree of autonomy. [Advisory only / human-in-the-loop / human-on-the-loop / fully automated. State who can override an output and how.]
2.6 Explicitly out of scope. [Uses the system is not designed or approved for.]
Section 3: Regulatory and classification screen
| Question | Answer | Notes |
|---|---|---|
| Does the system fall under an EU AI Act prohibited practice (Article 5)? | [Yes / No] | [If yes, stop and escalate.] |
| Is the system a high-risk use case under Annex III (employment, credit, education, essential services, law enforcement, and similar) or an Annex I safety component? | [Yes / No / Unclear] | [Cite the Annex III category. See our high-risk categories explainer.] |
| Does the system interact directly with people or generate synthetic content (Article 50 transparency duties)? | [Yes / No] | [Transparency obligations apply from 2 August 2026.] |
| Does the system process personal data (GDPR, CCPA, or sector rules)? | [Yes / No] | [Link the DPIA if one exists.] |
| Does the system make or materially support decisions with legal or similarly significant effects on individuals? | [Yes / No] | [Triggers a full impact assessment in Section 5.] |
| Applicable sector rules (financial services, health, employment law, state AI laws) | [List] | [Owner of regulatory tracking] |
Note on EU AI Act timing: under the Digital Omnibus on AI (Regulation (EU) 2026/1744, in force since 27 July 2026), obligations for stand-alone Annex III high-risk systems now apply from 2 December 2027, and for Annex I embedded systems from 2 August 2028. The obligations themselves did not change, only the enforcement date, so a system flagged as high-risk here should be assessed against Articles 9 through 17 and Article 26 now. Our EU AI Act compliance overview covers what applies when.
Section 4: Risk identification and scoring
Score likelihood and severity on a 1 to 5 scale. Risk score is likelihood multiplied by severity. Suggested bands: 1 to 5 low, 6 to 12 medium, 15 to 25 high. Adjust the bands to your organization’s risk appetite and document that choice.
| ID | Risk category | Risk description | Likelihood (1 to 5) | Severity (1 to 5) | Score | Existing controls |
|---|---|---|---|---|---|---|
| R1 | Data quality and bias | [Training or input data unrepresentative of affected population, leading to disparate outcomes] | [ ] | [ ] | [ ] | [ ] |
| R2 | Accuracy and reliability | [Hallucinated, stale, or incorrect outputs acted upon without verification] | [ ] | [ ] | [ ] | [ ] |
| R3 | Privacy | [Personal data exposed in prompts, outputs, logs, or vendor training] | [ ] | [ ] | [ ] | [ ] |
| R4 | Security | [Prompt injection, data poisoning, model extraction, insecure integrations] | [ ] | [ ] | [ ] | [ ] |
| R5 | Transparency and explainability | [Users or affected individuals cannot understand or contest a decision] | [ ] | [ ] | [ ] | [ ] |
| R6 | Human oversight | [Over-reliance on outputs, no practical override, alert fatigue] | [ ] | [ ] | [ ] | [ ] |
| R7 | Legal and regulatory | [Misclassification under the EU AI Act, IP infringement, contractual breach] | [ ] | [ ] | [ ] | [ ] |
| R8 | Third-party dependency | [Vendor model changes, outages, terms changes, sub-processor risk] | [ ] | [ ] | [ ] | [ ] |
| R9 | Operational and resilience | [Performance drift, missing monitoring, no rollback path] | [ ] | [ ] | [ ] | [ ] |
| R10 | Reputational | [Public harm, offensive outputs, loss of customer trust] | [ ] | [ ] | [ ] | [ ] |
| R11 | [Custom] | [ ] | [ ] | [ ] | [ ] | [ ] |
Section 5: AI system impact assessment (individuals and society)
ISO 42001 clause 6.1.4 and control A.5.2 require an impact assessment that looks outward at people and groups, not just inward at the organization. Complete this section for any system that touches individuals, and for any system rated medium or higher in Section 4.
| Affected group | Potential benefit | Potential harm | Severity | Reversibility | Mitigation |
|---|---|---|---|---|---|
| [End users] | [ ] | [ ] | [Low / Med / High] | [Reversible / Partially / Irreversible] | [ ] |
| [Individuals subject to decisions] | [ ] | [ ] | [ ] | [ ] | [ ] |
| [Vulnerable or protected groups] | [ ] | [ ] | [ ] | [ ] | [ ] |
| [Employees whose work changes] | [ ] | [ ] | [ ] | [ ] | [ ] |
| [Society, environment, market] | [ ] | [ ] | [ ] | [ ] | [ ] |
5.1 Fairness analysis. [Which protected attributes were tested, which metrics were used (for example demographic parity, equalized odds), and the results.]
5.2 Recourse. [How an affected individual learns a decision involved AI, contests it, and reaches a human.]
Section 6: Risk treatment plan
| Risk ID | Treatment option | Specific action | Owner | Due date | Residual score | Status |
|---|---|---|---|---|---|---|
| [R1] | [Mitigate / Transfer / Avoid / Accept] | [ ] | [ ] | [ ] | [ ] | [Open / In progress / Done] |
| [R2] | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] |
| [ ] | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] |
6.1 Accepted risks. [List any risks accepted above tolerance, the business justification, and the name of the executive who signed off. Acceptance without a named approver is not acceptance.]
Section 7: Monitoring and reassessment
7.1 Metrics monitored in production. [Accuracy, drift, fairness metrics, override rate, user complaints, latency. Name the dashboard or report.]
7.2 Reassessment triggers. [Model or version change, new data source, new user population or jurisdiction, incident or near miss, regulatory change, vendor terms change.]
7.3 Scheduled review date. [Date. Annual minimum for medium and above; every six months for high.]
7.4 Incident reporting path. [Who is notified, within what timeframe, and how it links to the corporate incident process.]
Section 8: Approval and sign-off
| Role | Name | Decision | Date |
|---|---|---|---|
| Business owner | [ ] | [Approve / Approve with conditions / Reject] | [ ] |
| AI governance lead or committee | [ ] | [ ] | [ ] |
| Security | [ ] | [ ] | [ ] |
| Privacy or legal | [ ] | [ ] | [ ] |
How does the template map to ISO 42001, NIST AI RMF, and the EU AI Act?
| Template section | ISO 42001 | NIST AI RMF | EU AI Act |
|---|---|---|---|
| 1 to 2: Identification and description | Clause 4.1, A.6.2.3 (documentation), A.4.x (inventory) | MAP 1, MAP 2 | Article 11 (technical documentation), Article 49 (registration) |
| 3: Regulatory screen | Clause 4.2, 6.1.1 | GOVERN 1, MAP 1.1 | Articles 5, 6, Annex III, Article 50 |
| 4: Risk identification and scoring | Clause 6.1.2 (AI risk assessment) | MAP 5, MEASURE 2 | Article 9 (risk management system) |
| 5: Impact assessment | Clause 6.1.4, A.5.2 to A.5.5 | MAP 5.1, MAP 5.2 | Article 27 (fundamental rights impact assessment, where applicable) |
| 6: Risk treatment | Clause 6.1.3 (AI risk treatment), Annex A controls | MANAGE 1, MANAGE 2 | Article 9(4) to 9(5) |
| 7: Monitoring | Clause 9.1, A.6.2.6, A.8.4 | MEASURE 3, MANAGE 4 | Articles 26, 72 (post-market monitoring) |
| 8: Approval | Clause 5.1, 5.3 | GOVERN 2 | Article 26(2) (oversight assignment) |
How do you adapt the template to your organization?
Start with scale. A ten-person company assessing a single customer-support chatbot can compress Sections 4 and 5 into a one-page grid. A bank assessing a credit model needs every row, plus links to model validation reports. The structure stays the same; the depth of each entry changes.
Next, align the scoring scale with the one your enterprise risk function already uses. If your ERM program scores on a 4 by 4 matrix, use that. The point of an AI risk assessment is to let AI risk sit next to cyber, financial, and operational risk in the same register, so leadership sees one picture. A bespoke AI scale that nobody outside the AI team understands defeats that purpose.
Finally, decide where the completed assessment lives. The weakest option is a document folder. The strongest is a system of record where each assessment is linked to the inventory entry, the treatment actions become tracked tasks, and the monitoring metrics in Section 7 are pulled from real telemetry. The AI governance policy template assigns the roles that own this process; this template is the artifact they produce.
What are the common mistakes in AI risk assessments?
The first is assessing the vendor instead of the use. A completed SOC 2 or ISO 27001 report from your AI vendor tells you about their security controls, not about whether your use of their model creates a fairness or accuracy risk for your customers. The second is scoring inherent risk and stopping. Auditors want to see residual risk after treatment, and they want the treatment to be verifiable. The third is treating the assessment as a one-time gate. Models drift, vendors update their models without notice, and a system approved for internal drafting quietly becomes customer-facing. Section 7 exists so the reassessment is scheduled, not remembered.
Frequently asked questions
Is an AI risk assessment the same as an AI impact assessment?
No. A risk assessment (ISO 42001 clause 6.1.2) evaluates risk to the organization from the AI system. An impact assessment (clause 6.1.4) evaluates consequences for individuals, groups, and society. This template includes both because auditors expect both, but they are scored and documented separately.
Do we need a separate assessment for each AI system?
Yes, one per system in your inventory. Systems that share a model but serve different use cases (for example the same LLM used for internal search and for customer email replies) need separate assessments because the risks differ.
Is a DPIA enough for AI systems that process personal data?
A DPIA covers the data protection dimension. It does not address accuracy, bias, security of the model, human oversight, or third-party dependency. Reference the DPIA in Section 3 and complete the rest of this template.
How often should the assessment be repeated?
On every material change and at least annually for systems rated medium or above. High-rated and high-risk (EU AI Act) systems should be reviewed every six months and after any incident.
Does this template satisfy the EU AI Act fundamental rights impact assessment?
Section 5 covers the substance of an Article 27 FRIA, but Article 27 applies only to specific deployers (public bodies and certain private entities providing public services, plus credit and life insurance use cases). If you fall in scope, expand Section 5 with the specific elements Article 27 lists and keep it as a standalone record.
Who should sign off?
At minimum the business owner and the AI governance function. Add security, privacy, and legal for any system that processes personal data, faces customers, or screens as high-risk. Accepted risks above tolerance need an executive signature.
From template to program
A single completed assessment proves you looked. A repeatable process, with every system inventoried, assessed, treated, monitored, and reassessed on schedule, is what an ISO 42001 auditor certifies and what a regulator asks to see. Compyl links each risk assessment to its inventory record, turns treatment actions into tracked tasks with owners and due dates, and collects the evidence for ISO 42001, the NIST AI RMF, and the EU AI Act in one place. Request a demo to see how the assessment, the inventory, and the audit trail fit together.
