Operationalizing Saudi AI Risk Management in Modulos

This is the rollout playbook for SDAIA's National AI Risk Management Framework in Modulos. It assumes you are already oriented on the framework: the four reference pillars, the five-stage cycle, and the 4×4 matrix (see the framework overview).

The framework is an advisory national methodology, not a law. In the Modulos catalogue the templates carry the Guidance label, which reflects the instrument type. The framework provides guiding lines, methodologies, and tools for entities to build their own internal policies; the regulations its pillars point to remain binding on their own terms.

Recommended project structure

Most rollouts use the following structure:

• One organisation project with the OFF-23 framework template attached. This holds the organization-level foundations set once and consumed by every AI system: the internal AI risk policy, the four pillar registers, the approved risk tolerance and decision-rights ladder, the documentation standards, and the training and capability programme.
• One AI-application project per in-scope AI system with the MFF-23 framework template attached. Each application project holds that system's execution of the risk cycle: the pillar-alignment record, the context-and-scope record, the risk register with its characterizations and scores, the treatment plans and decisions, and the monitoring and incident evidence.

OFF-23 carries 8 requirements (ORF-448–ORF-455); MFF-23 carries 17 requirements (MRF-414–MRF-430) — 25 in total. The two templates operate together: acceptance decisions on the app side reference the org-side tolerance, registers follow the org-side documentation standards, and training derives from app-side risks and treatment plans.

Primary source

SDAIA, National Artificial Intelligence Risk Management Framework, SDAIA-P145, version 1.0, April 2026, Saudi Data and Artificial Intelligence Authority (sdaia.gov.sa). The Arabic text is authoritative; SDAIA has published an official English executive summary (SDAIA-P145EN).

The 25 requirements mapped to framework activities

Framework element	Org requirements (OFF-23)	App requirements (MFF-23)
Purpose and scope	ORF-448 (internal policies and procedures)	—
Reference pillars	ORF-449 (general principles and AI ethics), ORF-450 (AI regulations), ORF-451 (data regulations), ORF-452 (sector regulations)	MRF-414 (per-system pillar alignment)
Context and scope	—	MRF-415 (system description and use boundaries), MRF-416 (data, I/O points, value-chain parties), MRF-417 (automation level and human role), MRF-418 (lifecycle stage and change plan)
Risk identification	—	MRF-419 (comprehensive risk inventory), MRF-420 (characterization by source, intent, and timing)
Risk assessment	—	MRF-421 (likelihood estimation), MRF-422 (impact estimation), MRF-423 (risk level via the 4×4 matrix)
Risk treatment	—	MRF-424 (treatment strategy selection), MRF-425 (control design and implementation), MRF-426 (residual-risk reassessment), MRF-427 (acceptance or escalation decision)
Monitoring and review	—	MRF-428 (continuous performance monitoring), MRF-429 (periodic reviews and register updates), MRF-430 (incident monitoring and response)
Governance and capability	ORF-453 (governance, decision rights, risk tolerance), ORF-454 (documentation standards), ORF-455 (awareness and capability)	—

The parentheticals in the table are activity summaries; the canonical requirement titles are in the templates (for example, MRF-414 is "Reference-Pillar Alignment for the AI System").

None of the 25 requirements carries a conditional applicability gate: the framework's flexibility works through proportionality (depth of application), not through switching duties off. The one conditional element sits inside ORF-455: equipping the internal AI policy function applies where the organization owns one.

Where in Modulos (requirements, controls, evidence, comments)

Surface	Use
Project dashboard Add Framework	Attach OFF-23 to the organisation project; attach MFF-23 to each in-scope AI-system project
Project → Settings → Frameworks	Manage attached frameworks — list, freeze, and update
Project → Requirements	Track the OFF-23 / MFF-23 requirements; status Not fulfilled → Fulfilled
Project → Controls	Document implemented measures — the policy, pillar registers, context records, the risk register with scores, treatment plans, monitoring and incident records — against the controls the template maps to each requirement; control status changes can be routed through review requests
Project → Evidence	Store supporting artefacts (the internal policy, regulatory registers, the per-system risk register, likelihood and impact justifications, treatment decision records, monitoring dashboards, incident reports) and link them to the relevant control components
Comments and logs on each requirement	Capture the rationale for fulfilment attestation, tolerance and escalation decisions, and taxonomy-crosswalk choices

Teams that also run the platform's risk register and quantification surfaces can attach those artifacts as evidence for the register-shaped duties (MRF-419–MRF-429); the framework's own 4×4 scoring remains a documented artifact either way.

The control library: 20 new, 41 reused

The framework pair was built reuse-first: the context, monitoring, and governance duties map largely onto controls the platform already carries, while the framework's own instruments — the pillars, the taxonomy discipline, the scales, and the matrix — needed new controls.

New controls. 20 controls were minted for this framework: 16 app-side (MCF-644–MCF-659) and 4 org-side (OCF-359–OCF-362). Five carry the framework's own instruments and are tagged Framework: Specific; the rest are framework-agnostic and reusable by future frameworks:

Control	Name	Anchored requirement	Framework tag
MCF-644	Record reference-pillar applicability and alignment for the AI system	MRF-414	Specific
MCF-645	Map the AI system's data flows and input/output points	MRF-416	Agnostic
MCF-646	Determine the automation level and the human role in the decision cycle	MRF-417	Agnostic
MCF-647	Verify risk-inventory completeness against a unified AI risk taxonomy	MRF-419	Specific
MCF-648	Characterize each risk by source, intent, timing, and origin	MRF-420	Agnostic
MCF-649	Estimate risk likelihood on the framework's four-level scale	MRF-421	Specific
MCF-650	Estimate risk impact on the framework's four-level scale	MRF-422	Specific
MCF-651	Determine risk levels via the 4x4 likelihood-impact matrix	MRF-423	Specific
MCF-652	Select and document a treatment strategy for each risk	MRF-424	Agnostic
MCF-653	Recompute residual risk with the initial assessment methodology	MRF-426	Agnostic
MCF-654	Analyze AI incident root causes and institutionalize the lessons	MRF-430	Agnostic
MCF-655	Record the AI system context and use boundaries	MRF-415	Agnostic
MCF-656	Define decision approval and escalation paths for the AI system	MRF-417	Agnostic
MCF-657	Maintain the AI system lifecycle record and change plan	MRF-418	Agnostic
MCF-658	Implement risk treatment plans and verify their effectiveness	MRF-425	Agnostic
MCF-659	Record the residual-risk operating decision for the AI system	MRF-427	Agnostic
OCF-359	Derive sector-specific AI controls from applicable sector requirements	ORF-452	Agnostic
OCF-360	Set AI risk documentation and register standards	ORF-454	Agnostic
OCF-361	Derive role-based AI training from system risks and treatment plans	ORF-455	Agnostic
OCF-362	Equip the internal AI policy function	ORF-455	Agnostic

Two pre-existing controls were generalized so this framework could reuse them: MCF-642 (AI incident containment, remediation, and cease-use response, previously carrying UAE-specific wording) and OCF-357 (data-quality directives for AI, previously FINMA-specific). Both are now framework-agnostic shared controls.

Reused shared controls. The remaining mapped controls come from the platform's ISO 42001, NIST AI RMF, NIS2/DORA, and related estates and carry no Saudi-specific text — 22 on the app side and 19 on the org side:

Requirement	Reused controls
MRF-414	MCF-15
MRF-415	MCF-47
MRF-416	MCF-25, MCF-28, MCF-232, MCF-233, MCF-243, MCF-246
MRF-417	MCF-131, MCF-232
MRF-418	MCF-325
MRF-419	MCF-23
MRF-427	MCF-61
MRF-428	MCF-65, MCF-67, MCF-68, MCF-76, MCF-139, MCF-148
MRF-429	MCF-76, MCF-77, MCF-81, MCF-185
MRF-430	MCF-642
ORF-448	OCF-52, OCF-97, OCF-98, OCF-142
ORF-449	OCF-5, OCF-32
ORF-450	OCF-6, OCF-7, OCF-55, OCF-56
ORF-451	OCF-7, OCF-105, OCF-181, OCF-357
ORF-453	OCF-1, OCF-95
ORF-455	OCF-44, OCF-109, OCF-110, OCF-111

Three controls are deliberately double-homed: MCF-76 on MRF-428 and MRF-429 (in-operation risk management feeds both continuous monitoring and periodic re-evaluation), MCF-232 on MRF-416 and MRF-417 (responsibility allocation spans the value-chain record and the decision-role record), and OCF-7 on ORF-450 and ORF-451 (one regulatory register serving two pillars). This reuse is realised at the control layer, not as any assertion of clause-level equivalence.

Framework mapping

Four layers, one reusable spine.

Frameworks

EU AI ActRegulatory

ISO 42001Standard

Requirements

Art. 9.1Risk management

Art. 10.2Data governance

6.1.1Risk assessment

Components

Risk identification

Impact analysis

Evidence

Risk registerDocument

Test resultsArtifact

Controls

The reusable spine

One control satisfies many requirements across many frameworks, and groups the components and evidence beneath them.

Risk assessment process

Data validation checks

Reusable

Edge from any layer card crosses into the Controls spine — the same control may serve a regulatory article, a standards clause, a downstream component, and the evidence that closes it.

Rollout sequence (foundations first)

The order follows the framework's own logic: the organization-level artifacts exist so the per-system cycle can consume them, and each cycle stage consumes the previous stage's record.

1. Stand up the org foundations (org). Adopt the internal AI risk policy on the five-stage methodology (ORF-448); build the pillar registers — principles and ethics, AI regulations, data regulations, sector regulations (ORF-449–ORF-452); approve the risk tolerance and the decision-rights and escalation ladder (ORF-453); set the register documentation standards (ORF-454).
2. Scope each AI system (app). Record pillar applicability and alignment (MRF-414) and the four context records: description and use boundaries, data and I/O, automation level and human role, lifecycle and change plan (MRF-415–MRF-418).
3. Identify (app). Build the comprehensive risk inventory against the seven-category taxonomy or a crosswalked equivalent (MRF-419) and characterize each risk by source, intent, and timing (MRF-420).
4. Assess (app). Estimate likelihood and impact on the four-level scales and compute each risk's level through the 4×4 matrix (MRF-421–MRF-423).
5. Treat and decide (app). Select a strategy per risk, implement controls with owners, timelines, and effectiveness indicators, recompute residual risk with the same methodology, and take the acceptance or escalation decision against the approved tolerance (MRF-424–MRF-427).
6. Operate the standing loop (app + org). Run continuous monitoring with alert thresholds (MRF-428), periodic reviews that update the register (MRF-429), and incident response with root-cause analysis (MRF-430); derive role-based training from the risks and treatment plans the cycle produced (ORF-455).

Each step is fulfilled through controls plus evidence plus a readiness signal plus owner-attested fulfilment.

Evidencing requirements: readiness signal + owner-attested fulfilment

Requirements in Modulos use a two-step pattern, not a review:

• when all linked controls reach a final state, the requirement becomes ready for review — a signal to the requirement owner;
• the requirement owner attests fulfilment by marking the requirement Fulfilled; the status change is logged automatically, and recording the rationale in the requirement's comments is the recommended practice.

Review requests in Modulos apply to control status changes (and other reviewable objects), not to the requirements themselves.

A defensible Saudi AI Risk Management evidence package usually includes: the internal AI risk policy; the four pillar registers and each system's pillar-alignment record; the context-and-scope records; the risk register with per-risk characterizations, factor-justified likelihood and impact estimates, and matrix scores; treatment strategy records and implemented-control evidence; residual-risk reassessments and the documented acceptance or escalation decisions; monitoring indicators, thresholds, and review outputs; incident reports with root-cause analyses; and training records traceable to the risks they address.

Common pitfalls

• Collapsing the register into a single system score. The framework's matrix scores individual register entries; the system-level classification the framework contemplates is revisited in periodic reviews, not a substitute for per-risk scoring. A single system tier cannot support per-risk treatment strategies or residual reassessment; keep the register granular.
• Changing methodology between initial and residual assessment. Residual risk must be recomputed with the same scales and matrix as the initial assessment (MRF-426); switching methods mid-cycle breaks comparability and undermines the acceptance decision.
• Treating the taxonomy as a label-matching exercise. An equivalent taxonomy is acceptable only with demonstrated semantic coverage of the seven categories' full scope. Mapping category names without checking scope leaves inventory gaps.
• Skipping the org foundations. Acceptance decisions need an approved tolerance and registers need common standards. Running the app-side cycle without ORF-453 and ORF-454 produces decisions with no defensible reference point.

Related pages

Saudi AI Risk Management overview

Framework structure, scope, and the OFF-23 / MFF-23 split

Reference pillars and context scoping

The pillars and context activities — ORF-449–452, MRF-414–418

Risk identification and assessment

The taxonomy, scales, and the 4×4 matrix — MRF-419–423

Governance operating model

How projects, requirements, controls, and evidence fit together

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 describes how Modulos maps the framework's pillars and five-stage cycle to platform surfaces through the OFF-23 and MFF-23 framework templates; the methodology itself is in the SDAIA publication, whose Arabic text is authoritative. 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 an advisory national methodology and creates no new obligations; the Guidance label on the Modulos templates reflects the instrument type. Entities remain fully responsible for their own legal and regulatory compliance. Verify against the current published edition and consult qualified advisers.