What MANAGE 2.4 asks you to prove about switching AI off
Suppose an AI system is producing outcomes that no longer match its intended use, and someone with authority has to decide whether to limit it, replace it or shut it down. MANAGE 2.4 in the NIST AI RMF covers that moment. It is a voluntary outcome in NIST AI 100-1, not a certifiable control, so no assessor will issue a MANAGE 2.4 certificate. What an auditor, customer or regulator can do is ask you to show that the outcome is real in your environment. The outcome, in paraphrase, is that mechanisms exist and are applied to supersede, disengage or deactivate an AI system when its performance or outcomes drift from intended use, and that the people responsible for those decisions are named and understand their role.
In practice, the evidence an assessor will look for falls into four groups: a documented trigger, a named decision owner, a tested fallback and preserved records. The trigger is the incident threshold that causes bypass or deactivation, and it should be written down in measurable terms. The owner is the person or role that can pull the switch at 2 a.m. without waiting for a committee. The fallback is the bypass procedure and the backup system that keeps the business process running, which the Playbook suggests reviewing for continuity. The records are the logs, model versions, inputs and outputs preserved for forensic, regulatory and legal review. Confirm with your own legal team how long those materials must be kept, because the framework does not set that period.
This is hard because the three gaps usually appear at once. Thresholds are vague, so nobody agrees that the system has crossed the line until harm is already visible. Decisions are unowned, so product, data science and security each assume another team will act. And there is no tested fallback, so switching off the system means switching off the process it supported. For self-hosted platforms, a ticketing tool such as GLPI or Zammad can record the escalation and change trail, DFIR-IRIS can hold the case and chain-of-custody record for preserved evidence, and Bareos can restore the data and configuration the fallback depends on. Each of these tools needs its own assessment before it counts as evidence.
Which AI systems and teams fall under MANAGE 2.4
MANAGE 2.4 applies to AI systems that are live and affecting people, but the boundary is set by several decisions: which systems count as deployed, who supplies the model, whether generative AI actions apply, and which teams hold the authority to act. Each card below is a scoping choice to settle before drafting mechanisms, because it determines what must be covered and who must be named.
Deployed systems versus pilots
MANAGE 2.4 is about systems whose performance or outcomes are inconsistent with intended use, which means a system must be producing outputs that reach users, customers or decisions. Pilots and sandboxes still need a documented way to stop, but the bypass plans, forensic preservation and redeployment criteria apply once a system is in production. Check whether a pilot has real users, live data or downstream integrations, because those features move it into scope. A system in production is the usual trigger.
Third-party AI services
When a vendor hosts the model or API, the organization still owns the decision to disengage it, so bypass procedures must not depend on the vendor's support queue. Confirm contract terms for suspension, data return and notice periods, and identify which internal system can route traffic to a fallback. Vendor-hosted systems often sit outside the team's own infrastructure, so their deactivation path needs to be tested like any internal system.
Open-source models you host
Self-hosted open-source models give the organization direct control over shutdown, rollback and version pinning, but that control must be built and tested. Record the exact model weights, serving stack and configuration in the inventory so a deactivation can restore a known prior version. The Generative AI Profile specifically asks for communication plans for stakeholders during deactivation, including for open-source models.
Generative AI under the GAI Profile
NIST AI 600-1 lists four suggested actions under MANAGE 2.4 (MG-2.4-001 to MG-2.4-004). These cover criteria that warrant deactivating a generative system, escalation to the organizational risk management authority, and stakeholder communication during shutdown. Apply them to chatbots, copilots and agents that generate content or take actions, and note that the Profile tags the actions to Human-AI Configuration and Information Security risks.
Operations and deployment teams
The Playbook tags MANAGE 2.4 with the AI Deployment, Operation and Monitoring actor category. These are the people who observe degraded outputs, run the switch, and maintain the bypass path. Confirm that named engineers and on-call staff can execute a shutdown without waiting for approval from a team outside operations, and that they have the access rights and runbooks to do it.
Governance and oversight owners
The Playbook also tags MANAGE 2.4 with the Governance and Oversight actor category. These owners set incident thresholds that trigger bypass or deactivation, approve redeployment criteria, and decide when a system returns to service. Name the accountable executive or committee in writing, and confirm that the decision rights for shutting down a system are separate from the business owner's interest in keeping revenue flowing.
How an assessor tests the deactivation mechanism
In a tabletop walkthrough, the assessor picks a realistic scenario in which an AI system's outputs drift away from intended use, then asks the people who own the system to narrate what happens from detection to restored service. The assessor is testing whether the decision to supersede, disengage or deactivate is actually made by the people named in the documentation, and whether they know the steps without looking them up. The walkthrough is illustrative only until the organization runs it against its own system.
- Scenario choice: The assessor asks which system, which failure and who is on call, then checks that the answers match the system inventory and the on-call roster.
- Decision owner: The assessor asks who can order deactivation at 2 a.m. and whether that person can say so without escalating first.
- Escalation path: The assessor follows the message from the first alert to the risk management authority and asks where it would stall.
- Stakeholder communication: The assessor asks who is told, through which channel and within what timeframe the organization has set.
- Weak answer: Participants pause, check a wiki page that is out of date, or disagree about whether the system can be switched off at all.
Before the session, confirm that the scenario, roles and participants are recorded so the assessor can compare what was said with the written procedure.
A live test asks the organization to take a system out of service, or route traffic to a non-AI or manual alternative, and show that the bypass works and that service continues. The assessor watches the actual switch, checks logs and timestamps, and confirms that the fallback performed as the continuity plan says. Test scope should be agreed in writing beforehand so that the test does not put production users at unplanned risk.
- Switch mechanism: The assessor asks to see the control that disengages the model, such as a feature flag, routing rule or service toggle, and watches it operate.
- Fallback performance: The assessor checks whether the backup process or manual procedure completes the core tasks and whether its outputs are validated.
- Restoration: The assessor asks for a documented rollback to a prior known-good version and checks the restored state against a baseline.
- Change records: The assessor compares the test with change management tickets, approvals and the time it took to act.
- Weak answer: The switch exists only in a runbook, the fallback has not been exercised in the last review cycle, or the rollback target cannot be identified.
Ask the auditor to confirm in advance whether they will witness the test or review a recording of it, since that determines what evidence to capture.
A document review tests whether the organization has defined when deactivation is required and who has the authority to act. The assessor looks for written incident thresholds that trigger bypass or deactivation, a responsibility assignment that names roles rather than individuals only, and evidence that the document was approved and is current. The assessor will compare what the policy says with what the system's monitoring and tickets actually show.
- Thresholds: The assessor asks for measurable criteria tied to intended use, such as performance or outcome limits, and checks that monitoring produces the data needed to apply them.
- Assigned responsibilities: The assessor looks for a RACI or equivalent that covers the AI owner, the security team, the risk authority and the operations team.
- Preservation rules: The assessor checks that logs, model versions and prompts are preserved for forensic, regulatory and legal review when a system is deactivated.
- Redeployment criteria: The assessor asks what conditions must be met before a deactivated system returns, and who signs off.
- Weak answer: Thresholds read as general statements such as "unacceptable performance," roles point to a team that no longer exists, or the approval date is missing.
Check that each threshold can be traced to a monitoring metric and that the document lists its owner and review date.
Implementing MANAGE 2.4 in six steps
This sequence turns MANAGE 2.4 from a statement of intent into working mechanisms: named owners, defined triggers, tested bypass paths, controlled changes, preserved evidence and documented criteria for bringing a system back. Each step produces a record an assessor or internal reviewer can inspect.
Assign owners and escalation paths
Name the person who can supersede, disengage or deactivate each AI system, the alternate who acts when that person is unavailable, and the escalation route to the organizational risk management authority. Governance and oversight owners set the authority, and deployment and operations owners carry out the action. Record these assignments in the system's governance file and confirm that each named person accepts the role. The step is complete when every in-scope system has a primary owner, an alternate and a written escalation path that the owners have acknowledged.
Set incident thresholds for bypass or deactivation
Define the measurable conditions that trigger bypass or deactivation, such as performance falling outside intended use, outcomes that breach agreed limits, or a generative AI system producing content that falls under criteria set for deactivation. Tie each threshold to a monitoring signal and state who decides when it is crossed. Thresholds should be reviewed against the metrics chosen under MEASURE 1 so the two sets do not contradict each other. The output is a threshold register that lists each trigger, its data source, its owner and the required action.
Document bypass procedures and backup systems
Write the procedure that moves work from the AI system to a bypass path, whether that is a non-AI method, a manual process or a previous system version. Identify the backup systems that keep the business function running during continuity events, and confirm who can operate them. Review these procedures before they are needed, because a bypass that has never been exercised often fails when used. The output is a runbook for each system with its bypass path, backup dependencies, activation steps and the people trained to run them.
Apply change management to assess consequences
Before any supersession or deactivation, route the change through the organization's change process to identify downstream effects on users, dependent systems, data flows, customers and affected communities. Record the consequences considered, the stakeholders notified and the communication plan used during the deactivation. Generative AI deployments should follow the communication steps in NIST AI 600-1 for stakeholders, including open-source models. The output is an approved change record that shows the impact assessment and who signed off on the action.
Preserve forensic material and run root cause analysis
Before the system is switched off or replaced, capture the materials needed for forensic, regulatory and legal review, including logs, model and configuration versions, prompts and outputs in scope, monitoring data and decision records. Store them under controlled access with a record of who collected them and when. Then run a root cause analysis to establish why performance or outcomes diverged from intended use. The output is a preservation inventory and a root cause report that link the trigger, the decision and the corrective actions.
Track the incident in a case record
Open a case for each supersession or deactivation so that triggers, decisions, actions, evidence and approvals sit in one auditable record. Use a ticketing or case system that keeps timestamps and assignments, and link the preserved evidence and the change record to it. Confirm that the case shows who acted at each stage and that nothing was changed without a logged approval. The output is a closed case file that an internal reviewer or assessor can follow from the first trigger to the final decision.
Set criteria for redeployment
Decide in advance the conditions under which a superseded or deactivated system may return to service, such as a documented fix, a passing retest against the failed threshold, and approval from the owner named in step one. Record who approves redeployment and whether the system returns under restricted conditions. Feed the redeployment decision back into the MANAGE 1 go or no-go determination. The output is a signed redeployment decision with its criteria, test results and any conditions placed on the restored system.
Preserving forensic and regulatory material when a system is switched off
Deactivating an AI system can destroy the evidence needed to explain what went wrong, so the retention decision has to be made before anyone turns the system off. A shutdown that clears runtime containers, rotates logs, overwrites model endpoints or redeploys a new model version can erase the prompts, outputs, configuration and model version that an investigator, regulator or lawyer will later ask for. The Playbook suggests preserving materials for forensic, regulatory and legal review under MANAGE 2.4, and the Generative AI Profile ties that preservation to communication plans for stakeholders during deactivation, including for open-source models (MG-2.4-004 in NIST AI 600-1).
Preservation should cover a defined set of artifacts: model weights or the exact model version identifier, prompt templates and system prompts, inference logs and sampled outputs, configuration and feature flags, retrieval sources, access records and the change tickets that approved the last update. For each artifact, the risk owner should name the system of record, the retention period set by legal and regulatory counsel, and who may access it. Confirm these periods with counsel and the regulators that apply to your sector, since NIST does not set them. Where evidence is collected, a case record with a hash check and a documented chain of custody (who handled the material, when and why) makes it usable later. Tools such as DFIR-IRIS can hold such records, but the retention rules remain an organizational decision.
This preservation work is distinct from MANAGE 2.3, which covers responding to a previously unknown risk and recovering from it, and from general incident response. A system can be preserved under a legal hold while the incident is still being analyzed, and a preservation decision can be needed even when no incident is declared. Ask the accountable owner to sign off on a preservation checklist as part of the deactivation runbook, and test it against a non-production copy so the team learns which logs roll over automatically and which backups expire before anyone needs them.
Evidence that satisfies MANAGE 2.4 and stays current
MANAGE 2.4 is tested by what an organization can show: who may switch a system off, under which conditions, and how the switch was carried out and recorded. The artifacts below connect those decisions to a runbook, a threshold register and a preserved record. Each one needs a named owner and a scheduled review so it still matches the live system when an assessor or regulator asks.
Deactivation runbook
The runbook is the step-by-step procedure for superseding, disengaging or deactivating each AI system, including the fallback process that takes over while the system is down. It should name the system owner, the technical operator and the people who approve the switch. Check that it covers both the full shutdown and partial disengagement, and that it lists the communication steps for affected users. Refresh it after every architecture change and at least once a year, and run a tabletop exercise against the current version.
Threshold register
The threshold register records the performance and outcome limits that trigger bypass or deactivation, such as accuracy falling below an agreed floor or a rise in harmful outputs. Each threshold should list its metric, its measurement source, the alert route and the authority that must act. The Playbook suggests setting these thresholds in advance, so the register should show the date each was approved. Review it whenever the system's intended use changes, because a threshold set for one purpose may not protect another.
Named decision owners
Assessors look for a written assignment of who decides to supersede or deactivate a system, who is consulted, and who can override a decision in an emergency. The register should separate the operational owner from the governance authority that receives escalations. Confirm that each named person has accepted the role and knows the escalation path, and that the list is updated when staff change. Record the date of each review so the assignment can be traced to the period under assessment.
Bypass test records
Bypass plans only work if they have been exercised. Keep records of each test of the bypass procedure and the backup system used for continuity, including the scenario, the result and the corrective actions. Test records should show that the fallback process operated within the time the business needs, and that the people involved could follow the runbook. Repeat tests after material changes to the system or its dependencies, and confirm with your team how often testing is required by your own policies.
Change tickets and root cause reports
Each deactivation or bypass should generate a change ticket that records the reason, the approval, the change window and the consequences assessed under change management. Attach the root cause analysis to the same record once it is complete. Open-source service management tools such as GLPI can hold these tickets with an ITIL-style change workflow, and the ticket history becomes the audit trail. Check that tickets link to the threshold that triggered them, so the chain from metric to decision is visible.
Preservation logs and forensic records
The Playbook suggests preserving materials for forensic, regulatory and legal review when a system is deactivated. A preservation log should list each preserved artifact, such as model versions, prompts, logs, configurations and datasets, with the hash, storage location, custodian and retention period. DFIR-IRIS can keep such evidence in a case record with chain of custody and SHA-256 verification. Ask your legal and records teams to confirm the retention periods that apply to your sector before the first deactivation.
Redeployment criteria
Redeployment criteria define the conditions a deactivated system must meet before it returns to service, such as a completed root cause fix, a fresh TEVV result and a renewed go or no-go decision. Record who signed off and which evidence was reviewed. Keep the criteria under version control alongside the runbook so an assessor can see what was required at the time of each return. Revisit the criteria after any incident, since the failure that caused the shutdown may point to a gap they did not cover.
What meeting MANAGE 2.4 costs in money and effort
This table lists the cost components of building and sustaining deactivation, bypass and forensic preservation for MANAGE 2.4, who is paid for each, and whether it is one-time or recurring. Use it to shape a written scope and to check that a quote covers every line before you compare offers.
| Cost component | Who is paid | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Engineering for kill switches and disengagement paths | Internal platform or MLOps engineers, or an implementation partner | One-time build, then recurring when systems change | Number of AI systems in scope, how many dependencies must be stopped safely, and whether controls are built into the platform or added later |
| Bypass paths and backup systems for continuity | Internal engineers, business owners and the implementation partner if one is engaged | One-time design, recurring maintenance | Business criticality of each system, whether a non-AI or manual process must be kept warm, and how often the fallback is updated |
| Governance time to set deactivation thresholds and escalation paths | Internal risk, legal, product and security owners | One-time setup, recurring review | Number of risk categories, how many decision makers are named, and how often thresholds are revisited after incidents |
| Change management and root cause analysis | Internal change board and incident responders | Recurring, tied to each deactivation or redeployment | Frequency of incidents, the depth of analysis expected, and whether tickets and changes already run in a single tool |
| Tooling for tickets, cases and backups | Vendors or open-source projects, plus whoever operates them | Recurring hosting and operations; license cost depends on the product | Self-hosted open-source options such as GLPI, Zammad, DFIR-IRIS and Bareos carry their own license terms (for example, GPL, AGPL and LGPL), which should be reviewed by legal before adoption; subscription or support contracts are optional |
| Testing of bypass and deactivation procedures | Internal operations staff, testers or the implementation partner | Recurring, at a cadence the organization sets | Complexity of the failover path, whether restores are tested end to end, and whether tests include tabletop exercises as well as technical runs |
| Evidence upkeep and forensic preservation | Internal compliance and security staff; storage provider | Recurring | Retention periods set by regulators or contracts, volume of logs and model artifacts, and the chain of custody the organization requires |
| External review or auditor sampling | Independent auditor, assessor or reviewer | Periodic, usually at each review cycle | Scope and sample size the reviewer selects, number of deactivation events in the period, and how well evidence is indexed before the review |
Who owns deactivation decisions, who prepares evidence, who audits
MANAGE 2.4 is an outcome about mechanisms that are in place and applied, with responsibilities that are assigned and understood. Those assignments belong to the organization. It decides which conditions count as performance or outcomes inconsistent with intended use, who has authority to pull a system from service, and which risk owner must be informed before a decision is executed. An outside party cannot accept that accountability on the organization's behalf, and a document written by a consultant does not make a responsibility real until managers have agreed to it.
- Incident thresholds: Named metrics and limits that trigger bypass or deactivation, approved by the business owner and the risk function.
- Decision authority: A named role, with a deputy, that can disengage a system without waiting for a steering committee.
- Escalation path: Who is informed, in what order, and the time expectations agreed internally for each step.
- Redeployment criteria: The conditions a system must meet before it returns to service, signed off by the accountable owner.
- Stakeholder communication: Who tells users, affected groups and regulators, and which messages are pre-approved.
Check that each threshold and authority appears in a signed governance record and that the people named know they hold the role.
An implementation partner turns the organization's decisions into working mechanisms. DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms in the client's own infrastructure, and it prepares systems and evidence for compliance assessments under a written scope. Preparation includes drafting deactivation runbooks, wiring ticketing, case management and backup tooling to the decision path, and assembling evidence packs. The partner does not decide thresholds, approve a shutdown or certify that a control is effective.
- Runbooks: Step-by-step deactivation and bypass procedures, drafted for the organization to approve.
- Tooling integration: Connections between the ticketing, case and backup platforms so each action leaves a record.
- Bypass and continuity setup: Configuration and testing of backup systems, with results recorded for the organization to review.
- Evidence packs: Organized logs, tickets, change records and restore test results mapped to the MANAGE 2.4 subcategory.
- Handover and support: Training for operators and, where contracted, a retainer for upgrades and testing.
Confirm in the written scope exactly which runbooks, integrations and evidence packs are delivered, and who signs off each one on the organization's side.
Only an independent auditor, assessor or certification body reaches a conclusion about whether the control is operating. The AI RMF has no certification program, and NIST does not validate or endorse any organization's use of the framework, so any assessment of MANAGE 2.4 is a matter of the organization's own engagement with an external reviewer. The assessor samples records, compares them with the organization's documented thresholds and tests whether deactivations actually happened as described. Its report belongs to the assessor, not to the implementation partner.
- Design review: Whether the thresholds, authorities and runbooks are documented and consistent.
- Operating tests: Sampling real events to see whether the decision path was followed and recorded.
- Forensic preservation: Whether materials from a deactivation were kept for review in line with the organization's legal and regulatory needs.
- Root cause follow-up: Whether analysis after a deactivation led to recorded changes.
- Scope and independence: Whether the assessor is free of conflicts with the team that built the controls.
Before engaging an assessor, ask which criteria it will test against and which evidence it expects to sample.
Organizations often buy outside help for the parts that need specialist time, and keep the parts that need authority in-house. Implementation work, such as building runbooks, configuring case and backup tools and assembling evidence, is the most common outsourced scope. Independent testing of the controls is usually bought separately from the build, so the team that configured a system does not also test it. Ongoing operation, including monitoring thresholds and running periodic restore tests, can be kept in-house or placed under a retainer.
- Commonly outsourced: Runbook drafting, tool configuration, evidence collection and restore testing.
- Usually kept in-house: Threshold setting, deactivation authority, stakeholder communication and redeployment approval.
- Separately bought: Independent assessment, which the auditor performs for its own report.
- Recurring costs: Retainers for upgrades, backup test cycles and periodic review, which depend on the scope agreed.
- Cost drivers: The number of AI systems in scope, the number of integrated platforms and the state of existing ticketing and backup records.
Ask any partner for a written scope that lists deliverables, owners and exclusions, since the quote follows from that scope.
Where organizations fall short on MANAGE 2.4
MANAGE 2.4 is tested in practice when an AI system has to be switched off, bypassed or pulled back under pressure. The gaps below tend to surface only at that moment, so each one pairs a common failure with an action to close it before an incident forces the question.
No tested kill switch
Many teams can describe how a system would be turned off but have never done it in a controlled test. A deactivation path that depends on a single engineer, an undocumented script or a vendor console may fail when needed. Test the full path in a non-production environment, confirm that inference endpoints, scheduled jobs and downstream integrations actually stop, and record the time and results as evidence.
Bypass plans never rehearsed
A bypass plan that routes users to a manual process or an earlier system is only useful if staff can execute it. Plans often sit in a policy folder with no owner, no current contact list and no dry run. Ask who runs the bypass, how long staff need to switch over, and whether the manual process can handle the expected volume. Rehearse it at least once and file the outcome.
Backups that cannot restore model state
Backing up model weights and data files does not guarantee that a system can return to a known good state. Configuration, prompt templates, feature pipelines, retrieval indexes and version pins can be missing or inconsistent. Confirm that a restore recreates the exact version approved for redeployment, and verify restores on a schedule rather than assuming the backup job succeeded. The backup tool's restore function is a reasonable starting point for that test, as described in the Bareos documentation.
Unclear authority to deactivate
When a model produces harmful outputs at 2 a.m., the on-call engineer may not know whether they are allowed to shut it down without approval from a product owner, legal or an executive. Ambiguous authority delays action and creates disagreement about who carries the risk. Write down who can supersede, disengage or deactivate each system, who must be notified, and which thresholds remove the need for approval. Assign a named backup for every role.
No preservation step before shutdown
Shutting a system down immediately can erase the logs, prompts, outputs and model versions that investigators, regulators or lawyers later need. The Playbook suggests preserving materials for forensic, regulatory and legal review. Add a preservation step to the deactivation runbook that snapshots logs, captures the active model version and configuration, and records a chain of custody. Ask counsel which retention periods apply before deleting anything.
No thresholds linking incidents to action
Teams often respond to AI incidents case by case, which makes the decision to bypass or deactivate inconsistent. Without defined thresholds, similar failures lead to different outcomes depending on who is watching. Set measurable incident criteria in advance, tie each to a bypass or deactivation decision, and review them after each event. Document why a threshold was chosen so that an assessor can follow the reasoning.
Questions buyers ask about MANAGE 2.4
Is MANAGE 2.4 certifiable?
No. MANAGE 2.4 is an outcome within the NIST AI RMF, and the framework has no certification, accreditation or conformity assessment program. NIST states that it does not validate or endorse any organization's use of the AI RMF. What you can do is show an independent assessor, customer or regulator that mechanisms exist to supersede, disengage or deactivate an AI system and that responsibilities for doing so are assigned and understood. Any formal attestation for your wider program must come from an independent auditor or certification body, not from NIST or from a consultant.
How long does preparing for MANAGE 2.4 take, and what drives it?
No researched figure exists for this, so confirm timing against your own environment rather than a generic estimate. The main drivers are the number of AI systems in scope, whether deactivation procedures already exist for your IT services, how many teams own a system, and whether bypass and backup paths have been tested. A system with a documented fallback process and a named owner needs far less work than an AI feature embedded in a customer workflow with no manual alternative. Ask any partner for a written scope that lists systems, deliverables and dependencies before agreeing on a schedule.
What does MANAGE 2.4 need from our internal staff?
It needs decisions that only your organization can make. Staff must define the performance and outcome thresholds that trigger bypass or deactivation, name the people with authority to act, and agree on who communicates with stakeholders during a shutdown. Operations and business owners must confirm that a fallback process works in practice. Security and legal teams must set what evidence is preserved and for how long. The NIST AI RMF Playbook tags this subcategory to AI deployment, operation and monitoring and to governance and oversight actors, so both groups need to be involved from the start.
Can open-source tools handle MANAGE 2.4 alone?
Open-source tools can produce much of the operational evidence, but they cannot make the governance decisions. A ticketing system such as GLPI, which follows ITIL practices for tickets, problems and changes, can record deactivation requests and change approvals. Zammad can centralize stakeholder communication during an incident. DFIR-IRIS can keep case records, evidence with SHA-256 verification and chain of custody, and an investigation timeline. Bareos can run backup and restore jobs that support a bypass plan. Confirm each tool's fit with your architecture and processes, because the thresholds, responsibilities and bypass design remain your responsibility.
When is it worth bringing in an implementation partner?
A partner is worth considering when you need self-hosted platforms configured to produce the evidence MANAGE 2.4 expects, such as ticketing workflows, case management, and backup and restore jobs, and when your internal team lacks capacity to build them. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with agreed deliverables. DeployOpen does not issue audit reports or certifications, and it does not decide your thresholds or risk tolerance. Ask for a written scope before work starts.
How does MANAGE 2.4 relate to the NIST AI RMF revision?
NIST says AI RMF 1.0 is being revised as part of the White House AI Action Plan and has not published a revised version as of October 2026. The July 2025 AI Action Plan recommends removing references to misinformation, diversity, equity and inclusion, and climate change. NIST also expects a formal review with community input no later than 2028. Because the playbook has not been updated since August 2023 and AIRC says it will be updated after the revision, subcategory wording may change. Keep your mechanisms documented against the version you use and track NIST's announcements before relying on specific text.
Does the Generative AI Profile change what MANAGE 2.4 requires?
It adds specific suggested actions for generative AI, but it does not replace the core subcategory. NIST AI 600-1, published July 26, 2024, lists four suggested actions for MANAGE 2.4 (MG-2.4-001 to MG-2.4-004), tied to the risks of human-AI configuration and information security. They cover criteria that warrant deactivating a generative system, escalation to the organizational risk management authority, and stakeholder communication during deactivation, including for open-source models. If you run or buy generative AI, use those actions as additional prompts for your procedures.
How DeployOpen prepares MANAGE 2.4 evidence
DeployOpen prepares the technical and operational material that an organization needs to show it can supersede, disengage or deactivate an AI system. The work is agreed as a fixed scope in writing before it starts, and the deliverables are named in that scope. Typical components include the deactivation runbook for each AI system in scope, the bypass path that keeps the business process running while the system is off, and the configuration of ticketing, case management and backup tools that will hold the evidence. The work happens inside the client's own environment, whether that is their cloud accounts, data center or air-gapped network, and the platforms involved are self-hosted open-source tools that the client keeps. DeployOpen does not issue audit reports, attestations or certifications. NIST does not certify AI RMF use, and any independent assessment is performed by a party the client engages separately.
Before any deployment, the scope should state which decisions belong to the client. The organization owns its deactivation criteria, its named accountable roles under the Governance and Oversight actor category, and its risk acceptance. DeployOpen can test whether a runbook works as written: simulate an incident threshold being crossed, confirm that the bypass procedure can be executed by the people named, check that backups restore the data the bypass depends on, and record what happened. Ask the implementation partner to show the test plan, the pass criteria and how failed tests are logged and retested. Confirm with your own legal and records team which materials must be preserved for forensic, regulatory and legal review, and how long, because the platform can hold them but the retention period is a client decision.
Ongoing work is usually handled through a retainer rather than a new fixed-scope project. A retainer can cover keeping runbooks current after system changes, rerunning bypass and restore tests on a schedule the client sets, upgrading the open-source tools, and reviewing that case records still meet the evidence needs of the assessor. Ask for the retainer's exact services in writing, who on the client side approves changes to deactivation criteria, and how a retainer ends and returns evidence to the client. Pricing for any engagement follows from the agreed written scope, so compare proposals on scope, deliverables and test coverage rather than on headline effort.
