GOVERN 1.3 risk management level: requirements and evidence

What GOVERN 1.3 asks you to decide before you measure any AI system

GOVERN 1.3 asks your organization to put processes, procedures and practices in place that decide how much risk management activity each AI system needs, based on your risk tolerance. If you are a compliance lead or AI risk owner, the test is simple: can you show that a high-impact system receives more scrutiny than a low-impact one, and that the difference traces back to a stated tolerance? NIST does not set that tolerance for you. AI 100-1 Section 1.2.2 says the framework can help you prioritize risk but does not prescribe risk tolerance, which is contextual and can be shaped by legal or regulatory requirements. Where no established guidelines exist, the organization has to define a reasonable tolerance itself. The outcome is a decision record that your organization owns, not a certificate. NIST does not certify, validate or endorse any organization's use of the AI RMF, so no outside body will stamp your tiering as compliant.

The requirement is hard for three common reasons. First, risk tolerance is often unwritten, so teams make tiering calls without a stated boundary to test them against. Second, scales differ between teams: one group rates impact as high, medium or low, another uses a numeric score, and a third uses no scale at all. Third, impact and likelihood are scored inconsistently, so two systems with the same potential harm can land in different tiers. Before you measure anything, confirm that you have a written tolerance statement approved by someone with authority to accept risk, a defined impact and likelihood scale with criteria for each level, a documented rule for combining the two into an overall tier, and a single scale applied across the whole AI portfolio. Confirm who signs the tier assignment for each system and how often the assignments are revisited when a system changes purpose or data.

Test the decision record with a short exercise. Pick two AI systems that your teams believe carry very different risk, such as an internal document summarizer and a model that influences credit or hiring decisions. Score both with your current process and ask a second reviewer to score them independently. Where the results diverge, the gap usually lies in an undefined scale or an unwritten tolerance, not in the systems themselves. The record should show the inputs, the scores, the tier, the approver and the date. For the broader set of expectations around AI governance, the NIST AI RMF Playbook for the Govern function suggests actions for this subcategory, and the output of this exercise is what those actions ask you to produce.

Which AI systems and portfolio decisions GOVERN 1.3 covers

GOVERN 1.3 applies to the whole AI portfolio, not only to models an organization trains itself. The decisions below determine which systems enter the tiering process, who makes the call and when a tier has to be revisited, so the scoring applied later stays consistent and defensible.

Systems built in-house

Models and AI features your own teams develop carry the most design control, so they usually get the deepest impact assessment at each lifecycle stage. Check that the tiering policy covers data sourcing, training, fine-tuning and deployment as separate decision points. Confirm that a system built on a shared internal platform is still inventoried as its own system, because its impact depends on the use case, not the platform.

Third-party AI and embedded vendor features

AI features inside SaaS products, such as scoring, summarization or screening, often arrive without a separate purchase decision. Ask whether each vendor feature is tiered by the way your staff use its output, not by the vendor's marketing. Record what the vendor documents about training data, model changes and testing, and flag gaps that prevent you from setting an impact level.

Generative AI systems and GAI Profile actions

Generative systems can produce harms that differ from those of predictive models, so tiering should account for them explicitly. NIST AI 600-1 lists suggested actions tied to GOVERN 1.3, including setting minimum performance or assurance thresholds reviewed at go or no-go approval, and a plan to halt development or deployment of a system that poses unacceptable negative risk. Confirm that these thresholds and halt criteria are written into the tier definitions.

Shadow and pilot AI

Staff often trial AI tools, browser plugins or proofs of concept outside formal procurement, and these can reach real decisions before anyone scores them. Set a rule that any pilot touching customer, employee or regulated data enters the portfolio with a provisional tier. Review discovery methods such as expense records, network logs and access requests, and confirm who acts when an unapproved tool is found.

Ownership of the tiering decision

Tiering needs a named accountable owner, usually a risk or AI governance function with input from the business owner and technical team. Document who proposes a tier, who can override it and who signs off on systems at the highest level. Check that the approver has the authority to halt deployment, since a tier without enforcement does not change how much risk management a system receives.

When a tier must be revisited

A tier is valid only for the use, data and user population it was assessed against. Define triggers for reassessment, such as a new user group, a change in the type of data processed, a model update or a shift into a regulated decision. Confirm that these triggers are tied to the AI inventory so that changes are noticed rather than discovered at audit.

How to set up risk tiers that apply across the whole AI portfolio

This sequence turns a risk tolerance decision into a single tiering method that every AI system in the portfolio is scored against, so each system receives a documented level of risk management and the reasons for that level can be shown to an auditor, regulator or customer.

Write and approve the risk tolerance statement
Start by drafting a short statement that says how much AI risk the organization accepts, in what contexts, and which harms are never acceptable. Include any limits set by laws or sector regulators that apply to your AI use, since AI 100-1 notes that risk tolerance is contextual and can be shaped by legal requirements. Executive leadership or the board risk committee approves the statement, and the approval is recorded with a date and named approver. You know this step is done when the approved statement is stored in the policy repository and every later tier decision cites it.
Define impact and likelihood scales
Set the scales used to rate each AI system. Choose qualitative levels (for example, red, amber and green with written criteria for each) or quantitative ranges, and write a definition for every level so two reviewers reach the same rating. Impact criteria usually cover harm to individuals, customers, operations, legal exposure and affected communities, and likelihood criteria cover how often the system is used and how often its failure modes are expected to occur. The output is a scale definition document signed off by the risk function. You know this step is done when a sample system scored independently by two people gets the same rating.
Combine impact and likelihood into one overall measure
Define a rule that combines the impact rating and the likelihood rating into a single overall risk measure, such as a matrix that maps each pair of ratings to one result. Use the same matrix for every system so that scores are comparable across teams, business units and vendor-supplied tools. The output is the scoring matrix, with a short note explaining why each cell maps to its result. You know this step is done when the matrix is applied without exceptions and the risk function confirms that no team uses its own variant.
Set the risk tier thresholds
Translate the overall measure into named tiers, for example tiers that set how much testing, documentation, human oversight and approval each system needs. Write the threshold for each tier and the minimum controls that go with it, so a tier means the same thing in every team. Confirm that the highest tier requires go or no-go approval before deployment and that the tier model covers generative AI systems as well as traditional models. The output is a tier definition table with required controls per tier. You know this step is done when the control owners agree that each tier maps to concrete, testable requirements.
Set impact assessment policies for key lifecycle stages
Write the policy that sets when an impact assessment is required, at minimum before development begins, before deployment, after material changes and at retirement. Assign who prepares each assessment, who reviews it and where it is stored, and link the assessment results to the tier. The Playbook suggests these policies as part of GOVERN 1.3, and they give the tier a basis in evidence rather than opinion. The output is a lifecycle assessment policy with named owners. You know this step is done when every stage in the policy has an owner and a stored template.
Score the existing AI inventory
Apply the scales, matrix and thresholds to every AI system in the inventory, including systems bought from vendors and systems built in-house. Where the inventory is incomplete, record the gap as a finding instead of guessing a tier. Scoring is usually done by the system owner with a second reviewer from the risk function, and disagreements are escalated to the approver of the tolerance statement. The output is a scored list of systems. You know this step is done when every system in the inventory has an overall score and the scoring record names the scorer and reviewer.
Record the tier and rationale for each system
Create a tiered register that holds, for each system, its assigned tier, the impact and likelihood ratings, a short written rationale, the assessment reference, the approver and the date. The rationale should cite the scales and the tolerance statement so that an assessor can follow the reasoning without interviewing the team. Keep the register under version control so earlier tier decisions remain visible after changes. The output is the tiered register. You know this step is done when an outside reviewer can trace any tier back to the approved tolerance statement and the scoring record.
Set the review trigger for tier changes
Define the events that require a system to be rescored, such as a change in purpose, a new user group, a new model or data source, a material incident, or a change in the legal requirements that apply. Also set the periodic review of the scales and thresholds themselves, with a named owner who approves any change to them. The output is a written review trigger list and a change log for the scales. You know this step is done when a test change to a sample system triggers a documented rescore and the change is logged in the register.

How an assessor tests whether risk tiers are consistent and used

This table lists the checks an assessor runs on GOVERN 1.3 risk tiering, the test approach for each, the evidence requested and the findings that usually come up. Read it as a pre-assessment checklist: each row shows what the organization should be able to produce before an outside reviewer asks for it.

Check	Test approach and evidence requested	Common findings
Risk tolerance is approved and dated	Ask for the risk tolerance statement and confirm an accountable executive or governance body approved it, with a date and version. Compare the date against the current AI portfolio and any later policy changes.	Tolerance written as a draft, unsigned, or undated. Statement exists in a policy but no one can say who approved it or when it was last reviewed.
Impact and likelihood scales are defined and applied the same way	Request the scale definitions and the scoring guidance. Sample two or three systems scored by different teams and check that the same scale and thresholds produced the ratings.	Teams use different scales, such as one team rating on a numeric range and another on words. Scale definitions are missing the criteria for the top rating.
Each inventoried AI system has a tier with a documented rationale	Cross-check the AI system inventory against the tier register. Select a sample of entries and read the rationale for each tier, looking for the impact and likelihood reasoning behind it.	Systems in the inventory with no tier. Tier recorded as a label with no rationale. Shadow or third-party AI systems missing from both lists.
Tiers drive real differences in testing, approval and monitoring	Compare the required testing, sign-off and monitoring steps for each tier against the records for systems in that tier. Ask for approval records and monitoring reports for a high-tier and a low-tier system.	Every system receives the same process regardless of tier. High-tier systems go live without the documented go or no-go approval. Tier has no effect on monitoring frequency.
Tiering is revisited after material changes	Ask for the trigger list that causes re-tiering, such as a new use case, a new data source, a model change or a new affected population. Check change records for systems that changed and confirm the tier was reassessed.	No defined re-tiering triggers. Systems expanded to new users or decisions keep their original low tier. Periodic reviews happen but no changes are recorded.
Tiering covers generative AI and third-party AI	Confirm that the scales and tier criteria apply to generative AI and to vendor-supplied AI, including the minimum assurance thresholds and halt criteria the organization sets for those systems.	Generative AI tools used by staff are excluded from tiering. Vendor AI is tiered on vendor claims without any organizational rationale.
Roles for tier decisions are assigned	Request the RACI or equivalent for who proposes, challenges and approves a tier. Check that the approver is independent of the team that built the system where the policy requires it.	The team that owns the system sets its own tier with no review. No named approver for overrides or downgrades.

Evidence that shows each system received the right level of risk management

GOVERN 1.3 is met by evidence that connects a documented risk tolerance to the level of management each AI system actually receives. The cards below cover the artifacts an assessor will ask to see, from the tolerance statement through to go or no-go decisions, and the routine that keeps them accurate between reviews.

Approved risk tolerance statement

This is the signed statement of how much AI risk the organization will accept, approved by an accountable executive or governance body. NIST AI 100-1 says risk tolerance is contextual and can be shaped by legal or regulatory requirements, so the statement should name those requirements and state what the organization does where no established guideline exists. Check that it has an owner, an approval date, a version number, and a link to the impact and likelihood scales it relies on.

Impact and likelihood scoring rubric

The rubric defines the qualitative or quantitative scales for impact and likelihood, the method for combining them into an overall risk level, and the thresholds that place a system in each tier. The Playbook suggests scales such as red-amber-green ratings. Assessors look for one rubric applied across the whole portfolio, with written definitions for each rating so two reviewers score the same system the same way.

Tiered AI system register

The register lists every AI system with its overall risk score, assigned tier, the management activities that tier requires, the accountable owner, and the date the tier was last set. It is the document that shows uniform scoring across the portfolio. Confirm that the register is complete, since a system missing from it cannot be shown to have received any tier at all, and that each entry records why it was placed in its tier.

Impact assessment records at lifecycle stages

Impact assessments are dated records completed at the lifecycle points the organization's policy names, such as design, pre-deployment, material model change, and retirement. Each record shows the scores assigned, the evidence behind them, and the reviewer. Look for records that show the score changing when the system changed, because a single assessment at launch does not show the risk management level was kept current.

Go or no-go records for high-tier systems

For systems in the highest tier, the evidence is a recorded decision to deploy, or to refuse deployment, made against the thresholds the organization set. The Generative AI Profile suggests setting minimum performance or assurance thresholds that are reviewed at go or no-go approval, and a plan to halt a system that poses unacceptable negative risk. Record who approved, which thresholds were met, and which conditions were attached to approval.

Evidence kept current between audits

Evidence goes stale unless it has review dates and change triggers. Set a review date for the tolerance statement, rubric and register, and define events that force an earlier review, such as a new use case, a material model change, a new regulation, or an incident. Ask who owns each trigger and how the change is logged. Open-source tools can help hold this record: CISO Assistant can run framework assessments and track their status, Langfuse traces can supply runtime evidence for tier-specific monitoring, and garak JSONL reports can show probe results over time. Confirm each tool's fit and your license obligations before adopting it.

What meeting GOVERN 1.3 costs and what drives it up

This table compares the main cost components of setting risk tiers under GOVERN 1.3, who is paid for each, whether it is one-time or recurring, and what changes its size. Use it to scope internal effort and to check that a written quote covers every line. No supplied figures exist for these costs, so the table names what to ask for rather than amounts.

Cost component	One-time or recurring	What drives it	How to keep it down
Staff time to set tolerance and scales (executive, risk, legal, engineering)	One-time to set, then recurring at each review	Number of decision-makers, how many risk tolerance statements exist, and whether legal requirements already define thresholds	Start from an existing enterprise risk scale, limit the first workshop to one or two sponsors, and document decisions once
Impact and likelihood scale design and calibration	One-time, with revisions	Whether scales are qualitative (such as red-amber-green) or quantitative, and how many use-case types must be scored	Use one uniform scale across the portfolio, as the Playbook suggests, and test it on a few known systems before rollout
Tier register build and upkeep	Recurring	Number of AI systems in the inventory (GOVERN 1.6), how often systems change, and how many attributes each entry records	Keep the register in a single controlled tool, assign an owner per system, and reassess tiers only on defined triggers
Testing effort to support each tier	Recurring, scaled by tier	Higher tiers require deeper testing and more documented thresholds, including go or no-go reviews for generative AI under GOVERN 1.3	Match test depth to tier, reuse evaluation pipelines, and confirm which tests a given tier needs before the sprint starts
Tooling and licenses	Recurring where commercial	Whether a GRC or assessment platform is licensed, and how many frameworks it must cover. CISO Assistant is AGPL-3.0-only, so its license cost is zero, but hosting and administration still take staff time	Compare license terms, and when self-hosting open source, budget for hosting, patching and administrator time rather than license fees
External facilitation or review	One-time or periodic, by engagement	Scope, whether the organization wants an outside challenge to its tier logic, and whether a fixed-scope engagement covers workshops and documentation	Agree scope and deliverables in writing before work starts, and limit outside work to the design and documentation steps
Auditor or assessor sampling time	Periodic, when an assessment occurs	Number of tiers, number of sampled systems, and how well tier decisions are documented. NIST does not certify AI RMF use, so this applies only when a customer or regulator requests an assessment	Keep dated tier decisions, scale definitions and go or no-go records in one place so samples can be pulled quickly

Who does what: your team, an implementation partner, and the auditor

Your organization owns GOVERN 1.3 in full. NIST AI 100-1 does not prescribe a risk tolerance, so the level of risk you accept for each AI system is a business and legal decision that must be made, approved and recorded by people accountable for it. Your team sets the tolerance, decides the impact and likelihood scales, assigns each system to a risk tier, and makes the go or no-go call that follows from the tier.

Risk tolerance statement: Executive leadership approves the level of risk the organization will accept, and the approval names who may change it.
Scales and scoring rules: Your risk function defines the impact and likelihood scales and how they combine into one overall rating used across the whole AI portfolio.
Tier assignments: System owners propose a tier for each AI system, and a designated reviewer confirms it before the tier takes effect.
Go or no-go approvals: Named approvers sign off deployments in line with the tier, including any minimum performance thresholds you set.
Exceptions and overrides: Your governance body records every case where a tier is lowered, a control is waived or a system is approved outside the normal path.

Before relying on any partner output, confirm that your own staff can explain why each tier was assigned.

Where organizations fall short on GOVERN 1.3 and how to close each gap

GOVERN 1.3 asks whether the organization can decide how much risk management each AI system needs. The gaps below recur in programs that have policies on paper but cannot show consistent tiering, rationale or go or no-go decisions. Each fix points to an artifact the evidence section describes.

No written risk tolerance

Without a documented risk tolerance statement, each team decides for itself how much risk is acceptable, and tiers end up reflecting local preference. AI 100-1 notes that risk tolerance is contextual and that organizations should define a reasonable one themselves where no established guidance exists. Fix it by approving a short tolerance statement at executive level, covering which harms are unacceptable, which are accepted with controls, and who may accept residual risk. Check that every tiering decision cites it.

Scales differ across business units

When one unit rates impact on a five-point scale and another uses words like high or medium, the portfolio cannot be compared or ranked. The Playbook suggests defining qualitative or quantitative scales for impact and likelihood and applying one uniform risk scale across the AI portfolio. Fix it by publishing one impact and likelihood scale with written definitions and a combined risk matrix. Check that two systems with the same score would receive the same treatment regardless of owner.

Tiers assigned without rationale

A system labeled high risk with no recorded reasoning cannot be defended to an auditor, a regulator or the team that disagrees with the label. The tier should follow from the scored impact and likelihood, with the factors that drove each score written down. Fix it with a tiering record for each system that lists the impact and likelihood ratings, the evidence behind them and the assessor's name and date. Check that every tier in the AI inventory has a matching record.

High-tier systems without go or no-go records

Higher tiers usually call for more testing and sign-off, yet many programs have no recorded decision before deployment. The Generative AI Profile ties deployment approval to a go or no-go review, so the absence of that record is a visible gap. Fix it by requiring a signed approval memo for every high-tier system that names the accountable approver, the test results reviewed and any conditions attached. Check that no high-tier system appears in production without that memo.

Tiers set once and never revisited

A tier assigned at launch can become wrong when the model changes, the user base grows or a regulation takes effect. Most programs schedule no trigger for re-tiering, so the register drifts from reality. Fix it by defining triggers such as a material model change, a new use case or a new incident, and by setting a periodic re-review date in each tiering record. Check that the change log shows re-tiering after each trigger.

Generative AI without minimum thresholds

Generative AI systems are often scored on risk but approved without any minimum performance or assurance threshold to test against. GV-1.3-002 in the Generative AI Profile asks organizations to set such thresholds and review them in the go or no-go decision. Fix it by defining measurable minimums for each generative system, such as accuracy on a reference set or a maximum rate of unsafe outputs, and recording the test result against each threshold. Check that the approval memo shows the threshold, the measured value and the decision.

What buyers ask about GOVERN 1.3 cost, effort and outside help

Is GOVERN 1.3 mandatory under the NIST AI RMF?

No. NIST describes the AI Risk Management Framework as voluntary, and its FAQ says neither private nor public sector organizations are required to use it. GOVERN 1.3 is an outcome in that voluntary framework, so it becomes mandatory only when a contract, customer, sector regulator or state law requires it. Check the specific obligation with your legal team, since some laws name the framework or its Generative AI Profile. There is also no AI RMF certification, so no body can certify that you meet GOVERN 1.3. Independent auditors can test your evidence against your own stated approach, but the framework itself does not define a pass or fail.

How long does it take to set up risk tiers for GOVERN 1.3?

The duration depends mainly on how many AI systems you have and how many scales you need to define. An organization with a small, well-documented portfolio and an existing enterprise risk scale has less to design than one with many business units, mixed build and buy models, and no shared vocabulary for impact. Ask any partner to break the timeline into phases: agreeing the tolerance statement, defining impact and likelihood scales, scoring the inventory, and reviewing the results with risk owners. A fixed-scope engagement should state these phases and their deliverables in writing before work starts, along with the systems included.

What does the organization need to provide for this work?

Most of the decisions in GOVERN 1.3 sit with the organization, not with any outside party. Expect to need executive approval of the risk tolerance, since NIST notes that tolerance is contextual and must be defined by the organization where no established guidance exists. You will also need named risk owners and business owners for each AI system, engineers who can explain how each system works and fails, and someone who maintains the AI inventory. Without these inputs, scoring stays theoretical and the tiers will not survive review.

Can we define GOVERN 1.3 risk tiers in-house?

Yes, many organizations do this internally, particularly when they already run enterprise risk management and have a documented risk appetite. Outside help is most useful when no shared impact scale exists, when AI systems are spread across teams that score risk differently, or when staff lack time to run the workshops and document the reasoning. Whichever route you choose, the evidence an assessor looks for is the same: written scales, a rule for combining impact and likelihood, a record of who approved each tier, and consistent scores across the portfolio.

What drives the cost of a GOVERN 1.3 engagement?

Cost follows scope and internal readiness. The main drivers are the number of AI systems in scope, whether the inventory is complete, how many business units must agree on one scale, whether generative AI systems need the additional actions in NIST AI 600-1, and how many review cycles leadership requires. One-time costs include designing scales, agreeing tolerance and scoring the initial portfolio. Recurring costs include rescoring when systems change and reviewing tiers at a set frequency. Costs fall when the inventory and existing risk taxonomy are already in good shape.

What should we ask a partner to include in a quote?

Ask for a written scope that lists the AI systems covered, the NIST categories and subcategories addressed, and the deliverables, such as the tolerance statement, impact and likelihood scales, the tiering method, scored inventory and a decision record. Ask who on the partner side does the work, which organization roles they need from you, and what is excluded, such as legal interpretation or independent assessment. Confirm how revisions are handled, what happens if systems are added mid-engagement, and whether ongoing rescoring is included or offered as a separate retainer. A partner prepares systems and evidence, but only an independent auditor or assessor issues any report, so the quote should not promise an attestation.

How does the pending NIST revision affect GOVERN 1.3?

NIST says AI RMF 1.0 is being revised as part of the White House AI Action Plan and has not published a revised version as of October 2026. The July 2025 AI Action Plan recommends removing references to misinformation, diversity, equity and inclusion, and climate change, so wording in the framework and its Playbook may change. The Playbook has not been updated since August 2023 and AIRC says it will change after the framework is revised. Build your tiering method around the outcome, not the current wording, record which version you used, and confirm with your legal or sector contacts which version a law or contract cites.

How DeployOpen works on this

DeployOpen helps organizations prepare the systems and records that show how they decide the level of AI risk management each system needs. We work from the organization's own risk tolerance, which NIST AI 100-1 leaves to each organization to define, and we do not set that tolerance for you.

How we scope

Engagements are fixed-scope, with the GOVERN 1.3 deliverables agreed in writing before work starts.
We confirm which AI systems fall under the impact and likelihood scales and which teams own each record.
We agree which risk tolerance statements, tier definitions and go or no-go thresholds the organization has already approved, or must approve first.

How we build

We set up the impact and likelihood scales and the combined risk score as configurable, uniform definitions across the portfolio.
We configure tier assignment rules and record each system's tier, scoring inputs and approver in a single register.
Where the organization uses CISO Assistant, we can model GOVERN 1.3 controls and evidence within it, subject to confirming the fit for the scope.

How we hand over

We deliver the written scales, scoring method, tier criteria and a sample of scored systems for the organization's review.
We document the assumptions behind each scale so an independent assessor can trace how a tier was reached.
We provide a handover session so the organization's own owners can maintain the register and rerun scoring after changes.

How we support

Ongoing support, upgrades and periodic review of the scoring method are available as a retainer.
Retainers can cover re-tiering when a system changes purpose, data or deployment context.
Independent auditors and certification bodies, not DeployOpen, assess the evidence and issue any reports or certificates.