Many Saudi financial institutions approach their first ISO 27001 certification with a risk register copied from a template. The result is a generic list of threats—"malware," "insider threat," "data breach"—scored in isolation, with treatment plans that read like wish lists. When the surveillance audit arrives eighteen months later, the register sits unchanged. When the CISO requests budget for a new control, the executive committee asks why it was not in the original risk assessment.
The disconnect stems from method. A risk register is not a document to complete; it is the output of a structured conversation about what you protect, what threatens it, and which controls close the gap. We build a cyber risk register through three facilitated workshops over four weeks: asset inventory and valuation, threat-scenario modeling, and control-gap analysis. Each workshop involves specific client participants, follows a defined agenda, and produces an output that feeds the next session. At the end, you hold a populated risk register, treatment plans with owners and dates, and the evidence trail that satisfies both ISO 27001 Annex A justification requirements and your enterprise risk committee's expectations.
This article details how we run the ISO 27001 risk register workshop sequence, what each session delivers, and how the final register integrates with your broader risk framework.
Why the Workshop Sequence Matters for ISO 27001 and SAMA Compliance
ISO 27001 clause 6.1.2 requires organizations to assess information security risks: identify risks associated with the loss of confidentiality, integrity, and availability of information, assess the likelihood and consequence, and determine whether the risks require treatment. Annex A then lists 93 controls across four domains, but the standard does not prescribe *which* controls you must implement. Your Statement of Applicability must justify each control's inclusion or exclusion based on your risk assessment outcomes.
The Saudi Central Bank (SAMA) Cyber Security Framework and the National Cybersecurity Authority (NCA) Essential Cybersecurity Controls both expect risk-based control selection. SAMA CSF Domain 1 (Cybersecurity Governance) requires a documented risk management process, and NCA ECC Control 1-1-1 mandates a cybersecurity risk register updated at least annually. Both regulators review the register during on-site inspections, looking for evidence that treatment decisions reflect your institution's actual risk exposure, not a vendor checklist.
A workshop-driven approach produces that evidence. When the register shows that you valued customer transaction data as a critical asset, identified account-takeover as a high-likelihood threat based on your digital-banking footprint, assessed existing multi-factor authentication coverage, and decided to extend MFA to all customer-facing applications by Q3, the auditor sees a coherent chain of reasoning. When the executive committee reviews the same register, they understand why you need budget for the MFA expansion and can compare the residual risk against appetite.
Phase One: Align Method and Scales with Enterprise Risk
Before the first workshop, we align the cyber risk methodology with your enterprise risk management framework. Most Saudi financial institutions already operate an ERM function under SAMA's Corporate Governance Regulations, with established likelihood and impact scales, a risk appetite statement, and a quarterly reporting cadence to the board risk committee.
We establish or mature your cyber risk management: methodology, appetite, assessment, treatment and reporting—integrated with your enterprise risk framework. During this alignment phase, we review your existing ERM charter, risk taxonomy, and rating scales. We then adapt the cyber risk assessment to use the same five-by-five or four-by-four likelihood and impact matrix, the same risk-rating thresholds (e.g., "high" means inherent score above 15), and the same treatment principles (e.g., all high risks require a formal treatment plan with executive owner).
We also draft a cyber risk appetite statement that translates your institution's overall risk appetite into specific boundaries for information security. For example: "We accept up to two moderate-rated risks in customer data protection, provided residual risk after treatment remains below appetite and is reviewed quarterly. We do not accept any high-rated risks in payment processing or core banking systems." This statement, reviewed with your chief risk officer and chief information security officer, becomes the decision rule for treatment prioritization in later workshops.
The output of this phase is a cyber risk management framework document—typically eight to twelve pages—that defines roles (risk owner, control owner, risk manager), the assessment process, rating criteria, treatment options (avoid, mitigate, transfer, accept), escalation thresholds, and reporting frequency. This document is presented to your enterprise risk committee for endorsement before the workshops begin, ensuring that the resulting register will slot directly into your existing risk governance without translation.
Phase Two: Identify Critical Assets, Threats, and Scenarios
The first workshop runs for half a day and gathers asset owners, application managers, infrastructure leads, and data custodians. The objective is to build an asset inventory and assign business-impact values to each asset based on confidentiality, integrity, and availability.
Workshop One Agenda: Asset Inventory and Valuation
We open with a structured brainstorming session, grouping assets into categories: data (customer records, transaction logs, employee data), applications (core banking, mobile app, treasury system), infrastructure (data center, cloud tenants, network segments), and supporting assets (identity directories, cryptographic keys). For each asset, we ask three questions:
- What business process depends on this asset?
- What happens if this asset is disclosed, altered, or unavailable for four hours? For one day? For one week?
- Who owns the business decision about acceptable risk to this asset?
Participants score each asset's confidentiality, integrity, and availability impact using your enterprise risk impact scale. A core banking database might score "critical" for integrity (unauthorized changes halt operations) and "high" for availability (downtime beyond four hours breaches SAMA service-level requirements), but "moderate" for confidentiality (data is encrypted at rest and access-logged). The mobile banking application might score "critical" for availability (customer-facing, reputational impact) and "high" for confidentiality (personal data, PDPL obligations).
By the end of the session, you hold a prioritized asset inventory—typically twenty to forty assets for a mid-sized institution—with impact ratings and named owners. This inventory feeds directly into the second workshop.
Workshop Two Agenda: Threat-Scenario Modeling
The second workshop, also half a day, brings together the same asset owners plus representatives from security operations, fraud prevention, and internal audit. We take the top fifteen assets by impact score and model realistic threat scenarios for each.
A threat scenario pairs a threat actor with a vulnerability and an attack path. For the core banking database, scenarios might include: "External attacker exploits unpatched SQL injection in legacy reporting module to exfiltrate transaction history" or "Privileged insider with database administrator access sells customer account details to fraudsters." For the mobile banking application: "Credential-stuffing attack using breached passwords from third-party site leads to account takeover" or "Man-in-the-middle attack on public Wi-Fi intercepts session tokens."
We score each scenario's likelihood using your enterprise scale, informed by threat intelligence (Are SQL injection attacks common in our region? Have we seen credential-stuffing attempts in our logs?), control effectiveness (Do we patch within 30 days? Do we enforce MFA?), and environmental factors (Do we operate branches in high-threat geographies?). We then combine likelihood with the asset's impact score to produce an inherent risk rating.
The output is a populated risk register with thirty to fifty risk scenarios, each linked to an asset, scored for inherent risk, and annotated with the reasoning behind the likelihood assessment. This register, typically a structured spreadsheet or risk-management-tool export, becomes the foundation for treatment planning.
Phase Three: Assess Likelihood and Impact with Risk Owners, Then Treat
The third workshop runs for a full day and involves risk owners (the business managers accountable for each asset), control owners (the technical leads responsible for implementing safeguards), the CISO, and the chief risk officer. The agenda has two parts: control-gap analysis and treatment-plan development.
Control-Gap Analysis
For each risk scenario in the register, we identify existing controls and assess their effectiveness. We map controls to ISO 27001 Annex A domains and, where applicable, to SAMA CSF and NCA ECC requirements. For the SQL injection risk, existing controls might include: web application firewall (Annex A 8.20, NCA ECC 6-2-1), annual penetration testing (Annex A 8.8), and secure coding training (Annex A 6.3). We then evaluate whether these controls are designed correctly, operating consistently, and sufficient to reduce likelihood below appetite.
If the current controls are insufficient—penetration testing is annual but the application changes monthly, or the WAF rule set has not been updated in two years—we document the gap. This gap analysis directly informs your ISO 27001 Statement of Applicability: if you mark Annex A 8.25 (secure development lifecycle) as "not applicable," the register must show that your applications are low-risk or that compensating controls are adequate.
Treatment-Plan Development
For each risk rated above appetite, we develop a treatment plan: specific actions, responsible owner, target completion date, and expected residual risk after treatment. Treatment options follow your enterprise framework: mitigate (implement or improve a control), transfer (cyber insurance, outsource to a managed service), avoid (decommission the asset or stop the activity), or accept (document executive approval for residual risk within appetite).
A treatment plan for the SQL injection risk might read: "Implement static application security testing in CI/CD pipeline for legacy reporting module (Owner: Application Development Manager, Due: Q2 2025, Cost: SAR 180,000, Residual Risk: Moderate)." A plan for the credential-stuffing risk might read: "Extend MFA to all customer-facing applications and enforce on 100% of logins (Owner: Identity and Access Manager, Due: Q3 2025, Cost: SAR 320,000, Residual Risk: Low)."
By the end of the workshop, every high and critical risk has an agreed treatment plan with a named owner and a date. Moderate risks are either accepted with documented rationale or added to a watch list for the next assessment cycle. The result is a set of risk treatment plans that your project management office can track and your internal audit team can test.
Phase Four: Reporting and Ongoing Governance
The final step is to establish the reporting cadence. We prepare a quarterly risk report template that summarizes open risks by rating, tracks treatment-plan progress, highlights new or escalated risks, and compares residual risk to appetite. This report is designed to fit your existing board risk committee pack, typically as a two-page executive summary with a detailed appendix.
We also define the triggers for updating the register: annually as part of ISO 27001 surveillance audit preparation, whenever a new critical asset is introduced (a new digital channel, a merger, a cloud migration), after a significant incident, or when a new threat emerges (a zero-day vulnerability in your core platform, a regulatory alert from SAMA or NCA).
The register is not static. It is a living tool that your risk and security teams update quarterly, using the same workshop method to assess new scenarios and re-score existing risks as controls mature.
What You Hold at the End of Four Weeks
At the conclusion of the workshop sequence, you receive:
- Cyber risk management framework: Methodology, roles, rating scales, treatment principles, and escalation thresholds, aligned with your enterprise risk management and endorsed by your risk committee.
- Risk appetite statement: Specific boundaries for information security risk, expressed in the same terms your board uses for credit, market, and operational risk.
- Populated risk register: Thirty to fifty risk scenarios, each linked to a valued asset, scored for inherent and residual risk, and mapped to ISO 27001 Annex A controls, SAMA CSF domains, and NCA ECC requirements.
- Risk treatment plans: Detailed action plans for every risk above appetite, with named owners, target dates, estimated costs, and expected residual risk ratings.
- Quarterly risk report template: A board-ready summary that tracks risk profile, treatment progress, and appetite compliance, ready to integrate into your existing risk committee reporting cycle.
These deliverables satisfy ISO 27001 clause 6.1.2 and 6.1.3 (risk assessment and treatment), support your Statement of Applicability justification, meet SAMA CSF and NCA ECC documentation requirements, and give your executive committee the information they need to make informed budget and priority decisions.
How This Supports Your Broader Risk and Compliance Program
The workshop-driven risk register integrates with other elements of your cybersecurity program. The asset inventory feeds your third-party risk assessments: if customer transaction data is a critical asset, any vendor processing that data receives enhanced due diligence. The threat scenarios inform your security monitoring use cases: if credential stuffing is a high-likelihood threat, your security operations center prioritizes detection rules for anomalous login patterns. The control-gap analysis directs your compliance roadmap: if Annex A 8.25 is marked "applicable" but you lack a secure development lifecycle, that gap becomes a finding in your next internal audit and a project in your remediation plan.
When you run a gap assessment against SAMA CSF, NCA ECC, or PDPL, the risk register provides the rationale for prioritization. A control gap that exposes a critical asset to a high-likelihood threat moves to the top of the remediation backlog. A gap that affects only a low-impact asset or mitigates an unlikely scenario can be scheduled for a later phase, with documented justification.
Moving Forward: Cyber Risk Management as a Service
The four-week workshop sequence is part of our Cyber Risk Management service. We establish or mature your cyber risk management: methodology, appetite, assessment, treatment and reporting—integrated with your enterprise risk framework. The service runs over six to eight weeks, allowing time for stakeholder interviews, enterprise risk alignment, the three workshops, and final review with your risk committee.
If your institution is preparing for ISO 27001 certification, planning your annual risk assessment update, or responding to a SAMA or NCA examination finding on risk management maturity, a structured workshop approach ensures the resulting register is defensible, actionable, and aligned with the way your board already thinks about risk.
We work with risk managers, CISOs, and internal audit teams at Saudi financial institutions to build risk registers that auditors accept and executives actually use for budget decisions. If you are ready to move beyond spreadsheet exercises and produce a risk register grounded in your real assets and threats, we can help.
