Penetration testing has become a routine compliance exercise at most Saudi banks and fintechs. An external firm scans for vulnerabilities, attempts to exploit a handful, documents findings, and delivers a report. The institution remediates critical issues, files the report with the audit committee, and considers the SAMA CSF red team testing requirements satisfied for another year.
The problem is that this approach tests only preventive controls—firewalls, patch levels, access controls—and never answers the question Domain 6 actually asks: can your security operations centre detect an attack in progress, can your incident response team contain it before impact, and can your people execute the processes you have documented?
SAMA Cybersecurity Framework Domain 6 establishes requirements for testing not just whether vulnerabilities exist, but whether your detection and response capabilities function when an adversary pursues realistic objectives inside your environment. Controls 6.3.1 through 6.3.4 require testing that simulates how a determined attacker actually operates: gaining initial access, moving laterally to valuable systems, escalating privileges, and exfiltrating or manipulating data.
This article explains the four adversary objectives that a red-team engagement must pursue to prove your defences work, and how to structure the rules of engagement so the exercise tests detection and response rather than simply cataloguing vulnerabilities.
The Gap Between Penetration Testing and Red Teaming
Traditional penetration testing follows a vulnerability-centric model. The tester identifies as many weaknesses as possible within the agreed scope, attempts exploitation where safe, and reports every finding regardless of whether an attacker would actually use it to achieve a business-impacting objective.
This approach serves an important purpose—it helps you prioritize patching and harden preventive controls—but it does not test the capabilities SAMA CSF Domain 6 requires you to maintain. A vulnerability scan tells you whether a patch is missing. It does not tell you whether your SIEM will generate an alert when someone exploits that vulnerability at two in the morning, whether the SOC analyst on duty will recognize the alert as a genuine threat, whether the incident response team can isolate the affected system before the attacker pivots to the core banking platform, or whether your executives will be notified within the timeframes your policy specifies.
Red teaming operates from the opposite direction. Instead of finding every possible weakness, the red team pursues specific objectives that mirror what a real attacker wants—access to customer data, compromise of a payment system, deployment of ransomware—and uses only the techniques necessary to achieve those objectives without being detected or stopped. The test succeeds when the red team reaches the objective. It fails when your defences detect and contain the attack before impact.
This objective-driven approach directly tests the capabilities described in SAMA CSF Domain 6: intrusion detection, security monitoring, incident response, and the coordination between technology, process, and people that must function together under pressure.
Four Adversary Objectives That Test Detection and Response
A red-team engagement structured to meet SAMA CSF requirements should pursue four objectives in sequence, each designed to test a different layer of your detection and response capability.
1. Initial Access
The first objective tests whether your defences detect an attacker's entry into your environment. Initial access techniques include spear-phishing, exploitation of internet-facing applications, compromise of third-party connections, or credential stuffing against exposed services.
The red team attempts to establish a foothold—typically a command-and-control channel from a workstation or server inside your network perimeter—using techniques that real threat actors employ against financial institutions. The question is not whether your firewall blocks the attempt, but whether your email security gateway, endpoint detection and response tools, or network monitoring systems generate an alert, whether that alert reaches a human analyst, and whether the analyst investigates and escalates appropriately.
Many institutions discover during this phase that their SIEM generates the correct log entries but no alert rule exists to surface them, or that alerts are firing but being dismissed as false positives, or that the SOC has no documented procedure for investigating this category of event.
2. Lateral Movement
Once initial access is achieved—or simulated as achieved, if your rules of engagement allow the red team to assume a foothold—the second objective tests whether your defences detect an attacker moving from the initial compromise point toward higher-value systems.
Lateral movement techniques include pass-the-hash attacks, exploitation of trust relationships between systems, abuse of legitimate administrative tools, and reconnaissance activities such as network scanning or Active Directory enumeration. A real attacker does not remain on the first workstation they compromise; they map your environment, identify where valuable data resides, and move toward it.
This phase tests whether your network segmentation actually limits an attacker's movement, whether your monitoring tools detect anomalous authentication patterns or unusual use of administrative protocols, and whether your SOC recognizes the pattern of behaviour that indicates an active intrusion rather than a single isolated event.
Institutions often learn that their network is flat, that domain administrator credentials are cached on workstations, or that their SIEM correlates events from individual systems but does not surface the multi-step pattern that reveals lateral movement in progress.
3. Privilege Escalation
The third objective tests whether your defences detect an attacker gaining administrative control over critical systems. Privilege escalation techniques include exploiting misconfigurations, abusing delegation relationships, cracking or stealing credentials, and leveraging vulnerabilities in operating systems or applications.
An attacker who reaches a database server or domain controller with standard user privileges will attempt to gain administrative access so they can disable logging, access protected data, or persist in your environment. This phase tests whether your privileged access management controls function, whether your monitoring detects unauthorized elevation of privileges, and whether your incident response procedures include immediate containment actions when such activity is observed.
Many institutions discover that local administrator passwords are identical across systems, that service accounts have unnecessary privileges, or that no alerting exists for sensitive operations such as adding a user to the Domain Admins group.
4. Data Exfiltration or Impact
The final objective tests whether your defences detect and prevent the attacker achieving their ultimate goal: stealing data, manipulating transactions, deploying ransomware, or causing another form of business impact.
Data exfiltration techniques include uploading files to external cloud storage, using DNS tunneling or other covert channels, or simply emailing data to an external address. Impact techniques include encrypting systems, deleting backups, or altering transaction records. The red team attempts the action that would constitute a reportable incident under SAMA regulations.
This phase tests whether your data loss prevention tools function, whether your network monitoring detects large or unusual outbound transfers, whether your backup integrity checks would reveal tampering, and whether your incident response team can execute containment and recovery procedures under realistic conditions.
Institutions often find that their DLP policies are in monitor mode rather than enforcement mode, that outbound traffic is not inspected with the same rigor as inbound traffic, or that their incident response plan has never been tested against a scenario where the attacker already has administrative access to critical systems.
Structuring Rules of Engagement to Test Detection
The value of a red-team engagement depends entirely on how the rules of engagement are structured. If the red team must notify you before each phase, or if the SOC is told that an exercise is underway, you are testing your controls in laboratory conditions rather than realistic ones.
SAMA CSF Domain 6 requires testing that reflects how your defences will perform during an actual incident. This means the rules of engagement should include several elements:
Defined objectives that mirror real attacker goals relevant to your institution—access to customer account data, compromise of the payment processing environment, or deployment of ransomware on critical infrastructure.
Realistic scope that includes the attack surface an external attacker would see—your internet-facing applications, email, and any third-party connections—as well as the internal environment where lateral movement and privilege escalation occur.
Limited notification to a small group—typically the CISO and one executive sponsor—while the SOC, incident response team, and broader IT staff operate without knowledge that an exercise is underway.
Clear boundaries that prevent business disruption, such as prohibiting actions that would trigger account lockouts for real customers, corrupt production data, or take critical systems offline.
Emergency stop procedures that allow the red team to halt immediately if they observe that their activity is about to cause unintended impact, or if a real security incident occurs during the exercise.
Purple-team replay after the engagement concludes, where the red team and your defenders review the attack timeline together, examine which actions were detected and which were not, and identify specific improvements to tools, rules, and processes.
The goal is not to trick your team or to prove they are incompetent. The goal is to create realistic conditions under which you can measure the true performance of your detection and response capabilities and identify gaps before a real attacker exploits them.
Mapping Red-Team Objectives to SAMA CSF Controls 6.3.1 Through 6.3.4
SAMA CSF Domain 6 includes several controls related to testing. While the specific numbering of controls 6.3.1 through 6.3.4 addresses various aspects of security testing and validation, the underlying requirement is clear: institutions must test not only whether preventive controls are in place, but whether detective and responsive controls function effectively.
A red-team engagement structured around the four objectives described above provides evidence that:
Your intrusion detection systems generate alerts when an attacker gains initial access and moves laterally, satisfying requirements for monitoring and detection capabilities.
Your security operations centre identifies suspicious activity, investigates alerts, and escalates genuine threats, satisfying requirements for security monitoring processes.
Your incident response team can contain an active intrusion, preserve evidence, and execute recovery procedures, satisfying requirements for incident management capabilities.
Your coordination between teams—SOC, incident response, IT operations, and management—functions under pressure, satisfying requirements for organizational readiness.
The red-team report provides objective evidence of these capabilities for your board, for internal audit, and for SAMA supervisory reviews. More importantly, it provides your security team with specific, actionable findings about which detection rules need tuning, which response procedures need revision, and which skills need development.
How Red Teaming Differs From Routine Penetration Testing
Most institutions already conduct annual penetration testing to satisfy various regulatory and compliance requirements. Adding a red-team engagement does not replace that testing; it complements it by testing a different set of controls.
Standard penetration testing remains valuable for identifying vulnerabilities in applications, misconfigurations in infrastructure, and weaknesses in preventive controls. It should continue as part of your annual testing program.
Red teaming tests whether your organization can detect and respond to an attacker who has already bypassed some preventive controls and is pursuing a specific objective inside your environment. It reveals whether your detection tools are configured correctly, whether your SOC can distinguish genuine threats from noise, and whether your incident response procedures work in practice.
The two types of testing provide complementary evidence. Penetration testing shows that you are reducing your attack surface. Red teaming shows that you can defend the attack surface that remains.
A Practical Approach to Red Teaming for SAMA CSF Compliance
Institutions planning their first red-team engagement, or seeking to improve the quality of existing testing, should consider several practical steps:
Begin with clear objectives. Work with your red-team provider to define objectives that reflect realistic threats to your institution—compromise of the core banking system, exfiltration of customer data, or deployment of ransomware—rather than generic objectives that do not test your most critical defences.
Establish realistic rules of engagement. Limit notification to a small group, allow the red team to use social engineering if that reflects how real attackers would target your institution, and ensure the SOC operates without knowledge of the exercise.
Plan the purple-team replay. Schedule time after the engagement for the red team and your defenders to review the attack timeline together. This joint session often provides more value than the written report, because it allows your team to ask questions, understand attacker techniques, and identify specific improvements.
Integrate findings into your improvement program. Red-team findings should feed directly into your SIEM tuning, SOC training, incident response plan updates, and architecture remediation efforts. The goal is not to generate a report; the goal is to improve your defences before a real attacker tests them.
Repeat the exercise. A single red-team engagement provides a snapshot of your capabilities at one point in time. Annual or biennial testing allows you to measure improvement, test new defences, and ensure that changes to your environment have not introduced new detection gaps.
Closing: Testing Detection and Response Under Realistic Conditions
SAMA CSF Domain 6 requires financial institutions to maintain effective detection and response capabilities, and to test those capabilities regularly. Most institutions test their preventive controls thoroughly but never test whether their SOC, SIEM, and incident response team can actually detect and contain an attack in progress.
A red-team engagement structured around four adversary objectives—initial access, lateral movement, privilege escalation, and data exfiltration—provides objective evidence of your detection and response capabilities under realistic conditions. It reveals which alerts fire, which are missed, and which are ignored. It tests whether your people execute the processes you have documented. It identifies specific improvements that will reduce the time between compromise and containment when a real incident occurs.
We simulate a determined attacker pursuing agreed objectives—from initial access to impact—to test your people, processes and technology end to end, providing a way to test detection and response against a realistic, objective-driven attack. The engagement follows a structured process: plan objectives, scope and rules of engagement; conduct reconnaissance and intelligence gathering on the attack surface; execute a controlled attack toward objectives; and replay the attack jointly with defenders and deliver a report. Deliverables include an executive summary for the board, technical attack narrative, detection and response gap analysis, and improvement roadmap. Engagements are structured around threat-informed scenarios, an objective-based attack chain, optional social engineering, strict rules of engagement, and purple-team replay with defenders, and typically require four to eight weeks to complete.
If your institution is planning its annual testing program and needs to satisfy SAMA CSF requirements for testing detection and response capabilities, a properly structured red-team engagement provides evidence that your defences work and a roadmap for making them better.
