SDAIA’s AI Risk Management Framework: A Practical Introduction for Organisations and Practitioners
Welcome to my GRC and architecture-led reading of SDAIA’s, National Artificial Intelligence Risk Management Framework (SDAIA-P145), version 1.0, April 2026. This article draws on the whole advisory originally titled
الإطار الوطني لإدارة مخاطر الذكاء الاصطناعي
Does SDAIA's National AI Risk Framework Apply To You?
If any of the following applies to your organisation, the short answer is yes.
In each case, the objective is not to create a parallel risk-management bureaucracy. It is to establish a common and nationally aligned method for understanding AI systems in context, making risk decisions consistently and demonstrating how those decisions are governed throughout the AI lifecycle.
Discuss your challenge with us
More Views From The Nexus
TL;DR
This Article at a Glance
Two decades working across IT, data, GRC, cybersecurity and Enterprise Security Architecture have shown me that AI introduces risks conventional technology controls were not designed to address.
AI outcomes may be difficult to explain or reproduce, while performance and risk can change as data, operating conditions and use evolve. The model is only one part of the system. Harm may also arise from data, technology, deployment context or how people act on its outputs. AI risk must therefore be understood against business objectives, stakeholders, risk appetite and operating conditions.
SDAIA’s National AI Risk Management Framework gives Saudi organisations a practical methodology for identifying, assessing, treating and monitoring these risks.
This article focuses on SDAIA’s methodology and practical application. Despite some rudimentary commentary towards the end of this article on Enterprise Security Architecture (ESA), the wider ESA perspective remains critical, and we welcome enquiries about integrating the framework into a SABSA-based architecture from organisations seeking advisory.
Figure 1 presents its five connected stages, governed by four reference pillars and informed by SDAIA’s AI Ethics Principles and seven-category risk taxonomy.
SDAIA's AI risk management lifecycle
Five connected stages provide a common method for understanding, assessing, treating and continuously monitoring AI risk.
-
Context and scope
Define the AI system, its purpose, intended and prohibited uses, stakeholders, data, operating environment and assessment boundary.
-
Risk identification
Identify credible risk scenarios, their sources, affected parties, related weaknesses and potential consequences.
-
Risk assessment
Evaluate the likelihood and impact of each identified risk and determine its initial risk level.
-
Risk treatment
Select and implement proportionate treatment measures, then reassess the remaining or residual risk.
-
Monitoring and review
Monitor performance, controls, incidents and changes that may require the risk assessment to be revisited.
Why AI Risk Needs Its Own Approach
Why are cybersecurity, ISO/IEC 27005 and privacy risk frameworks not enough?
Saudi organisations already use established frameworks to manage cybersecurity, information security and privacy risk provided by the likes of the National Cybersecurity Authority and the Saudi Central Bank, as well as the National Data Management Office. ISO/IEC 27005 (an internationally accepted best practice standard in the ISO/IEC 27000 family of standards and focused on information security risk management) provides a structured approach to information security risk management, while privacy frameworks focus on the lawful and responsible processing of personal data. These remain essential, but they do not address the complete risk profile of an AI system.
Cybersecurity frameworks typically focus on threats to confidentiality, integrity and availability. Privacy frameworks focus on how personal data is collected, processed, shared and protected. AI risk extends across these concerns, but also includes the behaviour, performance and consequences of the system itself.
An AI system may be secure and privacy-compliant while still producing inaccurate, biased, unsafe or misleading outcomes. It may perform well during testing but become less reliable as data, operating conditions or patterns of use change. Users may also place too much confidence in its outputs, apply it outside its intended purpose, or make decisions without appropriate human oversight.
AI risk emerges from the interaction of data, models, technology, people and operating context, and from the consequences those interactions create for affected stakeholders.
This is why the same AI capability may present very different risks in different settings. A model used to categorise internal documents is not equivalent to the same model supporting recruitment, lending, healthcare or access to public services. The technology may be similar, but the objectives, stakeholders and potential for harm are not.
With these distinctions established, we hope the need for an AI-specific risk management approach is now clear. SDAIA’s framework responds to this broader and more dynamic risk landscape by recognising that AI risks may emerge unexpectedly, change over time and prove difficult to explain or reproduce. Risk management must therefore continue throughout the AI lifecycle, from defining the use case and its context to deployment, monitoring and eventual retirement.
The answer is not to replace existing cybersecurity, ISO 27005 or privacy risk practices. It is to integrate and extend them. SDAIA’s framework provides the AI-specific perspective needed to connect security, privacy, data, model, human and contextual risks within a common risk management approach.
Where AI risk emerges
AI risk does not originate from the model alone. It emerges from interactions across the complete system and its operating context.
-
Data
Quality, provenance, suitability, representativeness and change over time.
-
Model
Behaviour, accuracy, bias, limitations, explainability and reliability.
-
Technology
Platforms, integrations, infrastructure, dependencies and security controls.
-
People
Use, interpretation, decision-making, oversight and reliance on outputs.
-
Context
Purpose, stakeholders, operating conditions and potential consequences.
AI system behaviour and outcomes
The interaction between these domains determines how the system behaves, how its outputs are used and what consequences may follow.
Changing AI risk profile
As data, use and operating conditions evolve, the nature, likelihood and impact of risk may also change.
Reading SDAIA's AI Risk Framework
SDAIA issued the framework, under Council of Ministers Resolution No. 292, to establish a unified national methodology for identifying, assessing, treating and monitoring AI risk in support of Saudi Vision 2030 and the National Strategy for Data and AI.
The framework is pragmatic in its approach rather than prescriptive. It focuses particularly on AI systems with a high potential impact on individuals, assets and operations, while allowing organisations to apply its methodology in proportion to their sector, size, use and digital maturity.
The framework is intended for AI developers, system operators and policymakers. It recognises that AI requires a distinct risk approach because data may not represent real operating conditions, system behaviour can change over time, and outcomes may be difficult to predict, test or reproduce.
Organisations are often eager to move directly towards policies, controls, assessments and compliance evidence (bottom-up approach). The framework is divided among specialist functions, responsibilities are assigned, and implementation begins. Yet insufficient time is spent understanding how its constituent parts relate to one another.
The result may be a collection of individually reasonable activities that never mature into a coherent management system.
SDAIA avoids much of this ambiguity by presenting the essential structure of its AI Risk Management Framework in a single view. Figure 3 brings together two distinct yet complementary dimensions: four reference pillars that govern the framework and a five-stage process for managing AI-related risks. I have translated the original Arabic text in the illustration below for the readers’ convenience.
The four reference pillars
Across the upper part of the framework sit four reference pillars:
- General principles
- AI regulations
- Data regulations
- Sector regulations
These pillars are not stages in a sequence. An organisation does not complete the general principles and then proceed to data regulation. They are continuing sources of values, obligations and constraints that must inform every stage of the risk-management process.
They answer a foundational question:
What must govern the enterprise’s design, development, deployment and use of artificial intelligence?
General principles
The first pillar establishes the ethical and human foundation of the framework. SDAIA identifies seven principal areas:
- integrity and fairness;
- privacy and security;
- humanity;
- social and environmental benefit;
- reliability and safety;
- transparency and explainability; and
- accountability and responsibility.
AI regulations
The second pillar concerns the policies, legislation and regulatory frameworks that govern the development and operation of AI systems.
Its purpose is to establish:
- applicable obligations;
- organisational responsibilities;
- conditions for safe and responsible use;
- governance and compliance expectations;
- consistency of control implementation; and
- continuing accountability throughout the AI lifecycle.
Data regulations
The third pillar addresses the collection, processing, storage and use of data within AI systems.
This includes considerations such as:
- lawful and defined purpose;
- privacy and protection of personal or sensitive data;
- access control;
- data quality and integrity;
- provenance and traceability;
- retention;
- authorised sharing;
- bias; and
- the security of data throughout its lifecycle.
Sector regulations
The fourth pillar recognises that AI risk is inseparable from the environment in which the system is used.
An AI system employed in healthcare does not possess the same consequence profile as one used for marketing. A model supporting financial eligibility decisions must be governed differently from one helping employees retrieve internal information. The technology may be similar, but the affected rights, safety considerations, regulatory obligations and acceptable risk levels may be markedly different.
Sector context therefore affects:
- the sensitivity of the information involved;
- the significance of the decision being supported;
- the populations that may be affected;
- the consequences of error;
- the required level of human involvement;
- applicable standards and regulations; and
- the degree of assurance the enterprise must demand.
This is an early indication of a principle that will become central to our architectural reading in more architectural-focused writing at a later date. Suffice it to say for now that,
Executing SDAIA's five-stage management process
- Context and scope
- Risk identification
- Risk assessment
- Risk treatment
- Monitoring and review
1. Context and Scope
The organisation first establishes what is being assessed and under which conditions.
This includes:
- The system type, purpose, and intended or prohibited uses
- Direct users and affected stakeholders
- Associated data, inputs and outputs
- Internal and external parties, responsibilities and approval routes
- The level of automation and human involvement in decisions
- Lifecycle stage, change management and reassessment arrangements
This stage is more consequential than it may initially appear. If the context is drawn too narrowly, the risk assessment will inherit that narrowness. The organisation may assess the model and overlook the business process, or examine the application while ignoring the external provider, affected customer or human decision-maker.
As I generally tell all my clients, implementing SDAIA’s AI Risk Management Framework does not require them to begin with a complex governance foundation or elaborate GRC tooling. A simple, well-owned process is more valuable than sophisticated technology with unclear accountability.
In fact, I would recommend starting with a manual approach. It keeps the process hands-on, helps teams understand the decisions and evidence involved, and exposes practical gaps before they become embedded (which usually means easily hidden) in a maze of different application screens. Once the process is understood and repeatable, the organisation has a far more pragmatic basis for integration and automation.
The objective is to establish visibility first, then progressively integrate AI risk management into existing organisational processes and systems.
Create an AI system inventory
Begin with a simple spreadsheet or manually maintained table. Record enough information to understand what the AI system does, where it is used and who is accountable for it.
Do not wait for a perfect definition of AI. Begin with known use cases and refine the inventory as organisational understanding improves.
At minimum, capture the following:
Start with a simple table that establishes visibility, accountability and a basic understanding of each AI system.
| Field | What to record |
|---|---|
| AI system or use case | Name and short description |
| Business purpose | The objective or decision it supports |
| Business owner | Person accountable for its use and outcomes |
| Technical owner | Team responsible for implementation and operation |
| Model or provider | Internal model, external service or embedded capability |
| Data | Main data sources and classifications |
| Affected stakeholders | People whose interests or decisions may be affected |
| Risk level | Initial likelihood and impact assessment |
| Lifecycle status | Proposed, testing, deployed, suspended or retired |
| Last assessment | Date of the most recent risk review |
2. Risk identification
- Bias, discrimination and system reliability
- Privacy, security and misuse
- Social, economic and environmental consequences
- The conduct of human and organisational actors
3. Proportionate Risk Assessment
Not every AI system requires the same level of scrutiny. Use an initial screening assessment to determine the system’s context, potential impact and required depth of review.
A low-impact productivity tool may need basic safeguards and user guidance. An AI system influencing employment, healthcare, financial or public-service decisions will require stronger evidence, oversight and approval.
Each identified risk is assessed by considering how likely it is to occur and the scale of its potential impact. SDAIA’s approach here adheres to the commonly used risk-scoring methodology, using the simple likelihood x impact formula visualised below.
Identified risks are therefore analysed according to their likelihood and impact.
The organisation considers:
- the nature of the risk;
- factors influencing its occurrence;
- exposure;
- existing controls;
- the potential scale of consequence; and
- the resulting level of risk.
This stage supports prioritisation. Not every risk can or should receive equal treatment. The organisation must determine which risks require immediate action, which may be monitored and which may be accepted within defined authority.
Likelihood and impact matrix
| Impact / likelihood | 1 Rare | 2 Unlikely | 3 Likely | 4 Almost certain |
|---|---|---|---|---|
| 4 Catastrophic | 4 Medium | 8 High | 12 High | 16 Catastrophic |
| 3 High | 3 Medium | 6 Medium | 9 High | 12 High |
| 2 Medium | 2 Low | 4 Medium | 6 Medium | 8 High |
| 1 Low | 1 Low | 2 Low | 3 Medium | 4 Medium |
4. Risk Treatment
The organisation selects an appropriate response for each material risk.
Treatment may include:
- avoiding the activity;
- reducing the likelihood of occurrence;
- limiting the severity of consequence;
- transferring or sharing aspects of the risk; or
- accepting the residual risk under defined conditions.
Controls and actions must then be assigned to accountable owners and incorporated into the design and operation of the AI system.
Record controls and evidence
For each material risk, record the selected treatment, responsible owner and supporting evidence. Evidence may include test results, data assessments, architecture decisions, supplier documentation, human-oversight procedures and monitoring reports.
The aim is not to accumulate documents. It is to preserve a traceable explanation of what was decided, why it was considered appropriate and who accepted any remaining risk.
Each assessed risk requires a documented treatment strategy, implemented controls and a decision on whether the remaining risk is acceptable, the diagram below shows an overview from assessment to the end of the treatment process.
Assessed AI risk
The likelihood, impact and initial risk level have been determined and documented.
Select an appropriate treatment strategy
-
Avoid
Stop, redesign or remove the activity that creates the risk.
-
Mitigate
Introduce controls that reduce the likelihood or impact.
-
Transfer
Allocate part of the risk through contracts, insurance or another party.
-
Accept
Retain the risk through an informed and authorised decision.
Implement and document the treatment
Assign an owner, implement the required controls and retain evidence of the decision and its rationale.
Assess the residual risk
Recalculate likelihood and impact after considering the effectiveness of the implemented controls.
Is the residual risk within approved tolerance?
Approve and monitor
Record the acceptance decision and continue monitoring the risk, controls and operating environment.
Escalate or revise
Strengthen the treatment, redesign the use case, or escalate the decision to the appropriate authority.
5. Monitoring and review
AI risk management continues after deployment. Organisations should monitor:
- System performance and model behaviour
- Changes in data, context and emerging threats
- Control effectiveness and human intervention
- Incidents, complaints and unintended consequences
- Changes requiring formal reassessment
Monitoring produces new knowledge. That knowledge may change the organisation’s understanding of context, reveal new risks or challenge earlier assumptions. The process must therefore return to identification and assessment when circumstances change.
The lifecycle is continuous because the system, the enterprise and the environment around them are all capable of change.
Define reassessment triggers
As noted earlier, the dynamic nature of AI means that risk assessment must continue after deployment. Define clear reassessment triggers, including:
- Material changes to the model, provider or data sources
- Expansion into new use cases or user groups
- Significant performance deterioration or harmful outcomes
- Security, privacy or safety incidents
As shown in the diagram below, AI risk management continues after deployment. Changes in the system, its data or its operating environment may require risks, controls and decisions to be reassessed.
Integrate with existing systems
Once the manual process is stable, integrate the inventory with existing governance and technology platforms.
The Configuration Management Database can provide useful information about applications, infrastructure, owners and technical dependencies. AI-specific records can then be linked to the relevant application, data service, model, supplier and business service.
The CMDB should support the AI inventory, not replace it. Conventional configuration records rarely capture purpose, affected stakeholders, model limitations, risk decisions or human-oversight requirements.
Over time, AI risk management can be integrated with:
- Enterprise architecture repositories, data catalogues and model registries
- GRC platforms and privacy or security assessments
- Change, release, incident and issue management
- Performance and control-monitoring platforms
Keep the AI risk profile under review
-
Deploy and operate
Place the approved AI system into its intended operating environment with defined ownership and controls.
-
Monitor performance and risk
Track system behaviour, performance, incidents, control effectiveness and emerging risk indicators.
-
Detect change or incident
Identify changes in data, models, use, stakeholders, regulation or operating conditions.
-
Reassess the risk
Reconsider likelihood, impact and residual risk using the organisation's approved assessment method.
-
Update controls and records
Revise treatments, decisions, monitoring requirements and the AI risk register where necessary.
Two Dimensions, One Framework
In light of what is mentioned in this section, Figure 3 can therefore be read as the intersection of two dimensions.
The first is a governing dimension, represented by the four reference pillars:
General principles, AI regulations, data regulations and sector regulations.
The second is an operational dimension, represented by the five stages:
Context, identification, assessment, treatment, monitoring and review.
The reference pillars establish the criteria that must be respected. The five-stage process establishes the activities through which those criteria are applied.
In practical terms, every stage must remain informed by every relevant pillar.
When context is established, the organisation must consider applicable principles and regulations. When risks are identified, it must consider ethical, data, technical and sector-specific consequences. When treatments are designed, the resulting controls must satisfy the same governing conditions. When the system is monitored, evidence must show that those conditions remain satisfied in operation.
This relationship is fundamental:
How SDAIA’s framework relates to International and Regional AI frameworks
- NIST AI RMF: The closest methodological comparison. Both provide flexible, lifecycle-based approaches, but SDAIA applies its own reference pillars, risk taxonomy, assessment scales and five-stage process.
- ISO/IEC 42001: Provides a certifiable organisation-wide AI management system. SDAIA complements it with a Saudi-specific methodology for identifying, assessing, treating and monitoring individual AI risks.
- EU AI Act: Establishes binding legal obligations within its scope. SDAIA is an advisory risk-management framework, so the two serve different purposes even where governance and control requirements overlap.
- UAE AI Ethics: Shares many responsible-AI principles, while SDAIA embeds those principles within a broader and more structured risk-management lifecycle.
AI Risk as an Emergent Property of the Enterprise
Where, precisely, does an AI risk begin? Does it begin within the model, within the data from which the model learns, within the process that employs its output, or within the human decision through which that output acquires consequence?
Donella Meadows begins her book Thinking in Systems by holding a Slinky from above while supporting it underneath. When she removes the supporting hand, the Slinky oscillates. She repeats the action with its rigid box, which simply hangs. The action is the same, but the response differs because behaviour arises from the system’s internal structure. External events may trigger behaviour; they do not determine it alone.
The analogy carries a powerful lesson for AI risk. A threat, model failure, hallucination or unexpected output may trigger an event, but the eventual consequence is shaped by the enterprise into which it is released. Data relationships, process dependencies, human authority, technical controls and feedback mechanisms determine whether the event is absorbed, amplified or transformed into harm. Risk therefore cannot be understood from the triggering event alone. We must examine the structure that gives the event consequence.
This is particularly dangerous in artificial intelligence. If the unit of analysis is limited to the model, the organisation may carefully assess accuracy, robustness and technical security while overlooking the business process in which the model participates, the people affected by its outputs, the authority granted to those outputs and the conditions under which human intervention remains possible.
The result may be a well-controlled model operating within a poorly designed and governed system.
The model is not the system
An AI model creates neither enterprise value nor social consequence in isolation. Its outputs acquire meaning through connections with:
- Data used to train, test or inform it
- Applications, platforms, networks and interfaces
- Processes, people and decision authorities
- Products, services, external providers and supply chains
- Governance and accountability arrangements
A model may produce a recommendation, but the enterprise determines what happens next. Users may challenge, misunderstand or accept it, while applications and organisational practices may give it more authority than intended.
Risk therefore arises not only from what the model can do, but from what the enterprise allows its outputs to become.
SDAIA’s emphasis on context
SDAIA reflects this wider view by requiring AI risk to be assessed within the system’s actual context of use.
This includes:
- Purpose, operating environment, and intended or unauthorised uses
- Relevant data, inputs and outputs
- Direct users and affected stakeholders
- Internal and external parties, automation and human decision-making
- Lifecycle stage, change and reassessment arrangements
These are not administrative details preceding risk assessment. They help determine the risk itself.
The same model may present very different risks when used to:
- Draft an internal email
- Prioritise a medical case
- Recommend access to financial services
- Identify a security incident
- Determine access to an essential public service
- Initiate action without prior human approval
The technology may be similar, but the purpose, authority, affected stakeholders and potential consequences are not.
From component failure to emergent consequence
Traditional technical analysis often begins with components: the vulnerability, the threat and the control. These questions remain necessary, but they cannot explain qualities such as fairness, accountability, safety and trustworthiness, which emerge through the interaction of the wider system.
Fairness, for example, may depend upon representative data, model behaviour, application design, human judgement, appeal routes and outcome monitoring. Accountability requires more than a technical log. It also requires an identifiable owner, clear decision authority and a means of challenging or correcting outcomes. Safety similarly depends upon operating conditions, human competence, escalation and the ability to suspend the service.
No single component owns these qualities, but the enterprise remains accountable for achieving them.
Risk travels through relationships
This changes how AI risk scenarios should be expressed.
A limited statement might read:
“The AI model may produce an inaccurate output.”
A more useful scenario would read:
“Unrepresentative operational data may produce an inaccurate recommendation which, when accepted without sufficient explanation or review, results in an inappropriate customer decision.”
The second statement identifies the data, model behaviour, process condition, human dependency, affected party and potential consequence. It also demonstrates why no single control will be sufficient. Effective treatment may combine data-quality controls, explanation requirements, human review, escalation, appeal and outcome monitoring.
Architecture distributes these responsibilities without allowing accountability to disappear between them.
Risk includes opportunity
Those of us working in security and GRC are naturally trained to look for adverse outcomes. We ask what may fail, who may attack and which obligation may be breached. These questions are essential, but they represent only one side of uncertainty.
The SABSA Risk Management Process also considers positive or upside risk. It asks which opportunities might become available if the enterprise develops the right capabilities, attributes and controls.
An AI system may create opportunities to:
- identify emerging problems earlier;
- improve consistency of service;
- extend access to specialist knowledge;
- reduce repetitive administrative work;
- strengthen fraud or threat detection;
- improve organisational resilience; and
- release human attention for work requiring judgement, creativity or empathy.
These benefits are not automatic. They also depend upon the wider system.
A promising model may fail to create value if employees do not trust it, if the process is poorly designed, if the data arrives too late or if governance prevents responsible experimentation. Opportunity, like harm, emerges through relationships.
The purpose of AI-risk architecture is therefore not to eliminate uncertainty. It is to help the enterprise understand and shape it, reducing unacceptable harm while enabling legitimate advantage.
The architectural implication
Once AI risk is understood as an emergent property, the task of implementation changes.
The organisation can no longer ask only:
It must also ask:
- What enterprise purpose, product, service or decision does the AI support?
- Which people, populations, information and business domains does it affect?
- Where do human authority, ownership and accountability reside?
- Which relationships create dependency, and what qualities must they preserve?
- What evidence demonstrates that the system remains within acceptable conditions?
These are architectural questions because they concern purpose, structure, behaviour, ownership and relationship.
SDAIA provides the governing principles and risk-management lifecycle through which they must be answered. Enterprise Architecture provides a view of the system. SABSA provides the means to define its required qualities, allocate responsibility and trace risk through domains, controls and evidence.
Questions or Observations?
Frequently Asked Questions About SDAIA's National AI Risk Framework
Is the framework a legal obligation for Saudi organisations?
No. The framework is advisory only and creates no new legal obligations. It provides guidance, methodologies and tools to help organisations develop their own AI risk-management policies and procedures. Any laws and regulations referenced by the framework remain binding on their own terms.
Who is the framework intended for?
It is intended for government entities and private-sector organisations operating in Saudi Arabia.
What does the framework focus on, and who should implement it?
The framework focuses particularly on AI systems that may significantly affect individuals, assets or operations. Examples include predictive models, natural language processing, image and video analysis, intelligent automation and general-purpose AI models.
It addresses three principal audiences: AI system developers, system operators and policymakers. In practice, implementation will also require coordinated involvement from business owners, risk, data, cybersecurity, legal, compliance and architecture functions.
Can we use our existing risk methodology or taxonomy?
Yes, provided that the relationship is documented through a clear crosswalk and that no relevant AI risk category is overlooked. SDAIA’s seven-category taxonomy provides the initial baseline, covering bias, discrimination and abuse; privacy and security; misinformation; malicious use; human-machine interaction; social, economic and environmental impacts; and safety and limitations.
The framework does not prescribe a formal process for approving an alternative taxonomy. Organisations should therefore document their rationale, mapping, coverage and governance decisions. For further support, contact us.
Do we need to establish a new AI Risk Committee in our organisation?
Not necessarily. AI risk oversight may be incorporated into an existing risk, technology or governance committee, provided it has the appropriate authority, expertise and accountability. The priority is effective governance, not creating another committee.
Is the complete framework officially available in English?
No. SDAIA has published an official English executive summary, SDAIA-P145EN, but the complete framework is published in Arabic. The Arabic text remains authoritative, and any full English rendering should be treated as an unofficial translation.
Sources, translations and attributions
Primary source: Saudi Data and Artificial Intelligence Authority (SDAIA), الإطار الوطني لإدارة مخاطر الذكاء الاصطناعي [National Artificial Intelligence Risk Management Framework], SDAIA-P145, version 1.0, April 2026. Available through the official SDAIA publications portal.
Official English summary: Saudi Data and Artificial Intelligence Authority (SDAIA), National Artificial Intelligence Risk Management Framework: Executive Summary, SDAIA-P145EN, version 1.0, April 2026.
Translations: The complete framework is published in Arabic, which remains the authoritative text. Unless expressly identified as official SDAIA wording, English translations and renderings in this article are unofficial Eternal Nexus translations provided for explanation and accessibility.
Figures and diagrams: Figures identified as “adapted from SDAIA-P145” are original visual interpretations of the framework by the author and should not be understood as official SDAIA diagrams. Any directly reproduced SDAIA material is identified separately and attributed to the relevant publication and page.
Supporting references: Comparative observations draw upon official publications from NIST, ISO, the European Union and the UAE Government.
Independence statement: This article is an independent practitioner interpretation. It has not been prepared, approved or endorsed by SDAIA and does not constitute legal or regulatory advice.
Sources last reviewed: 20 July 2026.