MANAGE 2.2 sustaining value of deployed AI systems

What MANAGE 2.2 asks for after an AI system goes live

MANAGE 2.2 asks that mechanisms be in place and applied to sustain the value of deployed AI systems. For a compliance lead or engineer whose system is already in production, that means the controls you set at launch must keep working after launch. The risk it addresses is decay: data distributions shift, users find new ways to use the system, attackers probe it, and business rules change, so a system that was valid and safe at go-live can quietly drift away from what was approved. This is harder than launch work because it has no finish line. It needs owners, recurring checks and a record that shows the checks happened. NIST AI 100-1 is voluntary, and there is no AI RMF certification. Your organization owns the outcome, and any outside party can help prepare evidence, but only an independent auditor or assessor can issue a report on it.

The Playbook suggests a set of control areas for MANAGE 2.2, and each one needs a named owner and a recurring check. Start with data quality and privacy: confirm that input pipelines still meet the quality and privacy rules approved at launch, and log changes to data sources. Next, cover ML and endpoint security countermeasures, such as monitoring for adversarial inputs, restricting model and API access, and patching the serving infrastructure. Then define business rules that limit outputs in certain contexts, for example blocking decisions outside an approved use case or routing edge cases to a person. Keep TEVV protocols and standardized documentation current so that re-testing after a change produces comparable results. Capture user feedback during deployment, and review insurance, warranties and contracts for risk transfer, because those documents determine who bears a loss if the system fails.

The Playbook tags MANAGE 2.2 to four AI actor categories: AI Deployment, AI Operation and Monitoring, AI Impact Assessment, and Governance and Oversight. Practically, the people who deploy the system should own rollback and change records, the people who operate and monitor it should own drift and incident signals, impact assessors should revisit whether harms have changed, and governance should approve changes to risk tolerances and contracts. Confirm with your own AI actor mapping (the roles in AI 100-1 Appendix A) that each category has a named person. The Playbook is a voluntary companion with suggested actions, not a checklist, so use it to decide what to evidence for your system, and record which actions you chose not to adopt and why.

Which deployed systems, data and third parties fall under MANAGE 2.2

NIST AI RMF is voluntary, so the scope of MANAGE 2.2 is set by your own risk tolerance and the obligations you have accepted, not by an external test. The cards below are the decisions that change how much work sustaining value of deployed systems turns out to be.

Which systems count as deployed

Start with a written definition of deployed, covering systems that serve real users, make or support decisions, or feed other systems, including pilots with live data. Then match that definition against your AI inventory, which should list each system, its owner and its operating status. Systems in a sandbox or retired systems that still hold data or keys often fall outside the list by accident. Ask who signs off on the list and how often it is refreshed.

Data pipelines and retrieval sources

Every training set, fine-tuning corpus, retrieval index and live input feeds a deployed system and can degrade it. Document where each source comes from, who may change it, and how quality and privacy checks run on it after go-live. For retrieval-augmented systems, include the document stores and the update jobs that refresh them, because a stale or poisoned index changes outputs without any change to the model.

Teams that operate and monitor

Name the team that runs each system day to day, the team that watches its outputs, and the team that can stop it. These are often different groups, such as a platform team, a data science team and a security operations team. MANAGE 2.2 work fails when monitoring alerts reach no one with authority to act. Confirm the handoffs in writing and test them with a tabletop exercise before an incident forces the question.

Third-party models and vendor components

Pre-trained models, hosted APIs, embedding services and vendor plug-ins are components you operate but did not build. Inventory each one with its version, its update channel and the contract that governs changes. A vendor model update can alter behavior without any change on your side, so confirm how you will be notified of changes and whether you can pin a version. This inventory links to the third-party work described under MANAGE 3.

Insurance, warranties and contracts

Risk transfer arrangements shift part of an AI risk to someone else, but only for the losses the document actually covers. Review insurance policies for exclusions tied to AI or automated decisions, vendor warranties for accuracy or uptime commitments, and indemnity clauses for data and output liability. Record which risks remain with your organization after these terms are applied, since the Playbook suggests reviewing these arrangements as part of sustaining value.

Generative AI and the NIST AI 600-1 actions

If a deployed system generates text, images, code or other content, the NIST AI 600-1 Generative AI Profile adds suggested actions under MANAGE 2.2, numbered MG-2.2-001 to MG-2.2-009. Decide whether your organization will adopt these actions in full, adapt them to its risk tolerance or document a reason for setting them aside. Note that the profile is a supplement to the core framework, and that its actions cover content risks such as harmful output and content lineage that traditional monitoring may not capture.

How an assessor tests MANAGE 2.2 in practice

This table compares the control areas under MANAGE 2.2, showing how an assessor samples each one, what records they request and where findings usually appear. No NIST body issues a certificate, so the reviewer is an internal reviewer, a contracted auditor, or a customer or regulator's reviewer, and each tests against the organization's own stated controls. Read each row as a sampling plan: the stronger the monitoring and change records, the fewer follow-up questions.

Control area	How the assessor tests it	Evidence requested	Common findings
Data quality and privacy	Samples a deployed system and traces its input data back to the quality checks and privacy controls set at deployment	Data quality monitoring reports, data change logs, privacy review sign-offs for recent data sources	Quality thresholds exist on paper but no monitoring runs against production data
ML and endpoint security countermeasures	Selects a sample of deployed endpoints and checks that the countermeasures listed in the design are running and were tested after the last change	Configuration baselines, vulnerability scan results, records of adversarial or injection testing	Security testing predates the most recent model or prompt change
Business rules limiting outputs	Picks contexts where the system is restricted and checks that the rule fired as written	Rule definitions with version history, sample logs of blocked or escalated outputs, rule owner approvals	Rules are documented but no owner reviews whether they still match the approved use
TEVV protocols and monitoring	Compares the test and monitoring schedule to what ran, then reviews a sample of results and the actions taken on them	TEVV plans, monitoring dashboards, test run records, follow-up tickets for failed checks	Monitoring is configured but alerts are not triaged or closed out
Standardized documentation	Checks that the documentation matches the deployed version and that changes were recorded before release	Model and system cards, change logs linked to releases, document review history	Documentation describes an earlier version than the one in production
Feedback capture during deployment	Follows a sample of user reports from intake to resolution and checks whether they reached the risk owner	Helpdesk tickets, feedback categories, trend reports, records of escalation to the AI team	Feedback is collected in one tool but never reviewed in the risk forum
Risk transfer review	Reviews insurance, warranties and third-party contracts for the system and checks that coverage terms were reviewed on schedule	Current policies or contracts, review minutes, records of coverage gaps and decisions taken	Contracts were signed at purchase and never revisited after scope changed
Risk acceptance decisions	Selects residual risks accepted in the period and checks the approval, the rationale and whether the acceptance was revisited	Signed acceptance records, risk register entries, expiry or review dates	Acceptances have no expiry date and cover risks the monitoring now shows as worse

Sequence for sustaining value after deployment

This sequence turns the MANAGE 2.2 outcome, that mechanisms are in place and applied to sustain the value of deployed AI systems, into a set of owned steps with a named output at each stage. The Playbook is a voluntary companion rather than a checklist, so the organization chooses which steps to adopt, how to order them, and how deeply to apply each one.

Confirm the value and risk baseline
Start from the results of the MAP and MEASURE work for the system: its intended purpose, the benefits it was approved for, the most significant mapped risks, and the metrics chosen to track them. The accountable system owner and the risk function confirm that these baselines still describe the system as deployed. The output is a signed baseline record that names the value the system must keep delivering and the thresholds that would signal it has stopped doing so.
Define risk controls for each area
Assign a control owner to each area the Playbook names for MANAGE 2.2: data quality and privacy, security countermeasures for machine learning and endpoints, and other risks in the baseline. For each area, record the control, the failure it prevents, how it is monitored, and who responds when it fails. The output is a control register that maps every baselined risk to at least one control and one owner.
Set business rules and output limits
Define the business rules that limit what the system may output or do in specific contexts, such as restricted use cases, confidence thresholds that trigger human review, and categories of content or decisions that require escalation. Business and legal stakeholders approve the rules, and engineering encodes them in the deployment. The output is a versioned rule set, with each rule traced to a risk in the control register.
Establish TEVV protocols and documentation
Set the test, evaluation, verification and validation protocols that run before and after changes to the system, and fix a standard documentation format for the results. Testing teams record which tests run, against which data, with what pass criteria, and who signed off. For generative AI systems, the Generative AI Profile's suggested actions for MANAGE 2.2 can inform these protocols. The output is a TEVV protocol document and a template that every test report follows.
Set up feedback capture during deployment
Establish channels that collect feedback from users and operators while the system runs, including error reports, complaints and observed misuse, and route them to a ticketing or case system with an owner. Monitoring data such as traces or logs can support this work, but each feedback item must reach a human who assesses it against the baseline. The output is a documented intake process and a log showing how each item was triaged and whether it changed a control or rule.
Review insurance, warranty and contract terms
Review the insurance, vendor warranties and contracts that allocate risk for the system, including terms with model, data and platform providers. Legal and procurement confirm what each arrangement covers, what it excludes, and whether any residual risk falls back on the organization. Ask counsel and brokers to confirm coverage in writing rather than relying on summaries. The output is a risk transfer register listing each arrangement, its gaps, and the owner of each gap.
Schedule periodic review with named owners
Set a review cadence for the baseline, controls, rules, TEVV results, feedback log and risk transfer register, and name the owner for each review. The reviewers compare current performance with the baseline, decide whether controls still fit, and record changes that require re-testing or deactivation planning under MANAGE 2.3 and MANAGE 2.4. The cadence should be set by the organization, based on the system's risk and the pace of change. The output is a dated review record with decisions and assigned actions.

What the generative AI profile adds to MANAGE 2.2

NIST AI 600-1, the Generative AI Profile published July 26, 2024, adds nine suggested actions under MANAGE 2.2, numbered MG-2.2-001 to MG-2.2-009, and ties them to ten of the profile's twelve generative AI risks. The two risks without a MANAGE 2.2 action are Environmental Impacts and Value Chain and Component Integration. For an organization running a generative AI system, that gap matters: the sustainment controls in the base framework still need to be applied to the environmental and supply chain exposure of the model and its components through other subcategories of the profile. Confirm the exact wording of each action in the profile itself, since this section summarizes the intent rather than quoting the text.

Three of the actions show what the profile expects in practice. MG-2.2-001 asks the organization to compare generative AI outputs against its own risk tolerance and guidelines, which means the risk tolerance set under GOVERN 1 has to be written in terms specific enough to test outputs against. MG-2.2-005 covers analyzing outputs for harmful content, potential misinformation, CBRN-related content and non-consensual intimate imagery, so the team needs defined test sets, classifiers or review queues for each category, plus a record of what was checked and what was found. MG-2.2-007 calls for real-time auditing tools that track content lineage, so the logging layer must capture enough about where an output came from to trace it after the fact. A useful first check is whether your current traces record the prompt, retrieved sources, model version and tool calls for every production response.

Because the profile is a supplement to the base framework, the practical question is which of its nine actions your deployment already covers and which need a named owner. Map each action to an existing control, a ticket type and a review cadence, and record the gaps as residual risk. Open-source tooling can supply parts of this evidence. Langfuse traces record inputs, outputs, token usage and metadata for each operation, which can support MG-2.2-007 lineage questions, and garak produces JSONL reports and a hit log of probe attempts that can feed output analysis. Neither tool decides whether an output is acceptable under your tolerance, so that judgment and its documentation stay with the organization, and an independent assessor is the party that tests and certifies conformance, if one is required.

Evidence that shows sustained value and how to keep it current

MANAGE 2.2 is shown through records that link each deployed system's risk controls to decisions, tests and actions over time. The cards below cover the artifacts an assessor usually asks for and the habits that keep them current between reviews, since NIST AI 100-1 sets no fixed review schedule for this subcategory.

Risk control register with owners

A register lists each control applied to a deployed system across data quality, security countermeasures, business rules and documentation, with a named owner, the risk it treats and a next review date. Assessors check that every control traces to a documented risk decision and that the owner still holds the role. Keep it current by updating the register whenever a model, data source or deployment context changes, and by recording who approved each change.

TEVV protocol and results history

Test, evaluation, verification and validation records show which protocols ran on the deployed system, against which criteria, and what changed between runs. Assessors look for results that are dated, tied to the model version in production and linked to the risk they test. Ask whether the history includes failed runs and the decisions that followed, because a history with only passing results gives little evidence of sustained value.

Standardized documentation for each system

Each deployed system needs a standard record covering its purpose, data sources, known limits, controls, owners and change history. Assessors check that the documentation matches the system as it runs now, not the version at launch. The AI RMF Playbook offers documentation prompts for MANAGE 2.2, which teams can adapt, and the record should name where each prompt was answered.

Monitoring and alert records

Monitoring logs show what the system observed in production, which alerts fired and what responders did. Assessors look for alert thresholds tied to a documented risk tolerance, timestamps, and evidence of action such as a rollback, a business rule change or a ticket closed with a root cause. Open-source tracing tools such as Langfuse can record inputs, outputs and token usage per request, but the organization still has to define the thresholds and review the alerts.

User feedback logs and adjudication

Feedback captured from users during deployment, such as complaints, overrides and reported errors, forms a log that the team reviews and adjudicates. Assessors check that each item has a recorded outcome, whether the item led to a control change, a retraining decision or a rejection with reasons. Helpdesk platforms such as GLPI or Zammad can hold these tickets, and the reviewer should confirm that closed tickets carry the adjudication outcome, not only a status.

Risk transfer review record

The risk transfer record summarizes the insurance, warranties and contracts that shift some AI risk to others, such as vendors or insurers. Assessors check that the review happened after material changes, that coverage limits and exclusions were compared with the system's actual risks, and that gaps were assigned to an owner. Ask counsel and the risk function to confirm the contract summaries match the current scope of the system.

What meeting MANAGE 2.2 costs in money and effort

This table compares the main cost components of sustaining deployed AI systems under MANAGE 2.2, showing who is paid, whether each cost is one-time or recurring, what moves it, and what to request in a written quote. Read it as a checklist for scoping, since no fixed figures are published for these components and the largest variable is how many systems and data flows are in scope.

Cost component	One-time or recurring	What drives it up or down	What to ask for in a quote
Tooling and licenses	Recurring	Number of deployed systems, log volume and whether commercial monitoring or red-team products are chosen; open-source options such as garak, Langfuse, GLPI and Zammad can remove license fees	Itemized list of every license, its terms, and confirmation of the vendor's license terms for self-hosted use
Engineering time for monitoring and feedback capture	One-time build, then recurring upkeep	Number of metrics and drift signals tracked, how many user feedback channels feed the ticket system, and integration with existing SIEM or service desk tools	Named deliverables for monitoring dashboards, feedback intake and alert routing, with acceptance criteria
TEVV and red-team testing	Recurring, with a one-time baseline	Number of generative AI risks covered under the GAI Profile actions, test frequency after model or prompt changes, and whether testing is internal or contracted	Test plan listing scope, cadence, tools and report format, plus who reviews results
Documentation upkeep	Recurring	Frequency of system changes, number of AI actors who update records, and how often the Playbook or profile guidance is revisited	Documentation templates delivered, update responsibilities, and review schedule
Legal and insurance review of risk transfer	Recurring, usually at renewal or contract change	Number of vendor contracts, warranties and insurance policies covering AI systems, and the degree of change in each	Confirmation of which contracts and policies are in scope and whether counsel or the insurer performs the review
Internal operations and staffing	Recurring	Alert volume, incident handling load, and how many people hold monitoring duties across operations and governance	Estimated operating roles and responsibilities, with the organization's own staffing figures used for planning
External review and assessor time	Recurring or per engagement	Independent review scope, number of systems reviewed, and whether a third party validates metrics; NIST does not offer certification, so the review is a contracted assessment	Written scope, deliverables and whom the report is addressed to, with a statement that no certificate is issued

How garak, Langfuse, GLPI and Zammad produce MANAGE 2.2 evidence

MANAGE 2.2 asks for mechanisms that keep deployed AI systems delivering value, and an assessor will want records showing those mechanisms run in practice. The four tools below each produce a different kind of record: test results, runtime traces, incident and change tickets, and user feedback. Together they give an organization evidence to review, though none of them decides whether a control is adequate.

garak for TEVV test records

garak is an Apache-2.0 scanner that 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. For MANAGE 2.2, these files can serve as repeatable TEVV evidence for generative AI controls, provided runs are scheduled, versioned and kept. Confirm that probe coverage matches the risks in your own risk register, since a clean run only covers the probes that were executed.

Langfuse traces for monitoring

Langfuse (MIT) records a trace for each request, covering LLM calls, retrieval steps, tool executions and custom logic. Each trace carries timing, inputs, outputs, token usage and metadata. For MANAGE 2.2, traces show whether a deployed system behaves as it did at release, and they let reviewers trace a disputed output back to the retrieval and tool steps behind it. Check how long traces are retained, who can read inputs that contain personal data, and whether your monitoring design meets your privacy obligations.

GLPI incident and change records

The GLPI Assistance module (GPL-3.0-or-later) lets teams create, follow and process tickets, problems and changes using ITIL practices. It adds plannings, statistics, recurrent-ticket tracking and a Kanban view. For MANAGE 2.2, these records show that a control failure was logged, assessed, and resolved through a documented change to the AI system. Recurrent-ticket reports help show whether the same fault keeps returning. Confirm the GPL-3.0-or-later terms with your legal team before modifying the code, and confirm that your change workflow matches your internal approval roles.

Zammad feedback consolidation

Zammad (AGPL-3.0-only) is a web-based helpdesk that brings customer communication from email, chat, telephone and social media into one ticket system. For MANAGE 2.2, this gives an organization one place where user reports about AI outputs, including errors, complaints and feedback on business rules, are logged and tracked to closure. Those tickets are the feedback records an assessor will ask about. AGPL-3.0-only has network-use obligations if you modify and host the software, so confirm license fit with your legal team and your deployment design.

Who owns MANAGE 2.2 and what an implementation partner can take on

Your organization owns MANAGE 2.2. The subcategory asks that mechanisms are in place and applied to sustain the value of deployed AI systems, and only your accountable leaders can decide which residual risks are acceptable, which outputs a system may produce in each business context, and who answers when a control fails. These decisions depend on your mission, customers, regulatory exposure and risk appetite, which an outside party cannot set on your behalf.

Risk acceptance: Executives or the designated risk owner decide which residual risks remain after controls are applied and sign off on them.
Business rules: Product and operations owners define the output limits, escalation thresholds and prohibited use cases for each deployed system.
Feedback and incident response: Internal teams review user feedback, decide on corrective action and communicate incidents to affected parties.
Vendor and insurance review: Legal and procurement review warranties, indemnities, contracts and insurance that transfer risk to third parties.
Ongoing operation: Your staff run the monitoring, review the results and keep the documentation current after the partner hands over.

Before engaging anyone, confirm which of these roles already have named owners and written authority.

Questions buyers ask about MANAGE 2.2 before bringing in help

Can MANAGE 2.2 be certified?

No. The NIST AI RMF has no certification, accreditation or conformity assessment program, and NIST does not validate or endorse any organization or its approach to using the framework. MANAGE 2.2 is one subcategory of a voluntary framework, so there is no MANAGE 2.2 certificate to earn. What a buyer can ask for instead is evidence: documented risk controls, TEVV records, feedback logs and reviews of risk transfer arrangements that show the mechanisms are in place and applied. If a customer or regulator asks for proof, an independent auditor can test those records against a framework that does issue reports, such as ISO/IEC 42001 or SOC 2, but that auditor's report is not an AI RMF certificate. Confirm with any party who claims otherwise exactly what document they will issue.

How much does sustaining deployed AI systems cost?

No researched cost figure is available for this work, so treat any number you see with caution and ask for a breakdown. The cost has three parts: internal staff time for risk owners and reviewers, tooling and infrastructure for monitoring, logging and ticketing, and external help for design, implementation and testing. Some costs are one-time, such as initial control design and documentation. Others recur, such as monitoring, periodic TEVV runs, feedback review and contract reviews. Costs rise with the number of deployed systems, their risk level, the number of data sources and the amount of logging you need. Ask any partner for a written scope listing deliverables, the systems covered, the tooling assumed and which costs are one-time and which are retainers.

How long does a MANAGE 2.2 engagement take?

No researched duration is available for this work, so the honest answer depends on your environment. Duration usually depends on how many AI systems are in scope, how mature your data and logging already are, how many teams must agree on risk controls and business rules, and whether existing contracts need review. Initial control design and evidence collection take longer than ongoing operation, which is recurring. Ask for a written scope with a timeline tied to named deliverables and to the dependencies your team controls, such as access approvals and decision meetings. Implementation partners such as DeployOpen agree on scope, deliverables and timelines in writing before work starts.

What does MANAGE 2.2 require from our own team?

Your team owns the controls, so several roles must be named before any outside help starts. You need an accountable owner for each deployed system, a data or ML owner for data quality and privacy controls, a security owner for model and endpoint defenses, and a business owner who sets the rules that limit outputs in certain contexts. You also need read access to telemetry such as logs, traces and user feedback, plus a forum with authority to approve or stop changes. Decision time matters as much as access. If risk treatment decisions wait weeks for committee slots, the controls will not sustain value. Confirm these owners and time commitments in the scope before work begins.

Can we do MANAGE 2.2 ourselves without an outside partner?

Yes. The framework is voluntary, and nothing requires an outside firm to run it. An internal team with the right owners, telemetry access and decision authority can design and operate these mechanisms. Teams that do this often start from the NIST AI RMF Playbook, which is a voluntary companion and not a checklist, and map its suggested actions to their own systems. The main risks of doing it alone are gaps in TEVV rigor, inconsistent documentation across systems and reviews that never happen because nobody owns them. If you want an independent view of whether your evidence supports the subcategory, an outside assessor or auditor can test it, but that assessor does not certify the framework.

What should we outsource for MANAGE 2.2 and what should we keep?

Keep decisions, accountability and business rules in-house. Your organization owns its risk tolerances, its go or no-go calls and its contract positions. An implementation partner can take on work that is technical and repeatable:

Setting up logging, tracing and ticketing so feedback and incidents are captured consistently
Building the documentation templates and TEVV protocols that the controls rely on
Running security testing of models, applications and agents against the risks you have identified
Preparing evidence packs for an independent auditor to test

Keep in mind that a partner prepares systems and evidence, while only an independent auditor or certification body issues reports or certificates.

How does the Playbook relate to MANAGE 2.2, and will it change?

The Playbook is the voluntary online companion to the framework. It suggests actions, documentation prompts and references for each subcategory, including MANAGE 2.2, but NIST says it is neither a checklist nor a set of steps. Its audit log shows the last content update in August 2023, and AIRC has said it will be updated after the AI RMF is revised. Use the Playbook as a source of ideas for your own controls, and record in your documentation which suggested actions you adopted, adapted or declined. You can read the MANAGE 2.2 entry in the NIST AIRC Playbook for the Manage function to see the current suggested actions.

Will the planned NIST revision change MANAGE 2.2 wording?

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. The July 2025 AI Action Plan recommends removing references to misinformation, diversity, equity and inclusion, and climate change, so wording in the Manage function could change. NIST also expects a formal review with community input no later than 2028. Because the framework uses a two-number version scheme, a major revision would change the first number and a minor one would add a decimal. Practically, keep your MANAGE 2.2 controls tied to the risks you have mapped rather than to the exact subcategory wording, and track the revision so your documentation can be updated when it is published. Ask any partner how they will handle a wording change inside your current scope.

How DeployOpen works on this

DeployOpen helps organizations prepare the systems, controls and evidence that show MANAGE 2.2 Sustaining value of deployed systems is in place and applied. The organization keeps ownership of its risk decisions, and an independent assessor or auditor reaches any conclusion about the controls.

How we scope

Agree in writing which deployed AI systems fall within the MANAGE 2.2 scope and which teams own each control.
Confirm which data quality, security, business rule, TEVV and feedback controls already exist and which are missing.
Define the evidence the organization wants to show for each risk control, and who reviews it, before work starts.

How we build

Configure self-hosted tooling inside the client's own infrastructure, such as ticketing for feedback and incident handling.
Set up tracing and logging for deployed model calls so monitoring records inputs, outputs and metadata for review.
Document TEVV protocols and standardized documentation templates that the client's teams can run and maintain.

How we hand over

Deliver a written evidence map linking each MANAGE 2.2 control to its owner, system, log source and review cadence.
Provide runbooks for reviewing user feedback, risk transfer documents such as contracts and insurance, and control exceptions.
Transfer administrative access and documentation so the client's own staff can operate and audit the environment.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope work ends.
Re-check controls when a deployed system changes, a model is updated or a new risk is reported.
Ask any assessor or auditor you engage to confirm which evidence they accept, since DeployOpen does not issue reports or certificates.