Form

Model Risk Incident Report Template

Structured, interactive incident report to document, triage, and track model failures, bias events, or unexpected model behavior. Saves consistent, auditable information (who, what, when, evidence, mitigations, remediation plan, and lessons) to support faster remediation, clear ownership, and durable learning.

Interactive Tool

Model Risk Incident Report

Use this form to capture a consistent, auditable record whenever a model behaves unexpectedly, shows signs of bias, or causes business or customer impact. Provide evidence, initial mitigations, a remediation plan, and the post-incident learning steps. Fields marked required help ensure regulators and auditors can follow the timeline and decisions.

Unique identifier (team may use existing incident number). If you don’t have one, leave blank and the system will generate an ID.
Person who submitted this report.
Format: YYYY-MM-DD HH:MM, e.g. 2026-08-26 14:30. Include timezone if not UTC.
Short, plain-language summary: what happened, when it was first observed, and who noticed it.
Select the primary detection channel.
List model names, IDs, versions, deployment IDs, and locations (prod/staging). Include URLs or pointers to model registry entries if available.
Select the best description of current impact.
Numeric severity to help prioritization.
1.0 10.0
Describe metrics that changed (counts, error rates, bias metrics) and point to dashboards, logs, or example records. Paste key numbers or short JSON snippets if helpful.
URLs to dashboards, logs, model registry entries, dataset snapshots, issue trackers, or evidence files.
What immediate checks were performed? Who was pulled in? Include commands, queries, or scripts used if helpful.
Example: disable feature flag, rollback to prior model, throttle traffic, apply business-rule override. State start time for each mitigation.
A concise hypothesis for why the model failed (data drift, training bug, feature pipeline change, labeling issue, model degradation, external system change, adversarial input, etc.).
How will the hypothesis be tested? List tests, datasets, expected outcomes, and owners.
Select stakeholder groups that have been or should be notified.
Notes on data subject rights, breach-reporting timelines, or contract obligations. Include statutory reporting deadlines if known.
Concrete actions to fix the problem, who will do them, and acceptance criteria.
Estimated days to remediate from now.
Suggested improvements to monitoring, runbooks, testing, deployment controls, or governance that will reduce recurrence.
Person responsible for ensuring PR, playbook, and policy updates are completed.
Yes = evidence is saved to a secure, immutable location; No = not yet preserved.
For example, recall, customer notification, or temporary shutdown.
Restrict sharing if the incident contains sensitive personal data or trade secrets.
Anything else the incident team should know.
You can explore this tool now. Sign in or create an account to save your responses and return to them later.
Sign In to Save Create an Account
Make this tool part of your work

Save a personal copy, bring it to your team, or tailor the questions and workflow to fit what you are hungry to improve.

Member customization and team collaboration are coming soon.
Discuss Ask the Librarian

Discussion

Comments and conversation will live here.