MANAGE 1.4 Documenting residual risks: evidence guide

What MANAGE 1.4 asks for and why residual risk documentation is hard

MANAGE 1.4 expects an organization to document the negative residual risks that remain after its AI risks have been treated, and to disclose them to the downstream acquirers of its AI systems and to end users. If a customer, regulator or internal risk committee asks what is still open, the answer should be a written record, not a recollection. The AI RMF is voluntary, and no certification program exists for it, so no outside body will confirm that this record is complete. The organization owns the outcome, and an implementation partner can help prepare the record and its supporting evidence, but the decision to accept each remaining risk belongs to the organization. NIST AI 100-1, Section 1.2.3, defines residual risk as the risk remaining after risk treatment. In plain terms, it is the sum of every risk that was not fully mitigated: risks the team accepted, risks it transferred to a vendor or insurer, and risks it reduced but did not eliminate. The framework's reason for recording it is that a provider who must write down what is left tends to consider deployment risk more fully, and end users learn what harm they could still face. Negative residual risk is the part that matters most for disclosure. The difficulty is usually record keeping, not analysis. Teams tend to log mitigations, controls and test results in tickets or model cards, but not the residual position that results from them. Accepted risks often live in an email thread, transferred risks sit in a contract clause no one linked to the system, and partial mitigations are recorded as closed. A useful first check is to pick one high-priority risk from the MANAGE 1.3 response plan and trace whether its remaining exposure, owner and disclosure recipient can be found in one place.

Which systems, teams and third parties fall under MANAGE 1.4

MANAGE 1.4 applies to each AI system you build, buy or adapt, so the first decisions are about which systems get a residual risk register, who receives the disclosures, and who signs off the response plans. Each decision below changes how much documentation you produce and who has to maintain it.

Systems with a residual risk register

Decide which AI systems need a residual risk register. Built in-house, bought and fine-tuned third-party models each carry residual risk, but the register differs in what the organization controls. For a system you build, you own every mitigation and must record what remains after treatment. For a bought system, the vendor's residual risks still matter to you, and you record the ones you accept, transfer or only partly mitigate through configuration, access rules and monitoring. Fine-tuned models usually need both views. Confirm the inventory from GOVERN 1 is complete before you scope the register, since an unlisted system cannot be disclosed.

Downstream acquirers of the system

Identify who acquires the system from you downstream. This may be an internal business unit that deploys a model you built, a customer that licenses your product, or a partner that embeds your component. Each acquirer receives a different disclosure, so the list should come from your contracts and distribution paths, not from memory. Record which acquirers receive the residual risk statement, the safe operation requirements and the known limitations. Where a system passes through several resellers, decide whether the disclosure is passed on in full or only at the first tier, and write that decision into the register.

End users and affected groups

Define who counts as an end user for each system. Employees using an internal assistant, customers interacting with a service and people affected by a decision the system informs are all candidates, and their exposure to negative residual risk differs. The documentation burden grows with the number of distinct user groups, because each group needs disclosure that matches how it encounters the system. Note which groups have no direct contact with the system but are still affected, and decide whether they are covered by the register or handled through separate impact assessment under MAP 5.

Teams that own response plans

Assign the team that signs each risk response plan. In many organizations, engineering owns the technical mitigations, a risk function owns the acceptance decisions and a product or business owner signs the disclosure text. The register is only as reliable as these sign-offs, so record the named owner, the decision made (accepted, transferred, minimally mitigated or fully mitigated) and the date of review. Where teams split ownership of one system, the handoffs become the documentation risk. Ask who can accept a residual risk on behalf of the organization and whether that authority is written down.

Third-party components with their own residual risks

Decide how third-party components enter the register. A model, dataset, plug-in or hosted API may carry residual risks its provider has documented, and you inherit those risks when you integrate it. Request the provider's disclosed limitations and safe operation requirements, then record which ones reach your users. Cross-reference this with the GOVERN 6 supply chain controls and MANAGE 3 monitoring. Expect the register to grow when a component changes, so set a trigger for updating entries when a provider releases a new version or revises its documentation.

How an assessor tests residual risk documentation

This table compares four assessor tests of MANAGE 1.4 residual risk documentation, with the evidence each test requests and the findings auditors commonly raise. The AI RMF has no assessor program, so the reviewer is an internal audit team, a customer's auditor or a third-party assessor the organization engages, and the organization owns the record being tested. Read each row as a sample-based walk from the residual risk record to the materials that actually reached downstream actors.

Test	Evidence requested	Common findings
Confirm the residual risk record covers accepted, transferred and minimally mitigated risks	The residual risk register for the AI system, the risk response plan it draws on, and the treatment category recorded for each entry	Register lists only fully mitigated risks; accepted or transferred risks are missing; no owner or rationale recorded for accepted items
Trace a sample of residual risks to a risk response plan and its approval	Selected register entries, the matching response plan sections, and dated sign-off by the accountable decision maker	Plan exists but cannot be linked to a register entry; approval is undated or signed by someone without authority; plan predates the latest system change
Check that disclosure procedures exist and were followed for a named downstream actor	The written disclosure procedure, the distribution record for a named acquirer or deployer, and the version of residual risk content sent	Procedure is undocumented; distribution record is missing; the recipient received an earlier version without the latest residual risks
Check that safe operation requirements, known limitations and warning labels appear in materials for acquirers and users	Product documentation, user interface text, model cards or deployment guides, and the warning label text compared against the register	Limitations recorded internally but absent from customer materials; warning labels exist in a draft only; wording in the materials does not match the register

How to build a residual risk record that holds up to review

This sequence turns the outputs of MAP and MEASURE into a residual risk record that names what remains after treatment, who accepted it, how it reaches downstream AI actors and end users, and when it must be reopened. Each step closes with an artifact that a reviewer can trace back to a decision.

Inventory the risks that remain after treatment
For each in-scope AI system, list every risk that still exists once controls are applied, drawing on the MAP and MEASURE records for that system. Include risks that were accepted, transferred or only minimally mitigated, because the Playbook suggests recording all three. The output is a residual risk register entry per system, with each item tied to the originating risk and its current rating. The step is done when every high-priority risk from MAP has a residual entry, even if the entry says the risk is unchanged.
Record the treatment decision and approver
For each residual risk, record whether it was accepted, transferred, minimally mitigated or otherwise treated, the rationale, and the named person who approved that position. Link the decision to the response plan that MANAGE 1.3 requires, so the reviewer can follow the path from identified risk to accepted residual. The output is a risk response plan section with an approver name, role and date. The step is complete when no residual item lacks a recorded decision and an accountable approver.
Define the disclosure procedure and recipients
Write the procedure that determines how residual risks reach downstream AI actors, such as acquirers, integrators and deployers, and how they reach end users. Name the recipient groups for each system, the channel used, the content of each notice and who is responsible for sending it. The Playbook suggests setting these procedures explicitly. The output is a disclosure procedure document with a recipient list per system. The step is done when a reviewer can identify who receives each category of residual risk and who signed off on the procedure.
Write safe operation requirements and known limitations
For each system, state the conditions under which the system is expected to operate safely, the operator skills or oversight needed, and the known limitations that the MEASURE evidence revealed. Keep each statement tied to a test result, incident or documented assumption so that it can be checked. The output is a safe operation and limitations statement per system, written in language that a deployer can act on. The step is complete when each limitation has a source reference and each operational requirement has an owner in the downstream documentation.
Draft suggested warning labels
Where a residual risk could affect end users, draft the warning or notice text that downstream actors should display, and record where each label applies. Confirm wording with legal, product and the teams responsible for user communication, since the labels must match what the system actually does. The output is a warning label register listing each label, its trigger condition and its placement. The step is done when every label traces to a residual risk and has been reviewed by the approver named in the previous step.
Set a review trigger tied to monitoring
Define the events that reopen the residual risk record, such as a monitoring alert, a new end user problem report, a material change to the system or a change in its operating context. Assign the owner who watches each trigger and the path for returning the record to the approver. The output is a review trigger schedule linked to the monitoring plan. The step is complete when every residual risk has at least one trigger and the monitoring plan references the record, so that the document stays current rather than being filed once.

Which evidence shows MANAGE 1.4 is met and how to keep it current

MANAGE 1.4 is shown by records of the organization's own residual risk decisions, not by a policy statement that residual risk exists. The six artifacts below connect to one another: the register feeds the response plans, the response plans feed disclosures, and every disclosure rests on approved limitations text. Each card explains what to keep current between assessments.

Residual risk register entries

Each entry records a risk that remains after treatment, the system and version it applies to, the affected downstream actors and end users, and the owner who accepted it. Because AI 100-1 defines residual risk as the risk remaining after risk treatment, an entry should state what treatment was applied and what is left over. Review entries whenever a model is retrained, a dataset changes or a monitoring finding reopens a risk. Check that the register totals match the sum of unmitigated risks described in the MANAGE 1.4 outcome.

Risk response plans with accepted risks

Response plans show which residual risks were accepted, transferred to a third party or only minimally mitigated, and why. Illustrative example: a plan might accept a known error rate on a low-stakes use while transferring liability for a vendor component through contract terms. Update the plan when a vendor changes a model, when an incident shows a mitigation failed, or when the risk tolerance set under GOVERN 1 changes. Record the decision date and the decision maker for each change.

Residual risk disclosure procedure

This written procedure sets how residual risks reach downstream AI actors, including who drafts the disclosure, who approves it, which channel is used and how quickly updates follow a change. The Playbook suggests procedures for informing downstream AI actors of residual risks, so the procedure should name the trigger events, such as a new release or a newly confirmed limitation. Review it at least when the organization's deployment or buyer base changes, and confirm the owner still exists.

Disclosure records to named actors

These records prove that specific downstream acquirers and deployers received specific residual risk information. Each record should list the recipient, the system version, the date sent, the content version and any acknowledgment received. Tie new records to model changes, incidents and monitoring findings so that a disclosure follows every material change rather than the annual review cycle. Keep the record of what was not sent to a recipient when a version was withheld for a stated reason.

Safe operation and limitations statements

These statements tell acquirers and end users how to operate the system safely, what it cannot do reliably and which warning labels apply. The Playbook suggests informing downstream actors of safe operation requirements, known limitations and suggested warning labels, so each statement should map to a named residual risk in the register. Store every statement under version control so an auditor can see what changed, when and who approved it. XWiki and BookStack both keep page history and role-based editing that support this, though the organization must confirm the configuration it uses.

Approval records for residual risk decisions

Approval records show that an accountable role reviewed and signed off on accepted residual risks, transfers and disclosure content before release. The approver should match the authority set under GOVERN 2, and the record should state the evidence reviewed, the conditions attached and any expiry date for the acceptance. Refresh approvals when conditions change or when an acceptance reaches its review date. An approval that cites only a generic statement, rather than the specific residual risk, does not show a decision was made.

What meeting MANAGE 1.4 costs in money and effort

This table lists the cost components behind documenting residual risks for downstream acquirers and end users, who is paid for each, whether it is one-time or recurring, and what to ask for in a quote. No fee or duration is supplied for this requirement, so the figures for your environment must come from your own scope and your own staff estimates. Read the table as a checklist of what to price, not as a budget.

Cost component	One-time or recurring	What drives it up or down	What to ask for in a quote
Tooling and licenses	Recurring license or subscription where a commercial GRC tool is used	Number of AI systems in scope and number of users who edit residual risk records. Self-hosted open-source tools remove license spend but not configuration or hosting work.	Itemized license terms, hosting components, and the platform owner's effort to configure and back up the records
Engineering setup of the record	One-time, with later changes	Number of AI systems, how many risk response plans exist, and whether residual risk fields link to the AI inventory and monitoring data	Deliverables for templates, workflows, version history settings and access roles, with the named owner of each
Risk and product staff time	Recurring, tied to each release and review cycle	How often systems change, how many accepted or transferred risks exist, and how many disclosure channels must be kept current	Hours or effort assumptions per release, per review cycle and per disclosure update, stated in your own staff plan
Downstream disclosure materials	Recurring with each release or material change	Number of downstream acquirers and end user groups, and whether safe operation requirements, known limitations and warning labels differ by audience	Scope of documents produced, review rounds included, and who approves wording before release
Evidence upkeep	Recurring	Frequency of record reviews, retention rules, and how much history must be kept to show what changed, when and by whom	Retention period you require, the review calendar, and how version history and access logs are preserved and exported
External review of the residual risk record	Recurring or per engagement, if used	Whether legal, privacy or an independent reviewer checks the wording and whether the review covers all AI systems or a sample	Reviewer credentials, scope of the review, and whether findings are written up as a dated deliverable
Auditor or assessor sampling	Set by the assessor, usually per engagement	How many residual risk records the assessor selects, how many systems are in scope, and how complete the audit trail is	Assessor's sampling approach and evidence list in writing before fieldwork, confirmed with the assessor directly

Which self-hosted open-source tools support residual risk evidence

Residual risk documentation under MANAGE 1.4 is a register, a disclosure record and an approval trail, and no single tool covers all three. The cards below describe three self-hosted open-source tools that can each hold part of that evidence, and what your team must still configure and confirm before relying on them.

Risk register in CISO Assistant

CISO Assistant (AGPL-3.0-only) ships more than 200 frameworks, including ISO 27001, NIST CSF, SOC 2, PCI DSS, NIS2, DORA and GDPR, and runs audits and compliance assessments against them with automatic mapping between frameworks. For MANAGE 1.4, it can hold the residual risk register and link each accepted or transferred risk to the controls and assessments it relates to. Your team must configure the risk entries, owners and treatment decisions, and confirm in your own environment that the mappings and audit records meet your assessors' expectations. The AGPL-3.0-only license requires care if you modify and distribute the software or offer it to users over a network.

Versioned disclosure pages in XWiki

XWiki (LGPL-2.1-or-later) 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. This suits the documents that disclose residual risks to downstream acquirers and end users, including known limitations, safe operation requirements and suggested warning labels. Your team must decide which pages are the approved disclosure versions and confirm that the version history is retained as your evidence policy requires. The LGPL-2.1-or-later license is generally permissive for use, but you should confirm its obligations with counsel if you modify the code.

Approval workflow with BookStack

BookStack (MIT) assigns user abilities through roles, and permissions can be overridden per role at the shelf, book, chapter or page level. For MANAGE 1.4, this lets you separate the people who draft residual risk disclosures from the people who approve and publish them, so no single author can release a disclosure unreviewed. Your team must define the roles, set the page-level overrides, and test that drafters cannot publish. Confirm the exact permission behavior in your installed version, since BookStack's documentation describes the model and your configuration determines the outcome. The MIT license places few conditions on use or modification.

Who owns residual risk decisions and who can prepare the evidence

Your organization owns the residual risk record. Under MANAGE 1.4, the question is which unmitigated risks remain after treatment, who accepted them, and what downstream acquirers and end users are told. Those answers depend on the organization's risk tolerance, its contracts and its obligations to affected people, so they cannot be delegated to a vendor or consultant. Leadership with authority to accept risk should sign off on each accepted or transferred item, and the people who operate the system should confirm the safe operation statements match how it actually runs.

Risk acceptance decisions: Named owners approve each accepted, transferred or minimally mitigated risk and record the rationale.
Disclosure content: Your legal, product and compliance leads decide what downstream AI actors and end users are told about known limitations.
Safe operation requirements: Operations and product owners write and maintain the conditions under which the system should and should not be used.
Warning labels and review cycles: Your team decides suggested warnings and how often the residual risk register is re-approved.
Accountability for changes: Internal owners approve updates when the system, its data or its users change.

Check that every residual risk entry names an internal approver, a date and a review trigger, because these are the items an assessor will ask you to explain in person.

Where organizations fall short on residual risk documentation

Residual risk documentation under MANAGE 1.4 tends to fail in the handoffs: between the risk register and the response plan, between the deploying team and the acquirers and users who rely on it, and between each model change and the limitations that were written for the previous version. The cards below describe the gaps we see most often and what closes each one.

Residual risks recorded only as mitigations

Many registers list the controls added to treat a risk but never state what risk remains afterward. MANAGE 1.4 asks for the residual risk itself, defined in NIST AI 100-1 as the risk remaining after risk treatment. For each high-priority risk, record the treatment, the remaining likelihood and impact, and the reason the remainder is acceptable. Ask the team to show one residual figure per risk, not a list of controls.

Accepted risks with no named approver

Risks that are accepted, transferred or only partly mitigated often appear in a plan with no owner. The Playbook suggests noting these explicitly in risk response plans. Each accepted residual risk should name the accountable executive, the date of the decision and the review trigger. Check whether an approver can point to the decision record without asking the people who wrote it.

Disclosures without a version record

Acquirers and downstream deployers often receive known limitations and warning labels by email or in a slide deck, and nobody records which version went out. When the system changes, the team cannot show which party received which limitations. Keep disclosure documents under version control with a dated record of each recipient, the version sent and the acknowledgment received.

Safe operation requirements not updated after model changes

Safe operation requirements are written for the system as it was tested. A new model version, prompt change or retrieval source can alter the behavior those requirements assume. Tie each requirement to the system version it describes, and make a change request trigger a review of the requirements and warning labels before release. Ask who signs off that the text still matches the deployed system.

Third-party residual risks invisible to the deployer

A deploying team may inherit residual risks from a pre-trained model, a vendor API or a data source without seeing the supplier's limitations. Those risks are part of the residual risk the deployer must document for downstream users. Collect each component supplier's documented limitations and safe use conditions, record them in the same register, and flag any the supplier does not provide.

Access to disclosures not controlled by role

Residual risk records often sit in shared drives where anyone can edit the limitations or view unreleased risk decisions. Use role-based permissions so that owners can edit, approvers can sign off, and external recipients see only the approved disclosure. Review who holds each role at least on the schedule your risk policy sets, and confirm that the platform you use can restrict access at the page or book level.

Questions buyers ask about MANAGE 1.4 before bringing in help

How much effort does documenting residual risks under MANAGE 1.4 take?

The effort depends mostly on how many AI systems are in scope, how many risks were accepted, transferred or only minimally mitigated in earlier work, and how many downstream parties receive the disclosures. A single system with a short, current risk register is a small exercise. A portfolio with many third-party models, several deployment contexts and unresolved residual risks from MAP and MEASURE takes considerably more work, because each residual risk needs an owner, a stated rationale and a disclosure path. Ask any provider to break its quote into inventory review, risk response documentation, disclosure procedures and evidence collection so you can see where the effort sits.

How long does it take to document residual risks for AI systems?

No duration figure is available for this work, and any number quoted without a written scope should be treated with caution. The timeline is set by the scope: the number of systems, whether risk response plans already exist, how many decision-makers must sign off on accepted risks, and whether disclosure procedures for customers or end users must be written from scratch. Ask for a schedule with named milestones and dependencies, and confirm which steps wait on your own approvals or on input from legal, product and customer-facing teams.

What does the work need from our own staff?

Your staff must supply the knowledge an outside team cannot infer: the intended purpose of each system, which residual risks leadership has accepted, which downstream acquirers and end users receive the system, and what known limitations engineers have observed. Expect time from the product owner, the risk owner who can accept residual risk, someone from legal or contracts who controls customer disclosures, and an operations lead who can confirm safe operation requirements. Agree on these named roles before work starts, because undocumented decisions are the most common reason the record stays incomplete.

Can an internal team document residual risks without a consultant?

Yes, an internal team can do this work if it has people who understand the AI systems, the risk register and the customer disclosure obligations. The framework is voluntary and does not require outside help. An implementation partner is useful when the team lacks time, when the record must be built across many systems, or when you want the documentation tooling configured and the evidence organized for an assessor. In any arrangement, the organization owns its risk decisions, and an independent auditor or assessor, not a consultant, reports on whether the controls work.

Can the NIST AI RMF be certified, and can we get a certificate for MANAGE 1.4?

No. The NIST AI RMF is a voluntary framework with no certification, accreditation or conformity assessment program, and NIST does not validate or endorse any organization's use of it. No certification body issues an AI RMF certificate for MANAGE 1.4 or any other subcategory. What you can produce is documented evidence that your residual risk records and disclosures exist and are maintained. Be wary of any vendor or consultant that offers an AI RMF certificate, and ask them to name the body that issues it.

What happens to our residual risk record when the AI RMF is revised?

NIST says AI RMF 1.0 is being revised as part of the White House AI Action Plan and has not yet published a revised version, so the subcategory wording and the Playbook guidance may change. Because the Playbook has not been updated since August 2023, its suggestions for MANAGE 1.4 may also shift. The residual risk record itself is your own work product, so keep it in a version-controlled system with dated entries and clear owners. When the revision is published, map your existing records to the new text, record what changed, and confirm with your auditor or customers which version they expect you to reference.

How DeployOpen prepares residual risk evidence for MANAGE 1.4

DeployOpen helps organizations prepare the systems and records that show how residual risks are documented and disclosed for MANAGE 1.4. The organization owns its risk decisions and disclosures, and DeployOpen works inside the client's own infrastructure to set up the records that support them. Only the organization's own governance and an independent assessor can judge whether the outcome is met.

How we scope

The written scope names which AI systems, risk response plans and downstream disclosure channels are included for MANAGE 1.4.
Scope lists which accepted, transferred and minimally mitigated risks must be recorded and who approves each one.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.

How we build

We configure a self-hosted wiki or documentation platform in your environment to hold residual risk registers and versioned disclosure notes.
We set role-based permissions so risk owners, reviewers and downstream-facing teams each see and edit only what they need.
We set up templates for safe operation requirements, known limitations and suggested warning labels for each AI system in scope.

How we hand over

You receive the residual risk documentation, templates, access model and configuration records in a format your team can maintain.
We document the procedure for disclosing residual risks to downstream AI actors, including who reviews it and how changes are approved.
Handover includes a walkthrough so your teams can keep the records current without outside help. Ask your assessor which artifacts they expect to sample.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, agreed separately from the initial written scope.
Retainers can cover periodic reviews of residual risk registers as systems, deployment contexts or known limitations change.
Before engaging, ask any implementation partner how it keeps records current and which decisions stay with your own risk owners.