AI Project Risk Register Template: 15 Fields That Support a Decision

Download the record and define what belongs in it

Download the editable 15-group risk record and the six-case worked example packet. Both are plain-text Markdown files: copy the sections into an approved document, work-management system or spreadsheet. They are not Excel workbooks and contain no scoring macros. Each numbered group can become several database fields; fifteen groups does not mean forcing evidence, owner and deadline into one cell.

Before entering risks, write a register-level agreement: pilot boundary, allowed actions, affected users, assessment horizon, evidence location, scoring-policy version, acceptance authority and review triggers. Our fictional example covers an internal support-assistant pilot through January 31, 2026. Its reporting snapshot is January 15 at 00:00 UTC. These dates illustrate an internally consistent record, not a real OpenMax deployment.

Use the following distinctions to prevent a register from turning into an undifferentiated task list.

One incident can reveal several future risks. Conversely, one risk can need several actions. Preserve those links instead of copying the same risk into a new row for every task. A risk register is a continuing record, not a report that is rebuilt from scratch each week. The NIST risk-register glossary includes both the time dimension and accepted risks in its definitions.

The 15 field groups and how to fill them

1. Stable ID and bounded workflow

Give each risk an enduring ID, a short title and the exact workflow it concerns. Include the system or configuration version when it affects the assessment. “R03: confidential information in assistant prompts, support pilot v0.4” is more useful than “data risk.” A later model or connector change should be visible as a new assessment against the same relevant risk, not an unexplained change in color.

Record exclusions too. A read-only draft assistant and an agent allowed to issue refunds have different exposures. If the pilot excludes refunds, do not imply that an assessment of draft replies approves transaction execution. Expand the boundary explicitly before expanding the authorization.

2. Cause, uncertain event and consequence

Write a complete statement: “Because expired price documents remain retrievable, the assistant may draft an obsolete quote, causing an agent to promise terms the business cannot honor.” The cause suggests possible treatment; the event identifies what to detect; the consequence identifies whose interests are at stake.

Do not collapse several unrelated consequences into “reputational damage.” A misleading support answer, disclosure of personal information and an unauthorized refund may share a model but need different evidence, owners and response decisions. Split records when the decision changes, not merely to make the register longer.

3. Category and affected people

Use a small, documented category set for filtering: information quality, confidentiality, unauthorized action, availability, people and process, or project delivery. Allow a secondary category where it helps. Categories are navigation aids, not substitutes for a risk statement.

Name the affected groups and plausible consequence for each. A delay may be inconvenient to an internal analyst but materially harmful to a customer waiting for an urgent resolution. Do not let a low internal repair cost erase a significant consequence for someone outside the project team.

4. Evidence and source locator

Attach a dated source reference, such as a test result, configuration review, incident record or documented dependency. Identify its version and the relevant passage or result. If a source is unavailable to a reviewer, record that access gap instead of presenting an uncheckable summary as verified fact.

Keep sensitive payloads in the approved restricted repository. The register usually needs a minimal description and an access-controlled evidence ID, not complete prompts containing personal information or secrets. A broken evidence link is a reason to investigate the assessment, not proof that the risk disappeared.

5. Assessment horizon and assumptions

Say what period, volume, users and operating conditions the assessment covers. “During a limited January pilot with internal agents reviewing every draft” is different from unrestricted customer-facing production. Record dependencies such as a maintained knowledge base or an available manual fallback.

Give each material assumption a verification owner and a trigger for reassessment. “No provider changes” is not a permanent fact. If it cannot be established, keep the uncertainty explicit and consider a more constrained decision. Unknown information should not quietly acquire the lowest likelihood value.

6. Hypothetical inherent assessment

If your governance process uses inherent risk, specify which relevant controls the hypothetical baseline excludes. Keep the same consequence and horizon as the current assessment, or explain the change. A label such as “before treatment” is insufficient when access restrictions and human review already exist.

An inherent assessment is an analytical scenario, not a measurement from deliberately removing safeguards. Do not disable a live control to obtain a score. Where your organization does not require this baseline, mark it not assessed with a reason; do not invent a high number solely to make the treatment appear impressive.

7. Controls operating now

List controls already in effect, their responsible parties, coverage and evidence dates. Distinguish a configured permission boundary from a policy that asks users to behave carefully. Both can matter, but they do not fail in the same way.

For each important control, note the condition under which it might stop protecting the workflow. A mandatory approval can lose value if the reviewer cannot see the source or if an alternate route bypasses it. “Human in the loop” is not a sufficient control description without a real decision point and the ability to stop the action.

8. Current likelihood, impact and priority

Assess exposure with the controls that are actually operating. Record the likelihood label, impact label, resulting priority, rationale, assessor, date and scoring-policy version. Treat the confidence in the evidence as separate from the severity of the consequence.

This guide uses a small illustrative lookup policy below. It is not a probability model or a NIST-prescribed scale. If an assessment is missing, use Unassessed. A team may still need to hold the affected capability while investigating; lacking a numeric score is not a reason to ignore a potentially severe event.

9. Response strategy and scope

State the proposed response and what changes in the workflow. Avoiding an exposure might mean removing the transaction capability; mitigation might mean restricting it and testing an approval boundary. Contractual allocation or insurance can change who bears particular costs without eliminating harm to affected users.

Acceptance is a separate authorized decision, not a synonym for having no spare engineering capacity. Explain the remaining exposure and alternatives. Where a response creates another risk—such as a fallback that overloads support staff—add or link that risk rather than reporting an unqualified improvement.

10. Accountable risk owner

Name one accountable person or a role with a designated incumbent, plus an escalation route. A shared department label such as “IT” does not establish who must respond to an overdue review. Confirm that the person has accepted the role and can obtain the relevant evidence.

The risk owner need not perform every action and may not have authority to accept the exposure. Keep those responsibilities distinct. If an owner is missing, make the gap an exception requiring assignment, not a row that disappears from a filtered “my risks” view.

11. Treatment actions, owners and deadlines

Give every action its own ID, deliverable, owner, due date with time-zone convention, status and evidence of completion. “Improve safety” cannot be verified; “remove the expired price collection and attach the retrieval test result” can be reviewed.

Separate completion from effectiveness validation. An action can be completed on time while its control fails a subsequent test. An overdue action remains visible even if the risk was assigned a moderate priority. Do not change the original deadline without preserving the reason and approval for the change.

12. Target assessment after planned treatment

Record the desired assessment and the assumptions needed to achieve it. Label it Target—not Current or Validated. This field helps a reviewer decide whether the proposed work is likely to be sufficient and whether a simpler restriction would be preferable.

A target is conditional on successful implementation and validation. It is not a promised safety outcome, and it should not drive the current-risk dashboard. If a team sets a lower target solely to secure launch approval, the record has concealed the decision rather than supported it.

13. Validation and reassessed residual risk

Record the test conditions, result, limitations, evidence locator and reviewer. Use explicit states such as Not run, Passed within stated scope, Failed or Inconclusive. Only then record a dated reassessment with its rationale; passing one test does not compel a lower rating.

In our R03 example, a completed prompt-filter change still allows a confidential test marker through an alternate input route. Validation failed. The proposed lower target remains a target, and the current High rating stays in place. The evidence supports reopening the treatment, not declaring the control effective.

14. Acceptance authority and conditions

If exposure is accepted, record who decided, their authority, what scope they accepted, why, any restrictions, the effective date and expiry or review condition. Link the decision record. A risk owner proposing acceptance is not evidence that the authorized decision maker approved it.

An accepted risk can remain material. Preserve the current assessment and operational monitoring requirements. If acceptance expires, the record should return for a decision under the organization's policy; the absence of a new comment must not silently renew permission.

15. Status, history and next review

Use status to describe lifecycle, not severity: Active, Accepted with conditions, or Closed for a defined exposure. Keep the next review date, event-driven triggers, previous assessments and reason for each change. An occurrence can be tracked in a linked issue while recurrence risk remains Active.

Closure needs a reason, supporting evidence and an authorized reviewer. Removing an obsolete scheduled export can close the risk tied to that specific job; it does not establish zero data-disclosure risk across the organization. Record what would reopen it, such as reintroducing the job or adding a new export route.

Put the register into operation in five steps

1. Agree the decision boundary before scoring. Record the pilot scope, assessment horizon, policy version and authorities. Ask who can restrict, pause or resume the affected capability. Resolve incompatible scoring definitions before combining records from different teams.
2. Create a small evidence-backed initial set. Review intended behavior, permissions, dependencies, known incidents and affected-user concerns. Treat generated risk suggestions as candidates. Reject irrelevant boilerplate and preserve an Unassessed state where source evidence is missing.
3. Assess current exposure and assign work. Ask the risk owner and relevant specialists to review assumptions and consequence. Define discrete actions, their owners, due dates and validation conditions. Keep target assessments outside the current-risk summary.
4. Validate treatments and record human decisions. Review what was implemented and what the evidence actually demonstrates. Keep failed or inconclusive results visible. Escalate acceptance, exceptions and release decisions through the established authority, with a preserved rationale.
5. Review on both dates and events. Reopen relevant assessments after a model, permission, source-data or workflow change; a failed control; an incident; an owner departure; or an acceptance expiry. Choose routine review intervals for the organization's exposure, not from a universal weekly or quarterly promise.

The NIST AI RMF Core addresses assessment of existing-control effectiveness in MEASURE 1.2 and documented responses and residual risks in MANAGE. It does not prescribe this template or its lookup matrix. Use those source concepts to inform a process reviewed by your organization's qualified risk and domain specialists.

Worked example: six records, three different kinds of progress

All records and evidence IDs in this example are fictional. The pilot team uses demonstration policy v1 for its January pilot; none of these assessments is an OpenMax benchmark or a general recommendation for your organization. The full downloadable packet contains the assumptions, evidence notes and decision history needed to follow the example.

For likelihood, Unlikely means the scenario needs unusual conditions given the current stated controls; Plausible means it has a credible route under the pilot conditions; Expected means the conditions make occurrence likely enough to plan for during the horizon. These are qualitative descriptions, not assigned percentages. Unknown means evidence is insufficient to choose. For impact, Minor means locally reversible inconvenience, Material means meaningful customer or operational harm, and Severe means a consequence requiring specialist escalation under this fictional policy. Your organization must define appropriate boundaries for its own people and use cases.

This lookup deliberately does not multiply ordinal labels. An Unknown input returns Unassessed, never zero. Severe consequences trigger escalation even when likelihood evidence is incomplete. These example priorities route attention; they do not grant approval. Low is not an automatic release, and a High entry must not become Moderate merely because someone changes its label without new evidence.

At the January 15, 00:00 UTC snapshot, all six records remain available. Five represent current exposure: R01 through R05. Four of those five have a current assessment, so assessment coverage is 4/5 = 80%. This is record completeness, not “80% safe.” R06 is retained history and is excluded from this particular current-exposure denominator.

There are two open actions in the example: assignment A01 and source correction A02. One is overdue, so the open-action overdue share is 1/2 = 50%. A03 is completed and therefore excluded from that denominator. It belongs in a different view: one completed treatment action requiring validation, zero with a passing result, or 0/1. A completed-action count alone would conceal the failed safeguard.

R04 is accepted, not closed. Its current assessment remains Moderate and its acceptance remains time-bounded. R05 has a linked issue because the refund event already occurred; resolving that issue would not by itself remove recurrence risk. R06 demonstrates a narrower form of closure: the documented exposure was removed, while related data risks may still exist elsewhere.

Choose manual, rule-based or agent-assisted operation

A small pilot can start with an approved shared record and a named reviewer. This is often preferable when sources are few and changes are infrequent. The weak point is missed follow-up, so establish a review owner and an explicit view of unassigned, overdue and expiring items. More software will not resolve disputed authority.

If the existing work-management system supports required fields, permissions, change history and reminders, configure those features around the agreed process. Verify their behavior with a test record. Check whether an overdue action remains visible after its parent risk is accepted, and whether edits preserve the prior deadline. Do not assume every tool enforces these distinctions.

Use deterministic scripts or rules for mechanical checks: missing owners, invalid dates, expired acceptance, inconsistent IDs and target values copied into current columns. Keep the scoring-policy version explicit. A rule can detect missing evidence; it cannot establish that an unavailable control is effective. Send uncertain cases for review instead of filling them with default Low values.

Agent assistance becomes more relevant when reviewers must collect candidate changes across many approved sources. Start with source-linked proposals and read-only access. Require review before a proposed statement replaces the current record. Monitor fabricated evidence IDs, inferred owners and unrequested changes to ratings. At larger scale, maintain separate authority for acceptance and release, plus change logs, access controls and a tested way to stop updates. These are acceptance criteria for an implementation, not proof that any particular product already satisfies them.

Where OpenMax belongs—and what needs verification

This is OpenMax-authored content. OpenMax presents its product around human–agent collaboration. For this workflow, a useful evaluation is whether agents can prepare evidence-linked updates while people retain assessment and acceptance decisions. That is a proposed application, not a verified claim that OpenMax provides a native risk register, certified risk scoring, automatic project-tool synchronization or regulatory compliance.

Before connecting real project data, ask for a demonstration using the six fictional records. The implementation should preserve R01 as Unassessed, flag A02 as overdue, retain R03's failed validation, keep R04's acceptance expiry, link R05 to its issue, and avoid reopening R06 without a relevant change. Ask who can see restricted evidence, change a rating, approve acceptance and restore an earlier version. Inspect the answers in the proposed configuration rather than assuming them from general product positioning.

Choose the simpler shared-record approach if the team has only a few risks, cannot establish source permissions, or lacks someone authorized to review suggested changes. The next step is to discuss a bounded human–agent workflow with OpenMax using fictional records first—not to authorize an agent to accept risk. Keep acceptance rationale in a decision log, connect realized events to an incident postmortem, and use the project status report as a summary of verified records rather than their replacement.

Limits, sensitive data and review requirements

A risk register is a coordination artifact, not a complete safety assessment or evidence of legal compliance. Its usefulness depends on the scope, evidence, expertise and decisions behind each entry. A well-maintained register can still omit a serious risk. Use relevant domain, security, privacy and legal expertise for consequential deployments; this guide has not received a named independent professional review.

Do not upload confidential prompts, personal information, credentials or incident details merely to populate a table. Establish approved storage, access and retention rules with the responsible teams. Share the minimum evidence necessary for the decision and test access from the intended reviewer's role. A broadly shared register can describe a restricted evidence record without exposing its contents.

The example matrix, dates, thresholds and states are editorial choices for teaching. They are not industry-wide requirements. The NIST AI RMF overview describes voluntary use and, as checked September 4, 2026, says version 1.0 is being revised. Confirm the framework version and applicable organizational or jurisdictional requirements before using this template in a formal process.

Frequently asked questions

Is this an Excel risk register template?

No. The downloads are editable Markdown records and a worked packet, not an XLSX workbook. You can copy the fifteen logical groups into a spreadsheet, but define separate columns for owners, dates, assessment types and validation states. Do not label a target assessment as current merely to simplify the sheet.

Should every AI project use a five-by-five scoring matrix?

No single matrix is suitable for every project. Use a documented organization-approved method that fits the decisions and consequences. This guide's three-by-three example is an explicit lookup, not a probability estimate. Unknown evidence remains Unassessed, and severe consequences need attention even when likelihood cannot be established.

When can residual risk be lower than current risk?

When implemented changes and a documented reassessment support that conclusion for the relevant scope. A completed task or passing narrow test does not automatically justify a decrease. Current risk may already be residual relative to existing controls; keep the assessment date and baseline clear.

Should accepted risks be removed from the register?

No, not while the accepted exposure remains relevant. Preserve the current assessment, authorized decision, conditions, review date and expiry. Acceptance is a governance decision, not elimination of the risk. Closure needs its own reason and evidence.

Can an AI agent maintain the register without human review?

An agent can be evaluated for bounded assistance such as preparing source-linked proposals, but it should not be presumed competent or authorized to assess consequences, accept exposure or approve deployment. Establish and test the review boundary. This page does not verify those capabilities in OpenMax or another product.

Sources and evidence boundaries

Sources checked September 4, 2026: NIST inherent risk, NIST residual risk, NIST risk register, the AI RMF Core and framework overview. Each supports the nearby stated concept, not the validity of this particular register or an endorsement of OpenMax. OpenMax's website is a first-party positioning source, not independent product validation.

The fifteen-group structure, six records, evidence notes, lookup policy and calculations are original teaching material. They are not customer results, an empirical study, an official NIST template or tested OpenMax automation. Before operational use, have accountable specialists approve the scope, rating method, evidence rules and decision authority.