Boards in the Kingdom often treat the appointment of a CISO as the moment cybersecurity governance begins. In practice, the appointment is the second step. The first is a SAMA ITGF CISO mandate definition: a written statement of what the cybersecurity function is responsible for, what authority it holds and to whom it answers.
We have seen the pattern in several Riyadh financial institutions. The CISO was hired first and the scope was left to be worked out later. What followed was a long period of overlapping authority with IT operations and enterprise risk, duplicate reporting to board committees and disputes over who owned security tooling. The people involved were capable. The mandate simply did not exist on paper.
SAMA's IT Governance Framework (ITGF) expects the cybersecurity function to be established with a documented mandate and clear governance. This article is written for board risk committee members and chief risk officers who are establishing or restructuring the function. It describes the common mistakes and what to do instead.
Mistake 1: Treating the hire as the mandate
A senior appointment feels like progress, so the job description becomes a substitute for a mandate. A job description describes a person's duties. A mandate describes the function's purpose, boundaries and authority, and it outlives any individual.
Do this instead: Write and approve the function's mandate before the search begins, and derive the role description from it. Candidates can then assess what they are accepting, and the board knows what it is asking for.
Mistake 2: Leaving scope undefined
Without a defined scope, every adjacent team assumes the grey areas belong to someone else, or to itself. Vulnerability management, security tooling administration, access governance and incident response are the usual points of friction with IT operations. Third-party cyber risk and operational risk assessments are the usual friction points with enterprise risk.
Do this instead: State what the function owns, what it advises on and what it only monitors. Name the boundary activities explicitly, and record which team performs and which team oversees each one.
Mistake 3: Granting responsibility without authority
A CISO who is accountable for outcomes but cannot set policy, require remediation or stop a risky deployment will spend most of their time negotiating. The other side of the same mistake is authority so broad that it overrides the legitimate responsibilities of IT and risk.
Do this instead: Define the authority in concrete terms: which policies the function approves, which exceptions it can refuse, and when it can require a change to be paused. Independence matters here. Regulators in the Kingdom expect the cybersecurity function to be independent from IT operations, which is why the question of whether the CISO should report to the CIO deserves a deliberate answer rather than a default one.
Mistake 4: Leaving escalation paths implicit
When a disagreement between security and IT has no defined route, it travels informally, usually to whichever executive each side trusts. Boards then receive inconsistent accounts of the same issue.
Do this instead: Document how disagreements and risk acceptances are escalated, to whom, and within what timeframe. Specify who can accept residual risk and who must be informed. Write down the route for incidents as well as for routine disputes.
Mistake 5: Letting reporting to committees duplicate
When the mandate does not say which committee receives which information, the CISO, the CIO and the head of risk may each present overlapping material to the audit, risk and technology committees. The messages drift apart, and members cannot tell which view is authoritative.
Do this instead: Define committee membership and terms of reference together with the mandate. Decide which committee receives cybersecurity reporting, what the CISO contributes, and how risk's independent view is presented alongside it. Agree a single set of metrics so the same figure is not reported three ways.
Mistake 6: Ignoring budget control
Budget disputes over tool ownership are one of the most visible symptoms of an unwritten mandate. If IT holds the budget for security tools, the function depends on another department's priorities. If security holds it without clear boundaries, duplicate purchases and unsupported platforms follow.
Do this instead: Decide who funds, who owns and who operates each category of security tooling, and record it. Give the function a defined budget line or a clear process for requesting funding, so that priorities are set by risk and not by negotiation.
The five mandate elements
The mistakes above map to five elements that a mandate should cover before the role is filled.
- Scope: the domains the function owns, advises on or monitors, with boundary activities named.
- Authority: the decisions the function can make, the policies it approves and the exceptions it can refuse.
- Escalation paths: how disagreements, risk acceptances and incidents move upward, and who decides.
- Committee membership: where the function sits in governance, which committees it serves and what it reports to each.
- Budget control: who funds, owns and operates security capabilities, and how the function's budget is set.
If a single page can answer all five questions without ambiguity, the role can be filled with far less risk of conflict.
A practical test for the board
Before approving an appointment, a risk committee can ask five questions. Can the proposed CISO and the CIO each describe, in the same words, where their responsibilities divide? Does the head of risk agree with the boundary on risk assessment? Is it clear which committee receives the cybersecurity report? Who decides when security and IT disagree? Who pays for the tools? If any answer differs depending on who is asked, the mandate is not yet ready.
If the CISO is already in post
Many institutions reading this have already appointed. The remedy is the same, applied retrospectively: review the current structure, compare it with regulatory expectations, and document the mandate with the people who are affected. It is easier to do before frustrations harden, but it remains worth doing afterwards. Involve IT and risk in the drafting, since a mandate imposed on them will be contested.
How we help
Our Cybersecurity Governance & Organization service designs or strengthens your cybersecurity governance: the function, its mandate, committees, roles and responsibilities, and how decisions reach the board. The work is a project of 4–6 weeks and follows four stages: review of current structure, mandates, committees and reporting; a gap comparison with regulatory expectations and good practice; design of the charter, committees, RACI and role descriptions; and embedding through approval support, the first committee cycle and handover.
The deliverables include a governance framework document, a cybersecurity function charter, committee charter and agenda templates, a RACI matrix, and an organization chart with role descriptions. The work also covers reporting lines and escalation paths and a segregation-of-duties review. It is aligned with SAMA ITGF, SAMA CSF and NCA ECC.
If your board is about to appoint a CISO, or is living with the consequences of having done so without a mandate, a short conversation about the five elements is a sound place to begin.
