What GOVERN 2.3 requires from executives and why assessors ask for proof
When a board member, customer or regulator asks who owns AI risk decisions, the answer should name a person, not a committee. GOVERN 2.3 in the NIST AI RMF is the outcome that executive leadership takes responsibility for decisions about the risks of AI system development and deployment. It sits in GOVERN 2 of Table 1 in *NIST AI 100-1*, the *Artificial Intelligence Risk Management Framework (AI RMF 1.0)*. NIST published that framework for voluntary use, and no certification, accreditation or conformity assessment exists for it. So no one can be certified against GOVERN 2.3. An assessor, customer or regulator will instead ask for evidence that your executives have actually made and recorded these decisions.
The Playbook suggests concrete actions for this outcome: management declares risk tolerances for developing or using AI, supports and resources AI risk management, delegates authority through the management chain, and considers board committees for AI risk oversight integrated with enterprise risk management. Confirm with your leadership which of these already exist in writing, such as a signed risk tolerance statement, a delegation of authority, or minutes showing AI risk on a board or committee agenda. The Playbook tags this subcategory with the Governance and Oversight actor category, so the people you name should be the ones who hold that role.
The hard part is not the paperwork. Section 1.2.4 of AI 100-1 says effective risk management depends on organizational commitment at senior levels, may require cultural change, and that using the AI RMF alone will not create the accountability mechanisms or incentives needed. Practically, this means an executive must be willing to stop a launch, fund testing or accept a stated residual risk, and the organization must be able to show that this happened. Ask your executives to decide and record three things: who holds final authority for each AI risk decision, what tolerance they have accepted, and how they will hear about failures that matter.
Which AI systems, decisions and executives fall under GOVERN 2.3
GOVERN 2.3 only works when the organization decides what it covers before it assigns anyone. The decisions below set which AI systems, business units, executive roles and third-party tools sit inside the executive remit, and each one changes who signs off on risk and how much evidence the program must produce.
Which AI systems enter scope
Start with the organization's AI inventory and decide which systems carry executive-level risk decisions. Include systems built in-house, embedded features in purchased software, and internal tools that influence customer or employee outcomes. A narrow definition leaves high-impact systems outside the executive review, while a broad one can bury leaders in low-stakes tools. Ask who maintains the inventory and how new systems are added to it. Illustrative example: a hiring screen bought from a vendor may need executive sign-off even if no internal team built it.
Which business units are covered
Decide whether the executive remit reaches every business unit that develops, buys or operates AI, or only the units that touch regulated customers, personal data or safety-relevant decisions. Units that run AI outside central IT, such as marketing, claims or operations, are the ones most often missed. Confirm each unit has a named executive who can accept or reject risk on its behalf, and that the mapping is written down rather than assumed.
Which executive roles hold risk decisions
Name the executive who accepts AI risk for each in-scope system, such as the chief executive, chief risk officer, chief information security officer or a business line head. GOVERN 2.3 expects leadership to take responsibility for decisions, so a committee alone is rarely enough. Check that the named executive has authority over budget and staffing, not only a seat in the discussion. Record the decision rights in the same document that sets the roles and communication lines.
Whether a board committee exists
Decide whether the board or an existing board committee receives AI risk reporting, or whether a separate AI committee is needed. The NIST Playbook suggests considering board committees for AI risk oversight that are integrated with enterprise risk management. Confirm who reports to the board, how often, and whether AI risk appears in the same risk register and reporting cycle as other enterprise risks. If no board committee exists, document why the executive committee is the escalation point.
How third-party AI enters the remit
Decide whether externally provided models, APIs and AI features fall under the same executive decisions as internal systems. Organizations that buy AI rarely control the model, so executives need contract terms, data use limits and exit options in front of them before approval. Confirm who can accept vendor risk, how vendor AI is reviewed at renewal, and which vendor changes trigger a fresh executive decision. The NIST Playbook tags GOVERN 2.3 with the Governance and Oversight actor category, so vendor decisions should sit with the same people.
Which risk tolerances leaders must set
Decide which risk tolerance statements executives approve for AI development and use, and which systems each one governs. Tolerances that stay abstract give teams no basis for a go or no-go decision. Check that each tolerance names the kinds of harm it covers, the systems it applies to, and the owner who can change it. Ask whether the tolerances are reviewed on a set schedule and after any significant incident.
How an assessor tests executive responsibility for AI risk
This table compares each element the Playbook suggests for GOVERN 2.3, the test an assessor typically runs, the evidence they ask for and the findings that appear most often. Read it as a checklist of what must exist on paper and in governance records, not as a list of statements made in presentations. NIST AI RMF is voluntary and has no certification, so these tests are run by an organization's own internal audit or by an outside party it chooses.
| Element | How the test is run | Evidence requested | Common finding |
|---|---|---|---|
| Declared risk tolerances | Assessor checks that a named executive or board body has set AI risk tolerances for developing or using AI, and that the tolerances are specific enough to guide go or no-go decisions. | Approved risk appetite statement, signed minutes recording approval, and the date and version of the tolerance document. | Tolerances exist only in a slide deck or a draft, or are so general that no system decision could be tested against them. |
| Support and resourcing | Assessor compares the stated AI risk priorities with the budget, staffing and tooling approved for them, looking for a clear link between the two. | Approved budget lines or headcount plans for AI risk work, resource requests and their approval records, and the owner of each. | Risk work is assigned to staff with no protected time, or budget requests were declined without a recorded decision. |
| Delegation through the management chain | Assessor traces authority from the executive level down to system owners and checks that each delegation is written, accepted and bounded. | Delegation letters or role charters, a decision rights matrix, and records showing who signed off on high-risk AI deployments. | Delegations are verbal, or a senior sponsor is named but the actual approver for a deployment cannot be identified. |
| Board committee oversight | Assessor checks whether the board, or a committee the board has chartered, receives AI risk reporting and whether that reporting is connected to enterprise risk management. | Committee charter with AI risk in scope, agendas and minutes showing AI risk items, and the reports presented with their decisions. | Board minutes mention AI only as a general topic, with no reports, questions or decisions recorded. |
| Escalation and decisions on AI risk | Assessor samples a few AI decisions, such as a deployment or a risk acceptance, and traces whether the executive or board level was engaged when the risk required it. | Escalation records, risk acceptance forms with named approvers, and dates that show decisions were made before go-live. | Risk acceptances are signed by a team lead beyond their delegated authority, or escalations are made informally with no record. |
| Commitment and culture | Assessor looks for evidence that senior commitment is more than statements, since the framework notes that use of the AI RMF alone will not create accountability. | Executive objectives or performance criteria that include AI risk outcomes, and records of follow-up on prior findings. | Objectives do not mention AI risk, and open findings from earlier reviews remain without owners or dates. |
How to put executive AI risk ownership in place, step by step
This sequence turns the GOVERN 2.3 outcome into named executive decisions on AI risk tolerance, resourcing, delegated authority and board oversight, each recorded so an assessor or auditor can trace who decided what.
Confirm the AI systems in scope
Start from the AI inventory maintained under GOVERN 1, and list every system the organization develops, buys or deploys, including generative AI tools used by staff. Name the business owner for each system and note which ones affect customers, regulated decisions or critical operations. The output is a scoped list that executives can review, signed off by the executive sponsor. The step is done when every in-scope system has a named business owner and nothing sits outside the list without a recorded reason.
Draft the risk tolerance statements
Prepare draft statements for developing and using AI, describing how much risk the organization accepts in areas such as accuracy, safety, privacy, fairness and security. Base each draft on the impacts identified in the MAP work for the scoped systems, and phrase it so that a team can tell whether a proposed system falls inside it. Ask the risk function and legal counsel to review the wording. The output is a draft statement set, not a final decision.
Obtain executive declaration of risk tolerances
Put the draft statements to the accountable executives, such as the chief executive, chief risk officer or the most senior business leader for AI, and record their decision. The Playbook suggests management declare risk tolerances for developing or using AI, so the decision must come from named executives rather than a working group. Minutes or a signed resolution should record the date, the approvers and any conditions. The step is done when the approved tolerances are version-controlled and linked to the AI inventory.
Assign resources and delegated authority
Decide how much budget, staff time and tooling the AI risk program receives, and who may approve, pause or stop a system within the approved tolerances. Write the delegation through the management chain, naming roles rather than individuals where possible, and state what each role may decide without escalation. Confirm the resourcing figures with the finance owner, since they should come from the organization's own budget process. The output is a delegation register with approved resourcing, and the step closes when each in-scope system maps to an accountable role.
Decide on a board committee and its enterprise risk link
Decide whether AI risk oversight needs a board committee, or whether an existing risk or audit committee will take it on. The Playbook suggests considering board committees that are integrated with enterprise risk management, so record how AI risk reports into the enterprise risk register and which committee receives them. Ask counsel to confirm any sector rules that set board duties for the organization. The output is a documented oversight decision with its reporting line, and it closes when the committee's terms of reference or a board minute records the choice.
Set the reporting cadence and escalation triggers
Define what executives receive about AI risk, how often, and which events must reach them before the next scheduled report, such as a high-priority incident or a decision to deploy a system outside tolerance. Tie each trigger to the tolerance statements so escalation is objective. Agree the format with the board or committee secretary if one is involved. The output is a reporting calendar and escalation matrix, and the step is done when the first report template has been approved.
Record decisions and keep the evidence file
Store the scope list, tolerance statements, executive approvals, delegation register, committee decision, reporting calendar and escalation matrix in one controlled location with version history and owners. Link each record to the GOVERN 2.3 outcome so an internal reviewer or independent assessor can trace the decision chain. Schedule a review of the file alongside the periodic review under GOVERN 1, and note that the NIST AI RMF itself is voluntary and that NIST does not certify or validate any organization's use of it. The step is complete when an outsider can follow the chain from a named executive decision to a specific AI system.
What the Playbook suggestions for GOVERN 2.3 mean in practice
The Playbook suggestions for GOVERN 2.3 are prompts for leadership decisions, not a checklist to close out. NIST says the Playbook is neither a checklist nor a set of steps, so the suggested actions (declaring risk tolerances for developing or using AI, supporting and resourcing AI risk management, delegating authority through the management chain, and considering board committees for AI risk oversight integrated with enterprise risk management) should be read as questions the executive team must answer in its own words. A useful test is whether a named executive can state, in a dated record, what AI risk the organization will accept, who holds the budget to manage it, and who can stop a deployment. If the answer is a policy document nobody has signed, the outcome is not yet met.
The Playbook tags GOVERN 2.3 with the Governance and Oversight AI actor category. Appendix A of AI 100-1 describes the tasks expected of each actor category, so the appendix is the place to check which responsibilities belong to the governance layer and which belong to builders, deployers or evaluators. Confirm this against the current text of the framework before you map roles, because the Playbook and AI 100-1 are the sources you will cite to an auditor or customer. Expect to see the same executives appear in the GOVERN 1 policy approvals and the GOVERN 2.1 role documentation, since an accountability decision that is not written into those records is hard to demonstrate later.
Two sources give less help than readers may expect. NIST AI 600-1, the Generative AI Profile, lists no suggested actions for GOVERN 2.3, so generative AI programs should not assume the profile adds executive-level detail. The Playbook's audit log shows August 2023 as the last content update, and AIRC says the Playbook will be updated after AI RMF 1.0 is revised. Until NIST publishes the revised text, treat the current suggestions as the working reference, record the version you used, and ask your advisors to flag any suggestion that the revision changes. AI 100-1 also notes that the framework alone will not create accountability, so the leadership commitment has to exist in governance practice, not only in the document.
Evidence that shows executives own AI risk decisions
Executive ownership of AI risk is shown by records, not by statements of intent. The artifacts below connect a leader's decision to a dated, versioned document that an assessor or customer can read. Keep each one current between audits with a named owner, a review cadence and a version history.
Signed AI risk tolerance statement
A short document in which senior management states how much AI risk the organization accepts for developing and using AI, by use case or risk tier. It is the anchor for GOVERN 2.3 because it shows leadership declaring tolerances rather than delegating the question. Check that it is signed by a named executive, dated, linked to the risk categories used in MAP and MEASURE, and reviewed when a new high-impact use case is proposed. Retain prior signed versions so the change history is visible.
Executive decision records
Written records of specific go, no-go or risk acceptance decisions made by executives on AI systems, including the options considered and the residual risk accepted. These show the accountability that GOVERN 2.3 describes in practice. Check that each record names the decision owner, the date, the evidence reviewed and any conditions attached. Store them in a register that is searchable by system so an assessor can trace a deployment to its approval.
Resourcing approvals
Budget and staffing approvals that show management has funded AI risk management, such as testing capacity, monitoring tools and dedicated risk roles. Without them, a declared tolerance has no means of enforcement. Check that approvals reference the systems and activities they fund and that they are revisited when the AI inventory grows. Ask the finance or planning owner to confirm which approvals are current and which lapsed.
Delegation letters
Documents that pass authority for AI risk decisions from executives to named managers, with the limits of that authority and the escalation path back up the chain. They show that delegation is deliberate, which the Playbook suggests for GOVERN 2.3. Check that each letter states its scope, its expiry or review date and the conditions that require escalation. Update the letters when people change roles, since an outdated delegation is a common audit finding.
Board and committee charters and minutes
Charters that define the mandate of any board committee or executive forum overseeing AI risk, and minutes that show it met and acted. The Playbook suggests considering board committees integrated with enterprise risk management. Check that the charter covers AI explicitly, that meetings record AI risk items and decisions, and that open actions carry owners and due dates. Confirm with counsel whether minutes are held under any confidentiality or retention rule that applies.
Executive reporting packs
Periodic reports prepared for executives and the board that summarize AI risk posture, incidents, tolerance breaches and open decisions. They turn oversight into a recurring activity with evidence attached. Check that each pack states the reporting period, the metrics drawn from MEASURE and MANAGE results and any threshold that triggered escalation. Keep the packs in a dated archive so trends can be shown across review cycles.
What meeting GOVERN 2.3 costs in executive time, tooling and review
This table lists the cost components of meeting GOVERN 2.3, who is paid or who spends time on each, whether it is one-time or recurring, and what moves it up or down. Use it to structure a quote request, since NIST publishes no cost figures for this subcategory and every number must come from your own scope and staffing. The main takeaway is that most of the cost is executive time and recurring review, not software.
| Cost component | Who is paid or spends time | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Executive and board time | Senior leaders and board members who approve risk tolerances and receive AI risk reporting | Recurring | Number of AI systems in scope, board meeting cadence, and whether a board committee is created for AI risk oversight |
| Governance workshops | Facilitators (internal or an implementation partner) and executives who attend sessions to agree on accountability | One-time, with periodic refreshers | Size of the business units involved and how many AI use cases already have named owners |
| Drafting and approving the risk tolerance | Risk, legal and business owners who draft the statement; executives who approve it | One-time, then reviewed periodically | Number of distinct AI use cases, regulatory exposure, and how many approval rounds the organization requires |
| Reporting tooling | Internal platform or security team, plus any partner who configures dashboards; license fees for proprietary tools if used | Setup one-time, licenses and hosting recurring | Choice between proprietary reporting suites and self-hosted open-source tools, which can remove license spend but still need hosting and maintenance staff |
| Delegation and authority mapping | Governance lead and HR or business leaders who document the management chain for AI risk decisions | One-time, updated on reorganizations | Frequency of organizational change and how many decision rights are delegated below executive level |
| Recurring management reviews | Executives and risk owners who review AI risk metrics and reaffirm tolerances | Recurring | Review frequency, the number of high-risk systems, and whether reviews are combined with existing enterprise risk meetings |
| Independent review or auditor sampling | External assessor, certification body or auditor, who tests evidence and issues any report | Recurring if the assessment repeats | Scope of the assessment, sample sizes the assessor selects, and how well governance records are kept ahead of the review |
Who owns what: executives, an implementation partner and the auditor
GOVERN 2.3 places responsibility for AI risk decisions with executive leadership. Those decisions cannot be delegated to a consultant or a vendor, because the organization is the party that accepts the risk. In practice, the executive team sets how much AI risk the business will accept, names who answers for each AI system, and decides whether a system goes live or stops. The NIST AI RMF Playbook suggests that management declare risk tolerances for developing or using AI, support and resource the work, and delegate authority through the management chain. Executives are also the people who decide whether a board committee should oversee AI risk alongside enterprise risk management.
- Risk tolerance statements: Written thresholds for which AI risks leadership will accept, reduce or refuse, approved by a named executive.
- Resourcing decisions: Budget, staff and tooling for AI risk management, approved as a recurring line item rather than a one-off project.
- Delegation records: Documented authority for each AI system, showing who may approve deployment and who must be escalated to.
- Board oversight design: A decision on whether a board committee receives AI risk reporting and how it connects to enterprise risk reporting.
- Cultural commitment: Visible follow-through, since AI 100-1 notes that the framework alone does not create accountability mechanisms or incentives.
Before engaging anyone, confirm that these decisions are recorded with the executive's name, date and scope so an assessor can trace them.
An implementation partner helps the organization build the machinery that makes executive decisions visible and testable. The partner does not set risk tolerance and does not accept risk on the organization's behalf. Its work is preparing reporting structures, evidence packs and the technical records that show leadership's decisions are being carried out. This work is often outsourced because it is time-consuming and benefits from experience with platform and documentation tooling, but the organization must keep ownership of the content it approves.
- Reporting structures: Templates and workflows for escalating AI risk to executives and the board, with defined cadences and owners.
- Evidence packs: Organized records of approvals, delegation letters, risk register entries and review minutes, mapped to GOVERN 2.3 subcategory expectations.
- Platform configuration: Self-hosted tooling set up inside the client's own infrastructure so that approvals and logs are retained under the client's control.
- Gap review: A readiness check that compares current practice with the Playbook suggestions and flags missing decisions or records.
- Handover documentation: Runbooks so internal staff can keep the reporting running after the engagement ends.
Ask any partner to state in writing which items it prepares and which the organization must sign, and confirm that approvals are made by named executives.
An independent assessor tests whether the organization's accountability structures work as described. The assessor reviews the evidence, interviews executives and staff, and reports findings. Only an independent auditor, assessor or certification body issues reports or certificates. The AI RMF itself has no certification, so any external review is an assessment against the framework or an agreed set of criteria, and NIST does not validate or endorse individual organizations' use of it. Organizations should confirm with their assessor exactly which criteria and report format will be used before work begins.
- Testing approach: Sampling of executive approvals, checking that delegation matches the actual decision path and that reporting reached the named committee.
- Interviews: Questions to executives to confirm they understand the risk tolerances they approved.
- Findings and reports: Written conclusions that the assessor owns, which the organization cannot edit or dictate.
- Independence line: The assessor must not design the controls it tests, write the executive's risk tolerance, or prepare the evidence it then evaluates for the same engagement.
- Scope agreement: A written statement of what was tested, the period covered and the limitations.
Confirm the assessor's independence policy and whether its engagement letter excludes design or remediation work that it would later review.
Where organizations fall short on executive AI risk ownership
Executive ownership under GOVERN 2.3 often exists on paper but breaks down in practice. The gaps below share a root cause: leaders make no visible, recurring decisions about AI risk, so the delegated owners below them have no mandate to act. Each gap has a closing action an organization can check against its own records.
Risk tolerance never declared
Many organizations let teams build and buy AI without any statement from management on how much risk is acceptable. The Playbook suggests that management declare risk tolerances for developing or using AI, so without that declaration, product teams guess and reviewers have nothing to test against. Closing action: ask the accountable executive to sign a written tolerance statement for AI use cases, with the categories of system that need board or committee sign-off before deployment.
Delegated owners without authority
A named AI risk owner is often a manager with responsibility but no budget, no veto over launches and no seat where priorities are set. The Playbook's delegation suggestion works only when authority passes down the management chain with the power to stop or pause a system. Closing action: check each delegation against a written list of decisions the owner can make alone, decisions that need escalation, and the budget the owner controls.
No board reporting cadence
Boards often hear about AI only when a launch is announced or an incident reaches the press. Without a fixed reporting rhythm, directors cannot exercise the oversight the Playbook describes, and management has no deadline that forces a review of deployed systems. Closing action: confirm that the board or a designated committee receives a standing AI risk report at an agreed interval, with a defined set of metrics and a named presenter.
AI risk missing from enterprise registers
AI risks often sit in project tracking or data science notes rather than in the enterprise risk register that executives review. The Playbook suggests that board oversight be integrated with enterprise risk management, so an AI risk left out of the register is one that leadership never weighs against other exposures. Closing action: compare the AI inventory against the enterprise risk register and confirm that each high-impact system maps to a register entry with a named owner and a review date.
Questions buyers ask about GOVERN 2.3
Is GOVERN 2.3 mandatory, and is there a certification for it?
No. GOVERN 2.3 is part of the NIST AI RMF, which NIST describes as a voluntary framework that neither private nor public sector organizations are required to use. There is also no AI RMF certification: NIST does not validate or endorse any organization's approach to using the framework, and it runs no accreditation or conformity assessment program. Whether the subcategory is mandatory for you depends on a contract, a customer requirement or a specific law that names the framework. Confirm that requirement in writing before you scope the work, because it determines what evidence you need to show and to whom.
How much executive time does GOVERN 2.3 take?
The framework does not set an hourly figure, so the answer depends on how your leadership already makes AI decisions. The time usually goes to declaring risk tolerances for AI development and use, reviewing the resourcing of AI risk work, and approving delegations of authority. A first pass tends to take the most attention, and recurring reviews after that are shorter if the risk tolerance and reporting lines are written down. Ask your advisors to split their estimate into one-time setup and recurring oversight, and to name which executives must attend each step.
Does GOVERN 2.3 require a board committee for AI risk?
No. The NIST AI RMF Playbook lists board committees for AI risk oversight as one action organizations might consider for GOVERN 2.3, and it asks that any such committee be integrated with enterprise risk management. It is a suggestion, not a requirement. Many organizations choose a board committee, a standing executive forum or an existing risk committee with an AI agenda item. The right choice depends on how much AI your organization develops or deploys, your existing governance structure and any sector regulator that expects board-level oversight. Document the choice and the reasons for it.
What does the work need from the organization?
Most of the work depends on decisions only leadership can make. The Playbook suggests that management declare risk tolerances for developing or using AI, support and resource AI risk management, delegate authority through the management chain and consider board oversight. NIST also notes in AI 100-1 that effective risk management depends on senior commitment and may require cultural change, and that using the framework alone will not create accountability mechanisms or incentives. In practice, you need named executives, a decision record for risk tolerances, a budget owner for AI risk work and a way to show that decisions were made and followed.
Can we meet GOVERN 2.3 in-house, and what would an outside partner do?
Yes, in principle. GOVERN 2.3 is an organizational decision about accountability, so the executives must own it and cannot delegate the decision itself. Your teams can draft the risk tolerance statement, delegation records and reporting packs without outside help if they have the time and the policy skills. An implementation partner such as DeployOpen can prepare systems, documentation and evidence in your own environment and support the work as a fixed-scope engagement with written deliverables. Any independent review of your posture comes from a separate assessor, because DeployOpen does not issue audit reports or certifications.
How does GOVERN 2.3 relate to ISO/IEC 42001?
They address similar ground from different starting points. GOVERN 2.3 is a subcategory of the NIST AI RMF, a voluntary framework with no certification. ISO/IEC 42001:2023 is an AI management system standard, and organizations can be assessed against it by a certification body. Both expect senior leadership to take responsibility for AI risk decisions, so one set of executive decision records can often serve both. Do not assume a line-by-line match between them. Ask the certification body or your own compliance lead to confirm which evidence satisfies each requirement you need to meet.
How DeployOpen prepares executive AI risk evidence
Executive responsibility for AI risk is a decision the organization makes and owns, and DeployOpen's role is to prepare the records that make those decisions visible and testable. In a fixed-scope engagement, the work starts with a written list of the AI systems in question, their owners, their business purpose and the deployment environments they run in. That scope is agreed before work begins, so the executive team knows exactly which systems its declared risk tolerances and resourcing decisions apply to. DeployOpen does not issue audit reports, attestations or certifications, and it does not decide what risk is acceptable. Those choices belong to the organization's leadership and board.
The decision record is the core deliverable. For each in-scope system, DeployOpen can help draft a register of the risk tolerance statements management has declared for developing or using AI, the named executive who accepted each residual risk, the delegation chain that passes authority down to system owners, and the resourcing decisions that fund the work. It can also set up the reporting structure that carries AI risk into enterprise risk management, including the recurring pack that goes to any board committee the organization chooses to use for AI oversight. Confirm with your own governance team whether the board committee already exists, what its charter says, and which enterprise risk forums already receive these reports, because the pack should reuse those channels rather than create a parallel one.
Evidence for an independent assessment comes from keeping these records current and dated. DeployOpen can assemble an evidence folder that maps each decision record to the matching Playbook suggested actions for GOVERN 2.3, with the source documents, meeting minutes, approval logs and version history an assessor would ask to see. Ask any assessor or certification body you engage which documents they expect for an AI risk assessment, because requirements for evidence vary by engagement. Keep in mind that NIST AI 100-1 notes that using the framework alone will not create accountability mechanisms or incentives, so the evidence should show real executive decisions, not just the presence of a document.
