NIST AI RMF: The Manage Function

Description

Map identified the risks. Measure quantified them. Manage acts: it prioritizes, mitigates, and monitors the response. This is the operational function — where governance + analysis turn into real changes.

By the end you'll be able to:

• Prioritize risks based on impact × likelihood
• Design the 4 types of risk response (mitigate, accept, transfer, avoid)
• Implement incident response for AI
• Track the status of remediation actions

---

The 4 categories of Manage

Manage 1: Risks prioritized

You combine impact and likelihood:

	Low Impact	Medium Impact	High Impact	Critical Impact
Low Likelihood	Accept	Accept	Mitigate (low priority)	Mitigate (medium)
Medium Likelihood	Accept	Mitigate (low)	Mitigate (medium)	Mitigate (high)
High Likelihood	Mitigate (low)	Mitigate (medium)	Mitigate (high)	Mitigate (critical)
Certain	Mitigate (medium)	Mitigate (high)	Mitigate (critical)	Mitigate (critical)

Critical priority: block production until mitigated. High priority: mitigate in the current sprint. Medium: plan for next quarter. Low: monitor, no immediate action.

Manage 2: Risk response strategies

4 fundamental strategies:

Mitigate: implement controls to reduce impact or likelihood. Accept: document and accept the risk (some risks can't be eliminated). Transfer: shift the risk (insurance, a partner agreement, contractual terms). Avoid: don't build the feature/system that causes the risk.

Manage 3: Continuous risk monitoring

Risks aren't static. Monitor:

• Are new risks emerging?
• Are the mitigations still effective?
• Are the impact assumptions still valid?

Manage 4: Communication and disclosure

Stakeholders need to know:

• The internal team: the detailed risk picture
• Customers: relevant disclosures (without compromising security)
• Regulators: the required disclosures
• The public: as appropriate (e.g., responsible disclosure of vulnerabilities)

---

The decision framework: when each strategy applies

Risk: Tenant data leakage (critical)
  ↓
  Likelihood: medium (a Pinecone filter bug is possible)
  Impact: catastrophic (legal, reputational)
  ↓
  Strategy: MITIGATE
  - Implement strict tenant isolation
  - Add validation at multiple layers
  - Penetration testing
  - Monitoring for cross-tenant access patterns


Risk: Vendor lock-in (OpenAI)
  ↓
  Likelihood: high (already locked in)
  Impact: medium (cost increase if OpenAI changes its pricing)
  ↓
  Strategy: TRANSFER + MITIGATE
  - Transfer: contractual agreements with OpenAI (price stability)
  - Mitigate: build a multi-provider architecture for future flexibility


Risk: Worker displacement (societal)
  ↓
  Likelihood: low
  Impact: medium (broader societal, not direct to us)
  ↓
  Strategy: ACCEPT
  - Document the acknowledgment
  - Participate in industry conversations
  - Not within our direct control


Risk: Building an AI for criminal sentencing (hypothetical)
  ↓
  Likelihood: N/A
  Impact: catastrophic (ethics, legal, reputational)
  ↓
  Strategy: AVOID
  - Decision: do not build this product

---

Implementation: the Risk Register

A central document that tracks all the risks:

# Risk Register — AI Knowledge Assistant
Last updated: 2026-05-11

## Critical Risks (3)

### R001: Tenant Data Leakage
- **Description**: A Tenant A user receives data from Tenant B
- **Identified**: Map document, 2026-XX-XX
- **Impact**: Catastrophic (legal, reputational, contract breach)
- **Likelihood**: Medium (filter bugs are possible)
- **Strategy**: MITIGATE
- **Mitigations**:
  - [x] Strict tenant_id filter in all RAG queries
  - [x] Database constraints preventing cross-tenant access
  - [ ] Penetration testing (scheduled Q3)
  - [ ] Automated monitoring for anomalies
- **Owner**: Tech Lead
- **Review date**: Quarterly
- **Status**: Active mitigation

### R002: Hallucination affecting decisions
[similar detail]

### R003: Art. 22 GDPR violation
[similar detail]

## High Risks (5)

[similar structure]

## Medium Risks (8)

[similar structure]

## Low Risks (10)

[similar structure]

## Accepted Risks (5)

These are risks we've documented and accepted:

### A001: Worker displacement
- **Description**: The AI assistant reduces the need for support staff
- **Rationale for accepting**: An indirect, societal impact outside our direct control
- **Monitoring**: Industry trend analysis

---

Incident response for AI

When a risk materializes, you need a clear process:

1. Detection
   - Monitoring detects an anomaly OR a user reports it
   - An automated alert goes to on-call

2. Triage
   - Assess the severity (P0/P1/P2/P3)
   - Identify the affected users/systems

3. Containment
   - Stop the bleeding (e.g., disable the feature, switch to a fallback)
   - Communicate internally

4. Investigation
   - Root cause analysis
   - Document the timeline
   - Identify other risks

5. Resolution
   - Implement the fix
   - Verify the fix
   - Re-enable the affected features

6. Communication
   - Internal post-mortem
   - User notification (if applicable)
   - Regulator notification (if it's a GDPR breach)

7. Learning
   - Update the mitigations
   - Update the risk register
   - Update the runbook

SLA targets:

• P0 (critical, affecting all users): respond <15 min, resolve <4h
• P1 (high): respond <1h, resolve <24h
• P2 (medium): respond <4h, resolve <1 week
• P3 (low): respond <1 day, resolve <1 month

---

Communicating risk to non-technical stakeholders

CEOs, CFOs, and customers need risk information without overwhelming detail:

"We've identified 23 risks in our AI system across categories like
data security, bias, performance, and compliance.

Of these:
- 3 are Critical, with active mitigation in progress
- 5 are High priority, being addressed this quarter
- 13 are Medium/Low, being monitored
- 5 are documented as accepted (low impact or outside our control)

Our mitigation budget is $X, allocated to the top priorities first.
Next quarterly review: [date].

The detailed report is available [link]."

The principle: signal (3 numbers + decision criteria) > noise (a 50-page report nobody reads).

---

Common traps

Trap 1 — A risk register you write once. Created in Q1, never updated. Risks change quarterly at minimum.

Trap 2 — Every risk marked "mitigate." Impossible. Some risks you have to accept. Trying to mitigate everything = mitigating everything poorly.

Trap 3 — Mitigations with no owner. "Tenant isolation will be addressed." By whom? When? With no ownership, it doesn't get done.

Trap 4 — No incident response plan. "When something happens, we'll handle it." For AI, breaches can be disastrous. Plan ahead.

Trap 5 — Mitigations with no verification. You implemented a mitigation and never test whether it works. Measure its effectiveness (M6-04).

---

Exercise

For your Capstone:

1. Create a Risk Register based on the M6-03 Map
2. Apply prioritization (critical/high/medium/low)
3. For each critical risk: define a mitigation strategy with an owner + a target
4. Draft an Incident Response Plan (high level, 1 page)

See the solution (skeleton)

The top critical risks in the Risk Register for the Knowledge Assistant:

1. Tenant data leakage (Critical, M)

   • Mitigation: strict filtering, validation, a pen test
   • Owner: Tech Lead, target Q1 done

2. Hallucination affecting decisions (Critical, M)

   • Mitigation: confidence display, human review, citations required
   • Owner: ML Engineer, target Q1

3. Compliance violations (Art. 22) (Critical, L)

   • Mitigation: human review for significant decisions, an explanation provided
   • Owner: Tech Lead + DPO

Incident Response Plan (skeleton):

• An on-call rotation (1 engineer 24/7)
• A severity assessment matrix
• A communication template (internal Slack, external email)
• A post-mortem template
• Quarterly DR drills
• SLAs by severity

---

Summary

You learned:

• ✅ The 4 categories of Manage (prioritize, respond, monitor, communicate)
• ✅ The 4 risk response strategies (mitigate, accept, transfer, avoid)
• ✅ The Risk Register template
• ✅ The incident response plan
• ✅ Communicating to non-technical stakeholders
• ✅ The traps: never updated, an all-mitigate mentality, no owners

Checkpoint: if you have a living Risk Register with owners, mitigations tracked, and an IR plan, Manage is functional.

---

Next capsule

06 — The IEEE 7000 series. After going deep on the NIST AI RMF, we look at IEEE — more conceptual ethics standards, but useful as vocabulary.

---

Resources

1. NIST AI RMF Playbook — Manage.
2. Atlassian — Incident Management — for IR patterns.
3. Google SRE — Incident Response — comprehensive.
4. Risk Register templates — examples.