SAMA IT Governance Framework: A CIO's Guide

The SAMA IT Governance Framework turned IT governance in a Saudi financial institution from a board slide into a regulated, assessable obligation that lands squarely on the CIO. It tells you how your IT function must be governed, how IT risk must be assessed and reported, who must sit on your IT Steering Committee, and — unusually for a governance document — it even sets conditions on who may hold the CIO role.

For a CIO, that makes the framework less a compliance checklist and more an accountability map. The controls describe the operating model the regulator expects of your IT organisation, and the IT risk management domain at the heart of it describes how the Saudi Central Bank wants you to see, treat and report the risk in your technology estate. This is the CIO's guide to what the framework requires and how to run it without it running you.

What the SAMA IT Governance Framework is

The Information Technology Governance Framework is Version 1.0, issued by the Saudi Central Bank in November 2021 under Circular No. 43028139 (29/3/1443H). It is mandated by SAMA, which owns and maintains it, and it applies to member organisations regulated by SAMA — the framework text states the scope at that level rather than enumerating sectors, though secondary reporting describes the banking sector, Saudi Payments and credit bureaus as in scope.

Critically, the framework is not meant to be read alone. Its own scope section (§1.3) states that it "should be implemented in conjunction with SAMA's Cyber Security and Business Continuity framework," and it includes a diagram of the relationship between the SAMA frameworks. The IT Governance Framework is the IT operating-model layer; the SAMA Cyber Security Framework and the BCM Framework sit alongside it for cyber and continuity specifics.

Like the other SAMA frameworks, it is assessed through a periodic self-assessment. Section 2.3 requires member organisations to complete a SAMA questionnaire that "will be reviewed and audited by SAMA to determine the level of compliance with the framework and the IT maturity level." The output is a maturity score, not a pass/fail.

The four domains

The framework is organised into four domains, each containing subdomains that state a Principle followed by numbered Control Requirements. There are 35 subdomains in total — a point worth stating plainly because several secondary summaries circulate an incorrect "25 subdomains" figure (they understate the System Change Management domain).

IT risk management: inside Domain 2

For a CIO, Domain 2 is the centre of gravity, because it is where the framework converts "govern IT well" into a defined, auditable risk process. The framework defines IT risk management as a continuous process of "identifying, analysing, responding, monitoring and reviewing risks related to IT from process, technology and people perspectives," carried out within tolerance levels set by senior management. Four subdomains structure it.

Managing IT risks (§3.2.1)

The IT risk management process must be defined, approved, implemented, communicated and — the phrase the regulator returns to repeatedly — aligned to the organisation's enterprise risk management process. It has to cover information assets across business processes and data, applications, infrastructure, and third-party relationships. Two control requirements matter most operationally:

• When risk assessment is triggered. A risk assessment must be initiated at the early stage of a programme or project, before critical or major changes, at the time of outsourcing, and before procuring new systems or adopting emerging technology (the framework names distributed ledger and robotic process automation explicitly).
• How often. All mission-critical and critical information assets must be risk-assessed at least once a year; non-critical assets are assessed according to business importance.

Risk responses follow the four classic options — avoid, mitigate, transfer, accept — and every response must be consistent with the organisation's risk appetite. IT Key Risk Indicators (KRIs) must be defined, implemented and monitored.

Risk identification and analysis (§3.2.2)

The framework requires a formal, centralised risk register, regularly updated, in which each risk records its asset classification, threats, impact and likelihood, the existing controls, the risk owner and control owner, and both inherent and residual risk. This is the artefact a SAMA assessor reaches for first, and a register that lacks owners or residual scoring is a predictable finding.

Risk treatment (§3.2.3)

Treatment is applied per the four options, in line with risk appetite, and approved by the IT Steering Committee. The framework is pointed about acceptance: risk acceptance is the least preferred option, must be formally documented, signed by the business owner, reported to the risk committee, kept within risk appetite, and must not contradict SAMA regulations — with periodic renewal so accepted risks cannot quietly become permanent.

Risk reporting, monitoring and profiling (§3.2.4)

Results are documented and reported to business owners and senior management, monitored against the treatment plan, and endorsed by the risk committee. Crucially, the IT risk profile feeds the operational risk function to build an organisation-level risk picture, and is presented periodically to senior management, the IT Steering Committee and the board.

The framework's consistent message to the CIO: IT risk is not an IT-department concern. It is set against board-owned risk appetite, endorsed by the risk committee, rolled into enterprise risk, and reported to the board — or it does not count.

What the framework expects of the CIO

Few governance frameworks legislate the leadership structure as directly as this one. For the CIO, the relevant mandates are explicit and citable.

• Board accountability. The board holds ultimate responsibility for establishing IT governance, must ensure a robust IT risk management framework exists, must approve the IT Steering Committee charter, and must endorse the IT strategy and IT policy.
• The IT Steering Committee (ITSC). Member organisations must establish a board-mandated ITSC, headed by a senior manager and including the CIO, CRO, CISO, compliance officer and business heads, with internal audit attending as observer. It requires a charter and must meet at least quarterly.
• CIO accountabilities. The CIO develops, implements and maintains the IT strategy, IT policy and IT budget; ensures IT standards and procedures; delivers risk-based IT solutions across people, process and technology; defines and maintains KPIs and KRIs; and briefs the ITSC on strategic initiatives.
• IT investment governance. Formal practices for IT budget and cost, with spending prioritised against the IT strategy and monitored through the year.

How it interlocks with the CSF and BCM frameworks

Because the framework explicitly directs you to implement it alongside the Cyber Security Framework and the BCM Framework, the practical reality for a CIO is overlapping control surfaces. IT asset management, change management, incident management and third-party governance all appear — from different angles — in the IT Governance Framework, the CSF, and the BCM Framework. Asset management under ITGF Domain 3 is the same asset inventory the CSF expects; the IT incident process under ITGF feeds the cyber incident process under the CSF; the IT risk register under Domain 2 should reconcile with the cyber risk register rather than contradict it.

A CIO who runs these as three separate documentation efforts pays three times and produces three slightly different versions of the truth. A CIO who maps each control once, to every framework it satisfies, turns the overlap from a cost into a saving — the same discipline we cover for the cyber side in the SAMA CSF and NCA self-assessment guide.

The CIO's real challenge: evidence and reconciliation

As with the rest of the SAMA family, the framework is satisfied with operating evidence, not policy binders. Reaching a defensible maturity level across 35 subdomains means producing, on demand: the ITSC charter and meeting minutes showing quarterly cadence; the IT strategy with board endorsement; the centralised IT risk register with owners and inherent/residual scores; the annual risk-assessment records for critical assets; the change-management and patch records under Domain 4; and the performance KPIs reported to the ITSC.

The friction is rarely that these things do not exist. It is that they live in different tools — the risk register in one spreadsheet, the committee minutes in email, the change records in a ticketing system, the maturity scores in last year's assessment file — and the CIO spends the assessment cycle reconciling them by hand, then doing a version of the same reconciliation again for the CSF.

How GRC Vantage supports SAMA IT governance

GRC Vantage gives the CIO the IT Governance Framework pre-mapped across all four domains and 35 subdomains, with the 0–5 maturity model built into the assessment so the self-assessment, the gap analysis and the target-state plan live in one place and trend year over year.

The Domain 2 IT risk requirements run on the risk management module: a centralised IT risk register with risk and control owners, inherent and residual scoring, treatment approvals routed to the ITSC, risk-acceptance records with renewal dates, and KRIs monitored against appetite — with the annual critical-asset assessment scheduled and evidenced. Because the IT risk profile is structured data, it rolls up into the enterprise risk picture and into the board and ITSC reporting the framework requires, rather than being re-typed into a slide each quarter.

And because every control carries its mappings, the controls the IT Governance Framework shares with the SAMA CSF — assets, change, incidents, third parties — are answered once and satisfy both frameworks. The platform is deployed inside Saudi Arabia for PDPL and SAMA data-residency, with Riyadh and Dammam teams who pre-load the framework content so the mapping is in place from day one.

For the full SAMA framework family, read our SAMA frameworks pillar guide; when you want to see the IT risk register and the ITGF maturity assessment running on real data, book a session with our team.

Building the programme: practical sequencing for a CIO

1. Stand up the governance scaffolding first. The ITSC (chartered, quarterly), the board-endorsed IT strategy and the IT policy are the spine; without them, every downstream control is capped at a low maturity level.
2. Build the centralised IT risk register. Owners, inherent and residual scoring, and the link to enterprise risk. This single artefact carries most of Domain 2.
3. Schedule the annual critical-asset assessments. Make the "at least once a year" requirement a calendared, evidenced process, plus the event triggers (projects, major changes, outsourcing, new tech).
4. Map controls across ITGF, CSF and BCM. Answer shared controls once. This is the largest efficiency lever.
5. Run the self-assessment and score honestly. The honest maturity baseline drives a remediation plan worth having.
6. Generate the reporting from the data. ITSC packs, board risk reporting and the SAMA self-assessment as exports, not hand-built decks.

Frequently asked questions

When was the SAMA IT Governance Framework issued?

Version 1.0 was issued by the Saudi Central Bank in November 2021 under Circular No. 43028139 (29/3/1443H). It is mandatory for SAMA-regulated member organisations and is assessed through a periodic self-assessment.

What are the four domains of the SAMA IT Governance Framework?

The four domains are IT Governance and Leadership, IT Risk Management, IT Operations Management, and System Change Management — 35 subdomains in total, each stating a principle and numbered control requirements.

What does the framework require for IT risk assessment?

Domain 2 requires a continuous IT risk process aligned to enterprise risk management: a centralised risk register with inherent and residual scoring and named owners; risk assessments triggered at project start, before major changes, at outsourcing and before adopting new technology; mission-critical assets assessed at least annually; treatment approved by the IT Steering Committee within risk appetite; and IT risk reported to the risk committee and the board.

Does the framework set requirements for the CIO role?

Yes. A full-time senior CIO must be appointed, the CIO must be a Saudi national, and SAMA's written no-objection is required before the appointment. The CIO also owns the IT strategy, policy, budget, and the IT KPIs and KRIs, and sits on the board-mandated IT Steering Committee.

Is the SAMA IT Governance Framework based on COBIT?

The framework's structure and its 0–5 maturity model closely parallel COBIT, and its risk process resembles ISO 27005/31000 — but the document itself references only generic "industry IT standards" and does not name COBIT, ISO/IEC 38500 or any specific external standard, so alignment to them should not be stated as a SAMA requirement.