NIST AI RMF MANAGE Function: Deep Dive for CISOs (2026)

MANAGE 1 requires that AI risks identified through MAP and characterised through MEASURE are prioritised based on impact, likelihood, and the organisation's risk tolerance, and that documented response strategies are applied. The outcome is a ranked, time-bound risk register with assigned owners and response strategies (accept, transfer, mitigate, avoid) per risk item.

A concrete example: a regional bank CISO maintains a per-system risk register for the customer-service chatbot. MEASURE outputs flag three high-priority risks (prompt injection bypass of refund-limit guardrails, hallucinated regulatory disclosures during account opening, and PII leakage through unsanitised logging). The CISO ranks these by impact-times-likelihood, with the regulatory hallucination risk top because the consumer protection regulator has signalled appetite for enforcement on AI-generated disclosures. The response strategy: mitigate via a deterministic disclosure template that the model must use verbatim, with a rejection rule if the model output deviates from the template. The owner is the head of customer experience, the deadline is 30 days, the budget impact is documented, and the residual risk after mitigation is re-scored and routed back to the AI Governance Committee for acceptance.

The trap to avoid: treating the risk register as a spreadsheet that lives on the GRC team's laptop. NIST AI 100-1 expects the register to be the operational system of record for AI risk, integrated with the inventory and the incident management process. Areebi dashboards surface the ranked risk register by owner and by system, so that the prioritisation discipline is visible to executives without a separate reporting cycle.

MANAGE 2 requires that the organisation allocates resources (people, money, tooling) commensurate with the prioritised risks and the expected benefits of the AI system. The outcome is a documented resource plan that maps each high-priority risk response to a budget line and a named team, with the executive sponsor on record.

A concrete example: a mid-market insurer with twelve AI systems on the inventory ties the MANAGE 2 plan to the annual budget cycle. The top three high-impact systems (claims triage, fraud detection, and underwriting assistant) receive a dedicated 0.5 FTE model risk analyst each. The next four systems share a single 0.5 FTE. The remaining five low-impact systems are reviewed by the central governance team on a rotating quarterly cadence with no dedicated resource. Tooling spend is allocated proportionally: red teaming for the top three, automated drift monitoring for the top seven, monthly policy review for all twelve. The CFO signs the resource plan, the CISO owns delivery, and the AI Governance Committee reviews the resource-to-risk ratio quarterly to catch any drift.

The trap to avoid: under-resourcing high-impact systems because they are "working fine". NIST is explicit that resource allocation must reflect the prioritised risks, not the squeaky-wheel pattern of past incidents. ISO/IEC 42001 clause on resource allocation reinforces this point and is one of the items external auditors test most consistently. The AI governance ROI business case covers how to articulate this resource ratio to a sceptical CFO using cost-of-incident framing.

MANAGE 3 requires that the organisation communicates AI risks and benefits to the relevant internal and external stakeholders in a form they can act on. The outcome is a documented communication plan that names audiences, formats, cadences, and the specific person responsible for each channel.

A concrete example: a public sector CISO running an eligibility-triage model maintains five distinct communication channels. Channel 1: the AI Governance Committee receives a quarterly risk dashboard with residual risk by system, ranked response items, and incidents-and-near-misses log. Channel 2: the responsible Minister or Secretary receives a one-page risk summary tied to programme delivery KPIs, semi-annually. Channel 3: front-line caseworkers receive a monthly "what the model can and cannot do" briefing with concrete examples of recent edge cases, in plain language. Channel 4: affected citizens receive a published model card and a simple appeal route, kept current on the public-facing site. Channel 5: the relevant regulator or oversight body receives the disclosures required by the applicable AI Act or sector regulation, on the schedule defined by that regulator. Each channel has a named owner, a defined format, and a documented frequency.

The trap to avoid: treating risk communication as a one-way executive briefing. NIST AI 100-1 contemplates a two-way channel with feedback captured and routed back into the governance loop. EO 14110 (October 30, 2023) extended this expectation for US federal agencies, and OMB M-24-10 (March 28, 2024) made it operational through agency-specific publication and transparency requirements. The Areebi audit log records each disclosure event so that the organisation can prove its communication cadence to auditors and regulators on request.

MANAGE 4 requires that the organisation tracks the effectiveness of risk treatments over time, captures lessons from incidents and near-misses, and updates the rest of the AI RMF (back through GOVERN, MAP, and MEASURE) accordingly. The outcome is a continuous improvement record that demonstrates the framework is a living system rather than a one-time deployment.

A concrete example: a healthcare CISO running a clinical documentation assistant logs every incident, near-miss, and clinician-reported issue against the system. Each entry includes the trigger (what happened), the immediate response (what was done in the moment), the root cause analysis (why it happened), the systemic change (what GOVERN, MAP, or MEASURE artefact must be updated), and the verification step (how the organisation will confirm the change worked). Quarterly, the CISO and the chief medical informatics officer review the log and feed material findings back into the next version of the policy, the impact assessment, and the measurement plan. Annually, the AI Governance Committee reviews the entire learning loop and reports to the board on programme maturity.

The trap to avoid: closing incidents without updating upstream artefacts. NIST AI 600-1 (the Generative AI Profile, published 2024-07-26) is explicit that learning from generative AI incidents must feed back through the framework rather than dead-ending in an incident report. This is also where the EU AI Act post-market monitoring requirements bite for high-risk systems: the EU AI Act expects evidence that incident data is shaping the management of the system over time, not just being filed. The Areebi platform inventory binds incident records to the model and policy version that was in production at the time of the incident, so that root cause analyses cannot lose track of which configuration was implicated.