SAMA IT Governance Framework: The Definitive Guide (And Why the "IT Strategy Committee" Does Not Exist)

If your board pack says SAMA requires an "IT Strategy Committee", you have a problem. SAMA requires no such body. The committee SAMA actually mandates is the IT Steering Committee (ITSC) — and a bank that renames its committee to match the fabrication does not become more SAMA-aligned. It becomes less.

That single error is a good illustration of how compliance fiction works. The conceptual spine sounds right — of course SAMA wants a board-mandated IT committee — and the fabrication hides in the one detail a compliance officer copy-pastes into a board pack: the name. Alongside it circulated an invented "39 board-level controls", a "SAR 1 million" approval threshold, "four IT audit reports per year" and "25% of controls reviewed annually". None of those exist.

Below is the SAMA Information Technology Governance Framework read straight from SAMA's own rulebook, with a section number against every claim. Where SAMA states no number, this guide says so rather than supplying one.

The 60-second answer

• The instrument is the Information Technology Governance Framework, issued under Circular No. 43028139, dated 29/3/1443H — 4/11/2021G. Status: In-Force. Scope of application: Banking Sector and Credit Bureaus.
• The real committee is the IT Steering Committee (ITSC), mandated by the board (§3.1.1.1). There is no "IT Strategy Committee".
• Structure: 4 domains, 35 subdomains. Each subdomain states a Principle and numbered Control Requirements.
• The framework is principle-based / risk-based (§2.2), with a formal waiver process from SAMA when a control cannot be implemented.
• Maturity model: 6 levels (0–5) (§2.4). Note the honest gap below — the ITGF text does not state a mandated minimum level the way the CSF does.
• It is designed to be implemented alongside the Cyber Security Framework and the Business Continuity Management Framework (§1.3) — three instruments, not one.

What the ITGF actually is

SAMA established the framework "to enable organizations regulated by SAMA ("the Member Organizations") to effectively identify and address risks related to IT" (§1.1), with three stated objectives: a common approach to IT risk, "an appropriate maturity level of IT controls", and IT risks properly managed throughout the organization.

It is explicitly one leg of a three-legged stool. §1.3 is direct about it:

"The framework should be implemented in conjunction with SAMA's Cyber Security and Business Continuity framework respectively. For specific Cyber Security and Business Continuity related requirements please refer to SAMA's Cyber Security Framework and Business Continuity Management Framework."

So the ITGF governs how IT is run and directed. Cyber controls live in the Cyber Security Framework (Circular 381000091275). Continuity lives in the Business Continuity Management Framework (Circular 381000058504). Trying to satisfy all three from one document is a category error.

The real structure: 4 domains, 35 subdomains

§2.1 states the framework "is structured around four main domains". Here they are, with their actual subdomains:

3.1 — Information Technology Governance and Leadership (9 subdomains) 3.1.1 Information Technology Governance · 3.1.2 Information Technology Strategy · 3.1.3 Manage Enterprise Architecture · 3.1.4 Information Technology Policy and Procedures · 3.1.5 Roles and Responsibilities · 3.1.6 Regulatory Compliance · 3.1.7 Internal IT Audit · 3.1.8 Staff Competence and Training · 3.1.9 Performance Management

3.2 — IT Risk Management (4 subdomains) 3.2.1 Managing IT Risks · 3.2.2 Risk Identification and Analysis · 3.2.3 Risk Treatment · 3.2.4 Risk Reporting/Monitoring, and Profiling

3.3 — Operations Management (11 subdomains) 3.3.1 Manage Assets · 3.3.2 Interdependencies · 3.3.3 Manage Service Level Agreements · 3.3.4 IT Availability and Capacity Management · 3.3.5 Manage Data Center · 3.3.6 Network Architecture and Monitoring · 3.3.7 Batch Processing · 3.3.8 IT Incident Management · 3.3.9 Problem Management · 3.3.10 Data Backup and Recoverability · 3.3.11 Virtualization

3.4 — System Change Management (11 subdomains) 3.4.1 System Change Governance · 3.4.2 Change Requirement Definition and Approval · 3.4.3 System Acquisition · 3.4.4 System Development · 3.4.5 Testing · 3.4.6 Change Security Requirements · 3.4.7 Change Release Management · 3.4.8 System Configuration Management · 3.4.9 Patch Management · 3.4.10 IT Project Management · 3.4.11 Quality Assurance

Note that "Information Technology Strategy" (§3.1.2) is a subdomain — a topic, not a committee. That is almost certainly the source of the "IT Strategy Committee" fabrication: someone read a subdomain heading and promoted it to an organ of governance.

The real governance structure

This is the part worth getting exactly right, because it is the part that was invented. SAMA's chain of command runs Board → ITSC → CIO.

The board

The domain preamble to §3.1 states it plainly: "Member Organizations board is ultimately responsible for setting the Information Technology (IT) Governance and ensuring that IT risks are effectively managed within the Member organization. The board of the Member Organization can delegate its IT Governance responsibilities to senior management or IT steering committee (ITSC). The ITSC could be responsible for defining the IT governance and setting the Member Organization's IT strategy."

Per §3.1.5.1, the board is accountable for:

• (a) ultimate responsibility for the establishment of IT governance practice;
• (b) ensuring a robust IT risk management framework is established and maintained;
• (c) ensuring sufficient IT budget is allocated;
• (d) approving the IT steering committee (ITSC) charter; and
• (e) endorsing — after they have been approved by the ITSC — the governance and management practices roles and responsibilities, the IT strategy, and the IT policy.

Read (e) closely, because it inverts what most people assume: the ITSC approves the IT strategy, and the board endorses it. Not the other way round.

The IT Steering Committee (ITSC)

§3.1.1 — the framework's first control requirement — is unambiguous: "Member organizations should establish ITSC and be mandated by the board."

• Chair: "The ITSC should be headed by senior manager responsible for Member Organizations operations" (§3.1.1.2).
• Membership (§3.1.1.3): senior managers from all relevant departments (e.g. CRO, CISO, compliance officer, heads of relevant business departments); the Chief Information Officer (CIO); and Internal Audit may attend as an "observer".
• Charter (§3.1.1.4): committee objectives; roles and responsibilities; minimum number of meeting participants; meeting frequency (minimum on quarterly basis); and documentation and retention of meeting minutes and decisions.
• Responsibilities (§3.1.5.2): monitoring, reviewing and communicating the organization's IT risks periodically; and approving, communicating, supporting and monitoring the IT strategy, IT policies, IT risk management processes, and the KPIs and KRIs for IT.

The CIO

§3.1.1.5 requires "a full-time senior manager for the IT function, referred to as CIO", appointed at senior management level.

And then §3.1.1.6, which is the real, hard, citable specific that the fabricated "SAR 1 million threshold" displaced. Member Organizations should:

"(a) ensure the CIO is a Saudi national; (b) ensure the CIO is sufficiently qualified; and (c) obtain a written no objection letter from SAMA prior to assigning the CIO."

A nationality requirement and a SAMA no-objection letter before you appoint your CIO. That is a genuine, board-relevant, hire-blocking obligation — and it was absent from the fabricated version, which instead invented a spending threshold SAMA never wrote.

The CIO is accountable (§3.1.5.3) for developing, implementing and maintaining the IT strategy, IT policy and IT budget, and for ensuring detailed IT standards and procedures are established, approved and implemented.

Other real committees

The ITSC is not the only body SAMA names, and the others are worth knowing because they are also real:

• an audit committee, which approves the IT audit plan (§3.1.7.4) and receives IT audit reports (§3.1.7.8);
• a risk committee, which receives IT risk reporting (§3.2.4); and
• an IT project steering committee, which "should be established having representation from relevant business and technical teams" to oversee IT projects (§3.4.10.6).

None of them is called an IT Strategy Committee.

The maturity model

§2.4 states: "The information technology governance maturity model distinguishes 6 maturity levels (0, 1, 2, 3, 4 and 5) … In order to achieve levels 3, 4 or 5, Member Organizations should first meet all criteria of the preceding maturity levels."

Level 3 requires IT controls defined, approved and implemented, with compliance monitored against an IT documentation pyramid — policy ("why"), standards ("what"), procedures ("how") — and KPIs monitored (§2.4.1). The IT policy "should be endorsed and mandated by the board". Level 4 adds periodic measurement of control effectiveness using KRIs (§2.4.2). Level 5 adds continuous improvement, integration with enterprise risk management, real-time monitoring, and performance "evaluated using peer and sector data" (§2.4.3).

Implementation "will be subject to a periodic self-assessment … based on a questionnaire", and the self-assessments "will be reviewed and audited by Saudi Central Bank to determine the level of compliance with the framework and the IT maturity level" (§2.3).

An honest gap: the ITGF text sets out the six levels and says the objective is "an appropriate maturity level of IT controls" (§1.1). Unlike the Cyber Security Framework — which does state a minimum required maturity level — the IT Governance Framework text does not state a mandated minimum level. If you have been told "SAMA requires ITGF maturity level 3", that specific claim is not supported by the framework text, and you should confirm your target with your supervisor rather than with a blog. This guide will not invent one for you.

What the other three domains actually require

Most summaries stop at governance. The other three domains carry the bulk of the framework's 35 subdomains, and they contain the operational specifics an assessor will test.

3.2 — IT Risk Management

The IT risk management process must be "aligned with the Member Organization's enterprise risk management process" (§3.2.1.3) — IT risk is not allowed to live in its own silo. It must cover business processes and data, business applications, infrastructure components and third-party relationships and associated risks (§3.2.1.5), plus the people dimension including contractors and third parties (§3.2.1.6). All mission-critical and critical information assets should be assessed at least once a year (§3.2.1). The IT risk profile is "formulated and presented to the senior management, IT Steering Committee and board of directors" (§3.2.4).

3.3 — Operations Management

This is where infrastructure decisions meet the framework:

• §3.3.5 Manage Data Center. Physical and environmental controls must be defined, approved, implemented, monitored and periodically evaluated — including access "strictly controlled and provided on need to know basis", visitor entry logged and escorted, smoke detectors, fire alarms, fire extinguishers, humidity control, temperature monitoring and CCTV (§3.3.5.3). Critically, §3.3.5.4: "the outsourcing of data center should comply with the requirements published in SAMA circulars on the Rules of The Outsourcing and Cybersecurity Framework" — i.e. the Rules on Outsourcing (Circular 41027017, dated 18/4/1441H — 15/12/2019G) and the CSF. A documented business case for outsourcing the data centre is required, along with the nature and type of provider access (§3.3.5.5).
• §3.3.4 IT Availability and Capacity Management. An availability and capacity plan covering existing capacity, alignment with current and future business needs, high availability requirements including disruption and slowness for customer channels, and "identification of dependencies over service providers as part of capacity planning to address BCM requirements".
• §3.3.6 Network Architecture and Monitoring. Log retention: 12 months minimum. One of the framework's few hard numbers.
• §3.3.8 IT Incident Management. The process exists in part "to report relevant incidents to SAMA, according to a defined communication protocol". It must cover a designated incident team, prioritization and classification, timely handling, protection of evidence and logs, root-cause analysis and lessons learned (§3.3.8.3).
• §3.3.10 Data Backup and Recoverability. The backup management policy must consider "alignment with SAMA Business Continuity Management Framework" (§3.3.10.2a), and backup/restoration requirements must be defined in line with "the agreed RPO" (§3.3.10.5b). Note the word agreed — the ITGF, like the BCM Framework, treats the RPO as a figure you derive and agree. Two separate SAMA frameworks decline to state an RPO value. That is not an oversight; it is the design.
• §3.3.1 Manage Assets. Asset register maintained and updated yearly, or whenever an asset is introduced or removed.

3.4 — System Change Management

Eleven subdomains from governance of change through acquisition, development, testing, release, configuration, patch management (§3.4.9 — patches assessed for impact "including cyber security" before production, tested in a separate environment first, deployed via formal change management, with the deployment window communicated in advance and preferably in non-peak, non-freeze periods), IT project management (§3.4.10 — including the IT project steering committee at §3.4.10.6) and quality assurance.

3.1.6 — Regulatory Compliance

Worth singling out: you must run a process to ensure compliance with IT-related regulatory requirements, performed "periodically or when new regulatory requirements become effective", and maintain an up-to-date log of all relevant legal, regulatory and contractual requirements; their impact and required actions (§3.1.6.1). That register is the natural home for the circular numbers in this article — and the natural place where a fabricated "SAMA Cloud Rulebook" or an invented control count would have been caught.

Things that do not exist

❌ The "IT Strategy Committee"

There is no such committee in the framework. The body SAMA mandates is the IT Steering Committee (ITSC) (§3.1.1.1, and spelled out in full at §3.1.5.1(d): "approving the IT steering committee (ITSC) charter"). "Information Technology Strategy" is subdomain §3.1.2 — a subject area. Renaming a real ITSC to match an invented name would make your governance documentation diverge from the framework you are assessed against.

❌ "39 board-level controls"

SAMA publishes no headline control count for the ITGF. The framework is 4 domains and 35 subdomains; each subdomain carries a Principle plus its own numbered Control Requirements. There is no "39", and there is no separate class of "board-level" controls. (For scale: §3.1.1 alone contains 13 control requirements.)

❌ A "SAR 1 million" approval threshold

No monetary threshold of any kind appears in the IT Governance Framework. Not SAR 1 million, not any figure. §3.1.1.7 requires "formal practices for IT-related financial activities covering budget, cost, and prioritization of spending aligned with IT strategic objectives", and §3.1.1.8 requires the IT budget to be monitored, reviewed periodically and adjusted. You set the thresholds; SAMA does not.

❌ "Four IT audit reports per year" and "25% of controls audited annually"

Both invented, and both contradicted by the actual text. §3.1.7 explicitly delegates the frequency to you: "The Member Organizations should establish an audit cycle that determines the frequency of IT audits" (§3.1.7.2), and "The frequency of IT audit should be aligned with the criticality and risk of the IT system or process" (§3.1.7.5). The IT audit plan is approved by the audit committee (§3.1.7.4), and IT audit reports are "submitted to the audit committee on periodical basis" (§3.1.7.8c).

SAMA names no number here, deliberately — it is a risk-based framework (§2.2). A bank that reports "four audits per year" because a blog said so has substituted a cargo-cult metric for the risk-alignment SAMA actually asks for.

✅ The real numbers that do exist

The ITGF is sparing with figures, which is exactly why the few it states are worth knowing:

• ITSC meets at minimum quarterly (§3.1.1.4d).
• The CIO must be a Saudi national, and SAMA's written no-objection letter is required before assigning the CIO (§3.1.1.6).
• Log retention: 12 months minimum (§3.3.6).
• All mission-critical and critical information assets assessed at least once a year (§3.2.1).
• Asset register maintained and updated yearly, or whenever an asset is introduced or removed (§3.3.1).
• 6 maturity levels, 0–5 (§2.4).

That is close to the complete inventory of hard numbers in the framework. If someone quotes you a SAMA ITGF figure that is not on this list, ask them for the section number.

What SAMA does not tell you

• No mandated minimum maturity level is stated in the ITGF text (see above).
• No control count, and no n-n-n control ID format — controls are numbered within their subdomain (e.g. §3.1.1.6).
• No monetary approval thresholds.
• No IT audit frequency — explicitly your call, risk-aligned (§3.1.7.2, §3.1.7.5).
• No prescribed org chart beyond the ITSC, the CIO role, the enterprise application architect role (§3.1.1.11), and the requirement that IT roles be documented, approved and segregated to avoid conflict of interest (§3.1.1.12).

Where to start

1. Read the rulebook, not a summary — including this one. Every section number above is checkable.
2. Check your committee's name and charter. If your documentation says "IT Strategy Committee", fix it: SAMA's body is the ITSC, board-mandated, headed by the senior manager responsible for operations, quarterly minimum, with Internal Audit as observer.
3. Check the approval chain. ITSC approves the IT strategy and IT policy; the board endorses (§3.1.5.1e). If your papers show the reverse, they diverge from the framework.
4. Check your CIO paperwork (§3.1.1.6). Saudi national; SAMA written no-objection before assignment. This one blocks a hire, so it is worth confirming before you run a search.
5. Build the documentation pyramid — policy, standards, procedures — with KPIs, then KRIs (§2.4.1, §2.4.2).
6. Set your own audit cycle, risk-aligned, approved by the audit committee (§3.1.7).

Where a hosting provider fits — and where it does not

IT governance is not something a vendor can sell you. It is a board mandate, a committee with a charter, a CIO with a SAMA no-objection letter, a documentation pyramid and an audit cycle. No infrastructure purchase moves your ITGF maturity level. Any provider suggesting otherwise is doing the same thing the fabricated controls did: supplying comforting precision in place of accuracy.

Infrastructure does touch a handful of Operations Management subdomains directly — data centre management (§3.3.5), availability and capacity (§3.3.4), network architecture and monitoring including the 12-month log retention (§3.3.6), and backup and recoverability (§3.3.10). Those are places where where your workloads run genuinely matters.

Skyline Cloud runs an in-Kingdom region — Dammam, powered by Google Cloud, which keeps data in Saudi Arabia and gives a straight answer to the data-location question that every IT governance and third-party review raises. For a SAMA Member Organization it is an input to your §3.3 controls and nothing more than that — the governance work in §3.1 remains yours. For the far larger population of Saudi organizations that want ITGF-grade discipline without being SAMA-regulated, it is a well-run local region you can trial free for 14 days and assess on your own evidence.

Frequently asked questions

Does SAMA require an "IT Strategy Committee"?

No. That committee does not exist in SAMA's IT Governance Framework. SAMA mandates the IT Steering Committee (ITSC), established by the Member Organization and mandated by the board (§3.1.1.1), and names it in full at §3.1.5.1(d). "Information Technology Strategy" is a subdomain (§3.1.2), not a committee. If your governance documents name an IT Strategy Committee, they are describing a body SAMA never asked for.

How many controls are in the SAMA IT Governance Framework?

SAMA does not publish a total. The framework has 4 domains and 35 subdomains (§2.1), and each subdomain carries a Principle plus its own numbered Control Requirements. The widely-repeated "39 board-level controls" is a fabrication; there is no such count and no such category.

Who chairs the ITSC, and how often does it meet?

The ITSC "should be headed by senior manager responsible for Member Organizations operations" (§3.1.1.2), and its charter must set a meeting frequency of minimum quarterly (§3.1.1.4d). Membership includes the CRO, CISO, compliance officer, heads of relevant business departments and the CIO, with Internal Audit attending as an observer (§3.1.1.3).

Does SAMA require the CIO to be a Saudi national?

Yes. §3.1.1.6 requires Member Organizations to ensure the CIO is a Saudi national, ensure the CIO is sufficiently qualified, and obtain a written no-objection letter from SAMA prior to assigning the CIO. This is one of the few genuinely hard, personal-level obligations in the framework.

Is there a SAR 1 million IT spending approval threshold under SAMA?

No. No monetary threshold appears anywhere in the IT Governance Framework. SAMA requires formal IT financial practices covering budget, cost and prioritization of spending (§3.1.1.7) and periodic budget monitoring (§3.1.1.8) — the thresholds are yours to set.

How many IT audits per year does SAMA require?

SAMA states no number. §3.1.7.2 requires you to "establish an audit cycle that determines the frequency of IT audits", and §3.1.7.5 requires that frequency to be "aligned with the criticality and risk of the IT system or process". The audit plan is approved by your audit committee (§3.1.7.4). Claims of "four IT audit reports per year" or "25% of controls annually" are not in the framework.

What maturity level does SAMA require under the ITGF?

The framework defines six maturity levels, 0 to 5 (§2.4), and states the objective as "an appropriate maturity level of IT controls" (§1.1) — but the ITGF text does not state a mandated minimum level in the way the Cyber Security Framework does. SAMA determines your level via a self-assessment questionnaire that it reviews and audits (§2.3). Confirm your target with your supervisor, not with a secondary summary.

How do the ITGF, CSF and BCM frameworks relate?

They are three separate in-force circulars intended to be implemented together. §1.3 of the ITGF says it "should be implemented in conjunction with SAMA's Cyber Security and Business Continuity framework respectively". IT governance is Circular 43028139; the Cyber Security Framework is Circular 381000091275; the Business Continuity Management Framework is Circular 381000058504.

How to check any SAMA claim in five minutes

The fabrications described above survived in the Saudi market for a long time because almost nobody checks. Checking is genuinely fast. Here is the whole method.

1. Go to rulebook.sama.gov.sa. This is SAMA's official online rulebook and the live authority. Note that legacy sama.gov.sa/.../*.pdf links no longer serve PDFs — they return an HTML shell. If a source cites one of those PDF URLs as its evidence, that source did not open it either.
2. Find the instrument and read its header. Every rulebook page carries the circular number, the Hijri and Gregorian dates, and a status field. If the status is not In-Force, stop. If the document your source names does not exist in the rulebook at all — as with the mythical "SAMA Cloud Rulebook" — stop.
3. Navigate to the section number your source cites. A real citation resolves to a real page. An invented one does not resolve, or resolves to a section about something else entirely. This single step kills most fabrications outright.
4. Search the text for the number. If someone claims SAMA mandates X, the string X should appear in SAMA's text. Search for "tier". Search for "15 minutes". Search for "SAR". If the number is not there, SAMA did not say it. A regulator that wanted a figure would have written the figure.
5. Be equally rigorous about absence. The hardest discipline is writing "SAMA does not state a figure here" instead of supplying a plausible one. Every fabrication in the 2026 audit was, in its own way, someone declining to write that sentence.

Never accept a control ID, committee name, threshold or deadline from a consultancy blog, a vendor deck, a Big-4 marketing PDF or a LinkedIn post. Those are where the fabrications came from. Use them, at most, to locate a primary URL — then go read it.

Sources

Taken from SAMA's official online rulebook, which is the live authority. Legacy sama.gov.sa PDF links no longer serve the documents.

• Information Technology Governance Framework — Circular 43028139 (SAMA Rulebook)
• §2.1 Structure · §2.4 IT Governance Maturity Model
• §3.1.1 Information Technology Governance · §3.1.5 Roles and Responsibilities · §3.1.7 Internal IT Audit
• Cyber Security Framework — Circular 381000091275 · Business Continuity Management Framework — Circular 381000058504

This guide is a reading of the primary source, not regulatory advice. The binding text is the current version on SAMA's rulebook. If any statement here diverges from it, the rulebook wins — and we want to know.