A Practical Guide to SAMA Cyber Resilience Fundamental Requirements (CRFR) Compliance Using Picus

What Are the SAMA Cyber Resilience Fundamental Requirements?

The SAMA Cyber Resilience Fundamental Requirements (CRFR) are the Saudi Central Bank's baseline cybersecurity and resilience rules for entities entering the Kingdom's financial sector.

Published in January 2022, they set a prioritized set of mandatory controls for newly established entities operating in the early stages of their lifecycle, organized across three control areas and aligned with SAMA's broader regulatory frameworks.

Who issued the CRFR, and who must comply with it?

The CRFR was developed and is owned by the Saudi Central Bank (SAMA), which is responsible for periodically updating it.

The framework applies to entities intending to qualify for SAMA's Regulatory Sandbox environment and to entities seeking a license to operate in the Kingdom of Saudi Arabia. It acts as a catalyst that enables these entities to meet SAMA's minimum cyber resilience licensing requirements.

How does the CRFR relate to SAMA's other frameworks?

The CRFR is not a replacement for SAMA's Cyber Security Framework (CSF) or Business Continuity Management Framework (BCMF). It is a foundational, licensing-stage requirement that maps directly to those larger frameworks. Once an entity is licensed, it is expected to comply with the full set of relevant SAMA regulatory requirements.

Why Did SAMA Create a Fundamental Requirements Framework?

FinTech innovation in the Kingdom has accelerated rapidly, bringing a growing range of products and services that benefit consumers and financial institutions alike. Yet the increasing reliance on emerging technologies introduces cyber resilience risks that can affect the stability of the wider financial sector ecosystem.

Recognizing that newly established entities often face resource constraints, SAMA designed the CRFR to help them manage and mitigate a broad range of relevant cybersecurity and resilience risks while focusing limited resources on a fundamental set of controls that protect information assets effectively. The framework gives these entities clear, prioritized direction without imposing a burden that could stifle innovation or business growth.

What Does the CRFR Expect Beyond Documenting Controls?

The CRFR is built on a risk-based approach. Its three domains (Cyber Security Leadership and Governance, Cyber Security Operations and Technology, and Resilience) set the essential mandatory requirements, but SAMA expects more than a paper exercise.

Entities are expected to conduct their own internal risk assessments, monitor the evolving threat landscape, identify new and emerging risks, evaluate their potential impact, and, where necessary, implement additional or enhanced controls beyond the fundamentals in line with their risk appetite.

The key takeaway: writing a policy or deploying a tool is not the same as being resilient. Controls must be implemented, monitored, and shown to work.

What Should Entities Be Careful About During Self-Assessment and Audit?

The short answer: compliance is verified, not assumed. Implementation of the CRFR is subject to periodic self-assessment, and SAMA holds the right to scrutinize the results at any time.

How is CRFR compliance assessed?

Entities perform a periodic self-assessment based on a questionnaire and send a copy to SAMA. SAMA reserves the right to review that self-assessment to confirm compliance with the Fundamental Requirements at its discretion.

Can SAMA audit an entity directly?

Yes. SAMA reserves the right to audit an entity's compliance with the Fundamental Requirements at any time. An entity that cannot demonstrate compliance risks having its sandbox graduation or license request prohibited.

What stays constant, and why it matters

Across governance, operations, technology, and resilience, the CRFR shifts the expectation from control presence toward demonstrable control effectiveness. This creates an ongoing need for current, repeatable, and defensible evidence that controls function as intended, evidence that an entity can produce for a SAMA reviewer or auditor at any moment.

How Picus Supports Key SAMA CRFR Requirements

The following sections show how the Picus Platform helps entities satisfy specific CRFR control requirements, drawn from the three control domains of the Cyber Resilience Fundamental Requirements, through evidence-based validation of their security controls.

The control requirements covered are:

• Control 3.2.11 to 3.2.14: Logging, SIEM, Continuous Monitoring, and Incident Management
• Control 3.2.5 & 3.2.7: Vulnerability Assessment and Patch Management
• Control 3.2.10: Endpoint Security and Malware Protection
• Control 3.2.3: Secure Network Architecture
• Control 3.2.6: Penetration Testing
• Control 3.2.1: Identity and Access Management
• Control 3.2.16: Incident Notification to SAMA
• Control 3.1.6: IT and Cyber Security Risk Assessments
• Control 3.1.1: Cyber Security Leadership and Governance
• Section 2.3: Self-Assessment and SAMA Audit

SAMA CRFR Controls 3.2.11 to 3.2.14: Logging, SIEM, Continuous Monitoring, and Incident Management

Considered as a set, Controls 3.2.11 to 3.2.14 call for security logging with retention, SIEM integration across applications and infrastructure, continuous monitoring and analysis of events, and an incident-management process that identifies, responds to, and contains incidents. Whether any of these work hinges on one thing: does the detection-and-response stack actually fire during an attack, and do the people and processes around it react correctly?

How does Picus support SAMA CRFR Controls 3.2.11 to 3.2.14?

By running emulated adversary activity in a safe-for-production way, the Picus platform establishes whether events are caught, whether EDR, XDR, and SIEM rules raise alerts clear enough to investigate, and where blind spots remain across the stack.

This lets an entity confirm that its monitoring and incident-handling machinery genuinely works before a live incident, or a SAMA review following one, puts it to the test. The findings drive steady improvement, so incident procedures evolve from measured control performance rather than guesswork.

The platform also supplies the raw detection material to reinforce these controls: ready-to-use SIEM and EDR rules in both vendor-specific and SIGMA formats, requiring no custom detection engineering. Each rule arrives tied to its log sources, severity level, and MITRE ATT&CK technique, so the alerting pipelines Picus keeps validating sit on dependable, high-fidelity detections, making logging, SIEM integration, monitoring, and incident management work in the moment they are needed.

Figure 1. Picus Mitigation Library provides vendor-based detection rules

SAMA CRFR Controls 3.2.5 & 3.2.7: Vulnerability Assessment and Patch Management

Controls 3.2.5 and 3.2.7 work as a pair: regular, comprehensive vulnerability assessment across both the application and infrastructure layers, followed by patches that are tested, applied, and installed promptly so that known flaws cannot be turned against the entity. The practical snag is volume and sequencing. Scanners surface far more findings than a lean team can work through, raw severity ratings rarely reveal which of them actually put the entity at risk, and with finite time, the real questions become which patches to apply first and whether the ones already applied truly closed the gap.

How does Picus support SAMA CRFR Controls 3.2.5 & 3.2.7?

Picus's Exposure Validation capability pulls findings in from scanners such as Microsoft Defender for Endpoint, Tenable, and Rapid7 InsightVM, cross-references them against live control results from its own simulated attacks, and re-ranks them by proven exploitability instead of headline severity.

Figure 2. Vulnerability Asset List provided by Picus Platform integrations

This gives the periodic VA the CRFR asks for a sharper edge. Across both the application and infrastructure layers, an entity can see not only which vulnerabilities exist, but which ones can genuinely be reached and exploited in its own environment, and which are already neutralised by other controls, so remediation effort lands where it counts.

Figure 3. Picus Score deprioritizes exposures by validated exploitability

That same evidence drives patching. The flaws that can genuinely be exploited where the entity operates move to the front of the queue, while those already mitigated by layered controls can wait. And once a patch lands, the original attack can be re-run to confirm the exploit no longer succeeds and that exposure has measurably dropped, turning patching from an assumed fix into a verified one, with the evidence to prove it.

SAMA CRFR Control 3.2.10: Endpoint Security and Malware Protection

Control 3.2.10 requires endpoints to carry a baseline of protections, including real-time defence, behavioural and signature-based detection, and current anti-malware signatures backed by routine scanning for malicious files and unusual activity.

How does Picus support SAMA CRFR Control 3.2.10?

Picus checks whether endpoint and network defences genuinely stop and flag the malware and offensive tooling seen in live campaigns, including the specific techniques used by threat groups targeting the entity's industry.

Figure 4. Picus measures prevention and detection effectiveness against each threat set, breaking the results down into blocked, logged, and alerted outcomes.

Rather than taking real-time protection and signature freshness on trust, Picus runs emulated adversary activity and records whether the endpoint controls in place truly block, detect, log, and alert as they are meant to.

The entity gains continuously refreshed proof that its behavioural and signature-based tooling performs as expected, plus a precise read on where coverage falls short, well ahead of any attacker testing the same ground, in direct support of the endpoint baseline set out in Control 3.2.10.

SAMA CRFR Control 3.2.3: Secure Network Architecture

Control 3.2.3 calls for a securely designed network: segmented by service function, with security systems such as firewalls governing the traffic that moves between segments, and kept available throughout. A diagram can show how all of this is meant to work, but it cannot show whether the controls hold once an attacker pushes against them.

How does Picus support SAMA CRFR Control 3.2.3?

Picus proves the architecture empirically rather than on paper. It safely runs network-based infiltration techniques at firewalls and IPS, email infiltration attempts at secure email gateways, and web application attacks at WAFs, IPS, and web security gateways, verifying that each device enforces its intended policy under live conditions and not only in its configuration.

Figure 5. Picus Network Infiltration Attacks by Picus Breach and Attack Simulation (BAS)

SAMA CRFR Control 3.2.6: Penetration Testing

Control 3.2.6 requires penetration testing at least every six months, and again after any major or critical change, so an entity can gauge how well its defences perform. The value of that exercise rests entirely on whether the test mirrors the way real adversaries operate inside the entity's own environment.

How does Picus support SAMA CRFR Control 3.2.6?

This is precisely what Autonomous Pentesting delivers. AI agents chart the full attack surface, carry out real chained exploitation across hosts, and demonstrate which routes genuinely lead to the entity's highest-value assets, such as domain admin, customer databases, and payment systems.

Figure 6. Picus Autonomous Pentesting finds paths to critical assets.

Because testing runs on a continuous basis, the entity is no longer tied to two fixed checkpoints a year; it can repeat engagements straight after any significant change, which is exactly the trigger Control 3.2.6 names, and keep an up-to-date view of defensive strength in between.

Because testing can run continuously, Picus takes the repetitive validation work off security teams, freeing manual engagements to focus on judgment-intensive analysis where human expertise counts most. The platform can re-run straight after any significant change, which is exactly the trigger Control 3.2.6 names, and keep an up-to-date view of defensive strength in between.

What an entity ends up with is live evidence of how its own defences fare against latest attack methods, the comprehensive evaluation of defence capability the CRFR is asking for.

SAMA CRFR Control 3.2.1: Identity and Access Management

Control 3.2.1 asks for an access-management process that limits logical access to the information assets each user genuinely needs, applying need-to-have and need-to-know principles. Such rules tend to look airtight in documentation while quietly eroding in production, where stale permissions, misconfigurations, and excess privilege are exactly what attackers reach for.

How does Picus support SAMA CRFR Control 3.2.1?

Picus puts identity and access defences under real adversary pressure. Using Autonomous Pentesting, AI agents set their sights on the entity's most valuable targets (domain administrator, customer records, payment systems) and safely string together genuine exploitation steps from host to host until they either reach those targets or are stopped. The exercise confirms in practice whether authentication and access restrictions actually hold, or whether stolen credentials, escalated privilege, and weak IAM or Active Directory settings open a way through.

Because the platform traces the entire route from first foothold to final objective, it surfaces the linked weaknesses that real intrusions depend on, not just standalone findings that rarely matter on their own.

For cloud estates, Breach and Attack Simulation (BAS) extends the picture by safely emulating IAM policy abuse, misconfiguration exploitation, and privilege escalation across AWS, Azure, and GCP.

Figure 7. Picus Breach and Attack Simulation contains cloud-based attacks for Azure, AWS, and GCP.

The outcome is concrete proof that an entity's access controls do what Control 3.2.1 intends, with named weak points and direct remediation pointers wherever they fall short.

SAMA CRFR Control 3.2.16: Incident Notification to SAMA

Control 3.2.16 carries one of the CRFR's tightest clocks: an entity has to notify SAMA without delay once a cybersecurity fraud or disruptive incident rated medium or higher is identified.

The whole duty rests on a precondition that the entity can recognise the incident in the first place. Where detection quietly fails, an incident can slip by unseen, the notification to SAMA may arrive late or never, and the information needed to grade its severity may never be gathered.

How does Picus support SAMA CRFR Control 3.2.16?

Picus supports this obligation by proving that the detection layer actually generates the signal that a notification depends on. Running emulated adversary techniques and watching how EDR, XDR, IDS, and SIEM react, the platform establishes whether malicious behaviour is detected, whether it is logged in enough detail to support a first-pass severity call.

Picus Detection Analytics lays out which techniques set off alerts and escalation, and which slip through, giving an entity a clear path to close the blind spots that would otherwise leave notifications to SAMA late, partial, or absent.

By rooting detection in continuous testing, Picus helps an entity satisfy the real intent of Control 3.2.16, identifying incidents promptly and with the supporting detail the requirement assumes.

SAMA CRFR Control 3.1.6: IT and Cyber Security Risk Assessments

Control 3.1.6 calls for thorough IT and cyber security risk assessments spanning infrastructure, networks, applications, and systems, along with the controls put in place to treat whatever those assessments surface. The findings belong in a central register that is kept under regular review, and Section 2.3 adds the expectation that entities track how the threat landscape shifts over time.

How does Picus support SAMA CRFR Control 3.1.6?

A risk register is only worth as much as the inputs behind it. Severity ratings drawn from generic sources such as CVSS and EPSS, combined with configuration walkthroughs, describe hypothetical danger. What they leave unanswered is whether a given weakness can really be exploited inside the entity's own estate.

Picus settles that question with evidence. With its Adversarial Exposure Validation (AEV) capability, which fuses agentic, autonomous Breach and Attack Simulation (BAS) with Autonomous Penetration Testing, repeatedly tests the entity's live controls to establish which identified risks are genuinely reachable. Entities can then score risk on observed exploitability using the Picus Score, and feed those results straight into the central register so it reflects operating conditions rather than a one-time estimate.

Linking assessment, scoring, and review to ongoing validation keeps the entire 3.1.6 cycle anchored to current reality across your stack.

SAMA CRFR Control 3.1.1: Cyber Security Leadership and Governance

Control 3.1.1 places accountability for cybersecurity at the top of the organisation. Leadership has to set up a governance structure and resource it well enough to steer the entity's overall security direction. To steer anything, though, a board or executive team needs a dependable read on whether the entity's defences are actually holding.

How does Picus support SAMA CRFR Control 3.1.1?

Picus converts raw control performance into figures that leadership can govern with. Prevention and detection effectiveness are scored on a continuous basis, plotted over time so decision-makers can see whether security posture is climbing or slipping, and broken down to expose precisely which gaps remain open.

With this in hand, the people answerable for cybersecurity under Control 3.1.1 can base their direction on measured outcomes rather than progress updates, and can show, whenever it is asked of them, that the controls they approved are being verified on an ongoing basis instead of taken for granted.

SAMA CRFR Section 2.3: Self-Assessment and SAMA Audit

Section 2.3 is what gives the CRFR its enforcement weight. Entities run a periodic self-assessment from a questionnaire and hand it to SAMA, which may examine it whenever it chooses. SAMA can also audit compliance directly and at any moment, and an entity unable to show it complies risks losing its sandbox graduation or licence.

How does Picus support SAMA CRFR Section 2.3?

Here, validating in a continuous manner pays back as a supervisory advantage rather than overhead. When SAMA asks for proof of implementation, not an account of what the controls are meant to do, but evidence they work, Picus supplies validation data that is generated continuously, time-stamped, and mapped to MITRE ATT&CK, with full reporting behind it.

That record sets out exactly what was tested, what was stopped, what was caught, what was logged and alerted on, and what slipped through. The same body of evidence underpins the entity's own self-assessment questionnaire.

It also means an audit triggered by an incident lands on a defensible, current account of how the controls were performing, rather than a last-minute scramble to piece proof together.

Because this evidence builds up continuously rather than only at assessment time, an entity can stay audit-ready right through the supervisory cycle, meeting short-notice SAMA requests with fresh data instead of outdated point-in-time snapshots.

Making SAMA CRFR Compliance Resilient with Validation

The CRFR was designed to ensure that entities entering the Kingdom's financial sector are genuinely resilient because the controls protecting their information assets work in practice, not just on paper. The framework says so in its own structure: it is built on a risk-based approach, it expects entities to monitor the evolving threat landscape continuously, and Section 2.3 empowers SAMA to demand evidence of implementation through self-assessment and audit at any time.

Entities in scope should therefore approach the CRFR not as a one-time licensing exercise but as a long-term commitment to continuous assurance. Detection rules degrade, segmentation weakens after changes, access controls drift, and new adversary techniques emerge without being tested against existing defenses. When control effectiveness is assumed rather than proven, CRFR compliance becomes fragile precisely at the moment a SAMA reviewer or an attacker tests it.

The Picus Platform helps entities move from periodic, assumption-based compliance to continuous, evidence-based assurance. By validating control effectiveness against real attack behavior, Picus turns CRFR compliance into a living, defensible security posture, one that satisfies SAMA not just at the time of self-assessment or audit, but continuously.

Get your free demo and see how Picus helps entities meet their SAMA CRFR obligations with audit-ready evidence.