NCA NFCRM: The National Cybersecurity Risk Framework

The National Framework for Cybersecurity Risk Management (NFCRM) is the NCA's answer to a question Saudi entities have been answering differently for years: how exactly should cybersecurity risk be identified, scored, treated and escalated? Until now, an entity could satisfy the risk-management control in the Essential Cybersecurity Controls with almost any defensible methodology — ISO 27005, NIST SP 800-30, or a homegrown matrix inherited from the enterprise risk team. NFCRM removes that latitude.

The Framework does two things at once. At the entity level it prescribes a mandatory four-phase methodology and a fixed 5×5 risk assessment matrix with defined impact and likelihood scales. At the national level it turns the entity's risk register into a reporting obligation — asset inventories, high and critical risks, and treatment plans all flow to the NCA through Haseen.

That second half is the part most teams have not yet absorbed. Saudi organisations are used to reporting incidents to their regulator. NFCRM requires them to report risks — before anything has gone wrong.

What the NFCRM is

The NCA derives its authority from its statute, issued by Royal Order No. (6801) dated 11/02/1439H (31/10/2017), which makes it the competent national authority for cybersecurity in the Kingdom and the national reference in its affairs. That mandate expressly includes establishing and updating cybersecurity risk management frameworks and monitoring compliance with them. NFCRM is the instrument that discharges it.

The document is published as NFCRM – 1:2025, classified Public under TLP: Clear, and listed on the NCA's regulatory documents portal with an entry date of 22 July 2026. As with all NCA instruments, the Arabic version prevails in the event of any conflict between language versions.

The NCA states five objectives for the Framework:

• Identifying priority cybersecurity risks to treat.
• Enhancing national cybersecurity resilience through implementing the controls needed to reduce cybersecurity risks.
• Defining roles and responsibilities for cybersecurity risk management.
• Promoting a culture of cybersecurity risk management within entities.
• Managing cybersecurity risks effectively so entities can carry out their functions across their fields and sectors.

Read together, those objectives describe an ecosystem rather than a control: the NCA wants a unified, integrated, comprehensive and interoperable view of cyber risk in the Kingdom. Interoperability is the operative word — a national risk picture only assembles if every entity measures risk the same way. Hence the fixed matrix.

Who is in scope

The Framework applies to:

• Government agencies in the Kingdom — ministries, authorities, institutions and others — and their affiliated companies and entities inside and outside the Kingdom.
• All private sector entities that own, operate or host Critical National Infrastructure (CNI).

Both groups are referred to collectively as "the entity". The NCA additionally strongly encourages every other entity in the Kingdom to leverage the Framework and apply its practices — the familiar NCA pattern where today's encouragement becomes tomorrow's requirement, usually via a sector regulator.

Two scope details are worth flagging to legal and group functions early. First, the extraterritorial reach: a government entity's affiliated companies outside the Kingdom are in scope, which pulls overseas subsidiaries into a Saudi risk methodology and a Saudi reporting channel. Second, the CNI test is own, operate, or host — a private company that merely hosts critical national infrastructure for someone else is in scope on its own account.

The Framework defines CNI as the essential elements of infrastructure — assets, facilities, systems, networks, processes and the key personnel who operate and manage them — whose loss or compromise may cause a significant adverse impact on the availability, integration or delivery of basic services (including where compromise could lead to major property damage, loss of life or injury, taking national economic and social impact into account), or a significant impact on national security, national defence, or the Kingdom's economy or sovereign capabilities.

The national-level obligations: six duties that change your operating model

Section 5 of the Framework sets out what every in-scope entity owes the NCA. These are not internal good practice — they are submissions, and most of them are periodic.

Haseen is defined in the Framework as the comprehensive national cybersecurity ecosystem through which the NCA provides centralised and non-centralised cybersecurity services and products to beneficiaries at the national level — government entities, CNIs and private entities — in line with its mandate and national cyber regulatory requirements. In practice it is the pipe: assets in, risks in, treatment plans in, NCA observations out.

Section 5.5 is the structural change. An entity that scores a risk at 15 or above has to tell the regulator immediately — before an incident, before a breach, before anything has actually happened. Your risk register has become a regulatory filing.

The knock-on effects are operational, and they land on the risk team rather than the SOC:

• Scoring quality now carries regulatory consequence. An inflated score triggers an unnecessary notification to the NCA. A deflated one is a missed filing. Both are visible.
• "Immediately" needs an owner and a threshold decision. As with SAMA's significant-fraud reporting, no one should be debating whether a 15 is really a 15 while the clock is running. Pre-agree who signs off and how fast.
• Asset inventory becomes a submission, not a spreadsheet. Section 5.2 and 5.3 require classification and internet-facing asset identification that is reportable and kept current on change — an event-driven inventory, not an annual refresh.
• Social media accounts are named assets. They rarely appear in a CMDB. Under NFCRM they are explicitly in the asset population.

The entity-level methodology: four phases, twenty steps

Section 6 requires every in-scope entity to comply with the Cybersecurity Risk Management Methodology and the Cybersecurity Risk Assessment Matrix. The methodology is a continuous cycle of four phases — Identify, Assess, Treat, Follow up — using assets, vulnerabilities, threats and controls as its inputs.

Two obligations sit above the cycle: the entity must develop and operate a continuous programme for implementing the methodology with the necessary resources allocated (6.1), and must engage relevant stakeholders across the phases, explicitly including the cybersecurity steering committee and the IT department (6.2). That second one matters — it makes cyber risk management a governance activity with a named forum, not a spreadsheet owned by one analyst.

Identification phase (6.3–6.8)

Assets are identified and classified; expected risk scenarios are built from potential threats and identified vulnerabilities; the objective is to determine inherent risk.

• 6.3 Identify and classify the entity's assets.
• 6.4 Identify cybersecurity vulnerabilities.
• 6.5 Identify potential cybersecurity threats.
• 6.6 Develop expected cybersecurity risk scenarios from those threats and vulnerabilities.
• 6.7 Identify the controls currently implemented against each scenario.
• 6.8 Determine the entity's acceptable level of cybersecurity risk.

Step 6.8 deserves attention. The Framework defines the acceptable risk level as the level that can be accepted by an authorised official — so risk appetite is not a number the security team picks. It needs a named approver with the authority to accept risk on the entity's behalf, and that approval needs to be evidenced.

Assessment phase (6.9–6.10)

• 6.9 Analyse inherent risk for every expected scenario against the controls currently implemented, assessing likelihood and impact using the Framework's matrix.
• 6.10 Document the analysis and assessment results in the cybersecurity risk register.

Treatment phase (6.11–6.16)

The decision is one of four — accept, share, mitigate or avoid — followed by defined and implemented treatment plans.

• 6.11 Identify and develop treatment plans.
• 6.12 Assess expected residual risk after the plans are implemented, to confirm an acceptable level is reached.
• 6.13 Decide the treatment approach and the corresponding plans.
• 6.14 Develop plans based on priority.
• 6.15 Implement the plans.
• 6.16 Update the risk register with treatment plans and residual risks.

Note the sequence in 6.12: residual risk is assessed before the treatment decision is finalised, as a test that the plan actually lands the risk inside appetite. A treatment plan that leaves residual risk above the acceptable level is not a plan — it is a gap with a project code.

Follow-up phase (6.17–6.20)

• 6.17 Develop cybersecurity risk management reports.
• 6.18 Establish criteria for collecting statistical data related to risk monitoring.
• 6.19 Monitor implementation of treatment plans periodically and issue the related reports and data.
• 6.20 Re-execute the methodology's phases periodically, or as instructed by the NCA, or on any update to: treatment plans, potential threats, expected risk scenarios, the status of controls implementation, or changes in the digital infrastructure.

The five triggers in 6.20 are the difference between an annual risk assessment and a live one. A change in digital infrastructure — a new cloud workload, a new integration, a decommissioned segment — re-opens the cycle. Entities that run risk assessment as a once-a-year exercise will not satisfy 6.20 no matter how good the annual output is.

The Cybersecurity Risk Assessment Matrix

NFCRM fixes the calculation: Risk Level = Impact × Likelihood, each on a 1–5 scale, producing a score of 1 to 25.

The bands are defined numerically, which is what makes the matrix auditable:

The 15-point threshold is narrow. Only six of the twenty-five cells reach High or Critical, but they are exactly the combinations a real environment produces: an Almost Certain likelihood against a Medium impact (5 × 3 = 15) already trips the wire.

Impact levels: the national-level clause

Impact is classified on breach of one or more of confidentiality, integrity or availability, scored 1 (Very Low) to 5 (Critical). The gradation runs from "no impact on the entity" at level 1, through minor, tangible and significant impact at levels 2–4.

Level 5 is defined differently from the rest. It covers disclosure, unauthorised change, or disruption of the entity's assets producing a significant impact that is intolerable to the entity — or having an impact at the national level.

That second clause imports a national lens into an entity-level matrix, and it is the clause CNI operators need to calibrate deliberately. A disruption that a large operator could absorb financially may still be Critical under NFCRM if the consequence reaches beyond the entity — because the NCA is scoring the Kingdom's exposure, not the operator's balance sheet.

Likelihood levels: a dual test

Likelihood is scored 1–5 on either a time-frame test or an exploitability test. The Framework presents them as alternatives — the exploitability column is written as "Or a cybersecurity vulnerability can be exploited by…" — so a scenario that qualifies on either axis takes that level.

The exploitability axis is where NFCRM connects risk management to vulnerability management, and where scores move fastest. A vulnerability on an internet-facing asset with public exploit code is Almost Certain (5) on the exploitability test, whatever the historical frequency says. Pair that with a Medium impact and you are at 15 — a High risk, immediately reportable to the NCA.

How NFCRM sits alongside ECC, CSCC and ISO 27005

NFCRM does not replace anything in the NCA family — it standardises the risk layer beneath all of it.

• NCA ECC subdomain 1-5 Cybersecurity Risk Management requires a documented risk management approach covering identification, analysis, evaluation and treatment, with a maintained risk register. NFCRM is now the methodology that satisfies it — and the register in 6.10 and 6.16 is the artefact both instruments ask for.
• CSCC, CCC, OTCC, DCC and TCC supply the control populations you assess scenarios against in step 6.7 and select from when building treatment plans in 6.11. NFCRM's own definition of "Controls" points straight at them.
• ISO 27005 / NIST SP 800-30. The phase structure will feel familiar to anyone running either, and the vocabulary — inherent risk, residual risk, risk scenarios, acceptable risk level — maps cleanly. What does not carry over is the scale. If your ISO 27005 programme uses a 4×4 matrix, a 1–10 impact scale, or qualitative-only scoring, those scores are not NFCRM scores, and a High under your scheme is not necessarily a High under the NCA's.

That last point is the migration work. Entities with a mature ISO-based programme generally have the harder job, not the easier one: re-baselining an existing register of several hundred risks onto the NCA's exact scales, then finding out how many now sit at 15 or above and are therefore reportable. Doing that re-baseline before the first submission is considerably more comfortable than doing it afterwards.

Obligations and provisions

Section 7 is brief and absolute. All in-scope entities shall comply with the Framework, and shall also comply with all relevant NCA regulatory requirements — policies, frameworks, controls, guidelines and standards. The NCA may review and update the Framework in line with cybersecurity risk management requirements, and entities must adhere to any updates as approved and issued.

There is no maturity model here and no phased grace period written into the document — a contrast with SAMA's frameworks, which grade compliance on a 0–5 maturity scale. NFCRM states duties. The practical assessment mechanism will be the NCA's existing supervisory tooling and the submissions themselves: your asset reports, your reported High and Critical risks, and your treatment plans are the evidence.

A practical 90-day starting plan

For an entity that has just confirmed it is in scope:

1. Appoint the liaison officer (5.1) and tell the NCA. It is the only obligation that gates the rest, and it is a single decision.
2. Close the asset picture (5.2, 5.3). Classify assets per NCA issuance, and separately identify internet-facing assets. Include the categories teams routinely miss — operational technology, facilities, and social media accounts.
3. Re-baseline the register onto the NFCRM matrix. Rescore every existing risk on the 1–5 impact and likelihood scales, using the CIA-based impact descriptors and the dual likelihood test. Expect the distribution to shift.
4. Triage everything at 15 and above. These are your immediate reporting population. Confirm each score is defensible, then report through Haseen.
5. Set the acceptable risk level with a named approver (6.8). Get it documented and formally accepted by an authorised official, not assumed.
6. Wire the 6.20 triggers. Connect change management, vulnerability management and control assurance so a re-assessment fires on an event, not a calendar date.
7. Stand up the reporting cadence. Periodic asset reports, treatment plan submissions, and status updates on NCA-issued observations all need an owner, a template and a due date — before the first period closes.

How GRC Vantage supports NFCRM

GRC Vantage's risk management module implements the NFCRM matrix natively: the 1–5 impact and likelihood scales with the Framework's own descriptors, automatic banding on the 1–2 / 3–7 / 8–14 / 15–19 / 20–25 thresholds, and inherent-versus-residual scoring so step 6.12's "does the plan land it inside appetite?" test is answered on the record rather than in a meeting. Risks that cross 15 raise a flagged reporting task with the evidence pack attached, so the immediate notification under 5.5 has an owner and an audit trail.

The asset register carries the classification required by 5.2 and a distinct internet-facing flag for 5.3, and it feeds the compliance module where the ECC, CSCC and other NCA control libraries live — so the controls identified in step 6.7 are the same records your ECC assessment already assesses, not a parallel list. Re-assessment triggers under 6.20 fire from change and vulnerability events, and the risk register, treatment plans and follow-up reports export in the shape the NCA's periodic submissions expect. The platform is deployed inside the Kingdom for data residency, with delivery teams in Riyadh and Dammam who pre-load the NCA framework content.

For the wider NCA picture, read our NCA frameworks pillar guide and our guide to building a cyber risk register for SAMA and NCA. If you are working out what NFCRM means for your register and your first Haseen submission, book a session with our team.

Frequently asked questions

What is the NCA NFCRM?

The National Framework for Cybersecurity Risk Management (NFCRM – 1:2025) is the NCA's mandatory methodology for managing cybersecurity risk in Saudi Arabia. It defines a four-phase methodology (Identify, Assess, Treat, Follow up), a fixed 5×5 risk assessment matrix, and the reporting duties in-scope entities owe the NCA at the national level.

Who must comply with NFCRM?

Government agencies in the Kingdom — ministries, authorities and institutions — together with their affiliated companies and entities inside and outside the Kingdom, and all private sector entities that own, operate or host Critical National Infrastructure. The NCA strongly encourages all other entities in the Kingdom to adopt it.

When must a risk be reported to the NCA?

Under section 5.5, any cybersecurity risk assessed as High (score 15–19) or Critical (score 20–25) must be reported to the NCA immediately upon identification, via Haseen or another NCA-specified channel. Risk treatment plans are submitted periodically and on any update or change.

How is risk calculated under NFCRM?

Risk Level = Impact × Likelihood, each scored 1–5, giving 1–25. The bands are Very Low (1–2), Low (3–7), Medium (8–14), High (15–19) and Critical (20–25). Impact is assessed on breach of confidentiality, integrity or availability, with level 5 covering impact that is intolerable to the entity or that reaches the national level. Likelihood is scored on either a time-frame test or an exploitability test.

Does NFCRM replace ISO 27005?

No, but it overrides it where they differ. The phase structure and vocabulary are compatible with ISO 27005 and NIST SP 800-30, so an existing programme can continue — but the NCA's 5×5 scales and band thresholds are mandatory for in-scope entities, so an ISO-based register must be re-baselined onto the NFCRM matrix before it can support NCA reporting.

What is Haseen?

Haseen is the NCA's national cybersecurity ecosystem, through which it delivers centralised and non-centralised cybersecurity services to government entities, CNIs and private entities. Under NFCRM it is the specified channel for submitting asset reports, High and Critical risk notifications, and risk treatment plans.