Most Saudi institutions that run an ISO 27001 programme already hold a risk register. Fewer can say that their board has approved a risk appetite for cyber risk. The gap is one of language, and closing it is the core of ISO 27001 risk appetite board cyber risk management: the register speaks in assets, threats and scenarios, while the board speaks in revenue, regulatory exposure and customer trust.
This article sets out a three-step translation that a CISO or enterprise-risk manager can apply to the output of the ISO 27001:2022 risk assessment, and describes how we approach it.
Why the register does not reach the board
Clause 6.1.2 of ISO 27001 requires an organisation to define a risk assessment process, identify risks, analyse them and evaluate them against criteria. The output is usually a register of technical scenarios, each with a likelihood and impact rating. That is sound practice for the information security management system, but it is not an appetite statement.
Risk appetite is a statement by the board about how much risk it is willing to accept in pursuit of its objectives. Directors cannot approve "a high likelihood of credential compromise on a customer-facing system". They can approve "we will not accept a single event that costs more than a stated amount, or that triggers a regulatory penalty".
Step 1: Map information-asset risks to business-impact categories
Begin with the register as it stands. For each scenario, identify the information asset affected and ask what the business would actually lose if the scenario occurred. Group the answers into a small number of business-impact categories. Typical categories for a regulated Saudi institution include:
- Financial loss, including direct loss and revenue interruption
- Regulatory consequence, such as supervisory findings or penalties from the relevant regulator
- Customer impact, including attrition and loss of trust
- Operational disruption to critical services
- Reputational harm
Keep the list short. Three to five categories are easier for a board to hold in mind than twelve. Each register entry should map to at least one category, and the mapping should be agreed with the risk owner, not assigned by the security team alone. Scenarios that map to no category are a useful finding in themselves: they may not matter at board level, and can be managed within operational thresholds.
Step 2: Express thresholds in currency or percentage, not likelihood by impact
A five-by-five matrix is a useful working tool, but it hides the decision the board must take. A cell coloured amber does not tell a director how much money is at stake.
Restate each business-impact category as a threshold the board can read:
- Financial: a maximum tolerable loss per event and per year, expressed in riyals
- Regulatory: no tolerance for events that lead to a reportable breach or an enforcement action, or a defined tolerance for lesser findings
- Customer: a tolerable level of attrition or complaint volume attributable to a security event, expressed as a percentage of the relevant customer base
- Operational: a maximum tolerable outage for each critical service, expressed in hours
Use figures drawn from your own finance, customer and operations data rather than generic benchmarks. Where reliable data is thin, state the assumption openly and mark the threshold for review. A defensible estimate that the board understands is more useful than a precise-looking number nobody can trace.
Then test the thresholds against the register. Re-express each scenario's impact in the same units and see which ones sit above appetite. Those become the priority for treatment, and the residual risk after treatment can be compared directly with the threshold.
Step 3: Align with the enterprise-risk taxonomy
The board already reviews risk through an enterprise risk management framework. If cyber appetite arrives in a different structure, it will be treated as a separate technical topic rather than part of the institution's risk profile.
Obtain the enterprise risk taxonomy, rating scales and appetite statements already in use. Then:
- Use the same category names and the same rating scale wherever possible.
- Place cyber risk under the existing parent risk categories, such as operational, compliance or technology risk, rather than creating a parallel hierarchy.
- Match the appetite wording style, for example "low appetite" or "zero tolerance", and the review cycle of existing statements.
- Agree the escalation path from risk owner to risk committee to board with the enterprise risk function.
For institutions regulated by SAMA or subject to NCA requirements, this alignment also helps show that cyber risk is governed as part of the wider risk framework, which supervisors look for in the SAMA Cyber Security Framework and the NCA Essential Cybersecurity Controls.
What a good outcome looks like
When the translation is done well, you should see the following:
- A one-to-two page appetite statement the board can read and approve in a single sitting
- Thresholds in currency, percentages or hours, each tied to a named business-impact category
- A register in which every scenario can be compared with appetite and flagged when it exceeds it
- Terminology that the risk committee recognises from the rest of the enterprise risk framework
- A reporting rhythm in which breaches of appetite are escalated rather than discovered
Signs it is time
You are likely to need this work if any of the following is true:
- Your ISO 27001 register exists but has never been presented to the board in business terms
- Board papers on cyber risk are mainly lists of controls, incidents or maturity scores
- The risk committee asks how cyber risk compares with credit, operational or compliance risk and there is no common answer
- Cyber risk uses a different rating scale from the rest of the enterprise
- A supervisory review or audit has asked for a documented risk appetite
How we run it
Our Cyber Risk Management service establishes or matures your cyber risk management: methodology, appetite, assessment, treatment and reporting, integrated with your enterprise risk framework. The engagement runs as a project of 6–8 weeks and follows four stages.
- Align: method and scales agreed with enterprise risk.
- Identify: critical assets, threats and scenarios.
- Assess: likelihood and impact with risk owners.
- Treat: agreed plans, residual risk and reporting.
The deliverables are a cyber risk management framework, a risk appetite statement, a populated risk register, risk treatment plans and a quarterly risk report template. The work draws on SAMA CSF, NCA ECC and ISO 27001.
Closing
If your register is sound but your board cannot yet approve what it says, the missing piece is usually translation, not more assessment. Our Cyber Risk Management service is designed to produce a method your risk committee recognises and a register your team keeps alive. Contact CISO Consulting to discuss where your current register stands and what an appetite statement would need to contain.
