AI Risk Assessment Template: Questionnaire, Scoring and Checklist Mapped to NIST AI RMF and the EU AI Act

What the template covers and how it maps to NIST AI RMF and ISO/IEC 42001

Run one assessment per AI system, or per use case when a single model serves several purposes. Do it before you buy or build, again before go-live, and whenever something material changes. Keep it short enough that the product owner can write the first draft and reviewers from security, privacy and legal can check it in one sitting.

Read the table as a routing aid. NIST AI RMF is voluntary, ISO/IEC 42001 is certifiable against its own clauses, and the AI Act binds only the roles and systems it names. NIST’s AI RMF page says version 1.0 is being revised as part of the White House AI Action Plan, so confirm subcategory numbers before you quote them in an audit (verified October 2026). For a fuller crosswalk of NIST AI RMF, ISO/IEC 42001 and the EU AI Act, see our framework resource.

The scoring method further down follows ISO/IEC 23894:2023, which applies the ISO 31000 process of identifying, analysing, evaluating and treating risk to AI. ISO/IEC 42001 clause 6.1.2 asks for risk criteria that give consistent, repeatable results, and clause 6.1.4 asks for a separate look at consequences for individuals, groups and society, for which ISO/IEC 42005:2025 now gives guidance. If you are the provider of a high-risk system, treat this template as the first input to the Article 9 risk management system, which has to run across the whole lifecycle.

The AI risk assessment template

Copy each block into a document, your GRC tool or a spreadsheet; one row per numbered field turns it into an Excel workbook. Replace the bracketed placeholders. This is a working draft for your risk, security, privacy and legal reviewers, not legal advice.

1. System description

1. SYSTEM DESCRIPTION

1.1 System name and inventory ID:  [name] / [ID]
1.2 Business owner (accountable):  [name, role]
1.3 Technical owner:               [name, role]
1.4 Our role under the EU AI Act:
    [ ] Provider: we develop it, or put it into service under
        our own name or trademark
    [ ] Deployer: we use a system supplied by someone else
    [ ] Both
1.5 What it does, in two or three plain sentences: [...]
1.6 Components: model(s) and version, where they run, data
    sources and retrieval indexes, tools or APIs it can call,
    user interfaces.
1.7 Users: [teams, approximate number, internal or external]
1.8 Status: [ ] idea [ ] pilot [ ] production
    Planned go-live: [date]

2. Intended purpose and context of use

2. INTENDED PURPOSE AND CONTEXT OF USE

2.1 Intended purpose: the task, decision or output the system
    supports, and who acts on the result.
2.2 Excluded uses: what the system must not be used for.
2.3 People affected: customers, employees, patients,
    applicants, the public. Name any vulnerable groups.
2.4 Weight of the output:
    [ ] informs a person   [ ] recommends to a person
    [ ] decides without review   [ ] acts in other systems
2.5 Laws, contracts and policies that apply:
    [e.g. GDPR, sector rules, client contracts, AI use policy]
2.6 Risk tolerance agreed for this use: [low/moderate/high],
    set by [name, role].

3. EU AI Act risk classification

3. EU AI ACT RISK CLASSIFICATION

3.1 Prohibited practices (Article 5, applicable since
    2 February 2025). Does the system involve:
    - manipulative or deceptive techniques causing
      significant harm, or exploiting vulnerabilities due to
      age, disability or social or economic situation;
    - social scoring;
    - predicting criminal offences from profiling alone;
    - untargeted scraping of facial images;
    - emotion recognition at work or in education, other than
      for medical or safety reasons;
    - biometric categorisation inferring race, political
      opinions, trade union membership, religion, sex life or
      sexual orientation;
    - real-time remote biometric identification in public
      spaces for law enforcement;
    - from 2 December 2026, generating non-consensual intimate
      imagery or child sexual abuse material?
    [ ] No   [ ] Yes -> stop and escalate
3.2 High-risk through Annex I: is the system a product, or a
    safety component of a product, under legislation listed in
    Annex I that requires third-party conformity assessment?
    [ ] No   [ ] Yes -> obligations from 2 August 2028
3.3 High-risk through Annex III: biometrics; critical
    infrastructure; education; employment; access to essential
    services (benefits, credit scoring, life and health
    insurance pricing, emergency triage); law enforcement;
    migration; justice and democratic processes.
    [ ] No   [ ] Yes -> obligations from 2 December 2027
    If yes: does an Article 6(3) exception apply? Does the
    system profile people (then it stays high-risk)? Record
    the reasoning.
3.4 Transparency (Article 50, applicable since 2 August 2026):
    does it interact with people, generate synthetic content,
    recognise emotions or produce deepfakes?  [ ] No  [ ] Yes
3.5 Result: [ ] Prohibited  [ ] High-risk
    [ ] Transparency duties only  [ ] Minimal risk
    Classified by: [name, date]

The dates in 3.2 and 3.3 are those set by the Digital Omnibus on AI, Regulation (EU) 2026/1744; our EU AI Act timeline lists the rest.

4. Data, privacy and DPIA screening

4. DATA, PRIVACY AND DPIA SCREENING

4.1 Data the system receives: [prompts, files, retrieved
    documents, conversation history, records from systems]
4.2 Personal data involved?  [ ] No  [ ] Yes: [categories]
4.3 Special-category data (health, genetic, biometric,
    ethnic origin, religion, political opinions, trade union
    membership, sex life or orientation) or criminal data?
    [ ] No  [ ] Yes
4.4 Lawful basis and purpose, as recorded in the record of
    processing activities: [reference]
4.5 Where data is processed and stored, including the
    vendor's sub-processors and regions: [...]
4.6 Retention of prompts, outputs and logs, and who can read
    them: [period, roles]
4.7 DPIA screening (WP248 criteria). Tick all that apply:
    [ ] evaluation or scoring of people
    [ ] automated decisions with legal or similar effects
    [ ] systematic monitoring
    [ ] sensitive or highly personal data
    [ ] large-scale processing
    [ ] matching or combining datasets
    [ ] vulnerable data subjects (employees, patients, children)
    [ ] innovative use of technology
    [ ] processing that blocks a right, a service or a contract
    Two or more ticks: plan a DPIA before processing starts.
    One tick can still need one; check your supervisory
    authority's list.
4.8 DPIA reference, or the reason none is needed: [...]

For the questions to put to the provider of the tool itself, use our GDPR questions for AI vendors.

5. Model and vendor risk

5. MODEL AND VENDOR RISK

5.1 Model(s): name, version, provider, licence; open-weight
    or hosted API.
5.2 Change control: who can change the model or its system
    prompt, and how we hear about it before users do.
5.3 Training on our data: does the vendor use prompts, files,
    outputs or feedback to train or improve models?
    [ ] No, stated in the contract  [ ] Opt-out  [ ] Yes
5.4 Where inference runs and which sub-processors see data.
5.5 Evidence received: vendor questionnaire (below), security
    reports with their scope, data processing agreement, and
    for high-risk systems the instructions for use.
5.6 Exit: can we switch model or vendor without rebuilding?
    How is our data returned and deleted?
5.7 Open-source components, model files and their licences.

6. Security: prompt injection, data leakage and agent actions

6. SECURITY

6.1 Prompt injection, direct and indirect: can text in user
    input, retrieved documents, web pages, emails or tool
    results override the system's instructions?
    Controls: [...]
6.2 Sensitive information disclosure: can a user obtain data
    they are not entitled to see through answers, citations
    or the system prompt?  Controls: [...]
6.3 Excessive agency: list each tool and action, the
    permission it runs with, and which actions wait for a
    person's approval.  [...]
6.4 Output handling: is output passed to other systems (code,
    SQL, HTML, emails) without validation?  [...]
6.5 Data and model poisoning: who can change training,
    fine-tuning or retrieval data?  [...]
6.6 Supply chain: where model files, plug-ins and packages
    come from, and how they are verified.  [...]
6.7 Unbounded use: rate limits, quotas, cost alerts.  [...]
6.8 Red-team or penetration test:  [ ] Not yet
    [ ] Done on [date]; findings: [reference]

Items 6.1 to 6.7 follow the OWASP Top 10 for LLM Applications 2025, where prompt injection is LLM01, sensitive information disclosure LLM02 and excessive agency LLM06 (verified October 2026). NIST AI 600-1 describes the indirect form, in which instructions arrive inside content the system retrieves rather than from the user.

7. Human oversight

7. HUMAN OVERSIGHT

7.1 Who reviews output before it is used, and at which step:
    [role, step]
7.2 What the reviewer sees: sources, input data, warnings,
    the reasons given for the output.
7.3 Can the reviewer correct, override or stop the system?
    [ ] Yes, how: [...]  [ ] No -> explain why that is safe
7.4 Reviewer competence, training and authority: [...]
7.5 Decisions about people: is any decision with legal or
    similarly significant effects made without meaningful
    human involvement?  [ ] No  [ ] Yes -> GDPR Article 22
7.6 Automation bias: how reviewers are kept from approving by
    habit (sampling, second review, override statistics).

8. Testing and monitoring

8. TESTING AND MONITORING

8.1 Acceptance tests before go-live: task accuracy on [n]
    labelled cases; groundedness of answers; refusals; bias
    checks across [groups]; the security tests in section 6.
    Thresholds: [...]   Results: [reference]
8.2 Production monitoring: quality metrics, sampled reviews,
    user feedback channel, drift checks, cost and latency.
8.3 Logs: what is recorded (prompts, sources, tool calls,
    outputs, approvals), where, for how long, who can read
    them. Deployers of high-risk systems keep the system's
    logs for at least six months.
8.4 Re-assessment triggers: new model version, new data
    source, new tool or permission, new user group, vendor or
    sub-processor change, serious incident.
8.5 Incident route: who is told, how fast, and who can
    suspend or switch off the system: [...]

9. Residual risk and sign-off

9. RESIDUAL RISK AND SIGN-OFF

9.1 Risks scored: [n]. Highest inherent score: [ ]
    Highest residual score: [ ]
9.2 Residual risks accepted, with reasons: [...]
9.3 Conditions: [e.g. pilot limited to 50 users; no external
    use until test 8.1 passes]
9.4 Decision: [ ] Approved  [ ] Approved with conditions
    [ ] Rejected  [ ] Escalated to [committee]
9.5 Signed: business owner [name, date]; risk or compliance
    [name, date]; security [name, date]; privacy or DPO
    [name, date]
9.6 Next review due: [date, no later than 12 months]

Scoring AI risks by likelihood and impact

NIST asks for the likelihood and magnitude of each identified impact (MAP 5.1) and for treatment to be prioritised by impact and likelihood (MANAGE 1.2). A five-point scale for each, multiplied together, does both on one page. Score every risk twice: inherent, before controls, and residual, with only the controls that are already working.

Bands for the product: 1 to 4 low, accept and monitor; 5 to 9 medium, treat within an agreed period or accept with the owner’s signature; 10 to 14 high, treat before go-live or accept only at senior level; 15 to 25 critical, no go-live until the score comes down. Add one override: an impact of 5 on health, safety or fundamental rights is rated at least high, however unlikely. The responses NIST lists under MANAGE 1.3 are to mitigate, transfer, avoid or accept.

RISK REGISTER ENTRY (worked example)

ID:        R-07            Template section: 6 Security
Risk:      Indirect prompt injection in a retrieved document
           makes the assistant reveal a confidential file to a
           user who has no access to it.
Inherent:  Likelihood 4 x Impact 4 = 16 (critical)
Controls:  Retrieval limited to documents the user can already
           open; no outbound email or web tools; answers cite
           their sources; injection cases in the release tests.
Residual:  Likelihood 2 x Impact 3 = 6 (medium)
Response:  Mitigate, then accept the residual risk
Owner:     [head of knowledge management]   Review: [date]

The numbers in the example show the method; they are not a benchmark for any product.

AI vendor risk assessment questionnaire

Send this to every vendor whose model, platform or embedded AI feature will touch your data, and ask for evidence such as contract clauses, reports and documents rather than yes or no answers. Organisations under NIS2 carry supplier security as part of their own duties; our guide to NIS2 duties for AI systems and vendors covers that angle. Implementing Regulation (EU) 2024/2690 tells cloud, data-centre, managed service and other digital providers what their supplier contracts should specify where appropriate, including incident notification, audit rights, vulnerability handling, subcontracting and exit terms, and the list is a sound model for any AI contract.

AI VENDOR RISK QUESTIONNAIRE

A. Data use and retention
A1  Do you use our prompts, files, outputs or feedback to
    train or improve any model? Where does the contract say so?
A2  How long do you keep prompts, outputs, files and logs, and
    can we shorten that period?
A3  Which sub-processors and model providers receive our data,
    in which countries, and how are we told about changes?

B. Hosting and access
B4  Where does inference run? Can processing be limited to a
    region, our cloud tenancy or our own data centre?
B5  Which of your staff can reach our data, with whose
    approval, and is that access logged?
B6  How is our data separated from other customers' data?

C. Model provenance and change
C7  Which models power the service, who trained them, and
    under which licence?
C8  How much notice do we get before a model or system prompt
    change reaches our users? Can we pin a version?
C9  Which evaluation results can you share for our use case:
    accuracy, bias, robustness, safety?

D. Security
D10 How do you test for prompt injection, data leakage and
    unsafe tool use? Please share the latest summary.
D11 Which independent security reports or certifications cover
    this service, and what exactly is in their scope?
D12 How do you handle and disclose vulnerabilities?

E. Logging and control
E13 Can we export logs of prompts, sources, tool calls,
    outputs and admin actions to our own systems?
E14 Which actions can the service take in our other systems,
    and can we require a person's approval for them?

F. Regulation
F15 What is your role under the EU AI Act for this service:
    provider of an AI system, provider of a general-purpose AI
    model, or neither? Is it high-risk in our intended use?
F16 If it is high-risk: will you supply instructions for use
    and support our oversight, logging and incident duties?
F17 How do you meet the Article 50 disclosure and marking
    duties that apply to this service?
F18 Will you sign our data processing agreement and, where
    NIS2 or DORA applies to us, our supplier security clauses?

G. Incidents and exit
G19 How quickly will you tell us about a security incident or
    a serious AI incident affecting our data or users?
G20 At the end of the contract, how is our data returned and
    deleted, and how do you confirm it?

For contract wording, the European Commission’s public procurement community publishes model contractual clauses for AI, the MCC-AI, in a full version for high-risk systems and a light version for other systems. They are written for public buyers but read well as a checklist for private ones.

AI risk assessment checklist

• The system is in the AI inventory with a business owner and a technical owner
• Intended purpose, excluded uses and affected people are written down
• The EU AI Act class is decided and the reasoning recorded (Article 5, Annex I, Annex III, Article 50)
• Your role as provider, deployer or both is confirmed
• DPIA screening is done, and a DPIA completed where the screening calls for one
• The vendor questionnaire is back with evidence, and the contract covers training use, retention, sub-processors and incident notice
• Prompt injection, data leakage and tool-permission tests have been run
• A human review point is defined, and reviewers are trained and able to override or stop the system
• Acceptance thresholds are set and met
• Logging, log retention and production monitoring are in place
• Every risk has an inherent score, a residual score and an owner
• Residual risk is accepted by someone with the authority to accept it
• Re-assessment triggers and the next review date are set

When to run the assessment and who signs it

1. Screen at intake. Sections 1 to 3 take half an hour and stop prohibited ideas early. They also route high-risk cases to a fuller review.
2. Assess before purchase or build. Complete sections 4 to 6 and send the vendor questionnaire while you still have negotiating leverage.
3. Check before go-live. Sections 7 to 9 need test evidence, not intentions.
4. Re-assess on every trigger in 8.4, after a serious incident, and at least once a year.
5. Keep every signed version. Each one is evidence for internal audit, the data protection officer and, for high-risk systems, the market surveillance authority.

The business owner is accountable and signs first; risk or compliance, security and privacy co-sign. Anything still high or critical after treatment goes to the AI governance committee. If the rules for everyday staff use are still missing, pair the assessment with an AI acceptable use policy template that says which tools people may use and with what data.

Draft it with your own details

The AI risk management agent maintains the register behind section 9: it proposes risks from incidents, audit findings and assessments as they arrive, scores them with the likelihood and impact scales you configure, and tracks each mitigation and owner. The AI risk classification agent works through Article 6 and Annex III for section 3 and records the rationale, and the AI vendor risk agent reads questionnaire answers and certificates against your criteria and reports missing evidence as a finding. All three run on infrastructure you control.

How VDF AI fits

An assessment is only as convincing as the controls it can point to. VDF AI runs assistants and agents inside your own infrastructure, on-premises, in a private cloud or air-gapped, with network egress that can be switched off, so the answers to fields 4.5, 5.4 and B4 describe your data centre rather than a vendor’s list of regions.

Role-based access control is included on every plan, and tools are granted to roles through an administrator-governed MCP registry, which gives field 6.3 a precise answer. Agent steps with consequences can wait at a human approval gate, and VDF AI Router keeps each workload on the models you have approved. Every prompt, retrieval, model route, tool call, response and approval is recorded with the actor and time and can stream to your SIEM, which is the evidence sections 8 and 9 ask for. The assessment and its sign-off stay yours.

Sources

• NIST, AI Risk Management Framework page
• NIST AI 100-1, AI RMF 1.0
• NIST AI 600-1, Generative AI Profile
• ISO/IEC 42001:2023, AI management systems
• ISO/IEC 23894:2023, AI risk management guidance
• ISO/IEC 42005:2025, AI system impact assessment
• AI Act, Regulation (EU) 2024/1689, on EUR-Lex
• Digital Omnibus on AI, Regulation (EU) 2026/1744
• GDPR, Regulation (EU) 2016/679
• WP248 rev.01 DPIA guidelines, endorsed by the EDPB
• OWASP Top 10 for LLM Applications 2025
• Implementing Regulation (EU) 2024/2690 under NIS2
• EU model contractual clauses for AI procurement