GOVERN 1.4 transparent risk management: evidence

What GOVERN 1.4 asks for in the NIST AI RMF

GOVERN 1.4 asks for documented policies, procedures and controls, tied to risk priorities, that make the AI risk management process and its outcomes visible to people outside the team that runs them. When a customer questionnaire, a contract clause or an internal audit asks whether your AI risk management is transparent, this subcategory is the one that answers. The AI RMF is voluntary and has no certification, so nobody issues a pass. What counts is evidence that a customer, an internal auditor or an independent assessor will accept as showing that the policies exist, are followed and reflect how the organization ranks its risks.

The NIST AI RMF Playbook suggests several concrete actions. Set documentation policies that cover business justification, scope, expected risks, training data, algorithmic methods, testing results, dependencies, and deployment and monitoring plans. Standardize documentation across the organization so that a model built in one business unit can be read the same way as one built in another. Keep a model documentation inventory that records where each document lives and which system it describes. Decide which risk material, such as impact assessments and audits, will be disclosed publicly and which stays internal. For generative AI, NIST AI 600-1 adds two suggested actions under GV-1.4-001 and GV-1.4-002. They call for policies and mechanisms that stop generative systems from producing child sexual abuse material, non-consensual intimate imagery or other unlawful content, and for transparent acceptable use policies that address illegal uses. Confirm which of these apply to your systems before you write them into policy.

Two gaps make this subcategory hard. The first is documentation that exists only in people's heads or in a single engineer's notes, which cannot be standardized, inventoried or audited. A wiki with page version history, such as the one described in the XWiki and BookStack sources linked in the topic facts, can hold the record, but someone still has to decide what each template requires. The second is disclosure decisions that nobody has made. If no one has written down what is published, what is withheld and who approves the difference, the answer to a customer or auditor will change depending on who is asked. Settle the disclosure rules and the documentation template first, then decide which implementation partner or assessor will check them.

Which AI systems, teams and third parties GOVERN 1.4 reaches

GOVERN 1.4 applies to more than the model team's files. The scope decisions below determine which systems need full documentation, which generative AI actions apply, who writes and approves each record, and how vendor components are described. The organization owns these decisions, and scope should follow the risk tiers set under GOVERN 1.3.

Built, fine-tuned or bought systems

Documentation depth should not depend only on who trained the model. A system built in-house, a fine-tuned foundation model and a purchased product each need a documentation record, but the content differs. For built and fine-tuned systems, the team holds training data, algorithmic methods and testing results. For bought systems, the organization holds the use case, configuration, data flows and monitoring plan. Confirm that every category has a named documentation owner before the policy is approved.

Generative AI systems in scope

NIST AI 600-1 lists two suggested actions under GOVERN 1.4, GV-1.4-001 and GV-1.4-002, which cover policies to prevent generative AI systems from producing unlawful content and transparent acceptable use policies that address illegal uses. Any system that generates text, images, code or audio should be checked against them, including tools staff use under a vendor's terms. Ask whether the acceptable use policy names prohibited uses and who enforces it.

Documentation owners by team

Product owners usually record business justification, intended scope and deployment plans. Data science and engineering teams record training data, algorithmic methods, testing results and dependencies. Risk and compliance teams decide what impact assessments and audits are disclosed, and legal teams review use restrictions and public statements. No single team can complete a record alone, so the policy should assign each section to one accountable role and set a sign-off order.

Vendor-supplied models and data

When a vendor will not disclose model internals or training data, the organization still documents what it can observe: the vendor's stated purpose, version in use, contract terms, data sent to the system, known limitations from vendor materials, and the results of its own testing. Record which facts came from the vendor and which were verified internally. Ask vendors for documentation they can provide and note in the record where none is available.

Scope set by risk tiers

GOVERN 1.3 decides how much risk management each AI system needs. GOVERN 1.4 should follow that result: high-tier systems receive full documentation, disclosure review and inventory linkage, while low-tier systems may need a shorter standard record. Applying one template to every system either buries high-risk records in noise or leaves low-risk ones undocumented. Check that the tiering method is written down and applied the same way across the portfolio.

Public disclosure decisions

The Playbook suggests deciding which risk material, such as impact assessments and audits, is disclosed publicly. That decision belongs to the organization. The policy should state who may approve public release, which artifacts are candidates, which are kept internal for security or confidentiality reasons, and how disclosed material stays consistent with the internal record. Assign approval authority before any external request arrives.

How an assessor tests GOVERN 1.4 and what passes

This table compares each test area for GOVERN 1.4 with the evidence an assessor typically requests and the findings that usually come up. The assessor is an independent party engaged by the customer or internal audit, and no AI RMF certificate is issued at the end.

Test area	Evidence requested	Common findings
Documentation policy content	Written policy naming required model documentation fields: business justification, scope, expected risks, training data, algorithmic methods, testing results, dependencies, and deployment and monitoring plans	Policy exists but omits one or more fields, or lists fields without saying who completes them or when
One documentation standard	Single template or standard applied across teams, with version history and the approval record for it	Each team uses its own format, so entries cannot be compared or searched across the portfolio
Documentation inventory completeness	Documentation register checked against the AI system inventory (GOVERN 1.6) for the same sample of systems	Systems in the AI inventory have no documentation record, or retired systems still show as active
Documentation currency	Record of update dates and change history for a sample of model documents, compared with recent model or data changes	Documents describe the original release and were not updated after retraining, scope changes or new dependencies
Written public disclosure rule	Approved rule stating which risk material (such as impact assessments and audits) is published, to whom, and who decides	No written rule exists, or the rule is not referenced in any policy and no one owns the decision
Disclosure rule applied	Examples of published or withheld material, with the decision record showing the rule was followed	Rule exists but disclosure decisions were made case by case with no recorded rationale
Link to risk priorities	Evidence that documentation depth varies with the risk tier assigned under GOVERN 1.3	High-impact systems carry the same light documentation as low-risk tools
Access and change control	Version history, role-based permissions and an audit trail showing who changed each document and when	Edits are made in shared files with no record of authorship or approval

How to implement GOVERN 1.4 in order

This sequence turns GOVERN 1.4 from a policy statement into a set of documents, inventories and disclosure decisions that an assessor can read and test. Each step closes with a named artifact, so the organization can show how its risk management process is set and how its outcomes are made visible.

Set the documentation policy and minimum content
Your AI governance lead, with legal and the risk function, writes a documentation policy that states which AI systems it covers and what every model record must contain. The Playbook suggests the policy address business justification, scope, expected risks, training data, algorithmic methods, testing results, dependencies, and deployment and monitoring plans. Output: an approved documentation policy with a minimum content list. It is done when the policy names an owner and a approval date, and every system in scope can be checked against that list.
Choose one documentation template and retention rule
Select a single template for model documentation so that every team records the same fields in the same order. Decide how long each version is kept and where it lives. A wiki with version control, such as XWiki, records what changed, when and by whom, and lets reviewers compare versions and roll back. Output: a published template and a retention rule that states what is kept, for how long, and who may delete it. It is done when a sample record from one team can be compared line by line with another team's record.
Stand up the model documentation inventory
Create an index of model documentation records and link each record to its entry in the AI system inventory maintained under GOVERN 1.6. The Playbook suggests keeping a model documentation inventory, so this index should show, for each system, the current documentation version, its owner and its last review date. Output: a maintained inventory that an assessor can use to trace any deployed system to its documentation. It is done when every system on the AI inventory has a linked record, and no record exists without a matching system.
Assign owners and set review points
Name an accountable owner for each documentation record and a reviewer who is independent of the team that built the system. Set review points tied to material changes, such as a new training data source, a retrained model or a change in intended use, as well as periodic checks. Link these review points to the monitoring plan under GOVERN 1.5. Output: a roster of owners and reviewers and a review calendar. It is done when each record shows who maintains it and when it was last reviewed.
Decide public disclosure rules for risk material
Decide which risk material is published and which stays internal. Impact assessments, audit results and testing summaries are the examples the Playbook raises, so legal, privacy and communications should agree on what goes out, in what detail and who approves it. Document the reasons for withholding anything, including security sensitivity or confidentiality. Output: a written disclosure rule with a list of published items and the approval path for each. It is done when a reader can tell, for any risk artifact, whether it is public, restricted or internal, and why.
Run a pilot on one system before rolling out
Choose one AI system with a moderate risk profile and apply the full set of documentation, ownership, review and disclosure rules to it. Record where the template was unclear, where data was missing and where the review point failed to trigger. Output: a pilot record with the gaps found and the changes made to the policy, template or inventory. It is done when the pilot record shows the changes that were adopted, and the rules are updated before the wider rollout begins.

Evidence that shows GOVERN 1.4 is met and how to keep it current

GOVERN 1.4 is met through documents that exist, are approved and stay current, not through a single certificate because the AI RMF has none. The cards below cover the artifacts an assessor or customer will ask to see, and the routine that keeps each one accurate between reviews. Tie every review cadence to the periodic review planned under GOVERN 1.5 so the set is checked together.

Approved documentation policy with version history

This is the policy that sets what every AI model document must cover: business justification, scope, expected risks, training data, algorithmic methods, testing results, dependencies, and deployment and monitoring plans. Check that it names an owner, carries an approval date and records each revision with what changed and who approved it. Keep the policy in a wiki or document system with version control, so an assessor can compare any two versions and see which one was in force on a given date. Confirm that the policy is linked from the AI governance index.

Standard model documentation template

A single template gives every team the same structure, so documents for a credit scoring model and a support chatbot can be compared side by side. Include fields for the Playbook documentation prompts, risk tier from GOVERN 1.3, and named owners. Keep completed examples alongside the blank template, marked with the system they describe and the date they were reviewed. Examples show an assessor that the template is used in practice, not only written down.

Model documentation inventory with owners and dates

The inventory lists every model that has a documentation record, with the accountable owner, the document version in force, the date of the last review and the date of the next scheduled review. An assessor will sample entries and check that each one links to a real document. Reconcile this list against the AI system inventory maintained under GOVERN 1.6, so no system is documented in one place and missing from the other. Records kept in a database or spreadsheet should be exported and archived at each review.

Review and approval records

Each documentation change needs a dated record showing who reviewed it, what they checked, and who gave approval. Store the sign-off with the document version it applies to, not in a separate email thread that cannot be linked back. Set a review cadence for the policy and the template, and tie it to the periodic review planned under GOVERN 1.5 so the reviews happen together. Confirm with your reviewers how they record objections that were resolved or accepted as residual risk.

Public disclosure rule and decision log

The Playbook asks organizations to decide which risk material, such as impact assessments and audits, is published. Write a rule that names the document types, the audience, the approver and the conditions for withholding details for security or legal reasons. Keep a log of each disclosure decision with the date, the document, the reasoning and the approver, including decisions not to publish. Review the rule at each GOVERN 1.5 cycle, since disclosure duties may change with the laws that apply to your AI.

Generative AI acceptable use policy

Where the organization runs or buys generative AI, GOVERN 1.4 suggested actions in NIST AI 600-1 call for transparent acceptable use policies that address illegal uses, along with mechanisms that aim to prevent prohibited outputs such as child sexual abuse material and non-consensual intimate imagery. Keep the policy version-controlled, record the user groups it covers, and log exceptions and enforcement actions. Test the policy against the controls it relies on, using a tool such as garak to produce evidence of probing results, and confirm the results are reviewed with the policy owner.

What meeting GOVERN 1.4 costs in money and effort

This table breaks the cost of GOVERN 1.4 into its components, showing who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to structure a written quote request, since no fixed figures are given here and each organization's scope sets the total.

Cost component	One-time or recurring, and who is paid	What drives it up or down	How to keep it down
Tooling or licenses	Mostly one-time setup, then recurring if a commercial platform is used. Paid to the software vendor or to a services partner for setup.	Number of documentation tools, seats for model owners and reviewers, and whether a commercial governance suite is chosen over open source.	Use self-hosted open-source wikis and version-controlled documentation, which can remove per-seat license spend. Confirm hosting and support costs separately.
Internal engineering and documentation time	Largely one-time to build the documentation policy and templates, with recurring time per AI system. Paid through internal staff time, not a vendor invoice.	Number of AI systems in scope, number of teams producing models, and how much documentation already exists for each system.	Standardize one template for model documentation and reuse it across systems. Start with the highest-priority systems identified under GOVERN 1.3.
Evidence upkeep	Recurring. Covers keeping model documentation, the documentation inventory and version history current as systems change. Paid as internal time or a retainer.	Release frequency of models, retraining cycles, and the number of generative AI systems that change prompts or content filters often.	Tie documentation updates to change management so entries are updated as part of each release, not in a separate cycle. Retain page version history so changes are traceable.
Implementation partner support	One-time for scoped work such as drafting policies, configuring the documentation platform and preparing evidence. Paid to the partner under a fixed-scope written agreement.	Gap between current documentation and the target state, number of teams to train, and whether integration with existing GRC tooling is required.	Ask for a fixed scope listing the systems, teams and deliverables. Keep ownership of policies and controls in-house so partner work does not become a recurring dependency.
Generative AI documentation scope	Recurring where generative AI systems need added policies, acceptable use rules and public disclosure decisions. Paid as internal time, legal review or partner work.	Number of generative AI systems, use of third-party foundation models, and the extent of acceptable use and content policy requirements listed in NIST AI 600-1.	Scope generative AI controls by use case and risk tier rather than applying the full set to every tool. Reuse one acceptable use policy across teams.
External review or testing	Occasional, and paid to an independent reviewer or testing firm. NIST does not certify or validate an organization's use of the AI RMF.	Whether public disclosure of impact assessments or audit results is planned, and whether adversarial testing of generative AI outputs is in scope.	Decide which risk material will be disclosed before commissioning reviews. Use open-source testing tools for internal checks before paying for external testing.
Independent assessor sampling	Occurs only when a customer, contract or regulator requires an independent assessment, and paid to that assessor. Assessors issue their own reports; NIST issues none.	Number of documented systems the assessor samples, the depth of traceability between policies and records, and whether the assessment is scoped to GOVERN 1.4 alone.	Keep an inventory that links each system to its documentation, decisions and version history so samples can be pulled quickly. Confirm the assessor's sampling approach in writing before work starts.

Which self-hosted open-source tools can hold GOVERN 1.4 evidence

GOVERN 1.4 is satisfied through documents people can find, version and defend, so the tooling question is mostly about documentation and records. The four tools below cover version-controlled policy pages, role-based access to those pages, a framework-tracking layer for assessment records, and test output for language model evaluations. None of them is a substitute for the policies themselves, and each needs checking against your own requirements before you rely on it.

Version-controlled policy pages

XWiki keeps every change to a page under version control, recording what changed, when and by whom. Users can compare any two versions and roll back to an earlier one. For GOVERN 1.4, this gives you a traceable history for the documentation policy, standardized model documentation templates and the risk disclosure rules. Check that the audit history is retained long enough for your assessor's sampling period, that exports are available for evidence packs, and that the LGPL-2.1-or-later license terms fit how you plan to modify or distribute the software.

Role-based documentation access

BookStack assigns abilities through roles, and permissions can be overridden per role at the shelf, book, chapter or page level. This lets you give model owners edit rights on their own model documentation, give risk reviewers approval rights, and keep public disclosure drafts restricted until sign-off. Confirm that the role model can express your separation of duties, that page-level restrictions behave as you expect in your own tests, and that the MIT license meets your internal policy on modifying the software.

Framework tracking for assessment records

CISO Assistant ships a library of frameworks and runs audits and compliance assessments against them, with automatic mapping between frameworks. It can hold records of which documentation controls were assessed, by whom and with what result. Before relying on it for GOVERN 1.4, confirm whether the NIST AI RMF appears in its framework library in your version, since the tool supports many frameworks but NIST AI RMF coverage is not assumed here. Also review the AGPL-3.0-only terms, which carry obligations if you modify and offer the software over a network.

Language model test reports

garak probes language models for hallucination, data leakage, prompt injection, misinformation, toxicity generation and jailbreaks. It writes a JSONL report of every attempt and evaluation, plus a hit log of attempts that found a vulnerability. These files can document testing results for the generative AI actions tied to GOVERN 1.4, such as acceptable use and prohibited content controls. Confirm which probes match your model and use case, store the reports under version control with the policy they support, and note that the Apache-2.0 license carries its own attribution and notice terms.

Who owns GOVERN 1.4, who helps, and where the auditor stops

Your organization owns GOVERN 1.4. The documentation policy, the decisions about what risk material is published, the content of model documentation and the accountable sign-off all sit with named people inside the company. NIST's AI RMF is voluntary, so no outside body assigns these owners for you. Your governance function should decide who signs the policy, who approves disclosure, and who answers for documentation quality when a system changes.

Policy ownership: Name an executive owner for the documentation and disclosure policy, and record the business justification for why it applies to all AI systems.
Disclosure decisions: Decide which impact assessments, audit results and risk summaries are published, and who approves each release.
Documentation content: System owners write the entries covering scope, expected risks, training data, algorithmic methods, testing results and dependencies.
Standard templates: Approve the templates used across the organization so documentation is comparable from one system to the next.
Risk acceptance and sign-off: Keep accountable approval of residual risk and of any documentation exception with staff, not with a vendor.

Check that each of these roles has a named person, a backup and a recorded decision trail.

Where GOVERN 1.4 usually fails and how to close each gap

GOVERN 1.4 fails less often for lack of documents than for documents that do not agree with each other, with the systems they describe, or with what the organization can actually check. The gaps below share one root cause: transparency depends on a single standard, a maintained list of systems, and a written rule for what gets disclosed.

Documentation that is not standardized

Each team writes model documentation in its own format, so one team records training data and test results while another records only a purpose statement. The Playbook suggests a documentation policy covering business justification, scope, expected risks, training data, algorithmic methods, testing results, dependencies and deployment and monitoring plans. Close the gap by adopting one template with those headings as required fields, then check a sample of recent models against it. Illustratively, a reviewer should be able to find the same five facts in any model's record without asking the team.

Inventory that drifts from reality

The model documentation inventory is only useful if it lists the systems actually running. New features, vendor model swaps and retired pilots often reach production without an entry, or leave an entry behind after shutdown. Assign one owner for the documentation inventory, tie a new entry to change approval, and reconcile the list against deployment records and procurement data on a fixed schedule. Ask who can add a system to production without the inventory being updated, and what happens when they do.

Disclosure rule never written down

Teams often decide case by case whether an impact assessment, audit or bias test result can be shared outside the company. The result is inconsistent answers to customers, regulators and the public, and no record of why a decision was made. Write a disclosure rule that names the risk material in scope, the audience for each item, the approver and the conditions for withholding information for security or legal reasons. Test it against one recent system to confirm that the rule produces the same answer a second reviewer would reach.

Documentation written once, never reviewed

Documentation often describes a model as it was at launch, while retraining, new data sources and changed use cases make it inaccurate. Stale records also undermine the transparency the outcome is meant to provide. Set a review trigger for each record, such as a retraining event, a scope change or an incident, and a periodic review date for the rest. Keep version history so a reviewer can see what changed, when and by whom. Confirm that the platform you use for documentation supports that history before relying on it.

Vendor models documented without verification

Teams often copy the vendor's model card into their own records without checking what the organization can verify. Claims about training data, testing and limits may be impossible to confirm, and the gap is rarely recorded. Separate the record into vendor-stated facts, facts the organization tested and open questions, and assign each open question to a person with a date to resolve it. Ask vendors which of the documentation items they will provide under contract and what evidence supports each one.

Generative AI without an acceptable use policy

Generative AI systems can produce content that the organization never intended to allow, yet many deployments have no written acceptable use policy on record. NIST AI 600-1 lists suggested actions under GOVERN 1.4 for policies and mechanisms that prevent generation of child sexual abuse material, non-consensual intimate imagery and other unlawful content, along with transparent acceptable use policies that address illegal uses. Write the policy before launch, publish the parts users must follow, and record the technical controls that enforce each prohibited use. Confirm the rule covers both internal staff and external users.

Questions buyers ask about GOVERN 1.4

How much effort does GOVERN 1.4 take to meet?

Effort depends mainly on how many AI systems are in scope, how much documentation already exists, and how many teams must agree on one format. GOVERN 1.4 asks for transparent risk management policies, procedures and controls tied to risk priorities, so the bulk of the work is writing and standardizing documentation rules, building a model documentation inventory, and deciding what risk material is disclosed publicly. Costs have three parts: staff time from the organization, any outside help for drafting and implementation, and the recurring upkeep of documentation as systems change. Ask any provider to break its quote into these parts and to state which systems and documents are included.

How long does the GOVERN 1.4 work take?

Duration depends on the written scope and the number of AI systems in it, and no figure is given here. A narrow scope covering a few systems with existing documentation will move faster than an enterprise-wide standard that must cover every AI system and business unit. Timing also depends on how quickly leadership approves the documentation policy and disclosure rules, since those decisions often gate the rest of the work. Ask for a timeline tied to specific deliverables, such as the policy, the documentation template, the inventory and the disclosure decision, along with the dependencies each one needs from your side.

What does the work need from our staff?

The work needs time and decisions from several roles, not only from the security or engineering team. Legal and compliance staff must define what documentation and public disclosure the organization owns. Product owners and data scientists must supply the facts that go into each model record, such as business justification, training data, testing results and dependencies. Risk owners must confirm how risk priorities are set. Leadership must approve the policy and the disclosure rules. Ask the provider to name the people it needs, how many hours each review cycle will take, and who signs off each deliverable.

Can our internal team do GOVERN 1.4 without a partner?

Yes, an internal team can do this work if it has the authority to set policy and access to the people who maintain each AI system. The NIST AI RMF is voluntary and has no certification, so the organization owns its own controls and decides how to meet them. Internal teams often struggle with the time needed to standardize documentation across business units and to keep it current. An implementation partner can prepare templates, configure documentation tooling, and set up the inventory, but the organization remains responsible for the content and the decisions. DeployOpen plans and implements these systems inside the client's own infrastructure under a fixed-scope written agreement.

Is there an AI RMF certificate for GOVERN 1.4?

No. There is no AI RMF certification, and no certification body issues one. NIST does not validate or endorse any individual organization or its approach to using the AI RMF, and it describes no certification, accreditation or conformity assessment program. Any claim of AI RMF certification should be treated with caution. If a customer or regulator asks for evidence, the organization can show its documented policies, documentation records and disclosure decisions, and an independent assessor can review them. DeployOpen prepares systems and evidence but does not issue reports or certificates.

Can the same documentation serve ISO/IEC 42001 or EU AI Act evidence?

Some of it may, but confirm the mapping for the specific requirement with your assessor before relying on it. Model documentation, a documentation inventory and disclosure rules are useful inputs for other AI governance frameworks, including ISO/IEC 42001 and the EU AI Act. However, each framework asks for its own evidence, and an overlap in documents does not mean an overlap in requirements. Ask your assessor or the relevant regulator which records they will accept, which fields they expect, and how often records must be updated. Tooling can help track this, but it does not replace a requirement-by-requirement review.

What should we ask for in a written quote?

Ask for a fixed scope that lists the AI systems covered, the documents to be produced, the templates and tooling to be set up, and the disclosure decisions to be supported. The quote should separate one-time work, such as drafting the policy and building the inventory, from recurring work, such as review cycles and documentation updates. Ask which tasks the provider performs, which the organization must perform, and which need an independent assessor. Also ask about assumptions on existing documentation, what happens if scope grows, how changes are approved, and who owns the final documents and the hosted tooling after the engagement ends.

How DeployOpen prepares GOVERN 1.4 evidence

DeployOpen helps organizations set up the documentation policies, standard templates, model documentation inventory and disclosure rules that GOVERN 1.4 calls for, using self-hosted open-source platforms in the client's own infrastructure. The organization owns its policies and decisions, and an independent assessor or auditor is the only party that reviews and reports on them.

How we scope

The written scope names which AI systems, teams and documentation types are covered for GOVERN 1.4.
Scope defines the documentation fields, such as business justification, training data, testing results and dependencies, agreed before work begins.
Engagements are fixed-scope, with deliverables and timelines confirmed in writing before any work starts.

How we build

We configure self-hosted wiki platforms such as XWiki to hold versioned policy and documentation pages.
We set role-based permissions in tools like BookStack so owners can edit and reviewers can approve documentation.
We set up a model documentation inventory and templates that standardize entries across the organization.

How we hand over

Handover includes configured platforms, templates, permission models and the documentation inventory for the client to run.
We document the procedures for version history review, rollback and public disclosure decisions the client's owners approve.
Evidence packages map each GOVERN 1.4 artifact to its owner, so the organization can show its controls to an assessor.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the initial handover.
Retainers can cover platform upgrades and periodic checks that documentation stays current with the AI inventory.
Ask the provider which parts of the documentation review, such as expert validation or independent assessment, remain with your own staff or an outside assessor.