Cyber Risk Register: SAMA CSF and NCA ECC Alignment

A cyber risk register is the single most important artefact in a Saudi cyber risk management programme. SAMA inspectors and NCA assessors both ask to see it on day one, audit committees expect to be briefed against it quarterly, and the entire risk treatment plan flows from the structure that lives inside it. Yet many Saudi organisations run their cyber risk register on a spreadsheet that was originally built for one framework, has accumulated columns over time, and can no longer answer the questions either regulator now asks.

This post is a practitioner guide to building a cyber risk register that is aligned to SAMA CSF, NCA ECC and the international standards (ISO/IEC 27005:2022, NIST SP 800-30) the Kingdom's regulators implicitly recognise. It covers taxonomy, scoring, control linkage, key risk indicators and the evidence model that survives inspection.

What a cyber risk register actually is

The cyber risk register is the canonical record of every information security risk the organisation has identified, the assessed likelihood and impact, the controls in place, the residual rating and the treatment plan. It is not a list of incidents (that is the incident register). It is not a list of vulnerabilities (that is the vulnerability backlog). It is a forward-looking statement of what could go wrong, what is being done about it, and how the organisation knows whether the residual exposure is within appetite.

A credible Saudi cyber risk register has six structural elements:

1. Risk taxonomy — the categorisation under which every risk is classified.
2. Risk identification record — the standardised record for each risk.
3. Likelihood and impact scoring — defined criteria the assessors apply consistently.
4. Control linkage — every risk linked to the controls that mitigate it.
5. Treatment plan — actions, owners, deadlines and current status.
6. Key risk indicators (KRIs) — measurable signals that the residual risk is moving.

Each element matters; missing any one of them is a finding waiting to happen.

Step 1 — Build the risk taxonomy

The risk taxonomy is the categorisation tree under which risks are organised. A practical Saudi cyber risk taxonomy maps to the way SAMA CSF, NCA ECC and ISO 27001 organise their domains, so that the same risk can be reported in any of those formats without re-categorising.

A typical Saudi cyber risk taxonomy has three layers:

• Layer 1 — risk domain. Governance, identity and access, network security, application security, data security, third-party, incident, business continuity, physical, awareness.
• Layer 2 — risk family. Within each domain, the family of related risks. For example under identity and access: authentication, authorisation, privileged access, session management, federation.
• Layer 3 — risk scenario. The named scenario the assessor is rating. For example under privileged access: "abuse of privileged credentials by an insider", "compromise of privileged credentials by an external attacker", "lack of segregation of duties on privileged actions".

The taxonomy should be agreed once and frozen for the assessment period. Reorganising taxonomy mid-cycle invalidates trend analysis.

Step 2 — Standardise the risk record

Every risk on the register should carry the same fields. A practical Saudi cyber risk record includes:

• Risk ID and short name.
• Domain, family, scenario.
• Description of the threat, the vulnerability and the asset at risk.
• Risk owner (named individual, not a function).
• Inherent likelihood, inherent impact, inherent score.
• Linked controls and assessed control effectiveness.
• Residual likelihood, residual impact, residual score.
• Risk appetite category and acceptance status.
• Treatment plan reference and current status.
• Last review date and next review date.
• Linked framework references (SAMA CSF sub-control IDs, NCA ECC sub-control IDs, ISO 27001 Annex A references).
• Linked incidents, findings and KRIs.
• Audit trail of every change.

The single biggest cause of audit findings against cyber risk registers is partial records — risks captured in 2023, owners updated in 2024, scoring left unchanged since 2022, no link to controls. The discipline of a consistent record is itself half the value of a real risk register.

Step 3 — Scoring methodology

The scoring methodology is where Saudi cyber risk registers most commonly diverge from international good practice. ISO 27005:2022 and NIST SP 800-30 both recommend defined criteria for likelihood and impact, applied consistently across all risks, with the criteria documented and approved.

A practical Saudi scoring model has four dimensions:

Likelihood scale. Typically a five-point scale from rare (event expected less than once in five years) to almost certain (event expected multiple times per year). Each level should have a written definition the assessor can apply consistently.

Impact scale. Should be multi-dimensional — financial, operational, regulatory, reputational, customer impact — with a defined threshold for each level on each dimension. The overall impact is the highest of the dimensional scores.

Inherent score. The combination of likelihood and impact assuming no controls were in place. This is the worst-case rating.

Control effectiveness. A defined scale for assessing how well the linked controls reduce the inherent risk. Typically four levels: not implemented, partially effective, mostly effective, fully effective.

Residual score. Derived from inherent score adjusted by control effectiveness — not re-entered as a fresh number by the assessor. This is the most important methodology rule. Allowing assessors to re-enter the residual score breaks the link between control effectiveness and risk reduction and produces a register the auditor cannot defend.

The risk acceptance threshold should be defined per risk category and approved by the appropriate governance body (typically the risk committee or board risk subcommittee). Risks scoring above the threshold require treatment; risks scoring at or below the threshold can be accepted with documented rationale.

Step 4 — Link risks to controls and frameworks

The single most under-used feature of a real risk register is the linkage between risks, controls and framework references. When a risk is linked to the controls that mitigate it and those controls are linked to SAMA CSF, NCA ECC, ISO 27001 and NIST CSF references, three things become possible:

• A regulator asking how the organisation manages cyber risk under, say, SAMA CSF 3.3 can be answered by listing the risks tied to that sub-control and the residual scores.
• An audit finding against a control automatically surfaces the risks that depend on it, so the impact of the finding is immediately clear.
• A change to a control's effectiveness rating automatically updates the residual score of every risk that depends on it.

This is the model SAMA inspectors and NCA assessors are increasingly looking for, and the one almost no spreadsheet-based register can deliver.

Step 5 — Treatment plan

For every risk above the acceptance threshold, the treatment plan should specify the chosen treatment option (mitigate, transfer, avoid, accept), the actions, the owners, the deadlines and the expected effect on the residual score after completion. The treatment plan should be reviewed at the same cadence as the risk, with delayed actions escalated through the governance structure.

Treatment effectiveness should be tracked. A treatment plan that has been "in progress" for eighteen months with no observable change in the residual score is itself a finding.

Step 6 — Key risk indicators

KRIs are measurable signals that a risk is materialising or that controls are weakening. A modern Saudi cyber risk register pairs each significant risk with two or three KRIs and traffic-light thresholds.

Examples of practical cyber KRIs:

• For privileged access risk: number of privileged accounts, percentage with MFA enforced, number of dormant privileged accounts, number of privileged actions outside business hours.
• For patch management risk: percentage of critical patches applied within SLA, average age of unpatched critical vulnerabilities, number of unpatched internet-facing systems.
• For third-party risk: percentage of material vendors with current cyber assessments, number of vendors with critical findings open beyond SLA, number of new vendors added without due diligence.
• For phishing risk: phishing simulation click rate, time to report a phishing email, percentage of employees who completed required training.

KRIs should be reported on a defined cadence and trended over time. Falling green into amber is a signal; jumping straight from green to red is a failure of measurement.

Inspector-ready evidence

A SAMA inspector or an NCA assessor reviewing the cyber risk register will typically ask the same five questions. A well-structured register should be able to answer all five immediately:

1. How was this risk identified? Show the documented risk identification activity (workshop output, threat modelling result, incident review).
2. Who owns this risk? Show the named owner and the date they accepted ownership.
3. What controls reduce this risk? Show the linked controls, their effectiveness rating and the most recent control test result.
4. What is the trend? Show the residual score over the last four cycles and explain any change.
5. What is being done about the risks above appetite? Show the treatment plan, the actions, the owners and the current status.

If any of these answers requires a multi-day evidence chase, the register is not inspector-ready.

How GRC Vantage handles cyber risk registers in the Kingdom

GRC Vantage's risk module ships with a configurable risk methodology aligned to ISO 27005 and NIST SP 800-30, inherent and residual scoring with control-effectiveness derivation (not free-text), and risk-control-framework linkage on the same control library used by the compliance and audit modules. SAMA CSF, NCA ECC and ISO 27001 ship pre-mapped on day one, KRI dashboards are part of the standard product, and every risk record is fully audit-trailed. The platform can be deployed inside Saudi Arabia for data residency, fully on-premise or air-gapped, and is supported from our Riyadh and Dammam offices.

For the wider context this register has to satisfy, read our SAMA frameworks guide and NCA frameworks guide. When you are ready to see a working cyber risk register tied to SAMA and NCA control libraries, book a demo.