Risk Treatment, Monitoring, and Incidents

This page covers what happens after risks are scored: the treatment stage (MRF-424–MRF-427) that reduces each risk to an acceptable level and takes the operating decision, and the monitoring and review stage (MRF-428–MRF-430) that keeps the register honest during live operation.

The two stages close the framework's loop. Treatment converts assessment results into implemented controls and a documented decision; monitoring feeds operational reality back into the likelihood and impact estimates, so the register remains a living record rather than a one-time exercise.

Primary source

SDAIA, National Artificial Intelligence Risk Management Framework, SDAIA-P145, version 1.0, April 2026. This page draws on the stages «معالجة المخاطر» (risk treatment) and «المتابعة والمراجعة» (monitoring and review). The Arabic text is authoritative; English renderings are unofficial translations.

Treatment strategy selection (MRF-424)

Each assessed risk receives the most suitable response based on its risk level and the context of use. The framing question the framework poses: is the aim to prevent the risk, lower its likelihood or impact, transfer part of its consequences, or accept it within approved tolerance limits? Four options, chosen in a justified, auditable way:

Strategy	When and how
Avoidance	Modify the design, change the use cases, or restrict or stop functions — when reducing the risk to an acceptable level cannot be achieved
Mitigation	Apply technical, organizational, and operational controls (improving data quality and reducing bias, strengthening security and robustness, adding human intervention, raising transparency, monitoring deviations) to lower likelihood and impact
Transfer	Shift part of the risk or its consequences to another party through contractual arrangements, guarantees, or insurance — transfer does not remove the entity's responsibility for governance and compliance
Acceptance	When residual risk is shown to be within the approved tolerance and minimum controls are confirmed, with the reasons, conditions, and review plan documented

The decision record names the rationale, the responsibilities, and the approval and escalation requirements for high risks, and links the strategy to continuous measurement indicators. In the framework's words, that turns treatment from a theoretical decision into a path that can be executed, reviewed, and held to account. Acceptance presupposes an approved risk tolerance, which is an organization-level artifact (ORF-453).

Control design and implementation (MRF-425)

The approved strategy becomes a measurable implementation plan. Controls are selected to fit the risk's nature and source, in three families:

• Technical — data quality improvement, bias reduction, robustness and security, verification and explanation mechanisms.
• Organizational — policies, procedures, roles and responsibilities, approval requirements.
• Operational — usage procedures, human intervention, performance and deviation monitoring.

Each control gets a clear owner responsible for its design, implementation, and follow-up; an implementation timeline proportionate to the risk level and priority; and measurable indicators of its effectiveness in lowering likelihood or impact, linked to continuous follow-up. The treatment stage's stated aim is to reduce residual risk to an acceptable level before release or during operation: controls land at the applicable lifecycle stage.

Residual-risk reassessment (MRF-426)

After implementation, each risk is re-estimated: likelihood and impact in light of the controls now in place and any changes to the system's design or operating environment, computed with the same assessment methodology as the initial assessment — the same scales and the same 4×4 matrix — to preserve consistency and comparability. The reassessment confirms whether the required reduction was achieved and whether the residual risk falls within the approved tolerance limits or calls for additional measures. Results are documented and linked to the risk register and treatment plans.

Acceptance or escalation decision (MRF-427)

The final, documented decision on operating, releasing, or restricting the AI system, based on the residual risk level and the context of use:

• Acceptance is approved where residual risk is within acceptable limits.
• Escalation routes high risks to the appropriate governance level, where the outcome may be conditional release, restricted use, or temporary or permanent suspension.

The framework requires the decision level to match the system's riskiness, with approvals and escalation paths documented clearly for accountability, transparency, and reviewability. The ladder itself — which role or body decides at which risk level — lives in the paired org template (ORF-453); this activity consumes it.

Continuous performance monitoring (MRF-428)

During live operation, the system's performance and risks are monitored against defined indicators tied to the context of use:

• Model and data health — accuracy degradation, drift in the data or the model's behavior.
• Output quality — error rates, inconsistent results, fairness and bias indicators.
• Unexpected behavior affecting fairness, safety, or compliance.
• User-experience signals, where available — rising complaints, repeated objections to decisions, increasing requests for human review.

Clear alert thresholds trigger response when exceeded, follow-up responsibilities and reporting mechanisms are defined, and monitoring results feed back into the likelihood and impact estimates, redirecting treatment decisions when needed. Early detection is the point: recalibration, control improvements, usage adjustments, or use-case restriction happen while the deviation is still small.

Periodic reviews and risk register updates (MRF-429)

Estimates and controls age. The framework requires methodical reviews on a schedule or on developments: events, model updates, changes in the data, expansion of the scope of use, or new regulatory requirements. Each review re-estimates likelihood and impact per risk, checks treatment mechanisms and controls for continued effectiveness, updates the residual risk level, and revisits the system's classification against its current context of use and actual scope of impact. Review outputs are documented in the risk register in an organized, auditable way. That is what keeps AI risk management, in the framework's phrase, a living, renewing process rather than a fixed procedure.

Incident monitoring and response (MRF-430)

Failures and risk incidents during operation are handled methodically:

1. Reporting — clear mechanisms for reporting incidents or risk indicators as soon as they are detected.
2. Escalation — defined paths proportionate to severity and scope of impact, so the competent parties and decision-makers are involved in time.
3. Root-cause analysis — identifying the technical, operational, or organizational factors behind each incident and evaluating the adequacy of the applied controls.
4. Corrective and preventive action — measures that prevent recurrence.
5. Institutional learning — incidents, analysis results, and lessons learned are documented, linked to the risk register, and used to update the likelihood and impact estimates.

Worked example: treatment in practice

In the framework's appendix scenario (the internal report-drafting LLM), most of the eight registered risks take mitigation; the deliberate-misuse risk takes avoidance with reduction, and the sensitive-data-entry risk takes reduction with partial avoidance. The mitigations lean heavily on human and procedural controls: mandatory human review before any report is adopted, interface notices that outputs are unapproved, prohibited-input rules with data-loss-prevention tooling and audit logs, user training on the model's limits, and double review for sensitive reports. Every risk closes with a documented decision (acceptance after mitigation, or conditional acceptance with immediate escalation on any suspected incident), an expected residual level, and named monitoring arrangements: error-rate tracking, the share of outputs edited by humans as a reliance indicator, log surveillance for sensitive-data entry, and periodic sample reviews of adopted reports.

Cross-framework mapping (preview)

Preview

• ISO/IEC 42001 / ISO 31000 — the treatment stage follows the classic risk-treatment pattern (strategy, controls, residual risk, acceptance), and the monitoring stage aligns with performance-evaluation and improvement clauses.
• NIST AI RMF — treatment corresponds to the Manage function; continuous monitoring and incident feedback align with Measure and Manage outcomes.
• NIS2 / DORA — the incident activity (reporting, escalation, root cause, lessons learned) covers ground those regimes regulate as incident handling, without their statutory notification deadlines.

These are framework-level adjacencies; cross-framework reuse is realised at the control layer, not as clause-by-clause equivalence.

Related pages

Risk identification and assessment

The stage before this one: the taxonomy, scales, and the 4×4 matrix that produce the scores — MRF-419–423

Governance, documentation standards, and capability

The org-level artifacts these activities consume: tolerance, decision rights, register standards — ORF-448, ORF-453–455

Risk management in Modulos

The platform's own risk register and quantification surfaces, usable as evidence for the framework's register duties

Operationalizing in Modulos

The OFF-23 / MFF-23 rollout sequence, control split, and evidence model

Source attribution

The authoritative source is the National Artificial Intelligence Risk Management Framework (SDAIA-P145, version 1.0, April 2026), published by the Saudi Data and Artificial Intelligence Authority. This page draws on the risk treatment and monitoring-and-review stages and the applied scenario in the appendix. The Arabic text is authoritative; English renderings are unofficial translations. Requirement and control codes are Modulos template identifiers, not SDAIA references.

Disclaimer

This page is for general informational purposes and does not constitute legal advice. The framework is advisory and creates no new obligations. Verify against the current published edition and consult qualified advisers.