# SAMA CSF Domain 8: The Three Attack Scenarios Every Red-Team Engagement Must Simulate
The Saudi Central Bank (SAMA) Cyber Security Framework Domain 8 establishes requirements for testing the effectiveness of detection, response and recovery capabilities under realistic attack conditions. Yet most red-team engagements procured by SAMA-regulated institutions fail to meet the SAMA CSF red team requirements because they test for vulnerabilities rather than adversary objectives.
The difference is not semantic. A penetration test identifies exploitable weaknesses in systems. A red-team exercise simulates a determined attacker pursuing specific objectives—initial access, lateral movement to critical assets, and data exfiltration or operational disruption—to test whether your people, processes and technology can detect, respond to and recover from a realistic attack chain. Controls 8.1, 8.2 and 8.3 in Domain 8 require precisely this end-to-end validation, and the statement of work for your next red-team engagement must reflect it.
This article explains which three attack scenarios map to these controls, why most scopes fall short, and how to write a red-team statement of work that tests what SAMA expects you to test.
What Domain 8 Actually Requires
SAMA CSF Domain 8 addresses security testing and assurance. It requires regulated institutions to conduct regular testing of security controls, including penetration testing and red-team exercises, to validate the effectiveness of detective, preventive and corrective measures.
Controls 8.1, 8.2 and 8.3 build on one another:
Control 8.1 requires testing of technical security controls—firewalls, intrusion detection systems, endpoint protection, access controls—to confirm they function as designed.
Control 8.2 requires testing of detection and response capabilities, including the ability of security operations teams to identify, triage and contain an active threat.
Control 8.3 requires testing of recovery processes, including incident response plans, business continuity arrangements and communication protocols under stress.
Together, these controls demand more than a list of vulnerabilities. They require evidence that your institution can detect an attacker who has bypassed perimeter defences, respond effectively as the attacker moves toward critical systems, and recover operations if the attacker achieves impact.
A traditional penetration test satisfies 8.1. Only a red-team exercise satisfies 8.2 and 8.3.
Why Most Red-Team Scopes Miss the Mark
The majority of red-team statements of work we review contain one or more of the following gaps:
No clear adversary objective. The scope lists activities—phishing, network scanning, privilege escalation—but does not define what the simulated attacker is trying to achieve. Without an objective, there is no meaningful test of detection or response.
No social engineering component. Many scopes exclude phishing and pretexting because institutions fear operational disruption. Yet initial access via social engineering is the most common attack vector against financial institutions, and excluding it means you never test whether your users report suspicious messages or whether your SOC correlates a credential compromise with subsequent lateral movement.
No purple-team replay. The red team delivers a report, the blue team reads it, and no one discusses why detections failed or how response could improve. The learning opportunity is lost.
No test of recovery. The engagement ends when the red team demonstrates access to a critical system. There is no simulation of data exfiltration, no activation of incident response, and no test of whether the institution can restore operations under pressure.
These gaps exist because many institutions treat red-teaming as an advanced penetration test rather than an adversary simulation. The result is a report that satisfies a compliance checkbox but provides little assurance to the board or the regulator.
The Three Attack Scenarios That Map to Controls 8.1, 8.2 and 8.3
A red-team engagement that meets SAMA CSF Domain 8 requirements must simulate three sequential scenarios, each testing a different layer of your defences.
Scenario One: Initial Access via Social Engineering (Testing Control 8.1 and 8.2)
The red team attempts to gain initial access to the institution's environment using the same techniques a real attacker would employ—spear phishing, credential harvesting, exploitation of public-facing applications, or physical pretexting.
This scenario tests:
- Whether users recognize and report phishing attempts.
- Whether email security controls block malicious payloads.
- Whether endpoint detection and response tools identify suspicious execution.
- Whether the SOC detects anomalous authentication patterns or command-and-control traffic.
The objective is not to count how many users click a link. The objective is to determine whether a successful compromise triggers an alert, an investigation and a containment action before the attacker proceeds to the next stage.
Scenario Two: Lateral Movement to Critical Assets (Testing Control 8.2)
Once initial access is achieved, the red team moves laterally through the network toward a predefined critical asset—a core banking system, a customer database, a payment switch, or a domain controller.
This scenario tests:
- Whether network segmentation limits the attacker's ability to pivot.
- Whether privileged access management controls prevent credential theft.
- Whether the SOC detects reconnaissance, privilege escalation or abnormal access to sensitive systems.
- Whether the incident response team can contain the attacker before critical assets are reached.
The red team operates under strict rules of engagement to avoid operational impact, but the simulation must be realistic enough to generate the same alerts and decisions that a real intrusion would trigger.
Scenario Three: Data Exfiltration or Operational Disruption (Testing Control 8.3)
The final scenario simulates the attacker achieving their objective—exfiltrating sensitive data, deploying ransomware, or disrupting a critical business process—and tests whether the institution can detect the impact, activate incident response, contain the damage and recover operations.
This scenario tests:
- Whether data loss prevention controls detect exfiltration attempts.
- Whether the incident response plan is activated and followed.
- Whether communication protocols function under stress.
- Whether business continuity arrangements allow recovery within acceptable timeframes.
In practice, the red team does not exfiltrate real data or disrupt real operations. Instead, the engagement includes a tabletop exercise or controlled simulation in which the institution's response team works through the scenario step by step, demonstrating how they would respond if the attack were real.
How to Write a Red-Team Statement of Work That Meets SAMA Expectations
A compliant red-team statement of work must include the following elements:
Defined adversary objective. Specify what the simulated attacker is trying to achieve—access to a named system, exfiltration of a particular data type, or disruption of a specific process. The objective must be realistic and aligned to the institution's risk profile.
Agreed scope and rules of engagement. Define which systems are in scope, which are excluded, and what actions require prior approval. Rules of engagement must balance realism with operational safety.
Social engineering component. Include phishing, vishing or physical pretexting as an optional or required element, with clear boundaries to avoid disruption.
Purple-team replay. Require a joint session in which the red team and blue team review the attack chain, discuss why detections succeeded or failed, and identify improvements to people, process and technology.
Test of recovery. Include a tabletop exercise or controlled simulation of the institution's response to impact, testing incident response, business continuity and communication under realistic conditions.
Deliverables aligned to SAMA expectations. Require an executive summary for the board, a technical attack narrative, a detection and response gap analysis, and an improvement roadmap—not merely a list of vulnerabilities.
The Usual Gaps and a Sensible Order of Work
Institutions often procure red-team services before they are ready. The usual gaps include:
- No baseline security monitoring. If the SOC cannot detect a port scan, a red-team exercise will produce a long list of missed detections and little actionable insight.
- No documented incident response plan. Testing response without a plan in place is an expensive way to discover that no one knows what to do.
- No recent penetration test. A red-team exercise is not a substitute for regular vulnerability assessment. If basic hygiene issues remain unaddressed, the red team will exploit them immediately and the exercise will end before testing detection or response.
A sensible order of work is:
- Conduct regular penetration testing to identify and remediate exploitable vulnerabilities.
- Establish baseline security monitoring and a documented incident response plan.
- Procure a red-team exercise to test detection, response and recovery under realistic attack conditions.
- Use the gap analysis to improve controls, then repeat the cycle.
How We Deliver Red-Team Engagements That Meet SAMA CSF Domain 8 Requirements
We simulate a determined attacker pursuing agreed objectives—from initial access to impact—to test your people, processes and technology end to end.
Our approach follows four phases: Plan, where we define objectives, scope and rules of engagement; Recon, where we gather intelligence on the attack surface; Execute, where we conduct a controlled attack toward objectives; and Replay, where we conduct a joint review with defenders and deliver a report.
Deliverables include an executive summary for the board, a technical attack narrative, a detection and response gap analysis, and an improvement roadmap.
Engagements include threat-informed scenarios, an objective-based attack chain, social engineering as an optional component, strict rules of engagement, and a purple-team replay with defenders. The typical duration is four to eight weeks.
The service is designed to meet SAMA CSF requirements and provide the evidence your board and your regulator expect—not merely a penetration test report, but a realistic assessment of whether your institution can detect, respond to and recover from a determined attack.
Closing
If your institution is planning or procuring a red-team exercise to meet SAMA CSF Domain 8 requirements, the statement of work must test detection, response and recovery across three realistic attack scenarios—initial access, lateral movement and exfiltration or disruption. Most scopes fall short because they test vulnerabilities rather than adversary objectives. A compliant engagement requires defined objectives, strict rules of engagement, social engineering, purple-team replay and a test of recovery—delivered by a team that understands what SAMA expects and how to provide the assurance your board requires.
To discuss how we design and deliver red-team engagements that meet SAMA CSF Domain 8 controls 8.1, 8.2 and 8.3, contact us to review your current scope or plan your next exercise.
