Meeting the CBK Cyber and Operational Resilience Framework (CORF) Requirements With Picus

What is the CBK Cyber and Operational Resilience Framework (CORF)?

The CBK Cyber and Operational Resilience Framework, or CORF, is the cybersecurity and resilience regulation that the Central Bank of Kuwait (CBK) issued for the banks and financial institutions it supervises.

The CORF replaces the Cybersecurity Framework (CSF) that CBK issued in 2020. CBK describes the change as a move from foundational compliance to a "Resilience-first" and "Maturity-oriented" model [1].

Why did CBK replace the Cybersecurity Framework with the CORF?

CBK replaced the CSF because threats, technology and regulatory expectations changed faster than the 2020 framework could follow [1]. The CORF names drivers such as more frequent and complex cyber attacks, rapid adoption of cloud and AI, and growing reliance on outsourcing and FinTech partners.

The new framework also adopts a "Safe-to-Fail" mindset. CBK assumes no system is immune to disruption, so Regulated Entities must be able to prevent, absorb, recover from and adapt to incidents.

Who must comply with the CBK CORF?

The CORF applies to all Regulated Entities under CBK supervision [1]. CBK places each one in a tier based on its risk profile. Tier 1 covers high-impact entities such as Domestic Systemically Important Banks (D-SIBs) and Financial Market Infrastructures (FMIs), Tier 2 covers mid-sized entities, and Tier 3 covers smaller ones.

The Cyber Resilience Baselines also reach the entity's employees, third-party vendors and vendor staff who provide services to it.

What are the CORF requirements?

The CORF requirements are set out in three sets of Baselines within the CORF document. The Cyber Resilience Baselines hold 519 controls across 6 domains and 33 sub-domains, the Operational Resilience Baselines add 146 controls, and the Third-Party Risk Management Baselines add 211 [1].

The CORF Toolkit explains how to apply them. It contains the assessment criteria, a Statement of Applicability template and the maturity attributes for every sub-domain.

How is CORF compliance assessed?

Each CORF requirement is rated Compliant, Non-Compliant or Not Applicable, based on documented verifiable evidence, with no partial credit [1].

Each sub-domain also receives a maturity level from 1 (Initial) to 5 (Innovative), and a higher level only counts once the level below it is fully achieved. CBK uses the resulting overall maturity level for sectoral benchmarking, risk analysis, supervisory tiering and regulatory prioritization, so a higher level signals a stronger resilience posture and shapes how CBK views the entity.

CBK assesses Tier 1 entities every year, Tier 2 entities every eighteen months and Tier 3 entities every two years. Any entity can also face spot checks and ad-hoc reviews at any time.

How Picus Helps You Meet the CORF Requirements

Passing a CORF assessment depends on proof that controls work, that real exposures are found and fixed, and that the bank stays resilient as threats and its environment change. CBK rates every requirement on verifiable evidence, and the maturity model reserves its higher levels for entities that continuously validate their defenses (Level 4) and run a continuous threat exposure management (CTEM) program that brings testing, detection and risk mitigation together (Level 5). Regulated Entities therefore need to show what an attacker can reach and whether their controls stop and detect that attack.

The Picus Autonomous Exposure Validation Platform generates that proof with three validation techniques that fill each other's gaps. Picus Breach and Attack Simulation safely runs real attack techniques against the live prevention and detection stack and records whether each one was blocked, detected, logged only or missed. Picus Autonomous Penetration Testing runs production-safe exploits against reachable assets and links them into attack paths, showing how deep an attacker could go. Picus Exposure Validation proves exploitability without firing a live exploit, so it also covers core banking, payment and other systems that are too critical to test live.

Each result leads to a single decision per exposure (Patch, Mitigate, Monitor, or Accept with Evidence), together with an owner, a fix and a verified re-test. Over time, these decisions become the evidence trail a CBK assessor asks to see.

Below, we look at how Picus helps with each of these requirements:

• CORF 9.1.4: Testing and Validation of Operational Resilience
• CORF 5.13.1.2 and 5.13.2.5–5.13.2.11: Penetration Testing and Red Teaming
• CORF 5.13.1 and 4.2.3: Vulnerability Management and Risk Treatment
• CORF 5.12: Logging, Monitoring, and Security Incident Management
• CORF 5.3.1.3(k), 5.3.1.4, 5.3.2.2 and 5.15.2.1: Threat-Informed Network Security and Continuous Monitoring
• CORF 4.1.1.5 and 5.13.1.8: Board Updates on Emerging Threats and Vulnerability Management
• CORF 4.4.1.1: Independent Audit of Control Effectiveness
• CORF Toolkit: Level 4 and Level 5 Maturity for Cybersecurity Testing and Threat Management

CORF 9.1.4: Testing and Validation of Operational Resilience

Control area 9.1.4 asks Regulated Entities to test their operational resilience with scenarios that simulate a wide range of disruptions, including cyber incidents, and to document the results for evaluation and continuous improvement. Testing takes place at least once a year and again whenever the operating environment changes significantly.

New threats make cyber incident scenarios outdated quickly, and an annual test plan cannot keep up with changes in the environment.

How does Picus support CORF 9.1.4 operational resilience testing?

Picus supports 9.1.4 through security validation. Its three validation techniques run real cyber incident scenarios against the bank's environment and show whether its defenses hold.

Picus Breach and Attack Simulation validates prevention and detection controls. It runs multi-stage threat scenarios, such as a financially motivated threat group moving from a phishing email to the theft of customer data, safely against the live security stack and shows at which stage the attack was stopped, detected or missed.

Picus Autonomous Penetration Testing validates attack paths from the attacker's side. It chains production-safe exploits into attack paths and shows how far an incident could spread inside the network.

Picus Exposure Validation validates systems that are too critical for live testing, such as core banking and payment platforms. It proves whether an attack would succeed there without firing a live exploit.

Picus Swarm, a team of five specialist AI agents (Discovery, Exploitation, Validation, Mobilization and Reporting) orchestrated by Numi AI, starts new tests automatically when the environment changes or a new threat appears, which covers the second trigger in 9.1.4.9.

Every scenario result is stored with its gaps, the decision taken on each and a verified re-test. These records are the documented results 9.1.4.8 asks for, and they let the Regulated Entity show CBK how its resilience improves after every significant change.

CORF 5.13.1.2 and 5.13.2.5–5.13.2.11: Penetration Testing and Red Teaming

The CORF asks for penetration testing and red teaming that simulate real adversary tactics, techniques and procedures (5.13.2.5) and draw on threat intelligence, so that scenarios reflect current adversary behavior and emerging threats (5.13.2.6). Controls 5.13.1.2 and 5.13.2.7 also set a calendar minimum, and both require a new test when the environment, the threat landscape or critical systems change significantly.

That second trigger is where most programs fall short. A bank changes every week, with new applications, new vendors and newly exploited vulnerabilities. An annual test cannot react to any of them, so the attack paths found in January may look nothing like the ones open in September.

Control 5.13.2.11 also requires that every red team finding needs a remediation plan with clear timelines and must be tracked to closure.

How does Picus support CORF 5.13.1.2 and 5.13.2.5–5.13.2.11?

Picus Autonomous Penetration Testing runs stealthy, production-safe penetration tests on a continuous basis. It links real weaknesses and exploits into attack paths that show how far an attacker can reach.

Figure 1. Attack path validated by Picus Autonomous Penetration Testing, from initial access to domain compromise.

Picus Breach and Attack Simulation covers the adversarial simulation side of red teaming. It safely runs the tactics, techniques and procedures of real threat groups, mapped to MITRE ATT&CK, against the live security stack and shows which steps were blocked, detected or missed, as 5.13.2.5 describes.

Because the Picus Threat Library is updated continuously with new threat actor campaigns and emerging threats, these scenarios stay aligned with current threat intelligence, as 5.13.2.6 requires. For every step that was missed, the Picus Mitigation Library provides ready-to-apply vendor-specific and vendor-neutral prevention signatures and detection rules, so each finding on the 5.13.2.11 remediation plan comes with a concrete fix.

When a change occurs, such as a newly exploited vulnerability in the threat landscape or a new asset in the environment, Numi AI orchestrates the Picus Swarm agents and directs them to run a new breach and attack simulation or autonomous penetration test. This covers the change trigger in 5.13.1.2, keeps the results current and continues adversarial testing between the annual red team exercises.

Figure 2. Picus Swarm, five specialist AI agents orchestrated by Numi AI.

As a result, the Regulated Entity can show CBK a dated series of tests linked to the changes that triggered them, alongside its annual red team report.

CORF 5.13.1 and 4.2.3: Vulnerability Management and Risk Treatment

Control area 5.13.1 asks Regulated Entities to rank vulnerabilities by risk, fix them within defined timelines, and then confirm that each fix actually worked. Findings must be tracked until they are closed. Control area 4.2.3 adds that each risk needs a treatment decision, such as acceptance, avoidance, mitigation or transfer, that accepted risks need a documented and approved justification, and that a monitoring process must confirm the mitigating controls actually work.

The problem is volume. A single scan of a bank's network can return thousands of CVEs, far more than any team can fix on time. CVSS scores rate how dangerous a vulnerability is in general. They do not show whether an attacker can use it in this network.

How does Picus support CORF vulnerability management and risk treatment?

Picus Autonomous Penetration Testing safely runs real exploit chains against reachable assets to show which vulnerabilities an attacker can actually use.

Where no safe exploit exists, or a system such as a core banking platform is too sensitive for live testing, Picus Exposure Validation is used instead. It simulates the attack techniques behind the exploit, so the bank gets an answer on the day a vulnerability is disclosed.

Business Scopes group assets by how critical they are, so a payment switch ranks above a test server carrying the same CVE. The Picus Exposure Score then sets priority from validation results and asset criticality.

Figure 3. Picus Exposure Score re-ranking a critical CVSS vulnerability by validated exploitability.

For 5.13.1.5, the same test is run again after the fix. A passed re-test is the confirmation the control asks for, and the vulnerability closes with a Patch, Mitigate, Monitor, or Accept with Evidence decision on record.

These decisions match the risk treatment categories in 4.2.3.2. Patch and Mitigate reduce the risk, Monitor keeps it under watch, and Accept with Evidence documents why a risk was accepted, who approved it and which test result supported the choice.

CORF 5.12: Logging, Monitoring, and Security Incident Management

Sub-domain 5.12 expects logs on all critical assets, on-premises and in cloud, along with SIEM-based event correlation and continuous, automated monitoring of Indicators of Compromise. Control 5.1.2.1(d) sets the goal behind these controls. The bank's architecture must enable effective detection of adversaries and proactive incident response mechanisms, so an attack is caught and handled before it causes serious impact.

The weak spot is that these tools only report what they see. When a log source stops sending or a parser change breaks a correlation rule, the SIEM console still looks healthy. The gap only becomes visible when someone runs a real attack technique and checks whether the SIEM logged it and raised an alert. Until then, the response team gets no alert to act on, and incident response begins only after the attacker has already caused damage.

How does Picus support CORF 5.12 monitoring and detection?

Picus Breach and Attack Simulation runs attack techniques against endpoints, network segments and cloud workloads, then checks the SIEM and EDR to see whether each action was logged and whether an alert was raised. The results show where the bank has logging gaps, where telemetry never arrives, and detection gaps, where it arrives and no rule acts on it.

Picus Detection Rule Validation checks every rule in the SIEM without running a simulation. It looks at each rule from three angles: whether its log sources are actually feeding it, whether it runs without failing or being skipped, and whether it runs efficiently or wastes resources and produces false positives. Results are mapped to MITRE ATT&CK, so the team sees where detection coverage holds and where it breaks. Every broken rule comes with insights and a re-validation step.

Over time these checks produce a dated record showing that the monitoring 5.12 requires worked, and when each gap was closed.

CORF 5.3.1.3(k), 5.3.1.4, 5.3.2.2 and 5.15.2.1: Threat-Informed Network Security and Continuous Monitoring

Control 5.3.2.2 lists the security solutions a bank's network should rely on, and it states their purpose plainly. They must protect against and detect cyber threats. Control 5.3.1.3(k) adds that security configuration standards must include proactive measures against malware, ransomware and advanced threats, and Control 5.3.1.4 requires quarterly checks against those standards together with continuous monitoring.

Having these solutions in place does not prove that they protect against and detect cyber threats. Configuration changes, policy updates and even small changes in the environment can stop them from working as intended. Threats also change, so new prevention signatures and detection rules must be added to these tools continuously. That is why each solution needs to be tested regularly to confirm it still works.

How does Picus support these requirements?

Picus Breach and Attack Simulation safely runs attack simulations against each layer of the security stack, including next-generation firewalls, IPS, web application firewalls, secure web gateways, email gateways and endpoint controls. For every action, it records whether the action was blocked, detected, logged only or missed, so the team can see exactly which device let which attack through.

Figure 4. Picus Breach and Attack Simulation prevention and detection results across the security stack.

Simulations come from the Picus Threat Library, which contains a broad set of attack techniques and threat scenarios, including malware, ransomware and advanced threat actor campaigns, mapped to MITRE ATT&CK. Picus Labs adds critical emerging threats with a public proof of concept (PoC) within 24 hours, so the bank's defenses are tested against the attacks currently in circulation.

Figure 5. Picus Threat Library, updated continuously by Picus Labs.

When a layer misses an attack, the Picus Mitigation Library provides ready-to-apply vendor-specific and vendor-neutral prevention signatures and detection rules. After the fix is applied, the same attack is run again to confirm the control now stops or detects it.

Figure 6. Picus Mitigation Library with ready-to-deploy vendor-specific and vendor-neutral fixes.

Attack simulations run after changes, such as a firewall policy update or a newly emerging threat, so control effectiveness is measured continuously between the quarterly checks that 5.3.1.4 requires. When a prevention or detection score drops, the team sees the drift soon after it happens and can trace it to the control that weakened.

The Regulated Entity can then show prevention, logging and detection scores for the network security solutions it relies on, and make sure they are working as intended.

CORF 4.1.1.5 and 5.13.1.8: Board Updates on Emerging Threats and Vulnerability Management

The CORF holds the Board ultimately accountable for cyber resilience. Under 4.1.1.5, the Board receives regular updates and additional updates whenever an emerging threat or a significant change in the risk landscape appears.

When a major campaign hits the news, Board members ask one simple question: are we protected? The usual answer is a summary of the threat and a reassurance that controls are in place. That answer does not show how the bank's own defenses would perform against it.

Alongside updates on emerging threats, the Board receives a regular report on vulnerability management. Control 5.13.1.8 sets the pace at every quarter and asks for key metrics and unresolved issues, with the focus on how effective the process is.

Most security reports count activity, such as scans run, patches deployed and tickets closed. Those numbers can rise while the share of attacks the bank actually stops stays flat, so they cannot tell the Board whether risk is inside the appetite it approved.

How does Picus support CORF Board reporting?

On its first day of deployment, Picus Breach and Attack Simulation measures control effectiveness as a number: the share of attack techniques the environment prevents, the share it logs and the share it detects, per control and per security layer. That first run becomes the baseline, and every run after it adds a data point, so the Board sees a trend.

Picus Labs continuously updates the Picus Threat Library as the risk landscape changes, for example when a vulnerability starts being exploited in the wild or a new ransomware campaign targets financial institutions. The bank can run each new threat against its own controls and see which stages are blocked, detected or missed.

Picus Exposure Validation turns each validated exposure into one decision (Patch, Mitigate, Monitor, or Accept with Evidence), with an owner and a verified re-test. These decisions put evidence behind every number in the quarterly report. They show which exposures were found, how each one was treated and which fixes were proven to work, along with the unresolved issues 5.13.1.8 asks the Board to see.

The Steering Committee can then bring the Board a tested answer, with the gaps found and the fixes already applied. The Report Center exports the result so it can go directly into the Board pack.

The Board can then compare one quarter with the next and see, in measured terms, whether the bank is getting harder to attack.

CORF 4.4.1.1: Independent Audit of Control Effectiveness

Under sub-domain 4.4, high-risk areas must be audited at least once a year, CORF audits are carried out by an independent third-party auditor approved by CBK, and audit findings reach the Board through a quarterly dashboard. Control 4.4.1.1 requires these audits to evaluate both implementation and effectiveness.

Effectiveness is hard to judge from documents. Auditors work within a fixed window, sample a set of controls and rely on interviews and screenshots.

Third-party auditors must also be changed at least once every two years (Control Area 4.4.3), so a new team often starts without the history of earlier engagements.

How does Picus support CORF 4.4.1.1?

Picus keeps a time-stamped history of every test, the result per control, the decision taken on each gap and the re-test that closed it. An auditor can review how controls performed across the whole audit period.

Because this history stays with the bank, it also carries over when the audit firm changes. Results can be exported from the Report Center and attached to evidence requests, and the same data can feed the quarterly audit dashboard the Board receives.

CORF Toolkit: Level 4 and Level 5 Maturity for Cybersecurity Testing and Threat Management

The CORF Toolkit rates every sub-domain from Level 1 (Initial) to Level 5 (Innovative), and each level counts only when the one below it is fully achieved.

For the Cybersecurity Testing and Threat Management sub-domain (5.13), Level 4 (Advanced) and Level 5 (Innovative) describe a testing program that runs continuously, follows real adversary behavior and feeds its results straight into detection and risk decisions.

Most testing programs reach Level 3 with annual penetration tests, periodic vulnerability scans and findings tracked to closure. Moving higher requires automated, continuous and threat-led validation, which periodic manual testing cannot provide at the pace the environment and the threat landscape change.

How does Picus support CORF Level 4 and Level 5 maturity?

At Level 4, the Toolkit expects simulated attacks, such as phishing and lateral movement, to assess detection and response readiness, and Breach and Attack Simulation (BAS) tools to validate defensive control effectiveness continuously. This is exactly what Picus Breach and Attack Simulation does. It runs these attacks continuously, after every change, and shows which steps are blocked, detected or missed, with prevention, logging and detection scores for every tested control.

Level 4 also expects threat exposure to be prioritized by asset criticality, threat actor TTPs mapped to MITRE ATT&CK, and business impact. The Picus Exposure Score and Business Scopes rank exposures on exactly these factors. Test results should also inform tuning of SIEM, EDR and incident playbooks, and the Picus Mitigation Library turns each failed test into a specific prevention signature or detection rule, and Detection Rule Validation provides insights into which SIEM rules need tuning.

At Level 5, the Toolkit describes a continuous threat exposure management (CTEM) program that aligns testing, detection and risk mitigation. The Picus Autonomous Exposure Validation Platform runs the five CTEM phases as one loop, in three stages: Sense, Validate and Act.

Figure 7. The Picus Autonomous Exposure Validation Platform runs the CTEM loop in three stages: Sense, Validate and Act.

Sense covers scoping, discovery and prioritization, the first three CTEM phases. Picus connects to the bank's security stack and brings assets, exposures, identities, security controls, threats and earlier validation evidence into a single data fabric. From this data, it produces a prioritized list of exposures with their business context.

Validate is the fourth CTEM phase. Breach and Attack Simulation, Exposure Validation and Autonomous Penetration Testing work on one shared findings model that is deduplicated, evidence-backed and asset-aware. Numi AI orchestrates the five Swarm agents (Discovery, Exploitation, Validation, Mobilization and Reporting) and sends validated exposures and their evidence back into the data fabric.

Act is the fifth CTEM phase, mobilization. Proven findings and remediation guidance flow to ticketing and SOAR tools, to prevention controls as new signatures and policies, to detection tools as new rules, and to systems as hardening steps. When no patch exists yet, prevention and detection controls still mitigate the proven exposure. After every fix, a revalidation request goes back to the Validate stage, so each exposure is closed only on proof.

Get Ready for Your Next CORF Assessment Today

The CORF makes CBK's expectations clear. It requires penetration testing, red teaming and resilience testing that react to change, network defenses that protect against and detect threats, SIEM-based monitoring, risk-based vulnerability management, threat intelligence that leads to action, and risk treatment backed by proof that controls work. It rates every requirement on verifiable evidence, and its maturity model names continuous validation as a mark of an advanced program.

Picus helps Regulated Entities meet these expectations today. Autonomous Penetration Testing chains weaknesses and exploits into attack paths to show how far an attacker can get inside the network. Breach and Attack Simulation and Detection Rule Validation show whether prevention and detection controls hold. Exposure Validation proves exploitability even on systems too critical to test live. Together, they show which exposures put customer data and financial services at real risk, so teams fix what matters first, and every result is stored as a record of what was tested, what failed and how it was fixed.

Timing matters as well. Tier 1 entities face a CORF assessment every year, and maturity is judged on how consistently a capability performs. A bank that starts validating now will reach its next assessment with months of measured results behind it.

Get a demo to see how Picus proves which exposures attackers can exploit and which attacks your defenses stop, so your next CBK assessment rests on tested evidence.

References

[1] Central Bank of Kuwait, "Cyber and Operational Resilience Framework for All Local Banks and Financial Institutions," Version 1.0, Dec. 3, 2025. Accessed: Nov. 2, 2026. [Online]. Available: https://www.cbk.gov.kw/en/supervision/cyber_operational_resilience_framework