Regulatory Cybersecurity Framework (SAMA)

Overview

Financial regulators require the institutions they oversee to run cybersecurity to a defined standard, because a bank's cyber failure is not a private matter, it can shake confidence in the whole financial system. A regulatory cyber framework translates that public interest into specific, assessable obligations.

The framework of the Saudi central bank, SAMA, is a leading example in the region. It exists so that regulated financial institutions identify and address cyber risk in a common, comparable way, and it is built on recognized international standards while adding the supervisory expectation that maturity is measured and reported, not merely claimed.

This page describes how to operate to such a framework as a reusable model, organized around its four domains, and aligned to the publicly issued SAMA framework and the international standards it draws on, without reproducing their text.

The Four Domains

The framework organizes cybersecurity into four domains that together cover direction, decision, execution, and dependency. Splitting the work this way makes coverage easy to reason about and gaps easy to see.

The four domains are leadership and governance, risk management and compliance, operations and technology, and third-party considerations. Read together, they describe a complete program: leadership sets direction, risk and compliance decide and prove, operations and technology carry it out, and third-party management extends it to the parties the institution depends on.

The design mirrors the recognized governance-management split and the risk cycle used across international standards, which is why an institution already aligned to ISO or NIST finds most of the work already done and mainly needs to map it to the regulator's structure and evidence expectations.

A subtle but important feature of a regulatory framework is that it is prescriptive where an international standard is permissive. ISO tells you to manage risk and lets you decide how, while a regulator often specifies the how, mandating particular controls, notification timelines, and maturity targets. This trades flexibility for comparability: the supervisor can hold every institution to the same measurable bar and compare them, which is the whole point of regulating a sector where one firm's failure can spread. Operating well under such a framework therefore means meeting specific requirements to the letter while still running the underlying risk management with genuine judgment, not just to the checklist.

Leadership & Governance

The first domain makes cybersecurity a board-level responsibility, not a technical afterthought. In a regulated institution the expectation is explicit: senior leadership owns the cyber program and is answerable for it.

In practice this means a designated senior officer accountable for cybersecurity, a governance structure with a clear mandate, an endorsed cyber strategy and policy, and the resources to deliver them. The regulatory weight matters here, because it turns leadership involvement from good practice into a supervised obligation the institution must be able to demonstrate.

• Accountable officer: a named senior owner of the cyber program.
• Governance structure: a committee with mandate, decision rights, and cadence.
• Strategy and policy: endorsed direction that the rest of the program implements.
• Resourcing: the budget and people to meet the obligations, not just the intent.

Risk Management & Compliance

The second domain applies the standard risk cycle inside a compliance envelope. The institution must not only manage cyber risk well, it must prove to a supervisor that it does, which raises the bar on evidence and consistency.

This means a documented risk methodology, a maintained risk register, defined risk appetite, and treatment tracked to closure, all in a form a regulator can examine. Compliance adds the obligation to map controls to the framework's requirements and to demonstrate coverage, so the risk work and the regulatory reporting draw on the same underlying evidence rather than running as separate exercises.

The evidence bar is the practical difference from an unregulated program. It is not enough that a control works, the institution must be able to show, on demand and for a past date, that it was working then, which means logs, records, and sign-offs retained over time rather than reconstructed for an inspection. A useful discipline is to ask of every control, if the supervisor asked us to prove this was operating three months ago, could we, and to fix the answer before the question is ever asked. Building that evidence trail into daily operation is what separates a program that passes examinations calmly from one that lurches from one pre-audit crisis to the next.

• Methodology: a documented, repeatable way of assessing cyber risk.
• Register and appetite: a living record and a stated line for treatment.
• Control mapping: each requirement linked to the control that meets it and its evidence.
• Reporting: risk and compliance status presented to leadership and, as required, the regulator.

Operations & Technology

The third domain is where protection actually happens. It covers the operational controls that defend systems every day, from access and network security to monitoring, incident response, and resilience.

This domain is broad because it holds the working machinery of security. It expects the institution to run the practical controls covered elsewhere in this portfolio, security operations and incident management, identity and access, and secure configuration, and to keep them effective rather than merely present. A regulated institution also weighs resilience heavily, because a financial service that cannot recover quickly harms customers and confidence at once.

• Protective controls: access, network, endpoint, and cryptographic safeguards.
• Detection and response: monitoring and incident management that limit harm quickly.
• Resilience: the ability to keep critical services running and recover them fast.
• Secure operations: patching, configuration, and change control done consistently.

Third-Party Considerations

The fourth domain recognizes that a modern financial institution runs on outsourced services, and that a supplier's weakness can become the institution's incident. It extends the cyber obligations outward to the parties the institution depends on.

Practically, this means assessing a third party's security before relying on it, writing security requirements and audit rights into the contract, and maintaining assurance for as long as the dependency lasts. Where a service is outsourced, the regulator's expectation is that accountability is not: the institution remains answerable for risk it has handed to a supplier.

• Due diligence: assess a provider's security before onboarding, sized to the risk.
• Contractual controls: security terms, breach notification, and the right to audit.
• Ongoing assurance: periodic evidence the provider still meets the bar.
• Retained accountability: outsourcing the service does not outsource the responsibility.

Maturity Assessment

A defining feature of a regulatory framework is that compliance is measured on a maturity scale, not as a simple pass or fail. The institution assesses how well each control is embedded, and the regulator expects that assessment to be honest and improving.

A maturity scale describes control effectiveness in levels, from controls that exist only by individual effort, through defined and managed, to controls that are continuously improved. Placing each area on the scale turns compliance into a roadmap: the institution can see where it stands, agree a target, and plan the gap, and the supervisor can track progress over successive cycles.

The value is in honest placement and steady movement. A flattering self-assessment produces a plan that closes nothing, while an honest one, even where uncomfortable, gives leadership and the regulator a real picture and a credible path forward.

Key Takeaways & References

A regulatory cyber framework turns cybersecurity into a supervised, evidenced obligation, organized here around four domains and a maturity scale.

• Treat the framework as a floor built on international standards, and build above it.
• Make leadership accountable and evidence its involvement with records.
• Run the risk cycle inside a compliance envelope, mapping controls to requirements.
• Keep operational controls effective, and weigh resilience heavily.
• Extend obligations to third parties, and measure maturity honestly each cycle.

References

• SAMA Cyber Security Framework, version 1.0 (2017 record).
• SAMA Rulebook, Cyber Security Framework circular.
• ISO/IEC 27001:2022, Information security management systems.
• NIST Cybersecurity Framework (CSF) 2.0 (2024 record).
• ISO/IEC 27005:2022, Guidance on managing information security risks.