MANAGE: measures and risk management

How to prioritise risks, implement mitigations and manage incidents

NIST AI RMF function: MANAGE Guide sections: MG-1 to MG-4

The labels below organise this implementation guide. They are not official NIST subcategory identifiers; see the NIST mapping.

1. Overview of MANAGE

MANAGE turns findings from MAP and MEASURE into decisions and practical action.

Objective	Description
Prioritisation	Rank risks according to their context and significance
Mitigation	Implement and verify controls
Incidents	Respond to AI incidents
Improvement	Learn and improve continuously

2. MG-1: Risk prioritisation

2.1 Example risk scoring

Risk score = likelihood × impact × difficulty of detection

This is an illustrative internal scoring model. It is not a NIST-mandated formula or an EU AI Act classification. Multiplying ordinal ratings can help organise discussion, but the score does not replace judgement about severe harm or legal duties.

Factor	1 — Low	2 — Medium	3 — High	4 — Critical
Likelihood	Rare	Possible	Likely	Almost certain
Impact	Minor	Moderate	Major	Severe
Difficulty of detection	Easy to detect	Moderate	Difficult	Very difficult

Example internal treatment priorities:

Score	Level	Action
1–8	Low	Accept with justification or monitor
9–16	Medium	Plan mitigation within the quarter
17–32	High	Plan mitigation within the month
33–64	Critical	Immediate action

Applicable legal requirements and urgent harm can require action regardless of the score.

2.2 Risk register

## AI RISK REGISTER — ILLUSTRATIVE ENTRIES

| ID | Risk | System | L | I | D | Score | Status | Due |
|---|---|---|---|---|---|---|---|---|
| R001 | Bias in hiring | AI-001 | 3 | 4 | 2 | 24 | Mitigation in progress | YYYY-MM-DD |
| R002 | Exposure of personal data | AI-002 | 2 | 3 | 3 | 18 | Treatment decision required | YYYY-MM-DD |
| R003 | Harmful false output | AI-003 | 4 | 3 | 3 | 36 | Urgent containment | YYYY-MM-DD |

Include an owner, decision rationale, evidence and review date in the operational register. Record any accepted residual risk and who has authority to accept it.

2.3 Treatment options

Option	When appropriate	Example
Avoid	The risk is unacceptable	Do not use AI for that purpose
Mitigate	Controls can reduce the risk	Implement and test safeguards
Transfer or share	Some financial or operational exposure can be allocated	Insurance or contractual arrangements
Accept	Residual risk is justified and within authority	Document the decision and monitor

Insurance or an SLA does not transfer away an organisation’s statutory responsibilities.

3. MG-2: Risk mitigation

3.1 Control framework

3.2 Controls by risk area

Select and combine controls for the specific use case. No single control guarantees the absence of harm.

Bias and fairness

Control	Type	Implementation example
Relevant and representative training data	Preventive	Data curation process
Pre-deployment bias assessment	Preventive	Required internal release check where relevant
Fairness monitoring	Detective	Metrics and contextual review
Human review of decisions	Detective	Meaningful case or sample review
Appeal mechanism	Corrective	Accessible challenge and review process
Retraining process	Corrective	Triggered by validated evidence of a problem

Privacy

Control	Type	Implementation example
Data minimisation	Preventive	Process only necessary data
Anonymisation or pseudonymisation	Preventive	Suitable preprocessing and separate key management
Access controls	Preventive	Role-based access and least privilege
Personal data detection in outputs	Detective	Content scanning and review
Data breach response	Corrective	Tested incident response plan

Pseudonymised data remains personal data where it can be attributed to a person using additional information.

Generative AI safety

Control	Type	Implementation example
Content filters	Preventive	Input and output filtering
System instructions	Preventive	Task and safety instructions as one layer of control
Rate limits	Preventive	Abuse prevention
Output monitoring	Detective	Safety evaluations and contextual review
Emergency stop	Corrective	Ability to disable or limit the system promptly
User restrictions	Corrective	Restrict abusive accounts through a defined process

3.3 Human oversight

Model	Description	Possible use
Human in the loop	A person reviews and authorises a decision	Sensitive or consequential decisions
Human on the loop	A person monitors and can intervene	Supervised batch or operational decisions
Human in command	People set objectives, rules and operating limits	System-level accountability and control

These are design patterns, not a direct legal mapping from “high”, “medium” and “low” risk. Assess the oversight needed for the system’s purpose, potential harm and applicable obligations.

## HUMAN OVERSIGHT DESIGN

### 1. Decision points
- What does AI recommend, and what can it decide or execute?
- When is human review required?

### 2. Example escalation criteria
| Trigger | Action |
|---|---|
| Confidence below a justified threshold | Human review |
| High-impact decision | Approval by an authorised person |
| Edge case detected | Escalate to a specialist |
| Request for review | Follow the applicable review or appeal process |

### 3. Override capability
- Who can override the system?
- How is the override recorded?
- How does feedback inform future evaluation?

### 4. Appeal process
- How can an affected person challenge a decision?
- Who reviews the challenge?
- What deadlines apply?

4. MG-3: Incident management

4.1 Working definition

For internal governance, treat an AI incident as an event or series of events in which AI development, use or failure contributes directly or indirectly to harm, such as harm to health, critical infrastructure, rights, property, communities or the environment.

This working definition supports internal reporting. Legal definitions of an incident, a serious incident or a personal data breach differ by regulation.

4.2 Example incident categories

Category	Examples	Illustrative severity
Safety	Physical harm, dangerous content	Critical
Privacy	Personal data breach or exposure	Critical
Bias or discrimination	Unfair or discriminatory outcomes	High
Misinformation	False outputs causing harm	High
Security	Adversarial attack or system compromise	Critical
Performance	Major accuracy degradation	Medium
Availability	Service outage	Medium–High

Determine actual severity from impact, affected people and operational context.

4.3 Response process

4.4 Internal response targets

These are illustrative internal targets. Adapt them to operations and risk. They neither alter statutory deadlines nor create a TECHNOMATON support commitment.

Severity	Detection to triage	Triage to containment	Resolution	Communication
P1 Critical	15 minutes	1 hour	As soon as possible	Immediate
P2 High	1 hour	4 hours	24 hours	Within 4 hours
P3 Medium	4 hours	24 hours	1 week	Within 24 hours
P4 Low	24 hours	1 week	1 month	As needed

4.5 Regulatory notifications

For every incident, record when the organisation became aware of the event, when it classified it and which criteria it used. There is no single shared deadline:

• GDPR: a controller notifies the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach, unless it is unlikely to result in a risk to individuals’ rights and freedoms. A processor informs the controller without undue delay. Communication to affected individuals follows a separate high-risk test.
• Cybersecurity: in Czechia, determine scope and regime under Sections 15–18 of Act No. 264/2025 Coll., including the special digital-service regime in Section 18. Article 23 NIS2 distinguishes early warning, incident notification and a final report. Its general 72-hour notification deadline from awareness of a significant incident is not the final report; trust service providers have a 24-hour notification deadline.
• DORA: an in-scope financial entity reports a major ICT-related incident as soon as possible, within four hours of classification and no later than 24 hours after awareness. Article 5 of Regulation (EU) 2025/301 sets a special rule for later classification, conditional weekend and bank-holiday extensions and their exceptions, and separate deadlines for subsequent reports.
• AI Act: Article 73 concerns providers of high-risk systems and distinguishes deadlines by the nature of the incident. Assess deployer obligations and the relevant application date separately.

See the current sources and detail for GDPR, cybersecurity, DORA and the AI Act.

4.6 Incident report template

# AI INCIDENT REPORT

## Metadata
| Field | Value |
|---|---|
| Incident ID | INC-YYYY-XXXX |
| System | |
| First awareness | YYYY-MM-DD HH:MM and time zone |
| Classification and basis | |
| Resolved | YYYY-MM-DD HH:MM and time zone |
| Severity | P1/P2/P3/P4 |
| Category | Safety/Privacy/Bias/Security/Performance |

## Summary
[One or two sentences]

## Timeline
| Time | Event |
|---|---|
| | Detection or first awareness |
| | Triage and classification |
| | Containment |
| | Resolution |

## Impact
- People and users affected:
- Data affected:
- Business impact:
- Reputational impact:

## Root cause
[Underlying cause and supporting evidence]

## Resolution
[Actions taken and verification]

## Preventive actions
| Action | Owner | Due |
|---|---|---|
| | | |

## Lessons learned
[Key findings and changes]

## Regulatory notifications
| Authority or recipient | Applicable deadline and trigger | Sent at | Reference |
|---|---|---|---|
| | | | |

5. MG-4: Continuous improvement

5.1 Improvement cycle

5.2 Example review cadence

Review	Frequency	Scope	Participants
Operational	Weekly	Active incidents and metrics	AI operations team
Tactical	Monthly	Risk register and controls	Risk lead and system owners
Strategic	Quarterly	Governance and trends	Leadership
Programme review	Annually	Overall effectiveness	Relevant governing body

5.3 Sources of improvement

Source	Input	How to obtain it
Incidents	Lessons learned	Post-incident reviews
Metrics	Performance trends	Dashboards and evaluations
Audits	Findings and recommendations	Internal or external assessments
Feedback	Complaints and suggestions	Accessible feedback channels
Regulation	Applicable changes	Regulatory monitoring
Industry	Relevant practices and research	Publications and professional exchanges

5.4 Decommissioning

Consider retirement when:

• performance persistently falls below justified requirements;
• the business need no longer exists;
• security or safety risks cannot be adequately mitigated;
• applicable requirements cannot be met;
• a better alternative is available and transition is justified.

Decommissioning checklist:

• Notify affected stakeholders.
• Apply relevant retention and deletion requirements.
• Update the inventory and dependencies.
• Document lessons learned.
• Archive necessary evidence with controlled access.
• Verify that retention and deletion actions were completed.

6. Implementation checklist

The schedule is an illustrative sequence, not a fixed delivery term.

Phase 1: Risk treatment — weeks 1–2

• Establish a risk register.
• Define and justify the scoring method.
• Assign risk owners.
• Prepare treatment plans.

Phase 2: Controls — weeks 3–4

• Implement preventive controls.
• Establish detection mechanisms.
• Prepare corrective actions.
• Document human oversight.

Phase 3: Incident response — weeks 5–6

• Define the incident process.
• Assign responsibilities and decision authority.
• Establish communication channels.
• Run a tabletop exercise.

Phase 4: Continuous improvement — ongoing

• Review risks and controls regularly.
• Conduct post-incident reviews.
• Use evidence to prioritise improvements.
• Track relevant regulatory changes.

7. Templates in this guide

Resource	Purpose
Risk register in section 2	Record, assign and track risks
Incident report in section 4	Record incidents and notifications
Improvement cycle in section 5	Turn lessons into verified changes
Decommissioning checklist in section 5	Retire a system responsibly

Continue to Generative AI risks for context-specific risk areas and controls.

AI-Native Entry Framework | CC BY-NC-SA 4.0