Frequently Asked Questions
Find answers to your questions about cybersecurity and the CISO Consulting platform
Who must comply with the SAMA Cybersecurity Framework?
All financial institutions regulated by the Saudi Arabian Monetary Authority (SAMA) must comply, including commercial ba…
What is the NCA ECC and who does it apply to?
The NCA Essential Cybersecurity Controls (ECC) is a mandatory framework issued by the National Cybersecurity Authority o…
When did the Saudi PDPL come into effect?
The Saudi Personal Data Protection Law (PDPL) was enacted by Royal Decree in September 2021 and officially entered into…
What is a vCISO and when does an organization need one?
A Virtual CISO (vCISO) is an experienced cybersecurity executive who provides strategic leadership on a fractional or co…
General 1
CyberPulse KSA is Saudi Arabia's premier cybersecurity intelligence platform featuring a podcast, threat intelligence feeds, and the latest cybersecurity news relevant to the Saudi market.
Cybersecurity 21
We cover all major Saudi cybersecurity frameworks including NCA Essential Cybersecurity Controls (ECC), SAMA Cybersecurity Framework (CSF), Saudi Personal Data Protection Law (PDPL), and NCA Cloud Computing Regulatory Framework (CCRF).
A Security Operations Centre (SOC) is a centralized team responsible for monitoring, detecting, and responding to cybersecurity threats in real time. Both SAMA CSF and NCA ECC require 24/7 security monitoring for regulated entities. Organizations can establish an in-house SOC, use a Managed SOC (MSOC) provider, or a hybrid model depending on budget, size, and risk profile.
Building a cybersecurity program in KSA involves: (1) Identify applicable frameworks (SAMA CSF, NCA ECC, PDPL based on sector); (2) Conduct a baseline risk assessment and gap analysis; (3) Define governance structure and appoint a CISO or vCISO; (4) Develop policies and procedures aligned to the framework; (5) Implement technical controls (IAM, endpoint security, monitoring); (6) Build or outsource SOC capabilities; (7) Train staff; (8) Conduct annual assessments and report to regulators.
Identity and Access Management (IAM) is one of the most scrutinized control domains during both SAMA and NCA regulatory assessments. Below are the mandatory and recommended controls:
SAMA CSF Requirements (Controls 3.2.x – Access Management):
- Implement a formal access provisioning and de-provisioning process with documented approvals.
- Enforce least-privilege and need-to-know principles across all systems.
- Privileged Access Management (PAM): All privileged accounts (domain admins, DBAs, system admins) must be inventoried, managed via a PAM solution, and subject to enhanced monitoring.
- Multi-Factor Authentication (MFA): SAMA mandates MFA for all remote access, privileged accounts, and customer-facing digital banking services.
- Periodic Access Reviews: Conduct quarterly access reviews for privileged users and semi-annual reviews for standard users. Certify and revoke unnecessary access promptly.
NCA ECC Controls (ECC-2: Protection and Defense):
- ECC Article 2-6 requires organizations to implement role-based access control (RBAC) and ensure separation of duties for sensitive functions.
- Session management controls, automatic timeouts, and logging of all privileged sessions are explicitly required.
Practical Recommendations:
- Deploy a centralized Identity Governance and Administration (IGA) platform to automate access lifecycle management.
- Integrate your IAM solution with your SIEM for real-time anomaly detection on account behavior.
- Ensure service accounts and API credentials are managed with the same rigor as human identities — a common audit gap.
- Document your IAM policy and review it annually or after significant organizational changes.
Strong IAM is foundational to achieving compliance across SAMA CSF, NCA ECC, and ISO 27001 Annex A Control 9.
A well-structured Incident Response Plan (IRP) is not optional for Saudi financial institutions — it is a regulatory requirement with defined timelines and reporting obligations. Here is how to build and operationalize one that satisfies SAMA CSF Domain 3.5 and NCA ECC Control 2-14.
Plan Structure (6 Phases):
- Preparation: Define incident categories (per SAMA's severity classification: Critical, High, Medium, Low), establish an Incident Response Team (IRT) with clear roles, and maintain an updated asset inventory.
- Identification: Deploy SIEM and EDR tools to detect anomalies. Define what constitutes a reportable incident under SAMA and NCA guidelines.
- Containment: Isolate affected systems immediately. Document all actions with timestamps for regulatory evidence.
- Eradication & Recovery: Remove threat vectors, restore from verified clean backups, and validate system integrity before resuming operations.
- Post-Incident Review: Conduct a Root Cause Analysis (RCA) within 15 days of resolution and update the IRP accordingly.
- Reporting: This is the most regulated phase.
Regulatory Reporting Timelines:
- SAMA CSF Control 3.5.4: Critical incidents must be reported to SAMA within 72 hours of detection.
- NCA ECC Control 2-14: Significant cybersecurity incidents must be reported to NCA's National Cybersecurity Operations Center (NCOC) within 24 hours.
- PDPL Article 29: Personal data breaches must be reported to SDAIA within 72 hours.
Practical Tips: Conduct tabletop exercises at least twice a year. Ensure your IRP is tested, board-approved, and reviewed annually. Appoint a dedicated incident response coordinator and maintain a 24/7 escalation matrix to avoid response delays during off-hours incidents.
Both SAMA CSF (Domain 3 — Cyber Resilience) and NCA ECC (Article 3-7) mandate that organizations maintain a documented, tested, and regularly updated Cyber Incident Response Plan (CIRP). Regulators expect much more than a paper policy — they want evidence of operational readiness.
CIRP Structure Requirements: Your plan must define six phases aligned with NIST SP 800-61: Preparation, Identification, Containment, Eradication, Recovery, and Lessons Learned. It must assign specific roles — Incident Commander, Technical Lead, Legal/Compliance Officer, Communications Lead — with named alternates.
SAMA-Specific Obligations: SAMA CSF Control 3.3.3 requires banks to report material cyber incidents to SAMA within 72 hours of detection. Your CIRP must include pre-approved communication templates for regulators, customers, and media.
NCA Reporting: Per NCA ECC Article 3-7, organizations must report significant incidents to the National Cybersecurity Authority. Integrating NCA's reporting portal (CCC Platform) into your CIRP workflow is essential.
Testing Requirements: Conduct at minimum:
- Tabletop exercises quarterly — simulate scenarios like ransomware, insider threat, or data breach
- Functional drills semi-annually — test actual technical response procedures
- Full simulation annually — involves all stakeholders including executive management
Document all exercise outcomes, gaps identified, and remediation actions. SAMA examiners will request this evidence during assessments.
Practical Tip: Map your incident classification levels (P1–P4) to regulatory thresholds so your team automatically knows when regulatory notification obligations are triggered, removing ambiguity during a high-stress incident.
Security awareness training is a mandatory SAMA CSF requirement under Control Domain 3.3.6, and many Saudi banks treat it as a checkbox activity rather than a strategic risk reduction program. Here is how to build it properly:
SAMA CSF Baseline Requirements SAMA CSF Control 3.3.6 mandates that all employees, contractors, and third parties with access to organizational systems receive role-based cybersecurity awareness training. Training must be:
- Delivered at onboarding and at least annually thereafter
- Role-specific (general staff vs. IT vs. privileged users)
- Documented with completion records for audit purposes
Recommended Program Structure
Tier 1 – All Staff: Phishing awareness, social engineering, password hygiene, PDPL obligations for staff handling personal data, and physical security (clean desk, tailgating).
Tier 2 – Technical Staff: Secure coding (OWASP Top 10), cloud security basics, incident reporting procedures, and NCA ECC control awareness.
Tier 3 – Executives and Board: Cyber risk governance, regulatory liability under SAMA and NCA, and crisis communication during cyber incidents.
Phishing Simulation Run quarterly simulated phishing campaigns. Track click rates and report-rates as KPIs. SAMA CSF expects measurable evidence of awareness effectiveness.
Arabic-Language Content Ensure core modules are available in Arabic. Saudi regulators expect culturally relevant materials, not direct translations of Western content.
Metrics and Reporting Report training completion rates, phishing simulation results, and awareness assessment scores to the CISO and Board Audit Committee quarterly. Link these metrics to your cybersecurity risk dashboard per SAMA CSF Control 3.1.2 (Cybersecurity Risk Management).
Aligning your program with NIST SP 800-50 provides a recognized international methodology to complement SAMA requirements.
Security awareness training is far more than an annual checkbox — it is a regulatory requirement with specific expectations under both SAMA CSF and NCA ECC.
Regulatory Foundation SAMA CSF Control Domain 3.2 explicitly requires that all staff receive role-based cybersecurity awareness training at least annually. NCA ECC Article 2-5 further mandates a documented awareness program covering phishing, social engineering, password hygiene, and acceptable use policies.
Program Design Principles
Role-Based Curriculum: Do not deliver generic training. Design separate tracks for: (a) General staff — covering phishing, password management, and data handling; (b) IT and security teams — covering threat response, secure coding, and vulnerability management; (c) Executives and board members — covering cyber risk governance, regulatory obligations, and incident escalation.
Training Frequency & Formats Beyond annual mandatory training, implement monthly micro-learning modules (5–10 minutes), quarterly phishing simulations with failure-rate tracking, and real-time teachable moments triggered by security incidents.
Phishing Simulation Program Conduct simulated phishing campaigns at least quarterly. Track click rates, credential submission rates, and report rates. Per SAMA CSF guidelines, persistent high-risk users should receive targeted remediation training within 5 business days of a failed simulation.
Metrics & Reporting Maintain training completion records in your GRC platform. Key metrics to report to senior management include: completion rate (target: 95%+), phishing simulation failure rate (target: below 5%), and number of self-reported phishing emails. These metrics should feed into your quarterly cybersecurity risk dashboard.
Localization Ensure all training content is available in Arabic. Saudi regulators expect culturally appropriate, locally relevant content — not generic translated modules.
Security Awareness Training is not an optional best practice — it is an explicit regulatory obligation. SAMA CSF Control 3.4.1 requires organizations to establish a cybersecurity awareness and training program, while NCA ECC Domain 2-5 mandates ongoing staff education tailored to roles and risk exposure.
Building a compliant and effective SAT program:
1. Governance Foundation: Assign ownership (typically CISO or HR jointly), secure executive sponsorship, and document the program in a formal policy reviewed annually. Board members and senior leadership must be included — SAMA CSF explicitly expects awareness at all organizational levels.
2. Role-Based Training Tracks: Do not deliver generic training to all staff. Segment your audience:
- General staff: Phishing recognition, password hygiene, social engineering, device security
- IT & Security teams: Incident response procedures, secure coding (OWASP Top 10), vulnerability management
- Executives & Board: Cyber risk governance, regulatory obligations, crisis decision-making
3. Training Frequency & Format: SAMA CSF expects at minimum annual training for all staff, with quarterly updates for high-risk roles. Blended learning formats (e-learning modules, live workshops, tabletop simulations) improve retention significantly over passive presentations.
4. Phishing Simulation Testing: Run simulated phishing campaigns at least quarterly. Track click rates, credential submission rates, and reporting rates. Use results to identify vulnerable departments and tailor follow-up training.
5. Metrics & Reporting: Report training completion rates, phishing simulation trends, and awareness assessment scores to the board or audit committee. SAMA examiners will review evidence of program execution during assessments.
6. Regulatory Updates: Incorporate PDPL obligations, SAMA regulatory updates, and NCA threat advisories into annual content refresh cycles to keep material current and locally relevant.
A mature SAT program reduces human-vector incident risk and directly supports your SAMA CSF maturity scoring in Domain 3 (Cybersecurity Resilience).
A comprehensive Incident Response Plan (IRP) should include: (1) Roles and responsibilities (CISO, IR team, legal, communications); (2) Incident classification and severity levels; (3) Detection and reporting procedures; (4) Containment, eradication, and recovery steps; (5) Evidence preservation and forensics guidance; (6) SAMA/NCA regulatory notification requirements; (7) External communication plan; (8) Lessons learned process; (9) Testing schedule.
Security awareness training is explicitly required under SAMA CSF Control 3.2.1 (Cybersecurity Awareness and Training) and NCA ECC Article 2-6 (Human Resources Security). A program that satisfies both frameworks must go beyond annual slideshow training and embed a continuous security culture. Here's how to build one:
1. Conduct a Role-Based Training Needs Analysis: Not all employees face the same threats. Segment training by role: executives need governance and social engineering awareness; IT/security staff need technical deep-dives; general staff need phishing, password hygiene, and data handling modules. SAMA CSF specifically calls out privileged users as requiring enhanced training.
2. Define a Training Calendar: SAMA requires documented evidence of at least annual formal training, but best practice includes quarterly phishing simulations, monthly security newsletters, and mandatory onboarding modules for new hires.
3. Include Regulatory-Specific Content: Your program must cover topics directly mapped to Saudi regulations: PDPL data handling obligations, SAMA incident reporting procedures, NCA ECC acceptable use policies, and social engineering tactics targeting the financial sector (e.g., CEO fraud, vishing).
4. Measure Effectiveness: Track phishing simulation click rates, training completion rates, and pre/post knowledge assessments. SAMA and NCA auditors expect documented metrics showing program effectiveness over time.
5. Localize for Saudi Context: Arabic-language content, culturally relevant scenarios, and references to Saudi regulatory obligations significantly improve engagement and retention. Ensure content reflects local threat actors and fraud schemes common in the MENA region.
Document everything: attendance records, assessment scores, and remediation actions for staff who fail phishing tests. This documentation is essential during SAMA supervisory reviews and NCA compliance audits.
A robust Vulnerability Management Program (VMP) for Saudi banks must be structured to satisfy SAMA CSF Control 3.3.3 (Vulnerability Management) and ISO 27001 Annex A.12.6.1 (Management of Technical Vulnerabilities).
Program Pillars:
1. Asset Discovery & Classification Maintain a continuously updated asset inventory (SAMA CSF 3.1.1). Classify assets by criticality to prioritize remediation efforts — critical financial systems demand a tighter remediation window.
2. Vulnerability Scanning Cadence SAMA CSF requires regular vulnerability assessments. Best practice mandates:
- Weekly authenticated scans for internet-facing systems
- Monthly scans for internal infrastructure
- Real-time scanning integration with SIEM platforms
3. Risk-Based Prioritization Map findings using CVSS scores combined with business context. A CVSS 7.0 vulnerability on a core banking system takes priority over a CVSS 9.0 on an isolated test environment.
4. Remediation SLAs Establish documented SLAs aligned to SAMA CSF Control 3.3.3.5:
- Critical vulnerabilities: Patch within 7 days
- High: 30 days
- Medium: 90 days
- Low: Risk acceptance or 180 days
5. Metrics & Reporting Report monthly to the CISO and quarterly to the Board Risk Committee, covering mean time to remediate (MTTR), open vulnerability aging, and exception trends per ISO 27001 Clause 9.1.
6. Integration with Pen Testing Complement the VMP with annual penetration tests per SAMA CSF 3.3.4 to validate scanner coverage gaps.
A documented, metrics-driven VMP demonstrates regulatory maturity and reduces the attack surface significantly.
A robust vulnerability management program is a core requirement under SAMA CSF Control 4.3.5 and ISO 27001 Annex A Control 8.8. For Saudi fintechs, the following structured approach is recommended:
1. Asset Inventory as the Foundation: You cannot manage vulnerabilities in assets you don't know exist. Maintain a comprehensive, up-to-date asset register covering all hardware, software, APIs, cloud workloads, and mobile applications per SAMA CSF Control 4.1.1.
2. Scanning Cadence: Conduct authenticated vulnerability scans at minimum monthly for internal systems and weekly for internet-facing assets. SAMA CSF expects evidence of regular scanning with documented remediation tracking.
3. Risk-Based Prioritisation: Not every vulnerability requires immediate patching. Use CVSS scores combined with asset criticality and exploitability context. SAMA CSF Control 4.3.5 requires a documented SLA framework — typically Critical (24–48 hours), High (7 days), Medium (30 days), Low (90 days).
4. Patch Management Integration: Link your vulnerability management tool directly to your patch management workflow. ISO 27001 A.8.8 requires timely installation of security patches with exceptions formally risk-accepted and documented.
5. Compensating Controls: Where patching is not immediately feasible (e.g., legacy core banking systems), document compensating controls such as network segmentation, WAF rules, or enhanced monitoring.
6. Metrics & Reporting: Track Mean Time to Remediate (MTTR) by severity level and report monthly to the CISO and Board Risk Committee, fulfilling SAMA CSF governance reporting obligations.
7. Continuous Improvement: Feed lessons from penetration tests and red team exercises back into your vulnerability management process to close structural gaps identified beyond automated scanning.
Privileged Access Management (PAM) is a critical control area addressed by both NCA ECC (Control 2-5: Access Management) and SAMA CSF (Control Domain 3.1, specifically Controls 3.1.3 and 3.1.4). Saudi financial institutions must implement a comprehensive PAM framework with the following components: (1) Discovery and inventory of all privileged accounts across on-premises and cloud environments, including service accounts, admin accounts, and shared credentials; (2) Just-in-time (JIT) access provisioning, ensuring elevated privileges are granted only when needed and automatically revoked after task completion; (3) Multi-factor authentication (MFA) enforced for all privileged sessions without exception, per NCA ECC Art. 2-5-3; (4) Session recording and real-time monitoring of all privileged activities, with tamper-proof audit logs retained for a minimum of 12 months as required by SAMA CSF; (5) Separation of duties ensuring no single individual holds excessive administrative rights across critical systems; and (6) Regular access reviews — at least semi-annually — with formal recertification by system owners. For cloud environments, apply cloud-native IAM controls (e.g., AWS IAM, Azure PIM) alongside your enterprise PAM solution. Shared or generic admin accounts must be eliminated; all privileged access must be individually attributed and auditable. PAM solutions such as CyberArk, BeyondTrust, or Delinea are commonly adopted in the Saudi banking sector. Critically, SAMA examiners frequently test whether privileged access logs are actually reviewed — automate alerting on anomalous privileged sessions to demonstrate active monitoring.
An effective Incident Response Plan (IRP) in Saudi Arabia must satisfy dual regulatory obligations — SAMA CSF and NCA ECC — each with distinct notification timelines and requirements. Here's how to build a compliant IRP:
1. Establish an Incident Response Team (IRT): Define clear roles: Incident Commander, Technical Lead, Legal/Compliance Officer, and Communications Lead. Per SAMA CSF Control 3.3.6, the CISO must be notified immediately for critical incidents.
2. Incident Classification Framework: Adopt a severity tiering model (P1–P4) aligned with both SAMA and NCA definitions. Critical incidents include: ransomware attacks, data breaches involving customer PII, and disruption of core banking services.
3. Regulatory Notification Timelines:
- SAMA: Notify SAMA of significant cybersecurity incidents within 72 hours of discovery, with a preliminary report. A detailed incident report must follow within 30 days.
- NCA (ECC Art. 2-9-3): Report incidents affecting critical national infrastructure to NCA's National Cybersecurity Operations Center (NCOC) within 24 hours.
- PDPL: If the incident involves personal data breach, notify SDAIA within 72 hours per PDPL Article 23.
4. Incident Response Phases: Structure your IRP around: Preparation → Detection & Analysis → Containment → Eradication → Recovery → Post-Incident Review. Each phase must have documented runbooks for common attack scenarios (phishing, ransomware, insider threat).
5. Regular Testing & Drills: Conduct tabletop exercises at least annually and full simulation exercises every 18 months. Document results and remediation actions for regulatory evidence.
Pro Tip: Maintain pre-approved communication templates for regulatory notifications to avoid delays during high-stress incident scenarios.
Security awareness training is not merely a best practice — it is a mandatory regulatory requirement for Saudi financial institutions. Human error remains the leading cause of cybersecurity incidents, making a well-structured awareness program one of the most cost-effective security investments.
Regulatory Foundations:
- SAMA CSF Control 3.2.1 requires that all employees, contractors, and third-party users receive role-based security awareness training at least annually, with documented completion records.
- NCA ECC Article 2-6 mandates a formal cybersecurity awareness program covering threats relevant to the institution's operating environment, with evidence of employee acknowledgment.
Program Design Best Practices:
- Role-Based Training: Differentiate content for general staff (phishing, password hygiene), IT teams (secure coding, patch management), and executives (social engineering, governance responsibilities).
- Simulated Phishing Campaigns: Conduct quarterly phishing simulations to measure human risk and target repeat offenders with remedial training. Track click rates and report rates as KPIs.
- Onboarding Integration: Embed mandatory security training into new employee onboarding workflows, with a signed acknowledgment of the Acceptable Use Policy (AUP).
- Incident-Driven Updates: Refresh training content following significant internal incidents or emerging regional threat intelligence (e.g., CERT-SA advisories).
- Measurement and Reporting: Report program metrics — completion rates, phishing simulation results, knowledge assessment scores — to the CISO and board-level risk committee quarterly.
Documentation for Audits:
Maintain training completion records, curriculum materials, and assessment results for a minimum of three years to support SAMA examination requirements. Our platform automates training tracking and generates audit-ready compliance reports aligned to SAMA CSF and NCA ECC control mappings.
A robust vulnerability management program is foundational to cybersecurity compliance for Saudi financial institutions. Both SAMA CSF and NCA ECC explicitly require systematic identification, assessment, and remediation of technical vulnerabilities across all in-scope assets.
SAMA CSF Requirements (Control 3.3): SAMA mandates that member organizations establish a formal vulnerability management process covering network infrastructure, applications, endpoints, and cloud environments. This includes regular vulnerability scanning (at minimum quarterly) and risk-based prioritization of findings.
NCA ECC Requirements (ECC-1-4-3): NCA requires that critical vulnerabilities be remediated within defined SLAs — typically critical findings within 15 days, high within 30 days, and medium within 90 days — depending on your sector's risk classification.
Practical Implementation Steps:
- Asset Inventory: Maintain a complete, up-to-date asset inventory as the foundation. You cannot protect what you don't know exists.
- Scanning Cadence: Deploy authenticated scanning tools (e.g., Tenable, Qualys) for weekly internal scans and quarterly external scans at minimum.
- Risk-Based Prioritization: Use CVSS scores combined with asset criticality and exploitability context — not CVSS alone.
- Patch Management Integration: Link your vulnerability management workflow with your patch management process and change control procedures.
- Metrics and Reporting: Track Mean Time to Remediate (MTTR) per severity level and report to CISO and board-level risk committees quarterly.
- Penetration Testing: Complement scanning with annual penetration tests per SAMA CSF Control 3.3.4 and NCA ECC requirements.
- Exception Management: Formally document and risk-accept any vulnerabilities that cannot be patched within SLA, with compensating controls in place.
A well-implemented program reduces your attack surface, demonstrates regulatory maturity, and provides quantifiable risk reduction evidence during audits.
Human error remains the leading cause of cybersecurity incidents globally, and SAMA CSF explicitly addresses this under Domain 3.2 – Human Resource Security (Controls 3.2.4 and 3.2.5). A compliant and effective Security Awareness Training (SAT) program for Saudi banks must go beyond annual tick-box training.
Program Structure:
- Risk-Based Audience Segmentation: Tailor content by role. Frontline staff need phishing recognition and social engineering defense. IT and security teams require technical threat briefings. Executives and board members need cyber-risk governance training, including understanding their accountability under SAMA and NCA regulations.
- Training Frequency & Format: SAMA CSF requires at minimum annual training for all staff, but best practice — and NCA ECC guidance — recommends quarterly micro-learning modules, monthly security tips, and immediate teachable moments following phishing simulations.
- Phishing Simulation Campaigns: Run quarterly simulated phishing exercises across the organization. Track click rates, report rates, and credential submission rates. Use results to identify high-risk individuals requiring targeted remediation training. Per SAMA CSF Control 3.2.5, results should feed into your risk register.
- Arabic-Language Content: Given Saudi Arabia's workforce demographics, ensure training materials are available in Arabic and culturally relevant. Generic English content often underperforms in Gulf organizations.
- Metrics & Reporting: Report SAT effectiveness to the CISO and board annually. Key metrics include phishing simulation failure rates (target below 5%), training completion rates (target 95%+), and security incident tickets attributable to human error (track quarter-over-quarter reduction).
- New Hire Onboarding: All new employees must complete cybersecurity awareness training before accessing production systems — a hard requirement under SAMA CSF 3.2.4.
A well-executed SAT program not only satisfies SAMA examiners but measurably reduces your organization's attack surface.
Implementing robust Role-Based Access Control (RBAC) aligned with the principle of least privilege is a foundational requirement under both SAMA CSF Domain 3.2 (Identity and Access Management) and NCA ECC Control 2-5. For Saudi fintechs, here is a practical compliance roadmap:
Define Roles Before Assigning Access (SAMA CSF 3.2.1): Start by documenting a formal role inventory tied to job functions — not individuals. Map each role to the minimum permissions required for job execution. Common fintech roles include: Payment Operations, KYC Analyst, DevOps Engineer, Finance Controller, and CISO. Avoid broad admin roles shared across teams.
Privileged Access Management (PAM): SAMA CSF specifically requires controls around privileged accounts. Deploy a PAM solution to vault, rotate, and audit all privileged credentials. Privileged sessions must be recorded and reviewed periodically. NCA ECC Article 2-5-3 further mandates that privileged access be time-limited and subject to multi-factor authentication (MFA).
Segregation of Duties (SoD): Enforce SoD controls to prevent conflicts of interest — for example, the same user should not be able to both approve and execute financial transactions. This directly addresses SAMA CSF 3.2.3 and supports internal fraud prevention.
Access Reviews: Conduct formal access certification reviews at least quarterly for privileged accounts and bi-annually for all other users. Automate these reviews through your IAM platform where possible.
Joiner-Mover-Leaver Process: Establish an automated provisioning and de-provisioning workflow integrated with your HR system. Dormant accounts must be disabled within 30 days per SAMA guidance.
Audit Logging: All access events — especially for critical financial systems — must be logged and retained for a minimum of one year, with three months readily accessible, per SAMA CSF 3.6 logging requirements.
Human error remains the leading cause of cybersecurity incidents in Saudi financial institutions, making Security Awareness and Training (SAT) a regulatory and operational priority. Both SAMA CSF Control 3.2.2 and NCA ECC Article 2-4 mandate formal, role-based awareness programs that are measurable and regularly updated.
Program Design Essentials:
- Role-Based Curriculum: Develop tailored content for distinct audiences — general staff, IT/security teams, privileged users, executives, and Board members. Generic training fails to address the specific threats each group faces.
- Mandatory Training Frequency: Conduct organization-wide baseline training at onboarding and at minimum annually. High-risk roles (e.g., treasury, privileged access users) should receive quarterly refreshers. NCA ECC Article 2-4.2 explicitly requires documented evidence of training completion.
- Phishing Simulations: Run simulated phishing campaigns at least quarterly to measure click rates, credential submission, and reporting behavior. Track improvement trends over time and remediate repeat offenders with targeted training.
- Threat-Relevant Topics: Include Saudi-specific threat scenarios such as WhatsApp-based social engineering, fake SADAD payment requests, and CEO fraud — threats actively exploited against GCC financial institutions.
- Board & Executive Engagement: SAMA CSF requires cybersecurity awareness at the governance level. Conduct annual tabletop exercises and board briefings covering emerging threats and regulatory updates.
- Measurement & Reporting: Track KPIs including training completion rates, phishing simulation results, and incident tickets attributed to human error. Report these metrics to the CISO and Board Risk Committee quarterly.
- Localization: Provide content in Arabic to maximize comprehension and engagement across the full workforce, not just English-proficient staff.
A well-executed SAT program reduces human-vector incidents significantly and demonstrates to SAMA examiners a mature, proactive security culture.
A robust Cyber Incident Response Plan (CIRP) is mandatory under SAMA CSF (Domain 5 – Cyber Resilience) and NCA ECC (Control 2-12). Regulators expect not just a documented plan, but evidence of regular testing and continuous improvement.
Design requirements:
- SAMA CSF Control 5.3 requires a formal CIRP covering detection, containment, eradication, recovery, and post-incident review phases. The plan must define roles, responsibilities, escalation paths, and communication protocols — including mandatory notification to SAMA within defined timeframes for material incidents.
- NCA ECC Art. 2-12 mandates alignment with the NCA Cybersecurity Incident Management Framework and requires classified incident categorization (P1–P4 severity levels).
- PDPL obligations: Where incidents involve personal data breaches, the PDPL requires notification to the National Data Management Office (NDMO) and affected individuals within defined periods.
Testing requirements:
- Conduct tabletop exercises at least annually involving C-suite and IT leadership.
- Perform live simulation drills (e.g., ransomware scenario) at least once per year.
- Document lessons learned and translate them into CIRP updates within 30 days of each exercise.
Common gaps found during SAMA examinations: Undefined escalation thresholds, missing third-party notification procedures, and untested communication trees. Integrate your CIRP with your GRC platform to automate incident logging, evidence collection, and regulatory reporting workflows.
Podcast 1
New episodes are released weekly, typically on Sundays. Special episodes covering breaking cybersecurity events may be released as needed.
Compliance & Regulations 6
The SAMA Cybersecurity Framework is a comprehensive framework issued by the Saudi Arabian Monetary Authority to help financial institutions manage cyber risks. It covers governance, risk management, compliance, operations, and third-party security.
ISO/IEC 27001 is the international standard for Information Security Management Systems (ISMS). It is not mandatory in Saudi Arabia by law, but is strongly recommended and often required by enterprise customers and government tenders. Achieving ISO 27001 certification demonstrates a mature security posture and can accelerate compliance with SAMA CSF and NCA ECC.
ISO 27001:2022 is the internationally recognized standard for Information Security Management Systems (ISMS). For Saudi fintechs, achieving certification signals a mature, structured approach to cybersecurity — but understanding how it interacts with local regulatory frameworks is essential.
What ISO 27001:2022 Requires: The 2022 revision introduced 93 controls organized into four themes (Organizational, People, Physical, Technological), replacing the 2013 version's 114 controls. It added 11 new controls covering threat intelligence, cloud security, ICT readiness for business continuity, and data masking — areas directly relevant to fintech operations.
Complementary Value with SAMA CSF: ISO 27001 provides a strong governance backbone. Many SAMA CSF controls map directly to ISO 27001 Annex A controls, meaning a well-implemented ISMS can satisfy a significant portion of SAMA's requirements. However, SAMA CSF goes further with sector-specific controls around payment systems, SWIFT security, and regulatory reporting that ISO 27001 does not explicitly address. Think of ISO 27001 as the foundation and SAMA CSF as the sector-specific overlay.
Complementary Value with NCA ECC: NCA ECC (Essential Cybersecurity Controls) shares significant overlap with ISO 27001, particularly in access management, vulnerability management, and incident response. NCA has acknowledged ISO 27001 certification as a positive indicator during assessments, though it does not replace ECC compliance.
PDPL Alignment: ISO 27001:2022 Annex A Control 5.34 (Privacy and protection of PII) directly supports PDPL obligations, making the certification valuable for privacy compliance as well.
Practical Guidance: Use a GRC platform to perform a gap analysis mapping your existing ISO 27001 controls against SAMA CSF and NCA ECC requirements. This avoids duplicating effort and clearly shows regulators the control coverage you already have in place.
Third-party risk management is a critical compliance obligation for Saudi fintechs. SAMA CSF Control 3.3 (Third-Party Management) and NCA ECC Article 2-13 together create a comprehensive framework that requires fintechs to assess, monitor, and manage cybersecurity risks introduced by vendors, partners, and service providers.
Core Requirements:
- Pre-Onboarding Due Diligence: Conduct cybersecurity risk assessments before engaging any third party with access to systems or data. This includes reviewing the vendor's security certifications (ISO 27001, SOC 2), penetration testing history, and incident response capabilities.
- Contractual Security Clauses: Per SAMA CSF Control 3.3.2, contracts must include minimum cybersecurity requirements, audit rights, incident notification obligations (typically within 72 hours), and data handling standards aligned with PDPL.
- Ongoing Monitoring: Establish annual reassessments for high-risk vendors. NCA ECC emphasizes continuous monitoring for vendors with privileged access to critical national infrastructure-connected systems.
- Concentration Risk: SAMA guidance warns against over-reliance on a single vendor, particularly in cloud and core banking services. Fintechs must document mitigation strategies for concentration risk.
- Fourth-Party Risk: Assess subcontractors and downstream dependencies of your primary vendors — a growing area of regulatory scrutiny.
Practical Tip: Develop a tiered vendor classification framework (Critical, High, Medium, Low) and tailor your due diligence and monitoring intensity accordingly. Maintain a vendor risk register as evidence for SAMA assessments.
ISO 27001:2022 restructures Annex A from 14 domains and 114 controls to 4 themes (Organizational, People, Physical, Technological) and 93 controls. Key additions include controls for Threat Intelligence, Information Security for Cloud Services, ICT Readiness for Business Continuity, Physical Security Monitoring, Configuration Management, and Data Masking. Organizations certified to 2013 must transition by October 2025.
Security awareness training is a foundational control that both SAMA CSF and NCA ECC explicitly mandate, yet many fintechs treat it as a checkbox exercise rather than a behavioral change program.
Regulatory Baseline:
- SAMA CSF Control 3.1.4 requires all employees to receive cybersecurity awareness training upon joining and at regular intervals thereafter, with content tailored to job roles and risk exposure.
- NCA ECC-1:2018 Control 2-7 mandates that organizations implement a cybersecurity awareness and training program covering all staff, including contractors and third parties with system access.
Program Design Best Practices:
1. Role-Based Curriculum: Generic training is insufficient. Develop separate tracks for general staff (phishing, social engineering, password hygiene), developers (OWASP Top 10, secure coding), and executives (board-level cyber risk, regulatory obligations).
2. Phishing Simulations: Run monthly simulated phishing campaigns. Employees who fail should be automatically enrolled in targeted micro-training rather than disciplined — this creates a learning culture rather than a punitive one.
3. Frequency and Format: Annual training alone does not satisfy SAMA examiners. Adopt a continuous model: monthly awareness nudges, quarterly topic-focused modules, and annual comprehensive assessments.
4. Metrics and Reporting: Track click rates on phishing simulations, training completion rates by department, and knowledge retention scores. Report quarterly to the CISO and annually to the Board Risk Committee.
5. PDPL Awareness: Include dedicated modules on handling personal data, data subject rights under PDPL, and reporting obligations — critical for customer-facing fintech teams.
Document all training records for a minimum of 3 years to support SAMA and NCA audit evidence requests.
Technical Support 1
You can report cybersecurity incidents through the National Cybersecurity Authority (NCA) portal, or contact us via our contact form and we will guide you to the appropriate authorities and resources.
Privacy & Data 1
We comply with the Saudi Personal Data Protection Law (PDPL). Your data is encrypted, access is role-based, and we implement industry-standard security controls including WAF, CSP, and regular security audits. You can request a copy or deletion of your data at any time.
SAMA & Banking 220
All financial institutions regulated by the Saudi Arabian Monetary Authority (SAMA) must comply, including commercial banks, insurance companies, finance companies, payment service providers, and fintech firms operating in the Kingdom.
The SAMA Cybersecurity Framework v2.0 contains 251 sub-controls organized across 12 domains covering Governance, Risk Management, Identity & Access, Operations Security, Network Security, System Acquisition, Third-Party Management, Business Continuity, and Threat Management.
Under SAMA CSF Control Domain 3.3 (Third-Party Cybersecurity), regulated entities must implement a structured vendor risk management lifecycle covering onboarding, ongoing monitoring, and offboarding. Here's how to structure it effectively:
1. Vendor Classification & Tiering: Categorize vendors by criticality — Tier 1 (critical/core banking vendors), Tier 2 (important), and Tier 3 (low-risk). This determines the depth of due diligence required.
2. Pre-Onboarding Due Diligence: Require vendors to complete a cybersecurity questionnaire aligned with SAMA CSF controls. Request evidence of certifications such as ISO 27001 or SOC 2. For Tier 1 vendors, consider independent security assessments.
3. Contractual Controls: Embed cybersecurity obligations in contracts, including right-to-audit clauses, incident notification timelines (typically 72 hours per SAMA expectations), data handling requirements aligned with PDPL, and minimum security standards.
4. Continuous Monitoring: Conduct annual reassessments for Tier 1 and Tier 2 vendors. Use threat intelligence feeds and surface web monitoring to identify vendor breaches proactively.
5. Offboarding Controls: Ensure data deletion confirmation, access revocation, and documentation of asset returns.
6. Board Reporting: Per SAMA CSF Control 3.1.4, the board and senior management must receive regular reports on third-party risk exposure.
A common gap observed in Saudi financial institutions is treating third-party risk as a one-time checkbox rather than an ongoing program. Embed vendor risk reviews into your annual SAMA self-assessment cycle to ensure continuous compliance posture.
A robust cybersecurity incident response plan (IRP) for Saudi financial institutions must satisfy the requirements of SAMA CSF Control 3.6 (Cybersecurity Incident Management) as well as NCA ECC Domain 2-7 (Cybersecurity Incident and Threat Management). At its core, the IRP must define six phases: Preparation, Detection & Analysis, Containment, Eradication, Recovery, and Post-Incident Review. SAMA specifically requires that any cybersecurity incident impacting operations, customer data, or financial services be reported to SAMA within 72 hours of discovery — with a full Root Cause Analysis (RCA) submitted within 30 days. NCA mandates reporting of significant incidents to the National Cybersecurity Authority through established channels, and institutions should register with the Saudi Computer Emergency Response Team (saCERT) for threat intelligence sharing. Practically, the IRP should include: clearly assigned roles (Incident Commander, Technical Lead, Communications Officer, Legal Counsel), a predefined severity classification matrix (P1–P4), communication templates for internal escalation and regulatory notification, and integration with PDPL obligations — since a breach involving personal data triggers mandatory notification to the SDAIA (Saudi Data and AI Authority) and potentially affected individuals. Tabletop exercises simulating ransomware, insider threats, and third-party breaches should be conducted at least annually per SAMA CSF best practices. The IRP must be reviewed after every major incident and updated annually. Our platform provides IRP templates pre-mapped to SAMA and NCA requirements, with automated incident ticketing and regulatory notification tracking.
Third-party risk management is a critical obligation for Saudi financial institutions under both SAMA CSF (Control 3.3.6 – Supplier Relationships) and NCA ECC (Domain 4 – Third-Party Cybersecurity). Here is a structured approach:
1. Pre-Onboarding Due Diligence: Before engaging any vendor, conduct a cybersecurity risk assessment covering data access scope, cloud or on-premise deployment, and regulatory exposure. SAMA CSF requires formal risk classification of all third parties with access to critical systems.
2. Contractual Safeguards: Embed cybersecurity clauses in all vendor contracts — including the right to audit, incident notification SLAs (typically 72 hours per PDPL Article 19), data handling obligations, and minimum security baseline requirements aligned with ISO 27001 Annex A controls.
3. Ongoing Monitoring: Third-party relationships must be continuously monitored, not just assessed at onboarding. This includes annual reassessments for critical vendors, review of their security certifications (e.g., ISO 27001, SOC 2), and tracking any publicly reported breaches.
4. Concentration Risk: SAMA specifically highlights the risk of over-reliance on a single vendor for critical services. Institutions must maintain documented exit strategies and business continuity plans for key third parties.
5. Cloud Providers: For cloud-based third parties, NCA CCC controls apply. Ensure your vendor is either hosted within Saudi Arabia or has received explicit regulatory approval for cross-border data processing.
Practically, build a third-party risk register, assign risk tiers (Critical, High, Medium, Low), and define review cycles accordingly. A CISO Consulting vCISO can help design and operationalize this program from day one.
Security awareness training is far more than a compliance checkbox — it is a frontline defense against phishing, social engineering, and insider threats. Both SAMA CSF (Control 3.3.2 – Cybersecurity Awareness and Training) and NCA ECC (Control 2-4 – Human Cybersecurity) mandate structured awareness programs. Here is how to build one that truly satisfies both frameworks:
Regulatory Minimum Requirements:
- SAMA CSF: Requires role-based security training differentiated by job function (general staff, privileged users, IT/security teams, and senior management). Training must be documented, tracked, and renewed at least annually.
- NCA ECC: Requires a formal awareness program covering phishing recognition, password hygiene, clean desk policy, and incident reporting procedures.
Recommended Program Structure:
- Baseline Assessment: Start with a phishing simulation to measure current susceptibility rates. This creates a measurable benchmark aligned with SAMA's maturity measurement approach.
- Role-Based Curricula:
- All Staff: Phishing, social engineering, password management, PDPL data handling basics
- IT & Security Teams: Secure coding (if applicable), incident escalation procedures, privileged access hygiene
- Management & Board: Cyber risk governance, regulatory liability, business continuity obligations
- Delivery Formats: Blend short monthly microlearning modules (5–10 minutes), quarterly phishing simulations, and annual in-depth workshops. Gamification significantly improves completion rates.
- Measurement & Reporting: Track completion rates, phishing click-through rates before and after training, and quiz scores. SAMA expects documented evidence of training effectiveness during assessments.
- Language Localization: Deliver content in both Arabic and English to maximize comprehension and engagement across your workforce.
Key Tip: Maintain a training register with employee names, completion dates, scores, and training version — this is frequently requested during SAMA regulatory examinations and NCA assessments.
Under SAMA CSF Control Domain 3.3 (Third-Party Cybersecurity), Saudi financial institutions must implement a structured vendor risk management lifecycle that spans onboarding, ongoing monitoring, and offboarding. Here's how to build a compliant program:
1. Vendor Classification & Tiering: Categorize vendors by the sensitivity of data they access and the criticality of services they provide. Tier-1 vendors (e.g., core banking system providers, cloud hosting partners) require the most rigorous scrutiny.
2. Pre-Onboarding Due Diligence: Before engagement, require vendors to complete a cybersecurity questionnaire aligned with SAMA CSF domains. Request evidence of ISO 27001 certification, penetration test results, and SOC 2 Type II reports where applicable.
3. Contractual Security Requirements (per SAMA CSF 3.3.4): Embed mandatory cybersecurity clauses in all vendor contracts, including: right-to-audit provisions, incident notification obligations (within 72 hours of discovery), data handling and encryption standards, and compliance with NCA ECC and PDPL where data is involved.
4. Continuous Monitoring: Conduct annual reassessments for Tier-1 vendors and bi-annual reviews for Tier-2. Use threat intelligence feeds to monitor for vendor breaches or vulnerabilities in vendor-supplied software.
5. Offboarding Controls: Ensure secure data deletion, credential revocation, and access termination are documented and verified upon contract termination.
A common gap found during SAMA assessments is that institutions maintain vendor lists but lack documented risk ratings or evidence of ongoing monitoring. Establishing a formal Third-Party Risk Register with assigned ownership and review dates is essential for audit readiness.
Under SAMA CSF Control 3.3 (Third-Party Management), Saudi banks and financial institutions must implement a structured, risk-based vendor management lifecycle that covers onboarding, ongoing monitoring, and offboarding. Here is how to build a compliant program:
1. Vendor Classification & Risk Tiering: Categorize vendors by the sensitivity of data they access and their criticality to operations (e.g., Tier 1 for core banking system providers, Tier 3 for low-risk suppliers). This tiering drives the depth of due diligence required.
2. Pre-Engagement Due Diligence: Before contracting, require vendors to complete a cybersecurity questionnaire aligned to SAMA CSF domains. For high-risk vendors, consider requesting ISO 27001 certification evidence or independent audit reports (SOC 2 Type II).
3. Contractual Controls: Ensure contracts include mandatory security clauses: right-to-audit provisions, incident notification obligations (within 72 hours per PDPL Art. 24 and SAMA CSF expectations), data handling restrictions, and business continuity commitments.
4. Continuous Monitoring: Conduct annual reassessments for Tier 1 vendors and biennial reviews for Tier 2. Use threat intelligence feeds and cyber ratings platforms to monitor vendor security posture between formal assessments.
5. Offboarding Controls: Define secure data return and destruction protocols when terminating vendor relationships, ensuring no residual data exposure.
Your GRC platform should automate vendor questionnaire distribution, track remediation timelines, and generate SAMA-ready reporting dashboards that demonstrate third-party risk governance to regulators during examinations.
Business Continuity Management (BCM) is a mandatory domain under both SAMA CSF (Domain 4 – Operational Resilience) and NCA ECC (Control 2-10 – Business Continuity). Saudi financial institutions must establish, implement, test, and continuously improve their BCM programs to satisfy regulatory expectations.
SAMA CSF Requirements: SAMA CSF Control 3.4 requires institutions to maintain a documented Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP) that are reviewed and tested at least annually. Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) must be formally defined for all critical systems, with special attention to core banking platforms, payment systems, and customer-facing digital channels.
NCA ECC Alignment: NCA ECC Control 2-10 mandates that organizations define cybersecurity-specific continuity scenarios, including ransomware attacks, critical system outages, and supply chain disruptions. Cybersecurity must be embedded in BCM exercises, not treated as a separate workstream.
Practical Implementation Steps:
- Conduct a formal Business Impact Analysis (BIA) identifying critical processes, dependencies, and acceptable downtime thresholds.
- Define RTO/RPO for all critical assets and validate these with technology and business stakeholders.
- Develop cybersecurity-integrated DRP covering backup integrity, failover procedures, and out-of-band communication protocols.
- Conduct tabletop exercises and full simulation tests at least annually, involving IT, security, operations, and executive leadership.
- Document all test results, gaps identified, and corrective actions in your GRC platform for regulatory audit trails.
Regulators increasingly scrutinize BCM during SAMA examinations — institutions with outdated or untested plans face significant compliance findings.
Business Continuity Management (BCM) is a mandatory requirement for Saudi financial institutions under both SAMA CSF Control Domain 3.7 and NCA ECC Control 2-13. Here is a practical implementation roadmap:
1. BIA (Business Impact Analysis): Begin with a formal BIA to identify critical business processes, maximum tolerable downtime (MTD), Recovery Time Objectives (RTO), and Recovery Point Objectives (RPO). SAMA expects RTOs for core banking systems to typically not exceed 4 hours.
2. BCM Policy and Governance: Establish a board-approved BCM policy that assigns clear ownership. SAMA CSF requires the CISO and senior management to be directly accountable for BCM outcomes.
3. Business Continuity Plans (BCP) and Disaster Recovery Plans (DRP): Develop, document, and maintain separate BCP and DRP documents covering technology failover, manual workarounds, alternate site activation, and communication protocols.
4. Testing and Exercises: SAMA CSF mandates that BCM plans be tested at least annually through tabletop exercises, simulation drills, or full failover tests. NCA ECC Article 2-13 similarly requires documented test results and corrective action tracking.
5. Third-Party and Supply Chain Continuity: Ensure critical vendors maintain their own BCM programs aligned with your institution's RTO/RPO requirements, per SAMA CSF Control 3.6.
6. Cyber Incident Integration: BCM plans must explicitly address cybersecurity scenarios — ransomware, DDoS, and data center outages — ensuring alignment with your Cyber Incident Response Plan (CIRP).
7. Regulatory Reporting: SAMA requires institutions to report major disruptions within defined timeframes. Maintain a disruption log and ensure your BCM framework is reviewed during SAMA's annual cybersecurity examination cycle.
Business continuity and cyber resilience are among the most scrutinized areas during SAMA regulatory examinations. SAMA CSF Subdomain 3.5 (Cyber Resilience) sets out explicit requirements that go beyond traditional IT disaster recovery into true organizational resilience.
Core SAMA CSF Requirements (Subdomain 3.5):
- Control 3.5.1 – BCP/DRP Development: Banks must maintain documented Business Continuity Plans (BCP) and Disaster Recovery Plans (DRP) that specifically account for cyberattack scenarios (ransomware, DDoS, data destruction), not just natural disasters or hardware failures.
- Control 3.5.2 – Testing Frequency: BCPs and DRPs must be tested at least annually, with tabletop exercises, simulation drills, and full failover tests each serving distinct purposes. SAMA expects evidence of testing, including lessons-learned documentation.
- Control 3.5.3 – Recovery Objectives: Defined RTO (Recovery Time Objective) and RPO (Recovery Point Objective) targets must be formally approved by senior management and aligned to the criticality of each system.
- Control 3.5.4 – Cyber Incident Integration: The cyber incident response plan must be formally integrated into the BCP so that a cybersecurity event automatically triggers the appropriate continuity protocols.
Integration with ISO 22301: ISO 22301 (Business Continuity Management Systems) provides the structural framework that operationalizes SAMA CSF 3.5 requirements. Specifically:
- ISO 22301 Clause 6.2 (BIA) directly supports SAMA's requirement to identify and prioritize critical systems.
- ISO 22301 Clause 8.5 (Exercising and Testing) maps to SAMA CSF Control 3.5.2.
- Achieving ISO 22301 certification significantly strengthens your SAMA CSF maturity evidence.
NCA ECC Alignment: NCA ECC Article 2-14 independently mandates cyber resilience planning for government-affiliated entities — financial institutions with government ownership must satisfy both regulators.
Business Continuity Management (BCM) sits at the intersection of operational resilience and cybersecurity in SAMA's regulatory framework. Under SAMA CSF Domain 3.5 (Cyber Resilience), financial institutions are required to develop, maintain, and regularly test a Cyber Resilience Program that ensures critical operations can withstand, recover from, and adapt to cyber incidents.
SAMA CSF Control 3.5.1 mandates that banks establish a formal BCM framework that explicitly addresses cyber threat scenarios — not just traditional IT failures or natural disasters. This means BCP documents must include ransomware outbreak scenarios, DDoS attack playbooks, data exfiltration incidents, and critical system compromise procedures.
Key SAMA BCM requirements for CISOs include:
1. Business Impact Analysis (BIA): Identify critical business functions, their dependencies on IT systems, and define Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) for each. SAMA expects RTOs for critical payment systems to be extremely aggressive — often under 4 hours.
2. Cyber Incident Scenarios in BCP Testing: Annual BCM tests (per Control 3.5.3) must include at least one cyber-specific scenario. Tabletop exercises simulating ransomware or supply chain attacks are increasingly expected by SAMA examiners.
3. Crisis Communication Protocols: BCP must define escalation paths to SAMA (within 72 hours for major incidents per SAMA Cyber Incident Reporting Framework), the board, customers, and media.
4. Backup and Recovery Controls: Per SAMA CSF 3.3.10, offline and immutable backups must be maintained for critical data, with restoration tested regularly to validate actual RTO/RPO achievement.
5. Alignment with NCA ECC: NCA ECC Article 2-12 mirrors BCM obligations for all national entities, requiring coordination between the CISO and the COO/CRO on joint continuity planning.
CISOs should treat BCM not as a compliance checkbox but as a continuous resilience-building exercise embedded in the bank's annual security strategy.
Business Continuity Management (BCM) is a critical domain under SAMA CSF (Domain 5 – Cyber Resilience, Controls 5.1–5.4), requiring Saudi banks to maintain robust, tested, and board-approved continuity plans.
Program Foundation: Your BCM program must be anchored to a formal Business Impact Analysis (BIA) that identifies critical business functions, maximum tolerable downtime (MTD), recovery time objectives (RTO), and recovery point objectives (RPO) for each function. SAMA expects RTOs for critical systems to be defined and contractually enforced.
Cybersecurity Integration: BCM must be tightly integrated with the Cybersecurity Incident Response Plan (CIRP). Ransomware scenarios, DDoS attacks, and critical data loss must be explicitly covered in continuity plans — a gap many Saudi banks overlook.
Plan Components: A compliant BCM program includes: Crisis Management Plan, IT Disaster Recovery Plan (DRP), Business Recovery Plans per department, and Communication Plans (internal, regulatory, and customer-facing). SAMA CSF Control 5.2 specifically requires that SAMA be notified within defined timeframes during a major disruption.
Testing & Validation: SAMA requires annual BCP/DR exercises, including tabletop simulations and full failover tests. Results must be documented, lessons learned captured, and plans updated accordingly. NCA ECC also mandates resilience testing for entities managing critical national infrastructure.
Governance: The BCM program must have executive sponsorship, with the CISO and CRO jointly accountable. Plans must be reviewed and approved annually by senior management.
Our platform provides BCM templates pre-mapped to SAMA CSF domains, enabling banks to build, test, and evidence their resilience programs efficiently.
Business Continuity Management (BCM) is a tier-one requirement under SAMA CSF Domain 4 – Operational Resilience. SAMA expects member banks to maintain a formally documented, regularly tested, and board-approved BCM program that ensures the continuity of critical financial services during and after disruptive events.
Core BCM Components Required by SAMA CSF:
1. Business Impact Analysis (BIA): Per SAMA CSF Control 4.1.1, institutions must conduct a BIA to identify critical business functions, their dependencies (people, technology, third parties), and define Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO). For systemically important banks, RTOs for core banking services are typically expected within 4 hours.
2. BCM Policy and Strategy: A board-approved BCM policy must define scope, roles, responsibilities, and escalation procedures. The strategy must address alternative site activation, manual workarounds, and communication protocols.
3. IT Disaster Recovery (DR): Aligned with SAMA CSF Control 4.2, DR plans must be technically documented and cover failover procedures for all tier-1 systems. Data replication and backup frequencies must align with RPO commitments.
4. Testing and Exercises: SAMA requires at minimum an annual full DR test and tabletop exercises for crisis management scenarios. Results must be documented, gaps identified, and corrective actions tracked.
5. Integration with PDPL: Under PDPL Article 19, data backup and recovery mechanisms must preserve data integrity and access rights, ensuring that personal data is not exposed during DR failover events.
Documentation Tip: Maintain a BCM program register linking each plan to its owner, last test date, RTO/RPO targets, and SAMA CSF control reference. This significantly simplifies regulatory examination responses.
Business Continuity Management (BCM) is a mandatory component of SAMA CSF under Control Domain 3.5. Saudi banks must implement a BCM program that ensures critical financial services remain operational during disruptions — whether cyber incidents, natural disasters, or systemic failures.
SAMA CSF BCM Requirements:
1. Business Impact Analysis (BIA): Identify and classify critical business processes, define Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) for each, and assess interdependencies with third-party services and IT systems. SAMA expects RTOs for critical systems to be under 4 hours.
2. BCM Policy and Governance: A formally approved BCM policy must exist, endorsed by senior management and reviewed annually. A designated BCM owner must be appointed at the executive level.
3. Business Continuity Plans (BCP) and Disaster Recovery Plans (DRP): Separate but integrated plans must cover people, processes, technology, and facilities. Plans must include clear escalation paths, communication trees, and alternate site arrangements.
4. Testing and Exercising: SAMA requires BCM plans to be tested at least annually. Tests must include tabletop exercises, simulation drills, and full failover tests for critical systems. Results must be documented and gaps remediated.
5. Alignment with NCA ECC: NCA ECC Article 2-15 reinforces BCM requirements for organizations operating national infrastructure, adding requirements around cyber-resilience and continuity of digital services.
6. PDPL Consideration: BCM plans must account for data protection obligations — backup systems must maintain the same security and access controls as primary systems.
Practical Steps:
- Integrate BCM into your annual SAMA self-assessment submission.
- Use our platform's BCM module to map RTOs/RPOs, schedule tests, and generate regulator-ready reports automatically.
- Align BCM with ISO 22301 for internationally recognized best practice.
Business Continuity Management (BCM) is a critical regulatory obligation for Saudi financial institutions. Both SAMA CSF (Domain 4 — Operational Resilience) and NCA ECC (Article 2-14) mandate formal BCM programs. Here is a practical implementation roadmap:
1. Governance and Policy Foundation: Establish a BCM policy approved by the Board or senior executive committee. SAMA CSF requires explicit ownership at the executive level. Assign a dedicated BCM owner — often the CISO or COO — responsible for program maintenance.
2. Business Impact Analysis (BIA): Conduct a thorough BIA to identify critical business functions, their dependencies, and acceptable Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO). SAMA expects RTOs and RPOs to be defined for all critical systems including core banking, payments, and customer-facing channels.
3. Risk Assessment Integration: BCM must be integrated with the organization's broader cybersecurity risk assessment process. NCA ECC Article 2-14 specifically requires scenarios covering cyberattacks, ransomware, and system failures.
4. Plan Development: Develop Business Continuity Plans (BCP) and Disaster Recovery Plans (DRP) covering people, processes, technology, and facilities. Ensure plans address both partial and full site failures.
5. Testing and Exercises: SAMA CSF requires BCM plans to be tested at least annually through tabletop exercises, functional drills, or full failover tests. Test results and lessons learned must be documented and acted upon.
6. Third-Party Dependencies: Map and test continuity arrangements for critical vendors and cloud service providers. SAMA expects contractual BCM obligations to be embedded in third-party agreements.
Regular review cycles — at least annually or after significant changes — ensure plans remain current and aligned with evolving regulatory expectations.
Business Continuity Management (BCM) is a critical compliance domain for Saudi financial institutions, governed primarily by SAMA CSF Domain 4 (Operational Resilience) and NCA ECC Controls 2-9 and 2-10, which address resilience and recovery capabilities.
Core SAMA CSF Requirements: SAMA CSF Control 4.1 requires institutions to establish a formal BCM program covering Business Impact Analysis (BIA), Recovery Time Objectives (RTO), Recovery Point Objectives (RPO), and tested Business Continuity Plans (BCPs). RTOs for critical banking services are typically expected to be 4 hours or less, with RPOs of 1–2 hours for tier-1 systems.
NCA ECC Alignment: NCA ECC Article 2-9 mandates that organizations establish and maintain Disaster Recovery Plans (DRPs) with documented failover procedures, while Article 2-10 requires periodic testing and simulation exercises at least annually.
Practical Implementation Steps:
- Conduct a thorough BIA to identify critical processes and acceptable downtime thresholds.
- Define RTO/RPO for each critical system — core banking, payment rails, and customer-facing channels.
- Develop tiered BCPs: site-level, system-level, and crisis communication plans.
- Establish an alternate/hot site that meets SAMA's geographic separation requirements.
- Test plans through tabletop exercises, functional drills, and full failover simulations annually.
- Integrate BCM with your Cybersecurity Incident Response Plan to cover ransomware and cyber-induced outage scenarios.
Documentation of test results, gaps identified, and remediation actions must be maintained and submitted during SAMA regulatory reviews. A common weakness is treating BCM as an annual checkbox — successful institutions embed it into change management and release processes year-round.
Business Continuity Management (BCM) is a mandatory domain under SAMA CSF, addressed comprehensively in Domain 3.5 — Resilience. Financial institutions must build and maintain a BCM program that ensures critical operations can withstand and recover from disruptive incidents, whether cyber-related or operational.
Core components required by SAMA CSF:
- Business Impact Analysis (BIA): Identify and prioritize critical business functions, define Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) for each, and map dependencies on technology and third-party services.
- Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP): Develop documented, tested plans that address various disruption scenarios including ransomware attacks, data center failures, and key personnel unavailability.
- Crisis Management Framework: Establish a crisis management team with defined roles and escalation paths. SAMA expects named executives and deputies to be designated for continuity decisions.
- Testing and Exercises: SAMA CSF Control 3.5.4 requires that BCM plans be tested at least annually through tabletop exercises, functional drills, or full simulation tests. Results must be documented and gaps remediated.
- Integration with Cyber Incident Response: BCM must be aligned with the Cyber Incident Response Plan (CIRP) to ensure coordinated response during cyber disruptions, including ransomware or DDoS attacks targeting financial services.
- Regulatory Reporting: Any incident triggering BCP activation must be reported to SAMA within defined timeframes per the SAMA Cyber Incident Reporting Framework.
Fintechs should pay special attention to cloud dependencies, SaaS provider continuity, and ensuring contractual SLAs with vendors include documented RTOs aligned with their own SAMA-approved thresholds.
Business Continuity Management (BCM) is a mandatory domain under SAMA CSF, and for fintechs — given their digital-first nature and reliance on third-party infrastructure — it carries elevated risk. SAMA CSF Domain 4 (Operational Resilience) sets the overarching expectations, requiring that all member organizations establish, test, and maintain comprehensive BCM programs.
Core Requirements:
Business Impact Analysis (BIA): SAMA CSF Control 4.1 requires fintechs to conduct a formal BIA identifying critical business processes, dependencies, maximum tolerable downtime (MTD), recovery time objectives (RTO), and recovery point objectives (RPO). For payment services, RTOs are typically expected to be under 4 hours.
Business Continuity Plan (BCP) & Disaster Recovery Plan (DRP): Both must be documented, approved by senior management, and reviewed at least annually. DRP must address IT system recovery sequencing and failover procedures.
Testing & Exercises: SAMA expects regular tabletop exercises (at minimum annually) and full DR drills. Test results must be documented, gaps identified, and improvement actions tracked.
Communication Plans: BCPs must include internal escalation paths and external stakeholder communication protocols, including notification to SAMA in cases of significant operational disruptions.
Third-Party Resilience: Fintechs must validate the BCM posture of critical technology vendors (e.g., cloud providers, payment processors) as part of their overall resilience strategy.
ISO 22301 Alignment: While not explicitly mandated, aligning your BCM program with ISO 22301 significantly eases SAMA audit readiness and demonstrates a mature, internationally recognized approach to operational resilience.
Fintechs should treat BCM not as a compliance checkbox, but as a core operational risk discipline that directly protects customer trust and regulatory standing.
Business Continuity Management (BCM) is a critical compliance obligation for Saudi financial institutions. Both SAMA CSF and NCA ECC set explicit expectations that institutions must meet.
SAMA CSF Requirements (Control Domain 3.4): SAMA requires a formal BCM program covering Business Impact Analysis (BIA), Business Continuity Plans (BCP), and Disaster Recovery Plans (DRP). Key mandates include:
- RTO (Recovery Time Objective) and RPO (Recovery Point Objective) must be defined per critical system
- BCP must be tested at minimum annually through tabletop exercises, and full DR failover tests at least every two years
- SAMA expects BCM to align with the institution's risk appetite and be approved by senior management
NCA ECC Requirements (Article 2-13): NCA ECC mandates resilience controls including redundant systems, failover capabilities, and documented recovery procedures. Institutions must ensure cybersecurity continuity is embedded within the broader BCM framework.
Practical Implementation Steps:
- Conduct a formal BIA to identify critical business processes and their dependencies
- Define RTOs and RPOs in alignment with SAMA's operational resilience thresholds
- Develop tiered BCP and DRP documents covering people, process, and technology
- Establish an alternate site (hot, warm, or cold standby) for critical banking operations
- Integrate cyber incident scenarios into BCP testing, including ransomware and DDoS simulation
- Maintain an annual test schedule and document results with lessons learned
PDPL Consideration: Under Saudi PDPL, personal data must remain protected even during disaster recovery operations. Ensure DR environments enforce the same data protection controls as production.
Business Continuity Management under SAMA CSF is governed primarily by Domain 4 (Cyber Resilience), which mandates that Member Organizations establish, maintain, and test a comprehensive BCM program. Here are the core requirements and implementation steps:
1. BCM Policy & Governance (SAMA CSF Control 4.1) Establish a board-approved BCM policy that defines RTO (Recovery Time Objective) and RPO (Recovery Point Objective) thresholds for critical banking systems. Assign a dedicated BCM owner at the senior management level.
2. Business Impact Analysis (BIA) Conduct a formal BIA annually to identify critical business functions, dependencies, and acceptable downtime limits. For core banking systems, SAMA expects RTO to typically not exceed 4 hours for Tier-1 institutions.
3. Disaster Recovery Planning (SAMA CSF Control 4.3) Maintain a documented and tested Disaster Recovery Plan (DRP) covering IT systems, data centers, and third-party dependencies. DR sites must be geographically separated and tested at least annually through full failover exercises.
4. Testing & Exercising SAMA CSF requires at minimum annual tabletop exercises and bi-annual technical DR drills. Results must be documented, gaps remediated, and evidence retained for regulatory review.
5. Alignment with NCA ECC NCA ECC Article 3-8 also addresses resilience requirements. Ensure your BCM program satisfies both frameworks to avoid duplicate audit findings.
Practical Tip: Integrate your BCM program with your Cyber Incident Response Plan (CIRP) so that a major cyber incident automatically triggers BCM protocols. This alignment is increasingly scrutinized during SAMA on-site examinations.
Business Continuity Management (BCM) is a mandatory component under SAMA CSF Domain 4 and NCA ECC Control 2-10, requiring Saudi financial institutions to maintain resilient operations against disruptions, cyber incidents, and disasters.
SAMA CSF BCM Requirements (Domain 4.1):
- Develop and maintain a formal Business Continuity Policy approved by senior management
- Conduct Business Impact Analysis (BIA) to identify critical business functions and their maximum tolerable downtime (MTD)
- Define Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) for all critical systems — for core banking, SAMA typically expects RTO within 4 hours
- Establish and test Disaster Recovery Plans (DRP) for IT systems at least annually through simulated exercises
NCA ECC Control 2-10 Alignment:
- Requires cybersecurity considerations to be embedded within BCM, including cyber-specific recovery scenarios
- Mandates that BCM plans account for ransomware, DDoS, and supply chain disruption scenarios
Testing & Exercises:
- Tabletop exercises, functional drills, and full failover tests must be documented
- Results, gaps, and corrective actions must be formally recorded and tracked
- SAMA examiners will request evidence of test outcomes during assessments
Integration with Incident Response:
- BCM and Incident Response Plans must be aligned to avoid conflicting procedures during crisis activation
- Assign clear crisis communication roles including regulatory notification to SAMA within required timeframes
Practical Tip: Establish a BCM Steering Committee with cross-functional representation (IT, Operations, Risk, Legal) to ensure enterprise-wide ownership and alignment with SAMA's governance expectations.
Business Continuity Management (BCM) is a critical regulatory obligation for Saudi financial institutions under SAMA CSF Domain 4, specifically Controls 4.3.1 through 4.3.6. A compliant BCM program must address the following areas:
1. Business Impact Analysis (BIA):
- Identify and classify critical business processes, their dependencies, and maximum tolerable downtime (MTD).
- Define Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) for each critical system.
- BIA results must be reviewed and updated at least annually or after major changes.
2. Business Continuity Plan (BCP) Development:
- Document detailed recovery procedures for all critical functions.
- Assign clear roles, responsibilities, and escalation paths.
- Plans must address both cyber-incident-triggered disruptions and physical/environmental events.
3. Disaster Recovery (DR) Planning:
- Maintain a tested, operational DR site — SAMA expects financial institutions to have geographically separated primary and secondary data centers.
- DR failover capabilities must meet defined RTO/RPO commitments.
4. Testing and Exercising:
- SAMA CSF Control 4.3.5 requires regular BCM testing, including tabletop exercises and full failover drills.
- Testing must be conducted at least annually, with results documented and lessons learned incorporated.
5. Integration with Cyber Incident Response:
- BCM must be tightly integrated with the Cyber Incident Response Plan (CIRP) to ensure seamless activation during cybersecurity incidents.
6. Governance and Reporting:
- BCM program ownership should sit at the executive level (COO or CRO), with the CISO responsible for the cyber resilience component.
- Annual BCM reports must be presented to the Board Risk Committee.
Key practical advice: Regulators increasingly scrutinize the gap between documented plans and actual tested capabilities — invest in realistic simulation exercises.
Under SAMA CSF Domain 4 (Operational Resilience), Saudi financial institutions must establish a comprehensive Business Continuity Management program that addresses both technology and operational risks. Key requirements include:
1. BCP Documentation & Governance: Per SAMA CSF Control 4.1, institutions must maintain formally approved BCM policies, define clear ownership at the board level, and embed BCM into strategic planning cycles.
2. Business Impact Analysis (BIA): Control 4.2 requires a structured BIA that identifies critical business functions, maximum tolerable downtime (MTD), recovery time objectives (RTO), and recovery point objectives (RPO) for all core banking systems.
3. Testing & Exercising: SAMA mandates at least annual BCM tests, including tabletop exercises and full simulation drills. Results must be documented and remediation actions tracked.
4. IT Disaster Recovery Alignment: BCM must be integrated with IT Disaster Recovery Plans (DRP), ensuring that DR environments — whether on-premises or cloud-hosted — are tested independently and meet SAMA's data residency expectations.
5. Third-Party Coverage: BCM scope must extend to critical service providers. Vendors supporting core banking, payment processing, or data hosting must demonstrate their own BCM capabilities contractually.
6. PDPL Alignment: When activating recovery procedures, institutions must ensure personal data processed during failover scenarios remains protected per PDPL Article 19 obligations.
Practically, institutions should maintain a BCM register, schedule quarterly reviews, and report BCM status to the board risk committee at least semi-annually. SAMA may request BCM documentation during regulatory inspections, so audit-readiness is essential.
Business Continuity Management (BCM) is a critical regulatory obligation for Saudi banks under SAMA CSF Domain 3.4 (Resilience) and is further reinforced by SAMA's dedicated Business Continuity Management Guidelines. Here is a structured approach to achieving full compliance:
1. Establish a Formal BCM Program: SAMA requires a board-approved BCM policy that defines Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) for all critical systems. For core banking platforms, RTOs are typically expected to be four hours or less.
2. Conduct Business Impact Analysis (BIA): Identify critical business functions, their dependencies on IT systems, and the financial/reputational impact of disruption. The BIA must be reviewed annually and after significant organizational changes.
3. Develop and Maintain Plans: You need three interconnected plans:
- Business Continuity Plan (BCP): Covers operational continuity
- IT Disaster Recovery Plan (DRP): Covers technical recovery of systems
- Crisis Communication Plan: Covers internal and SAMA notification procedures
4. Testing Requirements: SAMA CSF mandates regular testing — tabletop exercises at minimum annually, and full failover DR tests at least once per year. Results must be documented and gaps remediated.
5. Third-Party Dependencies: BCM must account for critical vendor dependencies. If a core system provider experiences outage, your plan must address continuity.
6. SAMA Notification: In the event of a significant disruption impacting customer services, SAMA expects notification within defined timeframes per the incident reporting framework.
Integrating your BCM documentation into a centralized GRC platform ensures version control, audit trails, and real-time test tracking.
Business continuity management under SAMA CSF (Domain 4, Controls 4.3.1–4.3.6) requires Saudi financial institutions to maintain a comprehensive, tested, and regularly updated BCM program. Key requirements include: (1) Business Impact Analysis (BIA): Identify critical business functions, acceptable recovery time objectives (RTO), and recovery point objectives (RPO) for all core banking systems. (2) Business Continuity Plan (BCP): Document recovery procedures for people, processes, technology, and facilities. Plans must cover scenarios including cyberattacks, not just natural disasters. (3) Disaster Recovery (DR): Maintain a geographically separated DR site within the Kingdom, with data replication aligned to RPO targets. SAMA requires DR sites to be activated and tested at least annually. (4) Testing and Exercises: Conduct tabletop exercises and full DR failover tests at least once per year. Results must be documented, gaps remediated, and evidence retained for SAMA examination. (5) Third-Party Dependencies: Map and address continuity risks from critical service providers, including cloud vendors and payment networks. Practically, banks should assign a dedicated BCM owner, integrate BCM into the overall risk management framework, and ensure board-level sign-off on the BCP annually. SAMA examiners will review test evidence, BIA documentation, and board minutes during assessments. Fintechs operating under SAMA oversight are equally subject to these requirements and must demonstrate proportional BCM maturity relative to their operational scale.
Business Continuity Management (BCM) for Saudi financial institutions sits at the intersection of operational resilience and regulatory compliance. SAMA CSF Domain 3.6 mandates a fully documented BCM framework that includes Business Impact Analysis (BIA), Recovery Time Objectives (RTO), Recovery Point Objectives (RPO), and tested Disaster Recovery Plans (DRP).
Key implementation steps include: (1) Conduct a BIA identifying critical business processes, dependencies, and acceptable downtime thresholds — SAMA expects RTOs for critical systems to be no more than 4 hours; (2) Develop and maintain a Business Continuity Plan (BCP) covering crisis communication, staff roles, and alternate processing sites; (3) Test your BCP at least annually through tabletop exercises, simulations, or full failover drills, with results documented and presented to the Board; (4) Integrate cyber incident scenarios — ransomware, DDoS, and data breach — into your continuity planning, aligning with SAMA CSF Control 3.6.5.
The PDPL dimension adds a critical data protection layer: if a business disruption involves personal data unavailability or breach, Article 24 of PDPL requires notification to the Saudi Data & AI Authority (SDAIA) within a defined timeframe. Your BCP must therefore include a data breach response workflow that triggers PDPL notification obligations simultaneously with operational recovery.
Best practice is to align your BCM documentation with ISO 22301, which SAMA accepts as a recognized standard, and to cross-reference NCA ECC controls 2-15 for cybersecurity resilience requirements. Our platform provides BCM templates pre-mapped to all relevant frameworks.
SAMA CSF Domain 4 — Business Continuity Management — sets comprehensive expectations for Saudi financial institutions to maintain operational resilience. A compliant BCM program must cover the following pillars: (1) Business Impact Analysis (BIA): Per SAMA CSF Control 4.1.2, conduct a formal BIA at least annually to identify critical business functions, Maximum Tolerable Downtime (MTD), Recovery Time Objectives (RTO), and Recovery Point Objectives (RPO) for all critical systems including core banking, payment infrastructure, and digital channels. (2) BCM Policy and Governance: Establish a board-approved BCM policy with clearly defined roles, responsibilities, and escalation paths. The CISO and BCM owner must coordinate closely, as cybersecurity incidents are a primary BCM trigger. (3) Business Continuity Plans (BCPs) and Disaster Recovery Plans (DRPs): Develop and maintain tested BCPs for all critical business units and technical DRPs for IT systems. Plans must be reviewed after every significant incident or change, and at minimum annually. (4) Testing and Exercises: SAMA CSF Control 4.3 requires regular BCM tests — including tabletop exercises, functional drills, and full failover tests for critical systems. Results must be documented and findings tracked to closure. (5) Crisis Communication: Define internal and external communication protocols covering regulators (SAMA, NCA), customers, and media. (6) Third-Party Dependencies: Map BCM obligations to critical vendors and ensure contractual alignment. Integrate your BCM program into your GRC platform to maintain living documentation, automate test scheduling, and generate audit-ready reports for SAMA examinations.
Under SAMA CSF Domain 3 (Cybersecurity Operations), specifically Controls 3.3.1 through 3.3.5, Saudi banks must implement a comprehensive Identity and Access Management program addressing several critical areas:
Privileged Access Management (PAM): All privileged accounts (system administrators, database admins, network engineers) must be inventoried, subject to multi-factor authentication (MFA), and monitored via privileged access workstations. Standing privileged access should be minimized in favor of just-in-time (JIT) access models.
Least Privilege Principle: Role-based access control (RBAC) must be enforced across all systems, with access rights reviewed at minimum semi-annually. Segregation of duties (SoD) controls must prevent any single user from having end-to-end control over critical financial transactions.
User Lifecycle Management: Onboarding, transfer, and offboarding procedures must be formally documented. Departing employees' access must be revoked within 24 hours of termination, with immediate revocation for involuntary departures.
Directory Services: Active Directory or equivalent identity providers must enforce password complexity, account lockout thresholds, and session timeout policies aligned with SAMA CSF Appendix requirements.
Third-Party and Vendor Access: Remote vendor access must be time-limited, logged, and conducted through secure jump servers or PAM solutions — never via shared credentials.
From an ISO 27001 alignment perspective (Annex A Control 5.15–5.18), these requirements map directly to information access controls and privileged access procedures.
Practical Recommendation: Conduct a quarterly IAM audit using your GRC platform to flag orphaned accounts, excessive privileges, and SoD violations before your SAMA assessment cycle. Document all exceptions with formal risk acceptance sign-off from your CISO.
Cybersecurity governance is the foundational pillar that regulators evaluate first during SAMA examinations. Building a robust governance structure requires deliberate mapping between SAMA CSF and ISO 27001.
SAMA CSF Governance Requirements: SAMA CSF Domain 1 (Cybersecurity Leadership and Governance) requires financial institutions to establish a Board-approved Cybersecurity Strategy, a dedicated Cybersecurity Function reporting to senior management, and a formal Cybersecurity Policy Framework. Control 1.1 mandates that the Board receive cybersecurity risk reports at least quarterly, and the CISO role must have clear independence from IT operations.
ISO 27001 Alignment: ISO 27001:2022 Clause 5 (Leadership) and Clause 6 (Planning) directly complement SAMA CSF Domain 1. Institutions can leverage an ISO 27001-certified ISMS as documented evidence during SAMA assessments, demonstrating control implementation across Annex A domains. Gap analysis should map each SAMA CSF control to its ISO 27001 counterpart to eliminate duplication of effort.
Practical Governance Structure:
- Establish a Cybersecurity Steering Committee chaired by the CEO or COO with CISO, CRO, and Business Unit representation.
- Define a three-lines-of-defence model: Security Operations (1st), Risk & Compliance (2nd), Internal Audit (3rd).
- Develop a Policy Framework with a Master Cybersecurity Policy, supported by topic-specific standards (e.g., Access Control, Encryption, Incident Response).
- Implement a cybersecurity KRI/KPI dashboard reported to the Board Risk Committee quarterly per SAMA CSF Control 1.2.
- Schedule annual governance framework reviews aligned with ISO 27001 management review cycles.
Institutions that integrate both frameworks reduce audit fatigue significantly while achieving a stronger overall security posture.
Security awareness training is a foundational control under both SAMA CSF (Domain 2.3 – Human Resource Security) and NCA ECC (Control 1-3 – Cybersecurity Awareness and Training). Saudi financial institutions must implement structured, role-based training programs that address the following requirements:
SAMA CSF Requirements:
- All staff must complete cybersecurity awareness training at least annually, with records maintained for audit purposes.
- Privileged users and IT/security personnel require specialized, role-based training covering topics such as secure development, incident handling, and access management.
- New joiners must complete onboarding security training before or immediately upon gaining access to systems.
NCA ECC Requirements:
- Control 1-3 mandates a formal Cybersecurity Awareness Program with defined objectives, target audiences, delivery methods, and measurable KPIs.
- Training must cover phishing, social engineering, password hygiene, acceptable use policies, and incident reporting procedures.
Practical Implementation Guidance:
- Conduct an annual training needs assessment segmented by job role.
- Use a Learning Management System (LMS) to deliver, track, and report training completion.
- Run simulated phishing campaigns quarterly to measure behavioral change.
- Document all training completion records and present them during SAMA regulatory examinations.
- Include third-party contractors and vendors with access to sensitive systems in the training scope.
Non-compliance with these controls is a common finding during SAMA onsite inspections and can result in a lower maturity rating, impacting your institution's overall CSF assessment score.
Under SAMA CSF Control 3.3.1 (Human Resources Security), Saudi financial institutions are required to implement a formal, risk-based cybersecurity awareness and training program covering all employees, contractors, and privileged users. The program must be conducted at least annually, with role-specific training for personnel handling sensitive data or critical systems. Key requirements include: (1) Onboarding security orientation for all new hires before system access is granted; (2) Annual refresher training covering phishing, social engineering, password hygiene, and data handling; (3) Specialized technical training for IT, security, and developer teams aligned with their specific risk exposure; (4) Phishing simulation exercises to measure and improve employee vigilance; (5) Board and senior management briefings on cyber risk governance. Training effectiveness must be measured through KPIs such as phishing click-through rates, quiz scores, and completion rates, and documented for regulatory review. SAMA expects evidence of training records during examinations. Institutions should also align their programs with NCA ECC Article 2-8, which reinforces human security controls. Practical tip: Integrate awareness training into your GRC platform to automate scheduling, track completion, generate audit-ready reports, and trigger remediation workflows for employees who fail simulated phishing tests.
Cyber incident response for Saudi banks is governed primarily by SAMA CSF Control 3.5 (Cybersecurity Incident Management), which requires institutions to maintain a formally documented Incident Response Plan (IRP) that is tested at least annually through tabletop exercises or simulations. The IRP must define clear roles, escalation paths, containment procedures, and recovery objectives.
From a regulatory reporting perspective, SAMA requires that significant cybersecurity incidents — particularly those affecting customer data, core banking systems, payment infrastructure, or public-facing services — be reported to SAMA within 72 hours of detection. This timeline aligns with PDPL Article 27 requirements for personal data breach notification to the Saudi Data and Artificial Intelligence Authority (SDAIA). For critical infrastructure incidents, NCA ECC Article 4-3 may trigger parallel reporting obligations to the National Cybersecurity Authority.
The definition of a 'reportable' incident under SAMA typically includes: unauthorized access to customer accounts, ransomware or destructive malware affecting operations, DDoS attacks causing service unavailability exceeding defined thresholds, data exfiltration, and fraudulent transactions linked to a systemic compromise.
Post-incident, SAMA expects a formal Root Cause Analysis (RCA) report within 30 days, along with a remediation roadmap. Institutions must also maintain an incident log and demonstrate lessons-learned integration into their security controls.
Practically, your GRC platform should automate incident intake, classification by severity, and stakeholder notification workflows — ensuring that your team can trigger the right regulatory reporting chain within the 72-hour window without relying on manual processes under pressure.
Under SAMA CSF Control Domain 3.3 (People), Saudi financial institutions are required to implement a structured, role-based cybersecurity awareness and training program covering all staff, contractors, and third parties with access to critical systems. At minimum, programs must include: (1) Annual mandatory awareness training for all employees, with documented completion records; (2) Specialized technical training for IT and security personnel, aligned with their specific responsibilities; (3) Executive and board-level briefings on cyber risk governance; and (4) Phishing simulation exercises conducted at least quarterly. Programs should be mapped to real threats facing the Saudi financial sector, including social engineering, credential theft, and BEC (Business Email Compromise) attacks. Per SAMA CSF Control 3.3.2, institutions must maintain training completion metrics and report gaps to senior management. Practical structuring guidance: segment your curriculum into tiers — general staff, privileged users, developers, and executives — with differentiated content for each. Integrate PDPL obligations into training so employees understand data handling responsibilities. Leverage e-learning platforms with Arabic-language content to ensure accessibility across all workforce segments. Training effectiveness must be measured through post-training assessments, phishing click-rate tracking, and annual program reviews. Non-compliance in this domain is frequently cited in SAMA examination findings, making it a high-priority area for CISOs in Saudi banking.
Under SAMA CSF Control 3.3.1 (Security Awareness and Training), Saudi banks and financial institutions are required to establish a formal, risk-based Security Awareness and Training program that covers all employees, contractors, and privileged users. Here's a practical implementation roadmap:
Program Structure:
- Conduct an annual training needs assessment aligned to your organization's risk profile
- Develop role-based curricula: general staff, IT teams, and senior management each have distinct learning paths
- Include mandatory onboarding training for new hires and third-party staff with system access
Content Requirements:
- Social engineering, phishing simulation, and business email compromise (BEC) scenarios relevant to Saudi financial sector threats
- PDPL data handling obligations and confidentiality responsibilities
- Incident reporting procedures and escalation channels
- Acceptable use policies for critical systems
Delivery & Frequency:
- Minimum annual refresher training for all staff, with quarterly phishing simulations recommended
- Blended learning: e-learning modules, in-person workshops, and simulated attack exercises
- NCA ECC-3.3 also reinforces the need for continuous awareness campaigns, not just point-in-time training
Measurement & Reporting:
- Track completion rates, phishing click rates, and knowledge assessment scores
- Report program effectiveness to senior management and the board at least annually
- Use metrics to justify budget and demonstrate compliance during SAMA regulatory examinations
A mature SAT program is a leading indicator of your overall cybersecurity culture. Platforms like CISO Consulting can help automate tracking, generate compliance evidence, and align training content to your current threat landscape.
Third-party risk management (TPRM) is a critical obligation under SAMA CSF Domain 4 (Third-Party Management) and NCA ECC-1:2018 Control 3-8. Financial institutions must implement a structured lifecycle approach covering four key stages:
1. Vendor Due Diligence & Onboarding: Before engagement, conduct cybersecurity risk assessments for all vendors with access to sensitive systems or data. SAMA CSF requires classification of vendors by criticality tier, which directly determines the depth of assessment required.
2. Contractual Security Requirements: Embed mandatory security clauses into all vendor contracts, including right-to-audit provisions, incident notification SLAs (typically 24–72 hours per SAMA expectations), data handling obligations aligned with PDPL Article 29, and minimum acceptable security standards such as ISO 27001 certification.
3. Continuous Monitoring: Implement ongoing monitoring through annual reassessments for critical vendors, automated supply chain threat intelligence feeds, and periodic review of vendor security posture reports. NCA ECC Control 3-8-4 specifically mandates monitoring third-party access to organizational systems.
4. Offboarding & Access Revocation: Establish formal procedures for secure vendor offboarding, ensuring immediate revocation of access credentials and secure data return or destruction per PDPL requirements.
Practical recommendation: Maintain a centralized vendor risk register integrated into your GRC platform, enabling real-time risk scoring and automated compliance reporting. SAMA examiners routinely inspect TPRM documentation during regulatory reviews, so audit-ready records are essential. For fintechs leveraging multiple SaaS providers, prioritize vendors processing payment data or holding customer PII as your highest-risk tier.
Third-party risk management (TPRM) is a critical obligation under SAMA CSF Domain 4 (Third Party Management), which requires financial institutions to establish a structured, risk-based process for managing vendor and supplier cybersecurity risks throughout the relationship lifecycle.
Key Requirements:
- Pre-onboarding Assessment: Before engaging any third party with access to systems or sensitive data, conduct a cybersecurity due diligence assessment. Evaluate the vendor's security posture, certifications (e.g., ISO 27001), and compliance with NCA ECC controls.
- Contractual Controls (per SAMA CSF Control 4.2): Embed mandatory cybersecurity clauses in all vendor contracts, including the right to audit, incident notification obligations (within 72 hours), data handling requirements aligned with PDPL, and termination rights upon material breach.
- Ongoing Monitoring: Implement continuous monitoring for critical vendors — this includes periodic reassessments (at least annually), reviewing security incident reports, and conducting on-site or remote audits.
- Tiered Risk Classification: Categorize vendors by risk level (Critical, High, Medium, Low) based on data access, system integration depth, and regulatory sensitivity. Apply proportionate controls accordingly.
- Exit Strategy: Maintain documented exit and transition plans to ensure business continuity if a third party fails or is terminated.
Practical Tip: Use a standardized vendor questionnaire mapped to SAMA CSF and NCA ECC controls. For cloud service providers, additionally apply the NCA Cloud Cybersecurity Controls (CCC) framework. Document all assessments in your GRC platform for audit readiness and regulatory inspection by SAMA examiners.
Under SAMA CSF Control Domain 3.3 (Third-Party Management), Saudi financial institutions must implement a structured TPRM program covering the full vendor lifecycle. Here is a practical framework:
1. Vendor Classification & Risk Tiering Categorize vendors by criticality — Tier 1 (critical/high-risk, e.g., core banking providers, cloud hosts), Tier 2 (moderate), and Tier 3 (low-risk). Per SAMA CSF Control 3.3.2, due diligence depth must match the vendor's risk tier.
2. Pre-Onboarding Due Diligence Before contracting, assess vendors against: cybersecurity posture (ISO 27001 certification or equivalent), data handling practices aligned with PDPL obligations, sub-contractor exposure, and financial stability. Obtain evidence of relevant certifications and conduct questionnaire-based assessments.
3. Contractual Safeguards Contracts must include: right-to-audit clauses, cybersecurity incident notification obligations (within 72 hours per PDPL Article 19 if personal data is involved), data residency requirements (Saudi Arabia for sensitive financial data), and SLA-linked security KPIs.
4. Continuous Monitoring Conduct annual reassessments for Tier 1 vendors and biennial reviews for Tier 2. Use automated threat intelligence feeds to monitor vendor breach news and security ratings.
5. Offboarding Controls Ensure secure data deletion, certificate revocation, and access termination upon vendor exit — documenting closure per SAMA CSF Control 3.3.5.
NCA ECC Alignment: NCA ECC Article 2-8 reinforces third-party controls for government-adjacent financial entities.
Our GRC platform automates vendor questionnaires, tracks remediation timelines, and generates SAMA-ready TPRM reports — reducing manual effort by up to 60%.
Third-party risk management is a critical compliance obligation for Saudi financial institutions. Under SAMA CSF Control 3.3, member organizations must establish a formal TPRM framework that covers the entire vendor lifecycle — from onboarding due diligence through contract management to offboarding. NCA ECC Article 2-14 further mandates that critical suppliers undergo cybersecurity assessments before being granted access to organizational systems or data.
A robust TPRM program should include the following components:
1. Vendor Classification & Tiering: Categorize vendors by criticality (Tier 1–3) based on data access, system integration depth, and business dependency. Critical fintech partners and cloud providers typically fall into Tier 1 and require the most rigorous oversight.
2. Pre-Onboarding Assessment: Conduct cybersecurity due diligence using standardized questionnaires aligned with SAMA CSF domains. Verify ISO 27001 certification where applicable and review SOC 2 Type II reports for cloud vendors.
3. Contractual Obligations: Ensure all vendor contracts include cybersecurity clauses covering incident notification timelines (within 24 hours per SAMA guidelines), right-to-audit provisions, and data handling obligations consistent with PDPL Article 19.
4. Continuous Monitoring: Implement ongoing risk scoring using threat intelligence feeds and periodic reassessments — at least annually for Tier 1 vendors.
5. Concentration Risk: SAMA expects boards to be aware of concentration risk when multiple critical services depend on a single third party.
CISOs should maintain a centralized vendor risk register and present quarterly TPRM status reports to the board's risk committee. Regulators increasingly scrutinize TPRM maturity during SAMA examinations, making documentation and evidence collection as important as the controls themselves.
Under SAMA CSF Control Domain 3.3 (Third-Party Management), Saudi banks must implement a structured, risk-based approach to managing vendor and supplier relationships. Here's a practical framework:
Pre-Onboarding Due Diligence: Before engaging any third party with access to systems or data, conduct a formal cybersecurity risk assessment. Evaluate the vendor's security posture against SAMA CSF and ISO 27001 standards. Require evidence of certifications, audit reports (SOC 2, ISO 27001), and completed security questionnaires.
Contractual Obligations: All third-party contracts must include cybersecurity clauses covering data protection, incident notification timelines (typically 72 hours per PDPL obligations), right-to-audit provisions, and compliance with NCA ECC requirements where applicable.
Tiered Risk Classification: Classify vendors into Critical, High, Medium, and Low risk tiers based on their access level, data sensitivity, and operational dependency. Critical vendors (e.g., core banking system providers, cloud infrastructure) require annual reassessments and on-site audits.
Continuous Monitoring: Implement ongoing monitoring through periodic questionnaires, security ratings platforms, and review of vendor security bulletins. SAMA expects banks to maintain an updated third-party inventory with associated risk scores.
Exit Strategy: Document formal off-boarding procedures including data return/destruction certificates and access revocation timelines.
Practically, assign a dedicated Third-Party Risk Owner within your GRC team and integrate vendor assessments into your enterprise risk register. Regulators increasingly scrutinize supply chain risk, particularly for cloud and fintech partnerships, so documented evidence of this program is essential during SAMA examinations.
Third-party risk management is a critical obligation under SAMA CSF Domain 4 (Third Party Management), which requires Saudi banks to establish a formal, risk-based vendor management program. Here's how to implement it effectively:
1. Vendor Classification & Risk Tiering: Classify all third parties (cloud providers, fintech partners, IT vendors) based on data sensitivity, criticality of services, and access levels. SAMA CSF requires higher scrutiny for vendors with access to critical systems or customer data.
2. Pre-Onboarding Due Diligence: Before engagement, conduct cybersecurity assessments including review of ISO 27001 certifications, SOC 2 reports, and NCA ECC alignment. Require vendors to complete a security questionnaire aligned with SAMA CSF controls.
3. Contractual Security Requirements: Embed cybersecurity clauses in all vendor contracts covering: incident notification timelines (per SAMA CSF Control 4.3), data handling obligations under PDPL, right-to-audit provisions, and minimum security standards.
4. Continuous Monitoring: Don't treat vendor risk as a one-time assessment. Implement continuous monitoring through annual reassessments, periodic penetration testing of vendor-connected interfaces, and real-time threat intelligence on critical suppliers.
5. Offboarding Controls: Ensure data return/deletion processes are documented and verified upon contract termination, aligning with PDPL Article 19 on data retention.
Practical Tip: Maintain a centralized vendor risk register reviewed quarterly by your risk committee. SAMA examiners frequently assess the maturity of your third-party risk program during regulatory reviews, so documentation quality matters as much as the controls themselves.
Under SAMA CSF Domain 3.3 (Third-Party Management), Saudi banks must implement a structured TPRM program that spans the entire vendor lifecycle — from onboarding through offboarding.
Key Requirements:
- Risk Classification: Categorize vendors by criticality (Tier 1: critical/outsourced core banking; Tier 2: significant access; Tier 3: limited exposure). SAMA CSF Control 3.3.2 mandates risk-based due diligence prior to engagement.
- Contractual Controls: Ensure all vendor contracts include cybersecurity obligations, audit rights, incident notification clauses (within 72 hours per SAMA CSF 3.3.5), and data handling requirements aligned with PDPL Article 5.
- Ongoing Monitoring: Conduct annual cybersecurity assessments for Tier 1 vendors, including review of their ISO 27001 certification, SOC 2 reports, or completion of a standardized questionnaire aligned with NCA ECC controls.
- Cloud and Outsourcing: For cloud-based third parties, apply SAMA's Outsourcing Requirements and NCA Cloud Cybersecurity Controls (CCC-1 through CCC-4), ensuring data sovereignty requirements are met — particularly that sensitive customer data processed by third parties remains within approved jurisdictions.
- Offboarding: Define secure data disposal and access revocation procedures documented per SAMA CSF 3.3.8.
Practical Tip: Maintain a centralized Third-Party Register with risk scores, assessment dates, and contractual compliance status. This register is frequently reviewed during SAMA regulatory examinations. Automating this within your GRC platform significantly reduces audit preparation time and ensures continuous compliance visibility.
Third-party risk management (TPRM) is a critical obligation for Saudi financial institutions under SAMA CSF Domain 4 (Third-Party Management) and NCA ECC-1:2018 Article 3-5. Here is how to build a compliant program:
1. Vendor Classification & Risk Tiering Classify vendors based on data access, criticality, and integration depth. SAMA CSF Control 4.3 requires a formal classification methodology distinguishing critical from non-critical suppliers.
2. Pre-Onboarding Due Diligence Before engagement, conduct cybersecurity assessments including review of ISO 27001 certification, SOC 2 reports, and security questionnaires. Verify that cloud or SaaS vendors hosting financial data hold NCA approval where applicable.
3. Contractual Security Requirements Embed security clauses covering data handling, breach notification timelines (PDPL requires notifying SDAIA within 72 hours), right-to-audit provisions, and minimum security controls aligned with SAMA CSF.
4. Continuous Monitoring SAMA CSF Control 4.5 mandates ongoing oversight — not just point-in-time assessments. Use threat intelligence feeds, vendor security scorecards, and periodic reassessments (at least annually for critical vendors).
5. Exit & Termination Procedures Document data return and secure deletion processes upon contract termination, ensuring no residual data exposure.
6. Concentration Risk Awareness SAMA also expects boards to understand concentration risk — where multiple critical functions depend on a single third party.
A mature TPRM program protects your institution from supply-chain attacks and regulatory findings during SAMA examinations. Platforms like CISO Consulting can automate vendor risk scoring and map findings directly to SAMA CSF controls.
Third-party risk management (TPRM) is a critical obligation under SAMA CSF Domain 3.3 (Third-Party Management), requiring Saudi banks to establish a structured program covering the full vendor lifecycle. Here's a practical approach:
Pre-Engagement Assessment: Before onboarding any vendor with access to systems or data, conduct a cybersecurity due diligence review. Per SAMA CSF Control 3.3.1, vendors must be classified based on risk level — critical, high, medium, or low — depending on data sensitivity, system access, and regulatory impact.
Contractual Controls: All vendor contracts must include cybersecurity clauses addressing data handling, incident notification timelines (typically 72 hours), audit rights, and compliance with PDPL obligations if personal data is involved.
Ongoing Monitoring: SAMA CSF Control 3.3.3 mandates periodic reassessment of vendor risk posture. For critical vendors, this should occur at least annually, including review of their ISO 27001 certifications, penetration test results, and SOC 2 reports where available.
Exit Strategy: Define clear data return and destruction procedures for vendor offboarding, aligned with NCA ECC Article 2-14 on data lifecycle management.
Practical Tip: Use a vendor risk register maintained within your GRC platform to automate assessment workflows, track remediation deadlines, and generate audit-ready evidence for SAMA examination teams. Fintech companies should pay particular attention to cloud service providers and payment processors, as these often carry the highest concentration of risk.
Security awareness training is often underestimated, yet it is explicitly mandated and audited under both SAMA CSF and NCA ECC. A well-structured program goes far beyond annual click-through videos.
Regulatory Baseline:
- SAMA CSF Control 3.2.1 requires a formal cybersecurity awareness and training program tailored to staff roles.
- NCA ECC Article 2-7 mandates periodic awareness campaigns covering phishing, social engineering, and acceptable use policies.
Program Structure — What Auditors Look For:
- Role-Based Training: Generic training is insufficient. Segment your audience — executives require board-level briefings on cyber risk and governance; IT staff need technical deep-dives; general staff need phishing simulation and social engineering awareness.
- Frequency: SAMA expects at least annual mandatory training with documented completion records. For high-risk roles (e.g., privileged users, finance teams), quarterly refreshers are strongly recommended.
- Phishing Simulations: Run monthly or quarterly simulated phishing campaigns. Track click rates, report rates, and repeat offenders. Use results to trigger targeted remediation training — and maintain these records for SAMA examination.
- New Hire Onboarding: Security awareness must be embedded in onboarding programs within the first 30 days of employment.
- Metrics and Reporting: Report training completion rates, simulation results, and awareness KPIs to the CISO and board on a quarterly basis. This demonstrates a mature, measurable program.
- PDPL Awareness: Since Saudi PDPL imposes personal liability on staff handling personal data, include dedicated modules on data handling, consent, and breach reporting obligations.
Document everything rigorously — training logs, attendance records, and phishing simulation reports are standard evidence requests during SAMA regulatory inspections.
Third-party risk management (TPRM) is a critical compliance obligation under SAMA CSF Domain 3 (Cybersecurity Risk Management), specifically controls 3.3.1 through 3.3.5, which require financial institutions to assess, monitor, and govern all third-party relationships that touch sensitive systems or data.
To build a compliant TPRM program, Saudi banks should:
- Vendor Classification: Categorize all vendors by criticality — Tier 1 (critical/direct system access), Tier 2 (moderate risk), Tier 3 (low risk). SAMA CSF Control 3.3.2 mandates risk-based classification.
- Pre-Onboarding Due Diligence: Conduct cybersecurity assessments before contract signing. This includes reviewing ISO 27001 certifications, SOC 2 reports, or equivalent evidence of security posture.
- Contractual Controls: Ensure contracts include cybersecurity clauses covering incident notification timelines (typically 72 hours), right-to-audit provisions, and data handling obligations aligned with PDPL Article 19.
- Continuous Monitoring: SAMA CSF requires ongoing oversight — not just point-in-time assessments. Use automated tools or periodic questionnaires to monitor Tier 1 vendors at least annually, and Tier 2 vendors biannually.
- Fourth-Party Risk: Identify and assess sub-processors used by your critical vendors, particularly cloud providers or payment processors.
- Exit Strategy: Maintain documented offboarding procedures to revoke access and retrieve or destroy data when vendor relationships end.
NCA ECC Article 2-14 further reinforces these obligations for entities within the national cybersecurity scope. Non-compliance with TPRM controls is a frequent finding in SAMA regulatory examinations and can result in formal corrective action plans.
Security awareness training is not optional for Saudi financial institutions — it is a formal regulatory requirement embedded in SAMA CSF Domain 3.2 (Human Resources Security), and a contributing control under NCA ECC Article 4.
SAMA CSF Requirements:
- Control 3.2.1 requires institutions to implement a cybersecurity awareness program covering all employees, contractors, and privileged users.
- Training must be role-based: general staff receive phishing and social engineering awareness, while IT and security teams receive technically advanced content.
- New joiners must complete foundational cybersecurity training before or immediately after system access is granted.
- Annual refresher training is mandatory, with records maintained for audit purposes.
What Makes a Program Effective:
- Phishing Simulations: Run monthly or quarterly simulated phishing campaigns and track click rates over time. SAMA examiners look for measurable improvement metrics.
- Role-Based Modules: Tailor content for executives (social engineering, deepfake fraud), customer-facing staff (account takeover, vishing), and developers (secure coding, OWASP Top 10).
- Arabic-First Content: Ensure training materials are delivered in Arabic to maximize comprehension and engagement across all staff levels.
- Metrics and Reporting: Track completion rates, phishing simulation results, and knowledge assessment scores. Report quarterly to the CISO and annually to the board.
- Regulatory Scenario Training: Include Saudi-specific scenarios — PDPL data handling, SAMA incident reporting obligations, and NCA notification duties.
Exam Tip: During SAMA examinations, auditors commonly request training completion records, phishing simulation reports, and evidence of board-level cybersecurity briefings. Maintain these artifacts meticulously to demonstrate a mature security culture.
Third-party risk management (TPRM) is a critical compliance obligation for Saudi financial institutions. Under SAMA CSF Domain 4 (Third Party Management), banks must establish a formal vendor risk management program that includes due diligence, contractual security requirements, and continuous monitoring.
Key implementation steps include:
1. Vendor Classification & Due Diligence: Categorize vendors by criticality and data access. Critical vendors handling sensitive financial or personal data must undergo comprehensive security assessments before onboarding, including reviewing their ISO 27001 certification status and security posture.
2. Contractual Obligations: All vendor contracts must include security clauses covering data protection (aligned with PDPL Article 29), right-to-audit provisions, incident notification timelines (typically 72 hours), and compliance with NCA ECC controls where applicable.
3. Ongoing Monitoring: SAMA CSF requires periodic reassessment — at minimum annually for critical vendors. This includes reviewing SOC 2 Type II reports, conducting questionnaire-based assessments, and tracking regulatory changes affecting your vendors.
4. Cloud & SaaS Vendors: For cloud service providers, NCA CCC (Cloud Computing Controls) compliance must be validated. SAMA also requires that data residency within Saudi Arabia is confirmed for sensitive financial data.
5. Offboarding Procedures: Ensure data return or destruction obligations are enforced contractually and operationally upon vendor termination.
Our GRC platform provides a structured TPRM module with pre-built vendor questionnaires mapped to SAMA CSF, NCA ECC, and PDPL, enabling compliance officers to track vendor risk scores, automate reassessment schedules, and generate audit-ready reports — saving significant manual effort.
Third-party risk management (TPRM) is a critical obligation for Saudi financial institutions. Under SAMA CSF Control 3.3, banks must establish a formal vendor risk management program that classifies suppliers based on the sensitivity of data accessed and criticality of services provided.
Key implementation steps include:
1. Vendor Classification & Due Diligence: Categorize vendors as critical, important, or standard. Conduct pre-onboarding security assessments including reviewing SOC 2 Type II reports, ISO 27001 certifications, and financial stability indicators.
2. Contractual Obligations: All vendor contracts must include cybersecurity clauses covering data protection (aligned with PDPL Article 21), incident notification timelines (within 72 hours per SAMA CSF), audit rights, and right-to-terminate provisions.
3. Continuous Monitoring: Implement ongoing monitoring using automated tools to track vendor security posture. NCA ECC Article 3-4 requires organizations to assess the cybersecurity controls of cloud and technology service providers periodically.
4. Concentration Risk: SAMA guidelines warn against over-reliance on a single vendor, particularly for critical infrastructure. Maintain fallback arrangements and exit strategies.
5. Subcontractor Oversight: Ensure primary vendors disclose and control their own subcontractors who may access your data or systems.
Practically, institutions should maintain a vendor risk register, conduct annual reassessments for critical vendors, and include TPRM findings in quarterly board-level cybersecurity reports as required by SAMA CSF's governance domain. A GRC platform can automate vendor questionnaires, track remediation, and generate audit-ready evidence for SAMA examinations.
Third-party risk management is a critical obligation under SAMA CSF Domain 4 (Third Party Cybersecurity), which requires Saudi financial institutions to establish a structured vendor risk program across the entire supplier lifecycle.
Key Requirements:
- Pre-onboarding Due Diligence (SAMA CSF 4.1): Conduct cybersecurity risk assessments before contracting any third party with access to sensitive systems or data. This includes reviewing ISO 27001 certifications, SOC 2 reports, and NCA ECC alignment.
- Contractual Obligations (SAMA CSF 4.2): All vendor contracts must include cybersecurity clauses covering data handling, incident notification timelines (typically within 72 hours), right-to-audit provisions, and compliance with PDPL data processing requirements.
- Continuous Monitoring (SAMA CSF 4.3): Implement ongoing monitoring of critical vendors using tools such as security ratings platforms and periodic reassessments (at least annually for Tier-1 vendors).
- Concentration Risk: SAMA guidance also highlights the risk of over-reliance on single vendors, particularly for cloud or core banking services.
Practical Steps:
- Classify vendors by criticality (Tier 1–3) based on data access and operational impact.
- Develop a standardized vendor security questionnaire aligned to SAMA CSF and NCA ECC controls.
- Include third-party incidents in your incident response runbooks.
- Maintain a live vendor risk register reviewed quarterly by the CISO.
Non-compliance with third-party risk requirements can result in regulatory findings during SAMA examinations and reputational exposure.
Third-party risk management (TPRM) is a critical compliance obligation for Saudi financial institutions. Under SAMA CSF Control 3.3, banks must establish a formal vendor risk management program that includes pre-onboarding due diligence, contractual security requirements, and ongoing monitoring.
Key implementation steps include:
1. Vendor Classification: Categorize vendors by criticality — Tier 1 (critical/core systems), Tier 2 (significant), and Tier 3 (low-risk). Apply proportionate controls accordingly.
2. Pre-Onboarding Assessment: Require vendors to complete security questionnaires aligned with ISO 27001 Annex A controls and NCA ECC Article 2-14, which mandates that outsourced services meet equivalent cybersecurity standards.
3. Contractual Obligations: Contracts must include cybersecurity clauses covering incident notification timelines (typically within 24 hours per SAMA expectations), audit rights, data handling, and exit strategies.
4. Continuous Monitoring: Conduct annual reassessments for Tier 1 vendors and use automated tools (threat intelligence feeds, security ratings platforms) for real-time monitoring.
5. Cloud Providers: For cloud-based vendors, apply SAMA's Cloud Computing Framework requirements, including data residency confirmations for sensitive financial data within Saudi Arabia.
Practically, institutions should maintain a centralized vendor risk register, assign ownership per vendor, and integrate TPRM findings into the broader risk register reported to the board. Failure to manage third-party risk adequately is one of the most cited findings in SAMA regulatory examinations, making this a top-priority compliance area for CISOs and compliance officers alike.
Security Awareness Training (SAT) is a mandatory compliance requirement — not optional — for Saudi fintechs and financial institutions. Both SAMA CSF and NCA ECC explicitly require formal, ongoing awareness programs targeting all employees.
Regulatory Requirements:
- SAMA CSF Control 3.2: Mandates cybersecurity awareness programs covering phishing, social engineering, acceptable use policies, and incident reporting procedures. Programs must be role-based and conducted at least annually, with new hire onboarding training.
- NCA ECC Article 2-5: Requires organizations to implement cybersecurity awareness and training programs, maintain training records, and ensure personnel understand their cybersecurity responsibilities.
Building an Effective SAT Program:
1. Role-Based Training Tracks: Develop separate modules for general staff, IT/security teams, privileged users, executives, and developers. Each role faces distinct threats — developers need secure coding awareness, executives need spear-phishing and BEC (Business Email Compromise) training.
2. Simulated Phishing Campaigns: Run monthly or quarterly simulated phishing exercises. Track click rates and tailor follow-up training for vulnerable users. SAMA examiners frequently request phishing simulation data during reviews.
3. Training Content Areas: Cover password hygiene, data handling per PDPL, social engineering recognition, mobile device security, and insider threat awareness.
4. Metrics and Reporting: Track completion rates (target: 95%+), phishing simulation failure rates (target: below 5%), and post-training assessment scores. Present results quarterly to the CISO and annually to the board.
5. Documentation: Maintain training records for at least 3 years to support SAMA and NCA audit evidence requirements.
Integrating SAT into a broader human risk management strategy — rather than treating it as a checkbox exercise — significantly reduces the likelihood of successful social engineering attacks against your institution.
A robust Third-Party Risk Management (TPRM) program for Saudi financial institutions must address requirements across SAMA CSF Control Domain 3.3 and NCA ECC Article 2-7. Here is how to structure it effectively:
1. Vendor Classification & Due Diligence: Categorize all third parties by risk tier (critical, high, medium, low) based on data access, system integration depth, and service criticality. Per SAMA CSF Control 3.3.1, formal due diligence must be conducted before onboarding any vendor with access to financial or customer data.
2. Contractual Obligations: Ensure all vendor contracts include cybersecurity clauses covering data handling, incident notification timelines (within 72 hours per PDPL Article 27), audit rights, and compliance with NCA ECC standards. Offshore vendors must adhere to PDPL cross-border data transfer restrictions.
3. Continuous Monitoring: Implement ongoing monitoring through annual security assessments, quarterly performance reviews, and real-time threat intelligence feeds for critical vendors. SAMA CSF requires periodic reassessment aligned with vendor risk tier.
4. Fourth-Party Risk: Map your vendors' subcontractors to identify hidden concentration risks, particularly in cloud and payment processing chains.
5. Incident Response Coordination: Establish joint incident response procedures with critical vendors, ensuring alignment with your institution's overall IR plan per SAMA CSF Control 3.6.
Practical Tip: Maintain a centralized vendor registry with automated risk scoring updated at least annually. Regulators increasingly scrutinize TPRM documentation during SAMA examinations, so audit-ready records are essential.
Third-party risk management (TPRM) is a critical compliance obligation for Saudi financial institutions. Under SAMA CSF Control 3.3 (Third Party Management), member organizations must establish a formal vendor risk program that covers the entire supplier lifecycle — from onboarding through offboarding.
Key requirements include:
1. Pre-Engagement Due Diligence: Before contracting any vendor, conduct a cybersecurity risk assessment aligned with SAMA CSF Annex requirements. Classify vendors by criticality (e.g., Tier 1 for core banking system providers).
2. Contractual Security Clauses: Ensure all vendor contracts include mandatory cybersecurity clauses covering data protection, incident notification timelines (typically within 24-72 hours), audit rights, and compliance with PDPL obligations when personal data is shared.
3. Continuous Monitoring: NCA ECC Article 2-12 requires periodic reassessment of third-party risks. Implement quarterly or annual security reviews depending on the vendor's risk tier. Use standardized questionnaires (e.g., SIG Lite or a SAMA-aligned template).
4. Cloud and SaaS Vendors: For cloud service providers, ensure compliance with NCA CCC (Cloud Computing Controls) and verify that data residency requirements are met — critical for banks storing customer financial data.
5. Incident Escalation Paths: Define clear escalation procedures if a vendor experiences a breach that could impact your institution. This should align with your internal SAMA-required incident response plan.
Best practice is to maintain a centralized Vendor Risk Register reviewed by your CISO or vCISO quarterly. Failure to manage third-party risks has been a leading cause of regulatory findings during SAMA examinations.
Third-party risk management (TPRM) is a critical compliance obligation for Saudi financial institutions. Under SAMA CSF Control 3.3 (Third-Party Management), banks must establish a formal vendor risk program that covers the entire vendor lifecycle — from onboarding and due diligence through contract management to offboarding.
Key requirements include:
1. Risk-Based Vendor Classification: Categorize vendors by criticality (Tier 1–3) based on data access, system integration depth, and service criticality. Critical vendors providing core banking or cloud infrastructure services demand enhanced scrutiny.
2. Pre-Engagement Due Diligence: Before onboarding, assess vendors' security posture using standardized questionnaires aligned with NCA ECC controls. Obtain evidence of certifications such as ISO 27001, SOC 2, or equivalent.
3. Contractual Security Obligations: Per SAMA CSF Control 3.3.2, contracts must include mandatory cybersecurity clauses covering data protection, incident notification timelines (typically within 72 hours), audit rights, and compliance with Saudi regulations including PDPL.
4. Ongoing Monitoring: Conduct annual security assessments for Tier 1 vendors and periodic reviews for lower-tier suppliers. NCA ECC Article 2-6 emphasizes continuous monitoring of supply chain risks.
5. Cloud and SaaS Vendors: For cloud service providers, validate CSP compliance with NCA Cloud Cybersecurity Controls (CCC) and ensure data residency requirements within the Kingdom are met where applicable.
6. Exit and Offboarding: Ensure data destruction or return protocols are contractually mandated and verified upon vendor termination.
Practically, implement a centralized TPRM register within your GRC platform to track assessments, risk ratings, and remediation actions. This provides audit-ready documentation for SAMA regulatory examinations and NCA inspections.
Third-party risk management (TPRM) is a critical obligation under SAMA CSF Domain 3.3 and NCA ECC-1: 2-7, requiring financial institutions to establish a structured vendor risk lifecycle.
Key Steps for Compliance:
- Vendor Classification: Categorize all third parties based on data sensitivity, service criticality, and access level. Distinguish between Tier 1 (critical/direct system access) and lower tiers accordingly.
- Pre-Onboarding Due Diligence: Before contracting, assess vendors using security questionnaires aligned with SAMA CSF controls. Require evidence of ISO 27001 certification or equivalent for critical vendors.
- Contractual Controls (per SAMA CSF 3.3.5): Ensure contracts include cybersecurity clauses covering: data protection obligations, right-to-audit provisions, incident notification timelines (typically within 72 hours), and compliance with PDPL if personal data is shared.
- Ongoing Monitoring: Conduct annual cybersecurity assessments for Tier 1 vendors. Use automated tools to monitor for supply chain vulnerabilities and threat intelligence related to your vendors.
- NCA ECC Alignment: NCA ECC Article 2-7 specifically requires that outsourced services maintain security controls equivalent to the institution's own standards. Document this equivalency formally.
- Offboarding Procedures: Ensure data deletion, access revocation, and documentation of secure vendor exit.
A practical starting point is building a Vendor Risk Register that tracks vendor criticality, last assessment date, identified gaps, and remediation status. This register should be reviewed quarterly by the CISO and presented to the board risk committee annually.
Third-party risk management is a critical obligation under SAMA CSF Domain 3 (Cyber Security Risk Management), specifically Controls 3.3.1 through 3.3.5, which require financial institutions to formally assess, govern, and monitor all third-party relationships that could impact cybersecurity posture.
A compliant TPRM program for Saudi banks should include the following components:
1. Vendor Classification & Risk Tiering: Categorize all vendors based on data access, system connectivity, and service criticality. Tier 1 vendors (e.g., core banking providers, cloud platforms) require full due diligence.
2. Pre-Onboarding Due Diligence: Conduct security assessments before engaging any vendor. This includes reviewing ISO 27001 certifications, SOC 2 reports, and questionnaire-based assessments aligned with NCA ECC controls.
3. Contractual Safeguards: Per SAMA CSF Control 3.3.3, contracts must include cybersecurity clauses covering data handling, breach notification timelines (aligned with PDPL Article 19's 72-hour notification obligation), right-to-audit provisions, and exit strategies.
4. Continuous Monitoring: Implement ongoing monitoring of critical vendors using threat intelligence feeds, security ratings platforms, and periodic reassessments — at minimum annually for Tier 1 vendors.
5. Concentration Risk Management: SAMA specifically flags concentration risk when multiple critical services rely on a single vendor or technology provider.
6. Incident Coordination: Establish clear escalation procedures for vendor-related security incidents, ensuring alignment with your own incident response plan.
Practically, banks should maintain a centralized vendor register within their GRC platform, automated assessment workflows, and audit-ready documentation. Non-compliance in this area has been a recurring finding in SAMA examinations across the Saudi financial sector.
Third-party risk management (TPRM) is a critical obligation under both SAMA CSF Domain 4.3 and NCA ECC-2: 1-5. Saudi financial institutions must implement a structured, risk-based TPRM lifecycle covering the following stages:
1. Vendor Onboarding & Classification: Classify vendors by criticality — Tier 1 (critical/core banking systems), Tier 2 (significant), and Tier 3 (low-risk). Per SAMA CSF Control 4.3.2, all critical vendors must undergo security due diligence before contract execution.
2. Contractual Security Requirements: Contracts must include cybersecurity clauses covering data protection (aligned with PDPL Article 21), incident notification timelines (typically 72 hours), audit rights, and compliance with applicable Saudi regulations.
3. Ongoing Monitoring: Conduct annual security assessments or questionnaires for Tier 1 vendors. NCA ECC recommends periodic reviews of vendor access privileges and security posture. Use standardized frameworks like shared assessments or CAIQ (CSA Cloud) for cloud vendors.
4. Concentration Risk: SAMA specifically highlights the risk of over-reliance on single vendors for critical services. Maintain documented contingency plans and alternative sourcing strategies.
5. Offboarding: Ensure secure data deletion, access revocation, and documentation per PDPL data retention requirements.
Practical Tip: Build a centralized vendor register with risk ratings, assessment dates, and contract expiry. Automate reassessment triggers using your GRC platform. Assign a dedicated TPRM owner within the information security function to maintain accountability and audit-readiness during SAMA examinations.
SAMA CSF Domain 3 (Cybersecurity Operations & Technology) and specifically Controls 3.3.1–3.3.5 mandate that financial institutions maintain and regularly test an Incident Response Plan (IRP). A tabletop or simulation exercise must be conducted at least annually, with critical institutions advised to run them semi-annually.
Step 1 – Define Scope and Scenario Select a realistic scenario relevant to your institution (e.g., ransomware attack on core banking, BEC fraud targeting SWIFT transactions, or insider data exfiltration). Align the scenario with your institution's crown jewels and recent threat intelligence.
Step 2 – Assemble the Right Stakeholders Involve IT security, legal, compliance, communications, operations, and senior management. SAMA CSF requires board-level awareness of cyber incidents, so including C-suite members in tabletop exercises is strongly recommended.
Step 3 – Define Injects and Timelines Structure the exercise with pre-planned injects that simulate real decision points: initial alert triage, escalation thresholds, regulatory notification to SAMA (within 72 hours per SAMA CSF Control 3.3.4), and customer communication decisions.
Step 4 – Regulatory Notification Simulation Practice drafting the mandatory incident notification to SAMA, ensuring it covers: incident type and classification, affected systems and data, containment actions taken, and recovery timeline estimates.
Step 5 – Post-Exercise Lessons Learned Document all gaps, decision delays, and communication breakdowns. Create a remediation action plan with owners and deadlines. SAMA assessors will specifically look for evidence that lessons learned are tracked and closed.
Pro tip: Integrate NCA ECC Article 2-7 crisis management requirements into your exercise design if your institution is also subject to NCA oversight, ensuring dual-framework compliance in a single exercise.
Under SAMA CSF Domain 4 (Cyber Resilience), Saudi banks must establish a comprehensive Business Continuity Management (BCM) program that addresses both IT and cybersecurity dimensions. Key requirements include:
1. BCP and DRP Development: Per SAMA CSF Control 4.3, institutions must develop, document, and maintain a Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP) that explicitly cover cyber disruption scenarios — not just traditional outages.
2. Recovery Time and Point Objectives: Banks must define and validate RTO and RPO targets for critical systems, ensuring alignment with SAMA's operational resilience expectations. Core banking systems typically require RTOs under 4 hours.
3. Regular Testing: SAMA CSF requires BCM tests at least annually, including tabletop exercises and full failover drills. Test results must be documented and gaps remediated within defined timelines.
4. Cyber Incident Integration: BCP must be integrated with the Cyber Incident Response Plan (CIRP) to ensure seamless escalation from incident containment to business recovery.
5. Third-Party Dependencies: Critical third-party and outsourced service providers must be included in BCP scope, with contractual SLAs supporting recovery objectives.
6. Board and Senior Management Oversight: BCM governance must include board-level approval of BCP policies and annual reporting on resilience posture.
Practically, institutions should conduct a Business Impact Analysis (BIA) annually to reprioritize critical processes and map dependencies. Aligning your BCM framework with ISO 22301 alongside SAMA CSF provides a robust, internationally recognized structure that also satisfies NCA ECC resilience controls.
Third-party risk management is one of the most scrutinized areas in SAMA examinations and NCA assessments. SAMA CSF Control 3.3.14 (Third-Party Management) and NCA ECC Article 2-9 establish clear expectations. For Saudi fintechs — which typically rely heavily on external technology providers, cloud platforms, and payment processors — a structured TPRM program is non-negotiable.
Vendor Inventory & Tiering: Begin by building a comprehensive inventory of all third parties with access to your systems, data, or critical processes. Classify vendors into tiers based on criticality and data sensitivity. Tier-1 vendors (e.g., core banking system providers, cloud infrastructure, payment gateways) require the most rigorous controls.
Pre-Engagement Due Diligence: Before onboarding any Tier-1 or Tier-2 vendor, conduct formal security due diligence — review ISO 27001 certifications, SOC 2 Type II reports, NCA compliance attestations, and conduct questionnaire-based assessments mapped to SAMA CSF and NCA ECC controls. SAMA expects documented evidence of pre-contract security reviews.
Contractual Security Requirements: All vendor contracts must include cybersecurity clauses covering: right-to-audit, incident notification obligations (within 72 hours per SAMA guidance), data handling and sub-processor restrictions, and compliance with Saudi data residency requirements under PDPL.
Ongoing Monitoring: TPRM is not a one-time exercise. Implement continuous monitoring through annual reassessments for Tier-1 vendors, ongoing threat intelligence feeds tracking vendor-specific vulnerabilities, and real-time monitoring of vendor access logs where applicable.
Concentration Risk: SAMA specifically flags concentration risk — where a single third party supports multiple critical functions. Map your dependencies and maintain documented contingency plans and exit strategies for critical vendors.
Board-Level Reporting: Aggregate TPRM findings into quarterly risk reports presented to the Risk Committee, demonstrating active governance — a key SAMA CSF requirement under Control 3.1.
Business Continuity Management (BCM) under SAMA CSF (Domain 3.3) is a mandatory requirement for all Saudi financial institutions. Here is how to structure a compliant BCM program:
1. Business Impact Analysis (BIA): Conduct a formal BIA per SAMA CSF Control 3.3.2 to identify critical business functions, dependencies, and acceptable downtime thresholds (RTO/RPO). Financial institutions must document Maximum Tolerable Downtime (MTD) for each critical process.
2. BCM Policy and Governance: Establish a board-approved BCM policy. SAMA CSF requires senior management accountability for BCM, with clear roles assigned to a Business Continuity Manager and departmental owners.
3. Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP): Develop and maintain documented BCPs per SAMA CSF Control 3.3.4, covering manual workarounds, alternate processing sites, staff escalation trees, and communication protocols. DRPs must address IT system recovery with defined RTO objectives — typically 4 hours or less for critical banking systems.
4. Testing and Exercising: SAMA CSF mandates periodic testing (at minimum annually) including tabletop exercises, functional tests, and full failover simulations. Test results must be documented and gaps remediated within defined timelines.
5. Integration with Cyber Incident Response: Align BCM with your Cyber Incident Response Plan (CIRP) to ensure continuity during cyberattacks — particularly ransomware and DDoS scenarios common in the Saudi financial sector.
6. Third-Party BCM: Per SAMA CSF Control 3.3.6, assess and verify the BCM capabilities of critical third-party vendors annually.
Annual SAMA audits will review BCM documentation, test evidence, and board-level oversight. A well-structured BCM program also satisfies overlapping requirements under NCA ECC Section 2-7 and ISO 22301.
Business Continuity Management (BCM) for Saudi financial institutions is governed primarily by SAMA CSF Domain 4 (Resilience) and NCA ECC Article 3-5, which together require documented, tested, and board-approved continuity plans capable of sustaining critical operations during cyber incidents, natural disasters, and system failures.
Core BCM Requirements Under SAMA CSF:
- Business Impact Analysis (BIA): Identify critical business functions, dependencies, Recovery Time Objectives (RTOs), and Recovery Point Objectives (RPOs). SAMA expects RTOs for Tier-1 systems to be defined and technically achievable — typically under 4 hours for core banking.
- Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP): Separate but aligned documents. The BCP addresses operational continuity; the DRP addresses IT systems restoration.
- Crisis Communication Plan: Define internal escalation paths and external communication protocols with SAMA, NFIS, and the public where applicable.
NCA ECC Additional Requirements (Art. 3-5): NCA requires cybersecurity-specific resilience controls integrated into the BCP, including secure backup architectures, offline/immutable backup storage, and cyberattack-specific recovery scenarios — not just traditional IT disaster scenarios.
Testing and Validation: SAMA CSF mandates at minimum an annual full-scale BCP/DRP test, including tabletop exercises and live failover drills. Test results must be formally documented, gaps remediated, and executive sign-off obtained.
Practical Recommendation: Align your BCM program with ISO 22301 as the international standard underpinning SAMA's expectations. Map ISO 22301 controls to SAMA CSF and NCA ECC requirements to produce a unified compliance artifact that satisfies all three frameworks simultaneously.
Business Continuity Management (BCM) is a critical pillar under the SAMA Cyber Security Framework (CSF), specifically addressed in Domain 4 (Cyber Resilience) and Control area 3.3 (Business Continuity & Disaster Recovery). Here is a structured approach for Saudi banks:
1. Business Impact Analysis (BIA): Identify and classify critical banking functions — core banking systems, payment gateways, SWIFT connectivity, and customer-facing digital channels. Per SAMA CSF Control 3.3.1, each critical process must have defined Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs).
2. BCM Policy & Governance: Establish a board-approved BCM policy assigning clear ownership to senior management. SAMA expects BCM to be treated as an enterprise-wide risk, not solely an IT function.
3. Business Continuity Plan (BCP) Development: Document response procedures for various disruption scenarios — cyberattacks, natural disasters, system failures, and pandemic events. Plans must include communication trees, escalation paths, and alternate site operations.
4. Disaster Recovery (DR) for IT Systems: Implement redundant infrastructure with geographically separated data centers within Saudi Arabia. SAMA CSF Control 3.3.4 requires documented DR plans tested at least annually, with evidence of test results maintained.
5. BCM Testing & Exercising: Conduct tabletop exercises, simulation drills, and full failover tests regularly. SAMA examiners will request test results and remediation logs during assessments.
6. Integration with ISO 22301: Aligning your BCM program with ISO 22301 (Business Continuity Management Systems) provides a globally recognized framework that also satisfies SAMA's structured documentation and audit requirements.
Maintain updated BCM documentation, review plans after every significant incident, and ensure third-party critical service providers also have verified continuity arrangements.
Under SAMA CSF Domain 4 (Cybersecurity Operations and Technology), Member Organizations must establish a formal, documented Incident Response Program that covers the full lifecycle: preparation, detection, containment, eradication, recovery, and post-incident review.
Key Requirements:
- SAMA CSF Control 4.3.1 mandates a written Incident Response Policy and Procedure reviewed at least annually.
- Control 4.3.2 requires classification of incidents by severity (Critical, High, Medium, Low) with defined SLAs for each tier.
- Control 4.3.3 obligates notification to SAMA within specific timeframes for critical incidents — typically within 72 hours of confirmed breach, aligned with NCA ECC Article 4-3 reporting obligations.
Practical Guidance:
- Establish an Incident Response Team (IRT): Assign clear roles — IR Lead, Legal/Compliance, Communications, IT/SOC — with documented escalation paths.
- Integrate a SIEM/SOAR Platform: Automate detection and initial triage to reduce Mean Time to Detect (MTTD) and Mean Time to Respond (MTTR).
- Conduct Tabletop Exercises: Simulate ransomware, data breach, and DDoS scenarios at least twice per year, per SAMA CSF best practice.
- Coordinate with NCA: For critical infrastructure sectors, ensure your IR plan aligns with NCA's National Cybersecurity Incident Management Framework.
- Document Everything: Maintain evidence logs and post-incident reports to demonstrate compliance during SAMA audits.
A mature IR program not only satisfies regulatory requirements but significantly reduces financial and reputational damage during an actual incident.
Business Continuity Management is a critical pillar under SAMA CSF Domain 4 (Resilience), requiring Saudi financial institutions to establish, maintain, and periodically test a comprehensive BCM program. Per SAMA CSF Control 4.3, banks must develop a Business Continuity Plan (BCP) and a Disaster Recovery Plan (DRP) that cover all critical business functions, IT systems, and third-party dependencies.
Key requirements include:
1. Business Impact Analysis (BIA): Identify critical processes and define Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) for each. Core banking systems typically require RTO of ≤4 hours and RPO of ≤1 hour.
2. Plan Documentation: BCPs must be formally documented, version-controlled, and approved by senior management and the board.
3. Testing Frequency: SAMA CSF mandates that BCM tests be conducted at least annually. Tests should include tabletop exercises, simulation drills, and full failover testing for critical systems.
4. Post-Test Reporting: Results must be documented and gaps remediated within defined timelines. Evidence of testing is a key artifact during SAMA regulatory examinations.
5. Alignment with NCA ECC: NCA ECC Article 3-5 also requires resilience controls for critical national infrastructure, which applies to licensed financial entities.
Best practice recommendations:
- Integrate BCM testing into your annual cybersecurity calendar.
- Include third-party providers in DR exercises where they host critical systems.
- Ensure your BCM documentation is reviewed after every significant infrastructure change or major incident.
A mature BCM program not only satisfies regulatory requirements but directly reduces operational risk exposure during ransomware attacks, outages, or natural disasters.
Under SAMA CSF Domain 4 (Cybersecurity Operations and Technology), specifically controls 4.3.1 through 4.3.5, Saudi financial institutions must establish a formal, documented Incident Response (IR) plan that covers the full lifecycle: detection, containment, eradication, recovery, and post-incident review.
Key mandatory elements include:
1. Incident Classification Framework: Define severity tiers (Critical, High, Medium, Low) aligned with business impact. Critical incidents — such as ransomware attacks or core banking system breaches — must be escalated to SAMA within 72 hours of detection, per SAMA's Cyber Incident Reporting guidelines.
2. Dedicated IR Team (CIRT): Assign clear roles including Incident Commander, Technical Lead, Legal/Compliance Liaison, and Communications Officer. Many Saudi banks fulfill this via a hybrid internal/vCISO model.
3. Playbooks by Scenario: Develop specific runbooks for high-risk scenarios relevant to banking: phishing-to-BEC attacks, ATM logical attacks, SWIFT fraud, DDoS on digital banking, and insider threats.
4. Integration with NCA ECC: NCA ECC Article 3-6-1 requires coordination with the National Cybersecurity Authority during major incidents. Ensure your IR plan includes the NCA escalation path alongside SAMA reporting.
5. Testing Requirements: SAMA CSF mandates that IR plans be tested at least annually via tabletop exercises or simulated attack scenarios. Results must be documented and used to update the plan.
6. Evidence Preservation: Establish forensic-ready logging (per SAMA CSF 4.2.x) to support post-incident analysis and potential regulatory investigations.
A practical starting point is to map your existing IR procedures against the SAMA CSF maturity model, targeting at least Level 3 (Defined) across all IR sub-domains before your next SAMA assessment.
Business Continuity Management (BCM) and cyber resilience are treated as critical pillars under SAMA CSF Domain 3.5, requiring Saudi financial institutions to maintain robust capabilities to withstand, respond to, and recover from disruptive cyber events.
Core SAMA CSF Requirements (Domain 3.5):
Business Continuity Planning: Institutions must develop, document, and maintain a Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP) that explicitly account for cyber incident scenarios — not just natural disasters or physical failures. Plans must identify Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) for critical systems, including core banking, payment processing, and customer-facing digital channels.
Testing and Exercises: Per SAMA CSF Control 3.5.3, BCPs and DRPs must be tested at least annually through tabletop exercises, simulations, or full failover drills. Test results must be formally documented, gaps identified, and remediation tracked to closure.
Cyber Incident Integration: BCM programs must be tightly integrated with the Cyber Incident Response Plan (CIRP). This means incident escalation paths, communication protocols, and recovery playbooks must be aligned and tested together — not maintained as separate silos.
Third-Party Dependencies: SAMA expects institutions to map critical third-party dependencies (e.g., cloud providers, payment networks, core banking vendors) within their BIA (Business Impact Analysis) and ensure contractual recovery commitments are captured in SLAs.
Board Oversight: Senior management and the Board must be briefed annually on BCM program status, test outcomes, and residual risks. Evidence of board engagement is a frequent SAMA examination checkpoint.
Building a resilient BCM program requires cross-functional collaboration between IT, cybersecurity, operations, legal, and communications teams — supported by a GRC platform that centralizes BIA data, test scheduling, and regulatory evidence.
Privileged Access Management (PAM) is a critical control for Saudi banks, directly addressed in SAMA CSF Domain 4 (Access Control) and NCA ECC Control 2-4 (Identity and Access Management). A non-compliant PAM posture is one of the most common findings in regulatory assessments.
SAMA CSF Requirements: Controls under Domain 4 require that privileged accounts are identified, strictly controlled, and their usage logged and monitored. Shared administrative accounts are explicitly discouraged.
NCA ECC Alignment: ECC Control 2-4-3 mandates that privileged access rights be reviewed periodically and revoked immediately upon role change or termination.
Practical PAM Implementation Framework:
- Discovery & Inventory: Enumerate all privileged accounts across on-premises systems, cloud environments, databases, and network devices. Many banks underestimate shadow admin accounts.
- Just-In-Time (JIT) Access: Eliminate standing privileges. Grant elevated access only when needed, for a defined duration, with full audit logging.
- Credential Vaulting: Store all privileged credentials in a PAM vault (e.g., CyberArk, Delinea, BeyondTrust). Rotate passwords automatically after each session.
- Session Recording: Record all privileged sessions for forensic and compliance purposes. This is essential for SAMA CSF audit evidence.
- Multi-Factor Authentication (MFA): Enforce MFA for all privileged access without exception.
- Quarterly Access Reviews: Conduct formal recertification of all privileged accounts every quarter, with documented approval from system owners.
CISOs should integrate PAM reporting into their board-level cybersecurity dashboards and ensure PAM controls are included in annual penetration testing scope to validate effectiveness.
Identity and Access Management (IAM) is a foundational control domain under both SAMA CSF and NCA ECC, and weak IAM is consistently cited in Saudi financial sector breach investigations. Here is a structured maturity roadmap:
SAMA CSF Requirements (Control Domain 3.3 & 3.4):
- Implement Role-Based Access Control (RBAC) aligned to job functions per SAMA CSF 3.3.5
- Enforce least-privilege principles and periodic access reviews (minimum quarterly for privileged accounts)
- Maintain a Privileged Access Management (PAM) solution for all administrative and system accounts per SAMA CSF 3.4.2
- Implement Multi-Factor Authentication (MFA) for all remote access, privileged sessions, and internet-facing applications per SAMA CSF 3.3.6
NCA ECC Requirements (Domain 2 - Access Management):
- NCA ECC Art. 2-1 mandates formal user lifecycle management including joiners, movers, and leavers processes
- NCA ECC Art. 2-3 requires annual recertification of all user access rights
- Shared and generic accounts must be eliminated or tightly controlled per NCA ECC Art. 2-2
Maturity Progression:
- Level 1 (Basic): Active Directory hardening, MFA deployment, documented access request process
- Level 2 (Intermediate): PAM solution deployment, automated provisioning/deprovisioning, SIEM integration for IAM events
- Level 3 (Advanced): Zero Trust Architecture adoption, Identity Governance & Administration (IGA) platform, behavioral analytics for anomalous access
Quick Wins for CISOs: Start with a privileged account discovery exercise — most Saudi banks discover 30-40% more privileged accounts than documented. Integrate IAM logs into your SOC for real-time detection of credential-based attacks, which account for over 60% of financial sector incidents globally.
Under SAMA CSF Domain 4 (Cybersecurity Resilience), Saudi banks must establish a robust Business Continuity Management (BCM) program that ensures critical financial services remain operational during and after a cyber incident.
Key Requirements:
- SAMA CSF Control 4.1: Develop and maintain a documented Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP) covering all critical systems and data.
- SAMA CSF Control 4.2: Conduct BCP/DRP testing at least annually, including full simulation exercises, not just tabletop reviews.
- SAMA CSF Control 4.3: Define Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) aligned with SAMA's availability expectations for core banking systems.
Practical Implementation Steps:
- Business Impact Analysis (BIA): Identify critical banking processes (payments, core banking, customer portals) and classify them by criticality tier.
- Recovery Strategy Design: Establish geographically separated hot/warm standby sites within Saudi Arabia to comply with data residency requirements under PDPL and SAMA guidance.
- Integration with Cyber IR: Ensure your BCP directly references your Cyber Incident Response Plan (CIRP), so activation triggers are clearly defined.
- Staff Training: Assign BCM roles to specific personnel and conduct awareness sessions at least twice yearly.
- Vendor Alignment: Ensure critical third-party providers have compatible BCM plans reviewed during annual vendor assessments per SAMA CSF Control 3.3.
SAMA examiners will assess BCM maturity during regulatory inspections, so maintain evidence of tests, gap remediation, and board-level sign-off on BCP documents.
Security Awareness Training (SAT) is a mandatory control for Saudi fintechs operating under SAMA CSF and NCA ECC. Far too many organizations treat this as a checkbox exercise — a single annual e-learning module — rather than a continuous risk-reduction program.
SAMA CSF Requirements: Under Domain 2 (Cybersecurity Leadership & Governance), Control 2.4 mandates that organizations establish a formal security awareness program covering all employees, contractors, and privileged users. The program must be role-based, documented, and reviewed annually.
NCA ECC Requirements: Article 3-4 (Human Security) requires organizations to conduct awareness campaigns, enforce security policies through training, and maintain records of training completion for audit purposes.
Building an Effective Program:
- Role-Based Curriculum: Develop separate training tracks for general staff, IT/security teams, executives, and developers. Developers, for example, should receive secure coding and OWASP Top 10 training.
- Phishing Simulations: Run monthly simulated phishing campaigns. Track click rates and use failures as teachable moments, not punitive events. Target a sub-5% click rate as a KPI.
- Onboarding Integration: All new hires must complete baseline security training within their first 30 days, with signed acknowledgment of acceptable use and data handling policies.
- Executive Briefings: Conduct quarterly cybersecurity briefings for C-suite and board members aligned with SAMA's expectations for board-level oversight.
- Metrics and Reporting: Report SAT completion rates, phishing simulation results, and policy acknowledgment rates to the CISO and board annually, and maintain evidence for SAMA regulatory examinations.
- Cultural Localization: Deliver content in Arabic and contextualize scenarios to Saudi financial sector environments for maximum relevance and engagement.
Under SAMA CSF Control 3.3.1, member organizations must establish a formal cybersecurity awareness and training program covering all employees, contractors, and relevant third parties. The program must be risk-based, role-specific, and reviewed at least annually.
Key requirements include:
Program Design: Training content must be tailored by role — executives require governance-focused modules, IT staff need technical deep-dives, and general employees need phishing and social engineering awareness. Per SAMA CSF Control 3.3.2, specialized training is mandatory for staff with privileged access or critical system responsibilities.
Delivery & Frequency: Annual training is the minimum baseline, but SAMA expects banks to supplement with quarterly micro-modules, simulated phishing campaigns, and real-time threat briefings following major incidents or emerging threat intelligence.
Measurement & Metrics: Track completion rates, phishing simulation click rates, knowledge assessment scores, and repeat offenders. SAMA expects documented evidence of training effectiveness, not just attendance records.
Board & Senior Management: SAMA CSF explicitly requires cybersecurity awareness at the board level. CISOs should deliver annual briefings to the board covering threat landscape, regulatory updates, and organizational risk posture.
Practical Steps: Use a Learning Management System (LMS) with SCORM-compliant modules to automate delivery and track compliance. Integrate awareness campaigns with internal communications during events like National Cybersecurity Month. Localize content in Arabic and align scenarios to Saudi-specific threats such as CEO fraud targeting Saudi financial institutions.
Failure to maintain a documented, tested awareness program is a common finding in SAMA CSF maturity assessments and can negatively impact your maturity score across multiple domains.
Under SAMA CSF Control 3.3.1 and 3.3.2, Saudi financial institutions are required to establish a formal cybersecurity awareness and training program that covers all employees, contractors, and privileged users. The program must be risk-based, role-specific, and conducted at least annually — with more frequent training for high-risk roles such as IT administrators, finance staff, and executive leadership.
A CISO should structure the program across four pillars:
- Baseline Awareness: Mandatory onboarding training covering phishing, social engineering, password hygiene, and acceptable use policies. This applies to every employee from day one.
- Role-Based Training: Specialized modules for IT, development, and compliance teams — aligned with NCA ECC Article 2-14 which emphasizes competency-based cybersecurity education for technical staff.
- Phishing Simulations: Conduct quarterly simulated phishing campaigns. Track click rates, report rates, and remediation completion. SAMA examiners increasingly look for simulation evidence during assessments.
- Executive & Board Briefings: Senior management must understand cyber risk at a governance level. Align these sessions with ISO 27001 Clause 7.3 (Awareness) and document board-level acknowledgment.
Measure effectiveness through KPIs such as phishing simulation failure rates (target below 5%), training completion rates (target 100% within 30 days of assignment), and post-training knowledge assessment scores.
Document everything — SAMA examiners will request training records, completion reports, and evidence of program updates following incidents or threat landscape changes. Platforms like CISO Consulting can automate training assignments, track compliance status, and generate audit-ready reports mapped directly to SAMA CSF controls.
SAMA CSF Control 3.3.1 mandates that all financial institutions implement a formal cybersecurity awareness and training program covering all staff, contractors, and privileged users. The program must be role-based, regularly updated, and aligned with the institution's risk profile.
To build a compliant and effective program, Saudi banks should:
1. Define Training Tiers: Segment your audience into general staff, IT personnel, and executives. Each tier requires tailored content — for example, phishing simulation for general staff, secure coding for developers, and cyber risk governance for the C-suite.
2. Mandatory Frequency: SAMA CSF requires awareness training at least annually, but leading practice suggests quarterly micro-learning modules supplemented by monthly phishing simulations. New joiners must complete training within 30 days of onboarding.
3. Role-Specific Content: Per SAMA CSF Control 3.3.2, privileged users (system administrators, DBA, network engineers) must receive additional training covering access control risks, insider threats, and secure configuration management.
4. Metrics and Reporting: Track completion rates, phishing click-through rates, and assessment scores. SAMA examiners expect documented evidence of training completion and program effectiveness reviews.
5. Integration with ISO 27001: Annex A Control 6.3 (Information Security Awareness, Education and Training) aligns closely with SAMA requirements, making it efficient to design a unified program.
6. PDPL Awareness: Include data privacy obligations under the Saudi PDPL as a mandatory training module — particularly for customer-facing staff handling personal and financial data.
Document all training records for at least three years and present them during SAMA examinations as evidence of a sustainable, risk-driven awareness culture.
Under SAMA CSF Control 3.3.1 and related subcontrols, Saudi banks and financial institutions are required to establish a formal, risk-based cybersecurity awareness and training program covering all employees, contractors, and privileged users. The program must be documented, regularly updated, and aligned with the institution's overall cybersecurity risk profile.
Key mandatory elements include:
Frequency & Coverage: Annual awareness training is the minimum baseline, but SAMA expects role-specific training for IT, security, and privileged users to occur more frequently — typically every six months. New joiners must complete onboarding security training before accessing critical systems.
Content Requirements: Training must cover phishing awareness, social engineering, acceptable use policies, data classification, and incident reporting procedures. For technical staff, content should extend to secure development practices and system hardening principles.
Phishing Simulations: SAMA CSF implicitly supports simulated phishing exercises as part of a mature awareness program. CISOs should run quarterly simulations and track click rates, reporting rates, and repeat offenders.
Metrics & Reporting: Completion rates, assessment scores, and phishing simulation results must be tracked and reported to the board or senior management periodically.
Building the Program: Start with a skills gap assessment, segment your audience by role and risk level, select a Learning Management System (LMS) that supports Arabic content, and integrate awareness campaigns with real-world threat intelligence (e.g., SAMA cybersecurity alerts or NCA advisories).
Cross-referencing with NCA ECC Article 2-6 further reinforces mandatory awareness requirements for government-related financial entities. ISO 27001 Annex A.7.2.2 also aligns with these obligations, making a unified program viable across multiple compliance frameworks.
Under SAMA CSF Control 3.3.1 and related sub-controls, Saudi financial institutions must establish a formal, risk-based cybersecurity awareness and training program covering all employees, contractors, and privileged users. Key requirements include:
Mandatory Elements:
- Annual cybersecurity awareness training for all staff, with documented completion records
- Role-specific training for IT, security, and privileged access users (at least semi-annually)
- Board and senior management briefings on cyber risk (aligned with SAMA CSF Governance Domain)
- Phishing simulation exercises to measure and reduce human risk
Building an Effective Program:
- Baseline Assessment: Conduct a staff awareness survey to identify knowledge gaps across departments
- Tiered Curriculum: Design separate tracks for general staff, IT/security teams, and executives — content must be relevant to job function
- Localization: Deliver content in Arabic and ensure cultural relevance for Saudi workforce segments
- Metrics & KPIs: Track phishing click rates, training completion rates, and incident reports attributed to human error
- Continuous Reinforcement: Supplement annual training with monthly micro-learning modules, security newsletters, and tabletop exercises
NCA ECC Alignment: NCA ECC Article 3-5 also requires organizations to maintain a documented security awareness program, making this a dual-compliance requirement for banks operating under both frameworks.
Practical Tip: Link awareness program outcomes to your SAMA CSF maturity assessment. Regulators expect evidence of a continuously improving program — not just a checkbox exercise. Maintain a training register and make it audit-ready at all times.
Privileged Access Management (PAM) is one of the highest-risk control domains for Saudi financial institutions and is explicitly addressed in both NCA ECC (Article 2-4: Access Management) and SAMA CSF (Control 3.3.6: Access Control). Misconfigured or unmonitored privileged accounts are among the leading causes of major breaches in the banking sector.
Key Regulatory Requirements:
- NCA ECC Art. 2-4: Mandates strict controls on privileged accounts including separation of duties, just-in-time access, and full session logging.
- SAMA CSF Control 3.3.6: Requires a formal access control policy with documented procedures for granting, reviewing, and revoking privileged access.
Practical Implementation Guidance:
- Privileged Account Discovery: Inventory all privileged accounts across on-premise, cloud, and third-party systems. Many institutions are surprised by the number of orphaned or shared admin accounts discovered.
- Implement a PAM Solution: Deploy a PAM platform (e.g., CyberArk, BeyondTrust, Delinea) to vault credentials, enforce just-in-time (JIT) access, and record all privileged sessions.
- Enforce Least Privilege: No user or service account should hold more privileges than required for their specific function. Review and right-size privileges at minimum semi-annually.
- Separate Privileged and Standard Accounts: Admins should use dedicated privileged accounts only for administrative tasks — never for email or browsing.
- Session Recording and Monitoring: All privileged sessions must be recorded and subject to real-time monitoring and anomaly detection, feeding into your SIEM.
- Periodic Access Reviews: Conduct quarterly access recertification reviews, with results documented for SAMA and NCA audit purposes.
Both SAMA and NCA examiners pay close attention to PAM maturity. A well-implemented PAM program is one of the most impactful investments a Saudi financial institution can make in its security posture.
Under SAMA CSF Control 3.3, Saudi banks must establish a comprehensive Identity and Access Management framework covering the full lifecycle of user identities. Key requirements include: Least Privilege Principle — access rights must be limited to what is strictly necessary per role (SAMA CSF 3.3.2). Privileged Access Management (PAM) — all privileged accounts (domain admins, DBAs, root accounts) must be inventoried, approved by management, and reviewed quarterly at minimum (SAMA CSF 3.3.5). Multi-Factor Authentication (MFA) — mandatory for all remote access, privileged accounts, and critical system access, aligning with NCA ECC-1:2-6.2.4. Access Reviews — formal recertification of user access rights must occur at least every six months, with immediate revocation upon role changes or termination. Separation of Duties — conflicting roles such as transaction initiator and approver must be segregated, especially critical in banking operations. Practically, banks should deploy a PAM solution (e.g., CyberArk, BeyondTrust) to vault privileged credentials, enforce session recording, and generate audit trails. All IAM activities must feed into the SIEM for anomaly detection. ISO 27001 Annex A.9 provides a complementary control framework that maps well to SAMA CSF 3.3 requirements. Non-compliance with IAM controls is consistently cited in SAMA examination findings, making this a high-priority area for CISOs.
SAMA CSF Control 3.7 mandates that Saudi banks maintain a formally documented, tested, and board-approved Cyber Incident Response Plan (CIRP). This is one of the most operationally critical compliance requirements, with direct regulatory reporting obligations.
Incident Response Plan Requirements (SAMA CSF 3.7.1–3.7.4):
- Define clear incident classification tiers (Critical, High, Medium, Low) based on business impact and data sensitivity
- Establish a dedicated Computer Security Incident Response Team (CSIRT) with defined roles, escalation paths, and 24/7 on-call coverage
- Integrate with SOC operations for real-time detection, triage, and containment
- Test the CIRP at least annually through tabletop exercises and simulate real attack scenarios (e.g., ransomware, data breach)
Regulatory Reporting Obligations:
- SAMA: Cybersecurity incidents that materially impact operations, customer data, or financial systems must be reported to SAMA within 72 hours of discovery. Post-incident reports are required within 30 days
- NCA (ECC-1: 6-2): Critical cybersecurity incidents must also be reported to the National Cybersecurity Authority (NCA) via the National Cyber Crisis Management Framework
- PDPL (Article 18): Personal data breaches must be reported to the Saudi Data & Artificial Intelligence Authority (SDAIA) within 72 hours, and affected individuals must be notified without undue delay if high-risk harm is likely
Practical Guidance:
- Develop incident classification playbooks for the top 5 threat scenarios relevant to your institution
- Pre-establish legal and communications protocols to manage breach disclosure to regulators, customers, and media
- Retain forensic evidence per chain-of-custody procedures to support regulatory investigations
- Conduct post-incident reviews (PIR) and feed lessons learned back into your risk register and control framework
- Align your CIRP with NIST CSF Respond and Recover functions for a globally recognized structure
Failure to report within mandated timelines can result in supervisory actions by SAMA, including formal citations and reputational consequences.
SAMA CSF Control Domain 3.3 (Third-Party Management) requires Saudi financial institutions to establish a comprehensive vendor risk management program covering the full supplier lifecycle — from onboarding to offboarding. Key requirements include:
Pre-Engagement: Conduct a risk classification of every vendor based on data access, system criticality, and service dependency. High-risk vendors (e.g., cloud providers, core banking system vendors) require full due diligence including ISO 27001 certification review, SOC 2 Type II reports, and on-site assessments where feasible.
Contractual Controls: Per SAMA CSF Control 3.3.3, contracts must include mandatory cybersecurity clauses covering data handling, incident notification timelines (typically within 72 hours), audit rights, and compliance with NCA ECC and PDPL obligations.
Ongoing Monitoring: Annual reassessment is the minimum for critical vendors. Monitoring should include continuous review of the vendor's threat landscape, patch management posture, and any regulatory sanctions.
Subcontractor Oversight: SAMA expects banks to apply equivalent scrutiny to fourth parties — vendors your vendors rely on — especially for cloud and managed service chains.
Practical Guidance: Build a vendor risk register categorized by tier (critical, high, medium, low). Use standardized questionnaires aligned to SAMA CSF and NCA ECC-2 controls. For fintech partnerships, ensure PDPL data processing agreements (DPAs) are executed before any data sharing begins. Document all assessments and maintain evidence for SAMA examination cycles.
SAMA CSF dedicates an entire control domain (Domain 4.5 – Third-Party Management) to vendor risk, requiring Saudi financial institutions to govern all outsourced services and technology providers through a structured lifecycle.
Key SAMA CSF Requirements:
- Control 4.5.1: Maintain a complete register of all third-party relationships, categorized by criticality and the data/systems they access.
- Control 4.5.2: Conduct formal due diligence and cybersecurity risk assessments before onboarding any vendor.
- Control 4.5.3: Ensure contracts include mandatory cybersecurity clauses covering data protection, incident notification (typically within 72 hours), audit rights, and compliance with applicable Saudi regulations including PDPL.
- Control 4.5.4: Perform periodic reassessments — annually at minimum for critical vendors, and upon any material change to the relationship.
Practical Implementation Steps:
- Tiering: Classify vendors into Critical, High, Medium, and Low tiers based on data sensitivity, system access, and operational dependency.
- Questionnaires: Use standardized cybersecurity questionnaires aligned to ISO 27001 Annex A or NIST CSF to evaluate vendor security posture.
- Contract Controls: Embed right-to-audit clauses, minimum security baseline requirements, and PDPL data processing agreements (DPAs).
- Continuous Monitoring: Leverage threat intelligence feeds and external attack surface monitoring tools to assess vendor risk between formal reviews.
- Exit Planning: Define offboarding procedures to ensure secure data return or deletion per PDPL obligations.
NCA ECC Article 2-14 further reinforces these obligations for organizations within the national cybersecurity scope. Non-compliance with SAMA's third-party requirements can result in regulatory findings during the annual SAMA CSF assessment cycle.
Under SAMA CSF Domain 3 (Cybersecurity Risk Management) and specifically Control 3.3, Saudi banks must establish a formal Third-Party Risk Management (TPRM) program that governs all vendor relationships with access to critical systems or sensitive data.
Key requirements include:
- Pre-onboarding due diligence: Conduct cybersecurity risk assessments before engaging any vendor. Evaluate their ISO 27001 certification status, data handling practices, and incident history.
- Contractual obligations: Embed cybersecurity clauses in all vendor contracts covering data protection (aligned with PDPL Article 29 on data processor obligations), right-to-audit, breach notification timelines (within 72 hours), and compliance with NCA ECC controls.
- Risk tiering: Classify vendors as Critical, High, Medium, or Low risk based on data sensitivity and system access. Critical vendors — such as core banking providers or cloud platforms — require annual on-site or remote audits.
- Continuous monitoring: Use automated vendor risk platforms or periodic questionnaires (at least annually for high-risk vendors) to track changes in their security posture. Review SOC 2 Type II or equivalent reports.
- Offboarding procedures: Ensure data deletion, access revocation, and credential decommissioning upon contract termination.
SAMA examiners specifically look for evidence of a documented TPRM policy, a vendor inventory register, completed risk assessments, and contractual cybersecurity annexes. Financial institutions that rely on cloud services must additionally comply with NCA Cloud Cybersecurity Controls (CCC) to ensure vendor environments meet residency and security benchmarks.
Security awareness training is a foundational requirement under SAMA CSF Domain 2 (Cybersecurity Leadership & Governance), specifically Control 2.4, which mandates that all financial institutions establish and maintain a cybersecurity awareness and training program tailored to employee roles.
Mandatory requirements:
- Frequency: All employees must complete cybersecurity awareness training at least annually. Employees with privileged access or critical roles (IT, finance, executive) require additional role-based training.
- Onboarding: New hires must complete foundational security training within their first 30 days.
- Phishing simulations: SAMA examiners expect evidence of phishing simulation campaigns conducted at least twice a year, with click-rate tracking and remedial training for employees who fail.
- Awareness metrics: Maintain records of training completion rates, test scores, and phishing simulation results. SAMA may request these during examinations.
Recommended program structure:
- Tier 1 – All Staff: Annual e-learning covering phishing, social engineering, password hygiene, data classification, and incident reporting procedures.
- Tier 2 – Technical & IT Staff: Advanced training on secure coding (if applicable), network security, vulnerability management, and access control best practices.
- Tier 3 – Executives & Board: Cybersecurity risk briefings focused on governance, regulatory liability, and crisis decision-making.
NCA alignment: NCA ECC Article 2-5 also requires organizations to ensure all users understand their cybersecurity responsibilities, reinforcing SAMA's training obligations.
Practical tips: Use Arabic-language training modules relevant to Saudi regulatory context, gamify assessments to improve engagement, and integrate training with your GRC platform to automate tracking and reporting.
Third-party risk management (TPRM) is a critical compliance obligation under SAMA CSF Domain 4 (Third Party Cybersecurity). Banks and fintechs must implement a structured lifecycle for managing vendor cyber risk across onboarding, ongoing monitoring, and offboarding.
Key requirements include:
- Risk Classification (SAMA CSF 4.1): Categorize all vendors by criticality — critical, high, medium, or low — based on data access, system integration depth, and service criticality to core banking operations.
- Due Diligence Before Onboarding: Require vendors to submit cybersecurity assessments, ISO 27001 certificates, or equivalent evidence before contract execution. For critical vendors, conduct independent security reviews.
- Contractual Controls (SAMA CSF 4.2): Embed mandatory cybersecurity clauses covering incident notification timelines (typically within 24–72 hours), right-to-audit provisions, data handling obligations aligned with PDPL, and minimum security baseline standards.
- Continuous Monitoring: Perform annual reassessments for critical vendors and biennial reviews for others. Use questionnaires, audit reports (e.g., SOC 2 Type II), or on-site assessments.
- Concentration Risk: Identify and document scenarios where multiple critical services depend on a single vendor to assess systemic exposure.
- Offboarding Controls: Ensure data deletion, credential revocation, and access termination are formally documented upon contract end.
NCA ECC Article 2-7 also requires organizations to assess cybersecurity controls of entities with access to national infrastructure. Institutions using cloud services must additionally apply SAMA's Cloud Computing Framework and NCA's Cloud Cybersecurity Controls (CCC-1).
Building a vendor risk register with automated review triggers is the most practical starting point for institutions scaling their TPRM programs.
Under SAMA CSF Domain 3.3 (Third-Party Management), Saudi banks and financial institutions are required to establish a formal, risk-based vendor management program. Here is what compliance looks like in practice:
Pre-Onboarding Assessment: Before engaging any third party, conduct a cybersecurity due diligence review. This includes reviewing vendor SOC 2 Type II reports, ISO 27001 certifications, and completing a standardized security questionnaire aligned with SAMA CSF controls. Classify vendors by criticality — Tier 1 (critical/core banking systems), Tier 2 (significant), and Tier 3 (low risk).
Contractual Requirements (SAMA CSF 3.3.2): All contracts must include mandatory cybersecurity clauses: right-to-audit provisions, incident notification obligations (typically within 72 hours), data handling and retention requirements aligned with PDPL, and minimum security standards the vendor must maintain.
Ongoing Monitoring: SAMA expects continuous oversight, not just point-in-time assessments. Implement annual reassessments for Tier 1 vendors, biannual for Tier 2. Monitor vendor security posture using threat intelligence feeds or external attack surface tools.
Concentration Risk: SAMA CSF also requires institutions to identify and manage concentration risk — if multiple critical functions depend on a single vendor, document this risk and establish contingency plans.
NCA ECC Alignment: NCA ECC Article 2-12 reinforces supply chain security controls, particularly for cloud and outsourced services. Ensure vendor agreements reference NCA ECC compliance obligations where applicable.
Practical Tip: Maintain a centralized vendor risk register updated quarterly, and report critical third-party risks to the board-level risk committee at least annually as required under SAMA governance expectations.
Third-party risk management is a critical compliance obligation for Saudi financial institutions. Under SAMA CSF Control 3.3, banks must establish a formal TPRM program covering vendor onboarding, continuous monitoring, and offboarding. NCA ECC Article 2-7 further mandates that outsourced services do not compromise organizational cybersecurity posture.
Key implementation steps include:
- Vendor Classification: Categorize vendors by risk tier (critical, high, medium, low) based on data access, system integration depth, and service criticality.
- Due Diligence: Conduct pre-contract cybersecurity assessments including questionnaires, evidence review, and on-site audits for Tier-1 vendors. Verify ISO 27001 certifications or equivalent controls.
- Contractual Controls: Embed cybersecurity clauses covering data handling, breach notification timelines (aligned with PDPL's 72-hour reporting requirement), audit rights, and right-to-terminate provisions.
- Continuous Monitoring: Implement ongoing assessments at least annually for critical vendors, with real-time monitoring for vendors with direct system access.
- Concentration Risk: SAMA expects banks to identify and mitigate over-reliance on single vendors, particularly in cloud and core banking services.
- Incident Coordination: Define escalation paths for vendor-originated security incidents and ensure vendors participate in your incident response exercises.
A mature TPRM program should integrate with your GRC platform to automate vendor scoring, track assessment cycles, and generate audit-ready reports for SAMA examinations. Financial institutions that outsource to cloud providers must additionally comply with SAMA's Cloud Computing Framework, ensuring data residency within the Kingdom where required.
Saudi banks must establish a robust Third-Party Risk Management (TPRM) program aligned with SAMA CSF Domain 3.3 (Third-Party Management) and NCA ECC-1:2-6.3. Here's a practical implementation roadmap:
1. Vendor Classification & Risk Tiering Categorize all vendors based on data access, criticality, and service type. Critical vendors (e.g., core banking providers, cloud platforms) must undergo full due diligence including on-site assessments.
2. Pre-Onboarding Security Assessment Before contracting, evaluate vendors against a standardized questionnaire covering ISO 27001 controls, data handling practices, and incident response capabilities. Per SAMA CSF Control 3.3.2, contractual obligations must include cybersecurity requirements, audit rights, and breach notification clauses (within 72 hours aligned with PDPL Article 19).
3. Continuous Monitoring Implement ongoing monitoring mechanisms including periodic security reassessments (annually for high-risk vendors), review of SOC 2 Type II or ISO 27001 certification validity, and threat intelligence feeds for vendor-related breaches.
4. Concentration Risk Management NCA ECC requires identifying and managing concentration risks where multiple critical services depend on a single vendor. Maintain documented fallback or exit strategies.
5. Fourth-Party Risk Awareness Extend risk visibility to sub-processors and key subcontractors your critical vendors rely upon.
6. SAMA Reporting Material third-party incidents or changes must be reported to SAMA through the established supervisory channels. Maintain a live vendor register accessible during regulatory examinations.
A well-structured TPRM program not only satisfies regulatory obligations but significantly reduces supply-chain attack exposure — a growing threat vector in the Saudi financial sector.
Identity and Access Management (IAM) sits at the core of cybersecurity compliance for Saudi financial institutions. Both SAMA CSF and NCA ECC establish detailed, mandatory controls governing how organizations manage user identities, privileges, and authentication.
Regulatory Requirements:
- SAMA CSF Control 3.3.3 requires formal access control policies, least-privilege enforcement, privileged access management (PAM), and periodic access reviews.
- NCA ECC Control 2-5 mandates strong authentication, role-based access control (RBAC), and monitoring of privileged accounts.
- SAMA CSF Control 3.3.7 specifically addresses privileged access, requiring multi-factor authentication (MFA) for all privileged users and administrators.
Practical Implementation Roadmap:
- Access Governance Foundation: Establish a formal Joiner-Mover-Leaver (JML) process ensuring accounts are provisioned, modified, and deprovisioned in a timely and auditable manner. Orphaned accounts represent one of the most common SAMA audit findings.
- Least Privilege & RBAC: Map all job roles to defined access rights. Eliminate shared accounts and generic admin credentials — common in legacy banking environments.
- Privileged Access Management (PAM): Deploy a PAM solution for all privileged accounts (domain admins, database admins, system owners). Session recording, just-in-time access, and password vaulting are considered baseline requirements.
- Multi-Factor Authentication: Enforce MFA across all remote access, privileged sessions, and internet-facing applications. SAMA and NCA both treat MFA as non-negotiable for financial institutions.
- Access Reviews: Conduct quarterly access certification campaigns for privileged users and semi-annual reviews for general users. Document all review outcomes as audit evidence.
- ISO 27001 Alignment: IAM controls map to ISO 27001:2022 Annex A Controls 5.15–5.18, making a unified implementation efficient across multiple frameworks.
A GRC platform can automate access review workflows, track exceptions and remediation, and generate cross-framework compliance evidence linking SAMA, NCA, and ISO 27001 controls in a single audit-ready report.
Under SAMA CSF Control Domain 3.3 (Human Resources Security), Saudi banks are required to implement a formal, role-based cybersecurity awareness and training program covering all staff — from executives to frontline employees. The program must be documented, periodically reviewed, and aligned with identified risks.
A compliant program should include:
1. Mandatory Onboarding Training: Every new hire must complete cybersecurity awareness training before or shortly after gaining system access, covering topics such as phishing, social engineering, password hygiene, and acceptable use policies.
2. Role-Based Modules: Privileged users, IT administrators, developers, and senior management must receive tailored content beyond general awareness — including secure coding (for developers), insider threat recognition (for managers), and access control responsibilities (for system admins).
3. Annual Refresher Cycles: SAMA CSF requires at minimum annual re-training, but best practice — especially given NCA ECC alignment — recommends quarterly micro-learning sessions supplemented by simulated phishing campaigns.
4. Phishing Simulation & Metrics: Run controlled phishing simulations at least twice a year and track click rates, reporting rates, and repeat offenders. Use these metrics to demonstrate program effectiveness to auditors.
5. Executive & Board Awareness: Senior leadership must receive briefings on cyber risk governance, their responsibilities under SAMA CSF, and emerging threat landscapes — ideally quarterly.
6. Documented Evidence: Maintain training completion records, assessment scores, and simulation results. These are reviewed during SAMA regulatory examinations and third-party audits.
Our platform automates training assignments, tracks completions, generates audit-ready reports, and integrates phishing simulation results — ensuring your institution remains continuously compliant with SAMA CSF human resource security requirements.
SAMA CSF Control Domain 3.5 (Third-Party Management) establishes clear obligations for Saudi financial institutions when engaging vendors, outsourced service providers, fintech partners, and cloud providers. Failure to manage third-party cyber risks adequately is one of the most cited findings in SAMA regulatory examinations.
Core SAMA CSF Third-Party Requirements:
1. Pre-Engagement Security Assessment: Before onboarding any vendor with access to systems, networks, or data, conduct a formal cybersecurity risk assessment. This should evaluate the vendor's ISO 27001 certification status, penetration testing history, SOC 2 reports, and adherence to NCA ECC controls if they are a Saudi entity.
2. Security Clauses in Contracts: All vendor contracts must include mandatory cybersecurity provisions covering: data handling obligations (aligned with PDPL Article 21 for cross-border transfers), breach notification timelines, right-to-audit clauses, and compliance with applicable Saudi regulations.
3. Ongoing Monitoring & Periodic Re-Assessment: Third-party risk management is not a one-time exercise. SAMA CSF requires periodic reassessment — annually at minimum for critical vendors — reviewing changes in their security posture, certifications, and incident history.
4. Concentration Risk Management: Evaluate dependencies on single vendors providing critical services (e.g., core banking platforms, cloud infrastructure). SAMA examiners assess whether institutions have contingency plans if a critical vendor suffers a major cyber incident.
5. Outsourcing-Specific Controls: For outsourced processes involving customer data or critical functions, SAMA CSF 3.5 requires additional controls including dedicated SLAs for security incidents, segregation of duties, and monitoring of vendor privileged access.
6. Vendor Register Maintenance: Maintain a continuously updated inventory of all third parties, categorized by risk tier (Critical, High, Medium, Low), with documented assessment outcomes and remediation tracking.
Practical Tip: Integrate your vendor risk program with your broader GRC platform so that third-party assessments, contract status, and risk ratings are centrally visible and audit-ready.
Our platform provides a structured vendor risk management module aligned to SAMA CSF 3.5, with automated questionnaires, risk scoring, and escalation workflows.
Saudi banks must establish a formal Third-Party Risk Management (TPRM) program aligned with SAMA CSF Domain 3.3 (Third-Party Management) and NCA ECC-2: 1-5. A mature TPRM program should include the following pillars:
1. Vendor Classification & Risk Tiering: Categorize all third parties based on data sensitivity, system access levels, and business criticality. SAMA CSF requires risk-based due diligence proportional to the vendor's exposure.
2. Pre-Onboarding Assessment: Before contracting, conduct cybersecurity assessments covering ISO 27001 controls, data handling practices, and regulatory compliance posture. Verify whether the vendor holds certifications recognized under NCA guidelines.
3. Contractual Security Obligations: All vendor contracts must embed security clauses covering incident notification timelines (within 72 hours per SAMA expectations), right-to-audit clauses, and data residency requirements aligned with PDPL Article 29 on cross-border data transfers.
4. Continuous Monitoring: Implement ongoing monitoring using automated tools (e.g., SecurityScorecard, BitSight) to track vendor security posture. Periodic reassessments — at least annually for critical vendors — are required under SAMA CSF Control 3.3.5.
5. Offboarding Controls: Ensure data deletion, access revocation, and formal offboarding procedures are enforced when vendor relationships end.
6. Concentration Risk Awareness: SAMA has increasingly scrutinized over-reliance on single vendors, particularly in cloud and payment processing. Document and report concentration risks to the board.
Our platform provides a structured TPRM workflow with pre-built assessment templates mapped to SAMA CSF, NCA ECC, and ISO 27001, enabling compliance officers to track vendor risk posture from onboarding through contract termination in a single dashboard.
Third-party risk management (TPRM) is a critical compliance obligation for Saudi banks under SAMA CSF Domain 4 (Third Party Management) and NCA ECC-1:2018 Article 3.3. A robust TPRM program must include the following layers:
1. Vendor Classification & Due Diligence: Categorize vendors by criticality (critical, high, medium, low) based on data access, system integration, and service dependency. Per SAMA CSF Control 4.2, due diligence must occur before contract signing and include cybersecurity posture assessments.
2. Contractual Obligations: Ensure all vendor contracts include cybersecurity clauses covering: data handling standards aligned with PDPL, the right to audit, incident notification SLAs (typically 72 hours or less), and minimum security baselines per NCA ECC.
3. Continuous Monitoring: SAMA CSF requires ongoing monitoring of critical vendors, not just point-in-time assessments. Use automated risk rating platforms and schedule annual reviews for critical vendors and biennial reviews for others.
4. Subcontractor Oversight: Extend your TPRM scope to include fourth-party risk — vendors your suppliers rely on — especially for cloud and IT service providers.
5. Exit Strategy: Maintain documented exit plans for critical vendor relationships, including data recovery procedures and transition timelines, to ensure operational resilience per SAMA BCM guidelines.
Practically, banks should establish a dedicated Third-Party Risk Committee, maintain a live vendor inventory, and integrate TPRM findings into the overall risk register presented to the board annually. Non-compliance with SAMA TPRM requirements can trigger regulatory findings during SAMA's cybersecurity examinations.
SAMA CSF uses five maturity levels: Level 1 (Initial/Ad-hoc) — informal controls; Level 2 (Developing) — repeatable but not documented; Level 3 (Defined) — documented and standardized; Level 4 (Managed) — measured and controlled; Level 5 (Optimizing) — continuous improvement. Financial institutions are expected to achieve at least Level 3 for most controls.
SAMA requires regulated entities to conduct an annual self-assessment against the Cybersecurity Framework. Results must be submitted to SAMA and used to drive remediation plans. SAMA may also conduct on-site inspections or request third-party audit reports.
SAMA can impose regulatory penalties including fines, supervisory warnings, mandatory remediation timelines, restrictions on business activities, or in severe cases, suspension of licenses. Exact penalties depend on the nature and severity of the non-compliance and SAMA's assessment discretion.
Under SAMA CSF Domain 3 (Cybersecurity Risk Management), specifically controls 3.3.1 through 3.3.5, Saudi banks and financial institutions must implement a structured Third-Party Risk Management (TPRM) program. This involves four critical phases:
1. Pre-Onboarding Due Diligence: Before engaging any vendor, conduct a cybersecurity risk assessment covering the vendor's security posture, data handling practices, and compliance certifications (e.g., ISO 27001, SOC 2). Classify vendors by risk tier — critical, high, medium, or low — based on data access and system integration levels.
2. Contractual Security Requirements: Embed security obligations into vendor contracts, including the right to audit, mandatory breach notification timelines (aligned with PDPL's 72-hour reporting requirement), data residency clauses for Saudi-hosted data, and compliance with NCA ECC controls where applicable.
3. Ongoing Monitoring: Conduct annual security assessments for critical vendors and biannual reviews for high-risk suppliers. Use continuous monitoring tools to track vendor security ratings and any publicly disclosed breaches.
4. Offboarding Controls: Ensure secure data deletion, access revocation, and documentation upon contract termination.
SAMA expects board-level oversight of TPRM programs, with the CISO responsible for maintaining a vendor risk register. Non-compliance may trigger regulatory findings during SAMA's annual supervisory review cycle. Platforms like CISO Consulting can help automate vendor assessments, map findings to SAMA CSF controls, and generate audit-ready reports for regulators.
Third-party risk management is a critical obligation under SAMA CSF Domain 3.3, which requires regulated entities to establish a formal vendor risk management program before onboarding any third party with access to sensitive systems or data. Practically, this means conducting a cybersecurity due diligence assessment for every vendor — covering their security controls, certifications (e.g., ISO 27001), incident response capabilities, and data handling practices. Per SAMA CSF Control 3.3.2, contracts with critical vendors must include mandatory cybersecurity clauses covering data protection, audit rights, breach notification timelines (typically within 72 hours), and the right to conduct or commission security assessments. Financial institutions should classify vendors by criticality — Tier 1 vendors (those with direct access to core banking systems) require the most rigorous scrutiny, including on-site assessments and continuous monitoring. Tier 2 and Tier 3 vendors may be managed through standardized questionnaires and periodic reviews. Additionally, PDPL intersects here: if vendors process personal data of Saudi residents, a Data Processing Agreement (DPA) must be in place, and the institution remains accountable as the data controller. Recommended actions include maintaining a live vendor inventory, performing annual reassessments for critical vendors, and establishing exit strategies to manage vendor offboarding securely. Our platform automates vendor risk scoring, tracks assessment cycles, and generates SAMA-ready reports to streamline this process.
Under SAMA CSF Control Domain 3.3 (Third-Party Cybersecurity), Saudi banks and financial institutions must establish a structured, risk-based vendor management program that goes well beyond standard procurement due diligence. At a minimum, your program should include: 1) Pre-onboarding assessment: Evaluate all third parties handling sensitive data or critical systems using standardized security questionnaires aligned to SAMA CSF controls. Classify vendors by inherent risk (critical, high, medium, low). 2) Contractual obligations: Ensure all vendor contracts include cybersecurity clauses covering data protection per PDPL requirements, incident notification timelines (72-hour breach reporting is a benchmark), right-to-audit clauses, and minimum security baseline expectations. 3) Continuous monitoring: Critical vendors (e.g., core banking providers, cloud platforms) should undergo annual on-site or remote security assessments. Use automated tools to monitor for vendor data breaches, dark web exposure, and certificate issues. 4) Concentration risk: SAMA expects boards to understand and manage concentration risk — if multiple critical functions rely on a single third party, a formal risk acceptance or mitigation plan is required. 5) Offboarding controls: Define procedures for data return, destruction, and access revocation when a vendor relationship ends. Practically, most Saudi banks find the greatest gaps in ongoing monitoring and contractual coverage. Start by inventorying all third parties, classifying them by risk, and ensuring your highest-risk vendors are assessed at least annually. Document everything — SAMA assessors look closely at evidence of active program management, not just policy documents.
Third-party risk management (TPRM) is a critical obligation for Saudi financial institutions. Under SAMA CSF Control 3.3, regulated entities must establish a formal vendor risk management program that includes pre-onboarding security assessments, contractual security obligations, and ongoing monitoring throughout the vendor lifecycle.
Practically, your TPRM program should include:
1. Vendor Tiering: Classify vendors by criticality — Tier 1 (critical/core banking), Tier 2 (significant), Tier 3 (low impact) — and apply proportionate controls.
2. Pre-Onboarding Due Diligence: Require vendors to demonstrate compliance with ISO 27001 or equivalent. For Tier 1 vendors, conduct on-site security assessments or review independent audit reports (SOC 2 Type II).
3. Contractual Requirements: Embed security clauses covering data handling, breach notification (within 72 hours per PDPL Article 19), right-to-audit, and minimum security standards aligned with NCA ECC controls.
4. Continuous Monitoring: Use automated attack surface monitoring tools to track vendor exposure. NCA ECC Domain 2 (Asset Management) implicitly requires visibility into third-party connected systems.
5. Offboarding Procedures: Ensure secure data deletion and access revocation upon contract termination.
Financial institutions that outsource critical operations to cloud or fintech providers must also comply with SAMA's Outsourcing Rules, which require SAMA notification for material outsourcing arrangements. Failure to manage third-party risk adequately is a common finding in SAMA supervisory reviews and can directly impact your CSF maturity score.
Saudi financial institutions face overlapping incident response obligations from multiple regulators. Understanding each layer is essential to avoid both operational and legal exposure.
SAMA CSF Requirements (Control 3.3.5 – Cybersecurity Incident Management):
- Institutions must maintain a documented Cybersecurity Incident Response Plan (CIRP) reviewed at least annually.
- Security incidents must be classified using a defined severity matrix (Critical, High, Medium, Low).
- Critical incidents must be reported to SAMA within timeframes specified in the SAMA Cyber Incident Reporting Framework — typically within 4 hours of detection for major incidents.
- Post-incident reviews (PIRs) are mandatory and must be documented with root cause analysis and corrective actions.
NCA ECC Requirements (Control 2-7 – Cybersecurity Incident Management):
- NCA requires entities to maintain a 24/7 security operations capability or a contracted SOC.
- Incidents must be reported to the National Cybersecurity Authority through official channels when they involve national infrastructure or sensitive data.
PDPL Requirements (Article 19):
- If a breach involves personal data, organizations must notify the Saudi Data & AI Authority (SDAIA) within 72 hours of becoming aware of the incident.
- Affected data subjects must also be notified if the breach poses a high risk to their rights or interests.
Practical Readiness Checklist: ✅ Documented CIRP with defined roles and escalation paths ✅ Incident classification and prioritization matrix ✅ Regulatory notification templates pre-drafted for SAMA, NCA, and SDAIA ✅ Tabletop exercises conducted at least twice per year ✅ Forensic investigation capability (internal or retained)
Building this capability in-house is resource-intensive. Many Saudi fintechs and mid-sized banks engage a vCISO service to design and maintain the CIRP while providing on-call incident support.
SAMA CSF Control 3.3 mandates that regulated entities establish a formal Third-Party Risk Management (TPRM) framework covering the full vendor lifecycle — from onboarding to offboarding. Practically, your program should include four pillars:
- Pre-Engagement Due Diligence: Before contracting any vendor, conduct a cybersecurity risk classification (critical, high, medium, low) based on data access, system integration depth, and service criticality. Per SAMA CSF Control 3.3.1, vendors with access to sensitive financial or customer data must undergo rigorous security assessments.
- Contractual Security Requirements: All vendor contracts must include enforceable cybersecurity clauses — right-to-audit provisions, incident notification timelines (typically 72 hours per PDPL Article 24 alignment), data handling standards, and compliance attestation obligations.
- Continuous Monitoring: SAMA expects ongoing monitoring, not just point-in-time assessments. Implement quarterly security questionnaires for critical vendors, annual on-site audits, and automated monitoring of vendors' public threat intelligence posture.
- Exit and Transition Planning: Document data return/destruction procedures and access revocation protocols for vendor offboarding, aligned with ISO 27001 Annex A.15.2.
Many Saudi banks fail SAMA assessments specifically on TPRM because they treat it as a procurement checkbox rather than a continuous risk process. Your GRC platform should map each vendor to relevant SAMA controls, assign risk owners, and track remediation timelines. A minimum viable TPRM program for a mid-sized bank typically covers 50–200 active vendors segmented by risk tier.
Business Continuity Management (BCM) is one of the most rigorously assessed domains in SAMA CSF audits. Under SAMA CSF Domain 4 (Operational Resilience) and specifically Control 4.2 (Business Continuity & Disaster Recovery), Saudi financial institutions must establish, implement, and regularly test a comprehensive BCM program.
Core BCM Components Required by SAMA CSF:
1. Business Impact Analysis (BIA): Conduct a formal BIA to identify critical business functions, their Maximum Tolerable Downtime (MTD), Recovery Time Objectives (RTO), and Recovery Point Objectives (RPO). For banking systems, RTOs are often set at 4 hours or less for tier-1 systems.
2. BCP & DRP Documentation: Maintain documented Business Continuity Plans and Disaster Recovery Plans that are reviewed and updated at least annually, or after significant organizational changes.
3. Testing Frequency: SAMA requires a minimum of one full DR test annually, complemented by tabletop exercises for key scenarios (ransomware, data center failure, cyber incidents). Results must be formally documented.
4. Backup & Recovery Controls: Per SAMA CSF Control 3.3.8, backups must be encrypted, stored offsite or in a secondary data center, and tested regularly to confirm restorability. Backup integrity checks should occur at minimum quarterly.
5. Communication Plans: Define escalation matrices, stakeholder notification procedures, and regulatory reporting timelines — including SAMA notification requirements for major disruptions.
6. Alignment with NCA ECC: NCA ECC Article 2-12 (Resilience) adds complementary requirements around cyber resilience that should be integrated into your BCM framework to avoid duplication of effort.
Organizations should nominate a BCM Owner at the senior management level and ensure BCM is integrated into the enterprise risk management framework rather than treated as a standalone exercise.
Business continuity and cyber resilience are among the most scrutinized domains during SAMA examinations. SAMA CSF dedicates a full control domain (Domain 3.6 – Cyber Resilience) to ensuring financial institutions can withstand, recover from, and adapt to cyber incidents.
SAMA CSF Core Requirements:
- Business Impact Analysis (BIA): Institutions must conduct a formal BIA identifying critical business processes, their dependencies, and acceptable recovery timeframes (RTO/RPO).
- Cyber Resilience Plans: A documented Cyber Resilience Plan must exist, covering incident containment, recovery procedures, and communication protocols — integrated with the overall Business Continuity Plan (BCP).
- Testing & Exercising: SAMA requires annual testing of BCP/DRP, including tabletop exercises and simulated cyber incident scenarios. Results must be reviewed by senior management.
- Recovery Time Objectives: Critical banking services (e.g., core banking, payment systems) must have RTOs defined per SAMA's operational resilience expectations — typically under 4 hours for tier-1 services.
- Supply Chain Resilience: Continuity planning must account for critical third-party dependencies.
Alignment with ISO 22301: ISO 22301 (Business Continuity Management Systems) complements SAMA CSF well. Key overlaps include BIA methodology, documented BCMS policies, competency requirements, and continual improvement cycles. Achieving ISO 22301 certification demonstrates maturity and can streamline SAMA examinations.
Practical Guidance:
- Map SAMA CSF 3.6 controls directly to ISO 22301 clauses to identify gaps.
- Integrate cyber incident scenarios (ransomware, DDoS, data breach) into your annual BCP testing.
- Ensure your crisis communication plan covers SAMA notification obligations (within 72 hours for major incidents).
- Review and update plans after every major incident or significant infrastructure change.
Business Continuity Management (BCM) is a critical compliance domain under the SAMA Cyber Security Framework. SAMA CSF Control Domain 3.5 (Resilience) requires member organizations to establish, implement, test, and continuously improve BCM programs that address both cybersecurity incidents and broader operational disruptions.
A SAMA-compliant BCM program should be structured around the following pillars:
1. Business Impact Analysis (BIA) Identify critical business functions, their dependencies, and determine Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO). SAMA expects that RTO/RPO targets for critical banking services align with the institution's risk appetite and customer commitments.
2. Business Continuity Plan (BCP) & Disaster Recovery Plan (DRP) Document step-by-step response procedures for various disruption scenarios — cyberattacks, system failures, facility unavailability. Ensure your DRP specifically covers IT system failover, data backup restoration, and alternate processing sites.
3. Crisis Communication Define internal escalation paths and external communication protocols, including notification to SAMA within required timeframes during significant incidents (per SAMA's Cyber Incident Reporting guidelines).
4. Testing & Exercising SAMA requires documented evidence of BCM tests — tabletop exercises, simulation drills, and full failover tests — at least annually. Gaps identified must feed into a formal improvement plan.
5. Third-Party Dependencies Ensure critical vendors and cloud service providers have their own BCM capabilities validated as part of your vendor risk management process.
Integrating your BCM program with ISO 22301 best practices will strengthen your SAMA maturity score and demonstrate a structured, internationally aligned approach during regulatory examinations.
Business Continuity Management (BCM) is a mandatory regulatory obligation for Saudi financial institutions, governed primarily by SAMA CSF Domain 5 (Resilience) and NCA ECC Control 3-7. Institutions must establish a comprehensive BCM program that integrates cybersecurity resilience with broader operational continuity.
Regulatory Baseline: SAMA CSF Control 5.1 requires institutions to develop, maintain, and regularly test Business Continuity Plans (BCPs) and Disaster Recovery Plans (DRPs). Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) must be formally defined and aligned with the criticality of each system.
Key Implementation Steps:
- Business Impact Analysis (BIA): Identify critical business processes, supporting IT assets, and maximum tolerable downtime. For core banking systems, RTOs are typically set at 4 hours or less.
- Cyber-Specific Scenarios: BCM plans must explicitly address ransomware attacks, DDoS incidents, and data center outages—not just natural disasters or hardware failures.
- Testing Cadence: SAMA CSF requires BCM tests at least annually. Tests should include tabletop exercises, simulation drills, and full failover tests for critical systems. NCA ECC reinforces this under its resilience controls.
- Third-Party Dependencies: BCP documentation must address the continuity posture of critical suppliers and cloud providers, including contractual SLA obligations.
- Board Reporting: BCM program status, test results, and identified gaps must be reported to senior management and the Board Risk Committee at least annually.
Documentation, test evidence, and gap remediation records should be maintained within your GRC platform to demonstrate regulatory compliance during SAMA examinations.
Business Continuity Management (BCM) is a regulatory imperative for Saudi financial institutions. SAMA CSF Domain 4 (Resilience) dedicates an entire section to BCM requirements, mandating that all member organizations maintain a documented, tested, and Board-approved BCM program. Alignment with ISO 22301 is strongly recommended and increasingly treated by SAMA examiners as the gold standard for BCM governance.
Here is a structured implementation roadmap:
1. Business Impact Analysis (BIA) Identify critical business functions, acceptable Recovery Time Objectives (RTO), and Recovery Point Objectives (RPO). SAMA CSF Control 4.2.1 requires that RTOs and RPOs be formally documented and approved by senior management.
2. Risk Assessment Integration BCM must be tightly linked to your organization's cybersecurity and enterprise risk framework. Cyber incidents, ransomware, and DDoS attacks must be explicitly modeled as threat scenarios in your Business Continuity Plan (BCP).
3. Develop Response Plans Create and maintain a BCP, Disaster Recovery Plan (DRP), and Crisis Communication Plan. Ensure these plans cover core banking systems, payment processing (SARIE/AFAQ connectivity), and customer-facing digital channels.
4. Testing and Exercises SAMA CSF Control 4.2.5 requires at least annual BCP tests, including tabletop exercises and full simulation drills. Test results and gaps must be documented and reported to the Board Risk Committee.
5. Third-Party Continuity Ensure that critical service providers also maintain BCM programs aligned with your own RTOs. This is a common gap flagged during SAMA examinations.
6. Continuous Improvement Post-incident reviews and annual BCM audits (preferably by an independent party) are required to maintain ISO 22301 certification and SAMA compliance.
Business continuity and cyber resilience are among the most scrutinized areas during SAMA supervisory examinations. SAMA CSF Control Domain 3.4 (Cyber Resilience) requires financial institutions to develop, maintain, and regularly test Business Continuity Plans (BCPs) and Cyber Incident Recovery Plans that specifically address cybersecurity scenarios — not just traditional IT disaster recovery.
Key Requirements:
1. Recovery Objectives: SAMA expects documented Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) for all critical systems, typically ranging from 4–24 hours for core banking depending on system criticality. These must be validated — not just estimated.
2. Scenario-Based Testing: Annual BCP tests must include cyber-specific scenarios such as ransomware attacks, DDoS against core banking infrastructure, and third-party service provider outages. Tabletop exercises involving the CISO, CRO, and Executive Management are mandatory per SAMA guidance.
3. Crisis Communication: SAMA CSF requires pre-approved communication templates and escalation matrices for cybersecurity incidents, including timely notification to SAMA within defined windows (typically within 72 hours of a significant incident).
4. Integration with NCA ECC: NCA ECC Control 2-14 mandates that organizations maintain operational resilience capabilities. SAMA-regulated entities should ensure their BCPs are cross-referenced and consistent with NCA requirements to avoid duplication of gaps.
5. Documentation & Evidence: Maintain test records, lessons-learned reports, and remediation logs in your GRC platform. SAMA examiners will request these during regulatory visits.
Weak BCP posture is a leading cause of downgraded SAMA CSF maturity scores. Treat resilience testing as a continuous program, not an annual checkbox.
Business Continuity Management (BCM) is a critical compliance area governed by multiple Saudi regulatory frameworks. Here is how financial institutions should structure their BCM program: SAMA CSF Requirements (Control 3.3.9): SAMA mandates a formalized BCM program that includes Business Impact Analysis (BIA), Recovery Time Objectives (RTO), Recovery Point Objectives (RPO), and tested Disaster Recovery Plans (DRP). RTOs for critical banking services such as core banking, payment systems, and internet banking are typically expected to be under 4 hours, with RPOs of no more than 1 hour. NCA ECC Alignment (Article 2-18): NCA ECC reinforces BCM requirements by mandating resilience controls for critical national infrastructure entities, including financial institutions. This includes documented continuity plans reviewed and tested at least annually. Key Implementation Steps: (1) Conduct a comprehensive BIA to identify critical processes and dependencies; (2) Define RTOs and RPOs per system criticality tier; (3) Establish alternate processing sites or cloud-based failover environments; (4) Develop and maintain a Crisis Communication Plan; (5) Conduct tabletop exercises and full DR drills at least annually; (6) Ensure BCM scope covers cybersecurity incidents, not just natural disasters or outages. Testing & Documentation: SAMA assessors will expect to review test results, lessons-learned reports, and evidence of executive sign-off on BCM plans. Gaps identified during drills must be tracked and remediated with clear ownership. Integrating BCM with your incident response plan ensures a seamless response to cyber-induced disruptions.
Business Continuity Management (BCM) is a mandatory domain under SAMA CSF (Domain 4: Resilience), and SAMA expects Saudi banks to maintain a comprehensive, tested, and board-approved BCM program. Here is what maturity looks like in practice:
Foundation — Policy and Governance:
- A Board-approved BCM Policy aligned with SAMA CSF Control 4.1 and ISO 22301.
- Clear ownership: a BCM Manager or function reporting to the CISO or COO.
- BCM scope covering critical business processes, technology systems, and third-party dependencies.
Business Impact Analysis (BIA):
- Identify and prioritize critical business functions with defined Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs).
- SAMA expects RTOs for critical banking services (e.g., payment processing, core banking) to be aggressive — typically under 4 hours for Tier-1 banks.
Plans and Playbooks:
- A documented Business Continuity Plan (BCP) covering people, process, and technology continuity.
- A separate Disaster Recovery Plan (DRP) for IT systems, with tested failover to a secondary data center.
- Crisis Communication Plans for internal staff, regulators (SAMA notification obligations), and customers.
Testing and Exercises:
- Full BCM tests must be conducted at least annually. SAMA CSF Control 4.3 requires documented test results and evidence of lessons learned.
- Tests should progress from tabletop exercises to full simulation drills.
Integration with Cybersecurity:
- Ransomware and cyber-incident scenarios must be embedded into BCP/DRP testing, reflecting SAMA's focus on cyber resilience.
- BCM findings should feed into your risk register and annual SAMA self-assessment.
A truly mature BCM program is not a document — it is a living capability that is continuously tested, updated, and embedded in your operational culture.
Business Continuity Management (BCM) is a critical compliance area for Saudi fintechs, governed by SAMA CSF Domain 4 (Operational Resilience) and NCA ECC Control 2-14. Non-compliance can result in regulatory sanctions and reputational damage, particularly given the Central Bank's focus on payment system resilience.
SAMA CSF Requirements (Domain 4):
- Conduct a formal Business Impact Analysis (BIA) identifying critical processes, dependencies, and maximum tolerable downtime (MTD) for each function.
- Define Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) aligned with the BIA findings.
- Develop and document a Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP) reviewed and approved by senior management annually.
- Test BCM plans at least annually through tabletop exercises, and full failover drills for technology-dependent processes.
NCA ECC Control 2-14 Requirements:
- Establish a dedicated BCM policy and assign ownership at the executive level.
- Ensure cyber incident scenarios are embedded within BCP exercises, not treated separately.
- Document lessons learned from tests and update plans accordingly.
Practical Implementation Steps:
- Map all fintech services (payments, lending, onboarding) to underlying IT systems and third-party dependencies.
- Define tiered recovery priorities — payment processing should typically target RTO < 4 hours.
- Use cloud-based geo-redundant infrastructure within Saudi Arabia or approved data residency regions per SAMA guidelines.
- Integrate BCM with your Incident Response Plan to ensure seamless escalation.
- Report BCM test results to the Risk Committee quarterly.
Aligning BCM with ISO 22301 principles provides an internationally recognized structure that satisfies both SAMA and NCA auditors simultaneously.
Business Continuity Management (BCM) is a mandatory domain under SAMA CSF, addressed comprehensively in Domain 4 — Resilience. Financial institutions must establish, maintain, and periodically test a BCM program that ensures the continued delivery of critical financial services during and after disruptive events.
Core SAMA CSF Requirements:
Business Impact Analysis (BIA): Per SAMA CSF Control 4.1, institutions must conduct a formal BIA to identify critical business functions, dependencies, Recovery Time Objectives (RTOs), and Recovery Point Objectives (RPOs). RTOs for critical banking systems are generally expected to be under 4 hours.
Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP): Documented plans must exist for all critical processes and IT systems, covering scenarios such as cyberattacks, data center failures, and pandemic events.
Testing and Exercises: SAMA CSF Control 4.3 requires BCM plans to be tested at least annually. Tests should include tabletop exercises, functional drills, and full failover simulations for critical systems. Results must be documented with lessons learned and improvement actions.
Crisis Communication: Plans must include defined communication trees for internal stakeholders, SAMA regulators, and customers during incidents.
Third-Party Dependencies: BCM must account for critical vendor and outsourcing continuity, ensuring suppliers maintain compatible BCM standards.
Board Oversight: The board and senior management are expected to review and approve BCM policies annually and receive test results.
Integration with ISO 22301: Many Saudi institutions align their BCM programs with ISO 22301 (Business Continuity Management Systems), which provides a globally recognized certification pathway that also satisfies SAMA's intent. Maintaining evidence of BCM testing, BIA updates, and board approvals is essential for SAMA regulatory examinations.
Under SAMA CSF Domain 3.7 (Resilience Management), Saudi financial institutions must establish a comprehensive Business Continuity Management (BCM) program that addresses both operational disruptions and cybersecurity incidents. Key requirements include: (1) BIA and RTO/RPO Definition — Conduct a formal Business Impact Analysis identifying critical processes, with Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) defined per system criticality. SAMA CSF Control 3.7.2 mandates these be formally documented and approved by senior management. (2) Tested DR Plans — Disaster Recovery Plans must be tested at least annually, with results documented and remediation actions tracked. Tabletop exercises alone are insufficient; full failover tests are expected for Tier-1 systems. (3) Cyber Resilience Integration — BCM plans must explicitly address ransomware scenarios, DDoS attacks, and core banking system outages. This aligns with NCA ECC Article 2-14 requirements for continuity under cyber incidents. (4) Third-Party Dependencies — Continuity plans must account for critical vendor failures, including cloud providers and payment processors. (5) Board Oversight — SAMA expects the Board Risk Committee to receive annual BCM status reports. Practical implementation tip: map your BCM documentation directly to SAMA CSF control references to simplify regulatory examinations. Integrate your BCM framework with ISO 22301 standards for a defensible, internationally recognized posture that satisfies both SAMA examiners and international auditors.
The SAMA Cyber Security Framework (CSF) uses a structured maturity model to evaluate the cybersecurity posture of member organizations. Understanding this model and preparing systematically is critical for Saudi banks and financial institutions seeking to demonstrate regulatory compliance and build genuine cyber resilience.
The SAMA CSF Maturity Model: SAMA CSF defines five maturity levels — from Level 1 (Initial/Ad-hoc) to Level 5 (Optimized). Most financial institutions are expected to achieve at minimum Level 2 (Developing) for foundational controls, with Tier 1 banks expected to target Level 3 (Defined) or higher across critical domains including Cybersecurity Leadership, Cybersecurity Risk Management, and Cybersecurity Operations.
Key Assessment Domains: The framework covers five primary domains: (1) Cybersecurity Leadership & Governance, (2) Cybersecurity Risk Management & Compliance, (3) Cybersecurity Operations & Technology, (4) Third-Party Cybersecurity, and (5) Cybersecurity Resilience. Each domain contains subdomains with specific controls and maturity indicators.
Preparation Best Practices:
- Conduct a gap assessment first: Map your current controls against each SAMA CSF subdomain using a structured gap analysis tool before the formal evaluation.
- Document everything: Maturity assessors look for evidence — policies, procedures, meeting minutes, training records, and technical configurations all matter.
- Align your CISO reporting structure: SAMA CSF Control 3.1.1 requires cybersecurity to report at the Board or senior executive level; ensure this is formalized.
- Prioritize high-risk domains: Focus remediation efforts on Identity & Access Management, Incident Response, and Vulnerability Management, which are frequently cited in findings.
- Engage an independent assessor: Use a qualified third party for pre-assessment to identify gaps before the regulatory review.
- Build a continuous monitoring program: Demonstrate ongoing control effectiveness, not just point-in-time compliance.
Banks that treat the SAMA CSF assessment as an annual event rather than a continuous program consistently score lower. Embed maturity improvement into your cybersecurity roadmap for sustained results.
Business Continuity Management (BCM) is a critical regulatory obligation for Saudi fintechs. SAMA CSF dedicates an entire control domain (Domain 3.6 – Cyber Resilience) to BCM, while NCA ECC addresses it under Article 2-10 (Business Continuity and Disaster Recovery).
Key Program Components:
1. Business Impact Analysis (BIA): Identify all critical business processes and their supporting IT systems. Define Maximum Tolerable Downtime (MTD), Recovery Time Objectives (RTO), and Recovery Point Objectives (RPO) for each. SAMA expects RTOs for critical payment services to be within 4 hours.
2. Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP): Develop documented, tested plans covering people, processes, technology, and facilities. Plans must address cyber-induced outages specifically — not just physical disasters.
3. Testing Requirements: SAMA CSF requires BCM tests at minimum annually. Tests must include tabletop exercises, functional drills, and full failover tests for critical systems. Results and lessons learned must be documented.
4. Backup and Recovery Controls: NCA ECC Article 2-10 mandates encrypted, geographically separated backups. Restoration tests must confirm data integrity. Backups of critical systems should follow a 3-2-1 strategy.
5. Governance and Ownership: A named BCM owner at senior management level is required. The CISO and Board must receive annual BCM status reports.
6. Regulatory Notification: Under SAMA guidelines, significant disruptions to financial services must be reported to SAMA within defined timeframes, aligned also with PDPL breach notification obligations.
Integrating BCM into your GRC platform ensures continuous monitoring, automated testing reminders, and audit-ready evidence management.
Business Continuity Management (BCM) for Saudi fintechs must address overlapping requirements from both SAMA CSF (Domain 4 – Operational Resilience) and NCA ECC (Control 2-18). Here is a practical implementation roadmap: 1. Business Impact Analysis (BIA): Identify critical business functions, define Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO). SAMA CSF requires RTOs to be formally approved by senior management. 2. BCM Policy and Governance: Establish a formal BCM policy endorsed by the Board. SAMA CSF Control 4.1 mandates board-level oversight of operational resilience. 3. Disaster Recovery Planning: Maintain a tested Disaster Recovery Plan (DRP) for all critical IT systems. NCA ECC Control 2-18 requires DR site separation and regular failover testing. 4. Crisis Management: Define escalation procedures, communication trees, and regulatory notification timelines — SAMA requires notification within specific windows during major disruptions. 5. Testing and Exercises: Conduct at least one full BCM simulation annually and tabletop exercises semi-annually. Maintain documented test results. 6. Third-Party Dependencies: Map and test BCM arrangements with critical service providers. 7. Continuous Improvement: Feed post-exercise lessons into annual BCM review cycles. Our platform provides BCM module templates pre-mapped to SAMA CSF and NCA ECC controls, enabling gap assessments and automated compliance scoring.
Business Continuity Management (BCM) is a mandatory governance obligation for Saudi financial institutions, deeply embedded in both SAMA CSF Domain 3.5 and NCA ECC Article 3.7. A compliant and mature BCM program must address the full lifecycle from risk assessment through to testing and continuous improvement.
SAMA CSF BCM Requirements (Domain 3.5):
- Establish a formal BCM policy approved by senior management.
- Conduct Business Impact Analysis (BIA) to identify critical processes and define Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO).
- Develop and maintain Business Continuity Plans (BCP) and Disaster Recovery Plans (DRP).
- Test BCM plans at least annually through tabletop exercises, functional drills, or full failover tests.
- Integrate cybersecurity scenarios (ransomware, DDoS, data center outage) into BCM exercises.
NCA ECC Alignment: NCA ECC Article 3.7 requires organizations to ensure critical national infrastructure remains operational during disruptions. Financial institutions classified as Critical National Infrastructure (CNI) must align BCM with national resilience objectives and report major outages to NCA.
Practical Implementation Steps:
- Appoint a BCM Owner at the VP or C-suite level with clear accountability.
- Map dependencies between IT systems, third-party providers, and critical business processes.
- Establish alternate processing sites (hot, warm, or cold) for critical systems.
- Define escalation matrices and communication trees for crisis scenarios.
- Document lessons learned after every test or real incident and update plans accordingly.
- Ensure BCM documentation is reviewed and approved by the board at least annually.
Regulatory examinations routinely assess BCM maturity, and gaps in testing evidence are frequently cited as high-risk findings.
Business Continuity Management (BCM) is a critical compliance domain for Saudi financial institutions, governed primarily by SAMA CSF Domain 4 (Resilience) and NCA ECC Controls 2-9 and 2-10. A compliant BCM program must address both cybersecurity-specific disruptions and broader operational resilience.
SAMA CSF Requirements (Domain 4):
- Maintain a formally approved Business Continuity Policy reviewed at least annually.
- Conduct Business Impact Analyses (BIA) to identify critical processes, Maximum Tolerable Downtime (MTD), Recovery Time Objectives (RTO), and Recovery Point Objectives (RPO).
- Develop and test Business Continuity Plans (BCP) and Disaster Recovery Plans (DRP) at least once per year, including tabletop and live failover exercises.
- Ensure cyber incident scenarios are embedded in BCP testing, not treated separately.
NCA ECC Alignment: NCA ECC Article 2-9 requires organizations to establish a resilience framework covering system redundancy, failover capabilities, and backup integrity verification. Article 2-10 mandates periodic DR drills with documented results reported to senior management.
Practical Implementation Steps:
- Assign a BCM Owner accountable to the Board or Risk Committee.
- Classify systems using a tiered criticality model (Tier 1: Mission Critical, Tier 2: Business Critical, Tier 3: Supporting).
- Ensure backup systems are geographically separated and tested for restoration integrity quarterly.
- Integrate BCM with the Cyber Incident Response Plan to create a unified crisis management framework.
- Document lessons learned from every exercise and update plans accordingly.
Regulators frequently assess BCM maturity during on-site examinations, so maintaining an evidence portfolio of test results, BIA reports, and plan updates is essential.
Business Continuity Management (BCM) under SAMA CSF (Domain 4.3) requires Saudi banks to establish a comprehensive, tested, and regularly updated BCM program. Here are the key implementation requirements:
1. BIA and Risk Assessment: Conduct a formal Business Impact Analysis (BIA) to identify critical business functions, acceptable downtime thresholds (RTO/RPO), and dependencies on IT systems and third parties — per SAMA CSF Control 4.3.1.
2. BCP and DRP Documentation: Develop and maintain written Business Continuity Plans (BCP) and Disaster Recovery Plans (DRP) that cover cybersecurity scenarios, not just physical disasters. Plans must be approved by senior management.
3. Testing and Exercises: SAMA CSF Control 4.3.4 mandates periodic testing — at minimum annually — including tabletop exercises, simulations, and full failover tests. Results must be documented and gaps remediated.
4. Cyber Incident Integration: BCM plans must explicitly address cyber incidents such as ransomware, DDoS attacks, and critical system compromise. Recovery procedures should align with your Cyber Incident Response Plan (CIRP).
5. Communication Plans: Define clear internal and external communication protocols, including SAMA notification timelines and customer communication procedures during disruptions.
6. Third-Party Dependencies: Map all critical vendor dependencies and ensure vendors have their own tested BCM/DRP plans, reviewed as part of your third-party risk management process.
Practical Tip: Align your BCM program with ISO 22301 standards for additional assurance — this strengthens your SAMA CSF posture and is increasingly expected by examiners during regulatory reviews.
Business Continuity Management (BCM) is a critical compliance domain under SAMA CSF Domain 4, specifically Controls 4.2 through 4.5. Saudi financial institutions must build a structured BCM program that goes beyond documentation to demonstrate operational resilience.
Governance Structure: Appoint a dedicated BCM owner at the senior management level, with clear accountability reported to the board. BCM policy must be reviewed and approved annually per SAMA CSF Control 4.2.1.
Business Impact Analysis (BIA): Conduct a formal BIA to identify critical business processes, dependencies, Maximum Tolerable Downtime (MTD), Recovery Time Objectives (RTO), and Recovery Point Objectives (RPO). SAMA expects RTOs for critical banking systems (core banking, payment rails, internet banking) to be aggressive — typically under four hours.
Plan Development: Maintain separate but integrated plans: Business Continuity Plan (BCP), Disaster Recovery Plan (DRP), and Crisis Communication Plan. Each plan must include activation triggers, escalation paths, and designated recovery teams.
Testing Requirements: SAMA CSF mandates regular testing — at minimum an annual full-scale simulation exercise and quarterly tabletop exercises. Test results, including gaps identified, must be documented and remediated.
Third-Party & Technology Dependencies: BCM must account for critical third-party providers (cloud vendors, payment processors, core banking vendors). SAMA CSF Control 4.3.5 requires continuity clauses in vendor contracts.
Integration with Cyber Incident Response: BCM and cyber incident response plans must be integrated, especially for ransomware or DDoS scenarios that could trigger a continuity event.
Practical Tip: Use your GRC platform to automate BIA reviews, track exercise outcomes, and link BCM controls directly to SAMA CSF control mappings for audit-ready reporting.
Business Continuity Management (BCM) for Saudi financial institutions sits at the intersection of SAMA CSF's Cyber Resilience domain and NCA ECC Article 3-7 (Resilience and Continuity Controls), making a unified, framework-aligned BCM program essential.
SAMA CSF Requirements (Control 3.5.x): SAMA requires institutions to maintain a Cyber Resilience program encompassing Business Continuity Plans (BCP), Disaster Recovery Plans (DRP), and Crisis Management procedures. Key obligations include:
- Formal BIA (Business Impact Analysis) identifying critical business processes and Maximum Tolerable Downtime (MTD)
- Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) defined per system criticality
- Annual BCP/DR testing, with results reviewed by senior management
- Integration of cyber incident scenarios into BCM exercises
NCA ECC Alignment (Art. 3-7): NCA ECC reinforces continuity requirements by mandating that organizations maintain documented recovery procedures for all critical national infrastructure-adjacent systems, with particular emphasis on data backup integrity and alternate site readiness.
Practical Implementation Steps:
- Conduct a unified BIA mapping both operational and cyber-specific risks
- Define and document RTOs/RPOs aligned with SAMA's criticality tiers
- Establish hot/warm/cold site strategies for critical payment and core banking systems
- Run tabletop exercises quarterly and full failover tests annually, documenting outcomes
- Ensure BCM documentation is reviewed by the CISO, CRO, and Board Risk Committee annually
- Maintain offline, immutable backups tested for restoration integrity per SAMA's ransomware resilience guidance
Our platform maps your BCM controls directly to both SAMA CSF and NCA ECC control families, providing real-time compliance gap visibility.
Identity and Access Management (IAM) is a foundational pillar under the SAMA Cyber Security Framework (CSF), specifically addressed in Domain 4 (Cybersecurity Operations) and Domain 3 (Cybersecurity Risk Management). Saudi banks must implement the following key IAM controls:
1. Privileged Access Management (PAM): Per SAMA CSF Control 4.2, privileged accounts must be strictly governed, with just-in-time access provisioning, session recording, and regular privilege reviews. No shared admin accounts should exist.
2. Multi-Factor Authentication (MFA): MFA is mandatory for all remote access, privileged user sessions, and access to critical banking systems. This aligns with SAMA CSF Control 4.3 and NCA ECC-1-4-3, which mandates strong authentication mechanisms.
3. Role-Based Access Control (RBAC): Access rights must follow the principle of least privilege. Roles should be formally defined, approved, and reviewed at least semi-annually, with user access recertification campaigns documented.
4. Joiner-Mover-Leaver (JML) Process: Automated workflows must ensure timely provisioning and, critically, de-provisioning of access. SAMA CSF requires that terminated employee access is revoked within defined SLAs — typically within 24 hours for critical systems.
5. Identity Governance: Banks should maintain a centralized identity directory with audit logs for all access changes, reviewed by internal audit periodically.
Practical Recommendation: Conduct a quarterly Access Rights Review (ARR) exercise using your IAM platform and document findings for SAMA CSF assessment evidence. Integrate your IAM solution with SIEM to correlate access anomalies in real time. Non-compliance in this domain is a recurring finding in SAMA CSF maturity assessments.
Under SAMA CSF Domain 3 (Cybersecurity Operations), Saudi banks are required to implement a robust Identity and Access Management program covering several critical controls. Per SAMA CSF Control 3.3.1, organizations must enforce the principle of least privilege, ensuring users are granted only the minimum access necessary for their roles. Control 3.3.2 mandates multi-factor authentication (MFA) for all privileged accounts, remote access sessions, and critical system interfaces. Banks must also maintain a formal joiner-mover-leaver process, ensuring access rights are reviewed during role changes and immediately revoked upon employee termination per Control 3.3.4. Privileged Access Management (PAM) solutions should be deployed to monitor, record, and audit all privileged sessions. Quarterly access reviews are required for critical systems, while annual reviews apply to standard user accounts. Additionally, shared or generic accounts must be eliminated or strictly controlled with individual accountability maintained. From an NCA ECC perspective, Article 2-6 reinforces these obligations for entities within scope, requiring documented IAM policies, automated provisioning workflows, and integration with a centralized directory service. Practical steps include deploying a PAM solution such as CyberArk or BeyondTrust, integrating Single Sign-On (SSO) with MFA via solutions like Azure AD or Okta, and conducting automated quarterly access certification campaigns. Non-compliance with these controls can result in regulatory findings during SAMA examination cycles and increased risk of insider threats or unauthorized access incidents.
Under SAMA CSF Domain 3 (Cybersecurity Operations), specifically Controls 3.3.1 through 3.3.6, Saudi banks must implement a comprehensive Identity and Access Management program that governs how users — especially privileged users — access critical systems and data.
Key requirements include:
1. Least Privilege Principle: Every user, system, and application should have only the minimum access needed to perform their function. Per SAMA CSF Control 3.3.2, access rights must be formally approved, documented, and periodically reviewed (at least annually or upon role changes).
2. Privileged Access Management (PAM): Privileged accounts (admins, DBAs, network engineers) must be tightly controlled. Implement a dedicated PAM solution (e.g., CyberArk, BeyondTrust) to vault credentials, enforce session recording, and require multi-factor authentication (MFA) for all privileged sessions.
3. Multi-Factor Authentication: SAMA CSF mandates MFA for remote access, privileged accounts, and critical system access. This aligns with NCA ECC Control ECC-2-2-6, reinforcing its importance across both frameworks.
4. Access Reviews: Conduct quarterly access recertification for privileged accounts and annual reviews for standard users. Automated joiner-mover-leaver (JML) processes should revoke access within 24 hours of employee departure.
5. Separation of Duties (SoD): No single individual should have end-to-end control over critical processes. Conflicting roles must be identified and mitigated via compensating controls.
Practical Tip: Integrate your IAM solution with your SIEM to alert on anomalous privileged activity. Document your IAM policy, access request workflow, and exception process — SAMA assessors will review these during maturity evaluations.
Identity and Access Management (IAM) is a foundational control domain that sits at the intersection of SAMA CSF and ISO 27001. Here is how Saudi fintechs can design a unified, compliant IAM program:
SAMA CSF Alignment (Control Domain 3.4 – Identity & Access Management):
- Implement a formal access control policy covering role-based access control (RBAC), need-to-know principles, and separation of duties.
- Enforce privileged access management (PAM): all privileged accounts must be individually assigned, logged, and reviewed quarterly.
- Multi-factor authentication (MFA) is mandatory for remote access, privileged accounts, and customer-facing portals.
- Conduct access recertification reviews at least every 90 days for privileged users and every 6 months for standard users.
ISO 27001 Alignment (Annex A Controls A.9.x – Access Control):
- Maintain a formal User Access Management procedure covering joiner, mover, and leaver (JML) processes.
- Document a Business Need justification for each access grant.
- Ensure privileged utility programs are restricted and monitored per A.9.4.4.
Practical Implementation Steps:
- Deploy an Identity Governance & Administration (IGA) platform to automate provisioning and de-provisioning workflows.
- Integrate Single Sign-On (SSO) with your IGA tool to reduce credential sprawl.
- Log all access events to your SIEM and retain logs per SAMA's 12-month minimum retention requirement.
- Map your IAM controls to both SAMA CSF and ISO 27001 in a unified controls register to avoid duplicating audit evidence.
Common Gap: Many fintechs overlook service accounts and API tokens — these must be included in your PAM scope and rotated regularly.
This is one of the most common strategic questions from CISOs at Saudi banks, and the short answer is: yes, pursuing both is highly recommended — they are complementary, not duplicative.
How They Relate: ISO 27001 provides a globally recognized Information Security Management System (ISMS) framework with rigorous process and governance requirements. SAMA CSF, on the other hand, is a sector-specific regulatory framework tailored to the risks and operational realities of Saudi financial institutions. The two share significant overlap — particularly in risk management, access control, incident management, and supplier security — which means ISO 27001 implementation work directly accelerates SAMA CSF compliance.
Key Areas of Overlap:
- Risk Assessment & Treatment (ISO 27001 Clause 6.2 ↔ SAMA CSF Control 3.2)
- Asset Management (ISO 27001 Annex A.8 ↔ SAMA CSF Control 3.3)
- Supplier Relationships (ISO 27001 Annex A.15 ↔ SAMA CSF Third-Party Risk Controls)
- Incident Management (ISO 27001 Annex A.16 ↔ SAMA CSF Control 3.6)
What ISO 27001 Adds: ISO 27001 certification signals to international partners, regulators, and customers that your institution meets a globally audited security standard. It also introduces structured continual improvement cycles (PDCA) that institutionalize security maturity over time.
Practical Recommendation: Conduct an integrated gap assessment mapping your current controls against both frameworks simultaneously. Use a unified control library to avoid redundant documentation. Sequence your effort: establish your ISMS foundation first, then layer SAMA-specific controls. Most mid-sized Saudi banks achieve both within 12–18 months with proper program management.
Our platform's GRC module supports cross-framework mapping to eliminate duplication and track compliance posture across SAMA CSF, ISO 27001, NCA ECC, and NIST CSF in a single dashboard.
Identity and Access Management (IAM) is one of the most scrutinized control domains during SAMA examinations. Under SAMA CSF Control 3.3.3 (Access Control), banks must enforce a formal access management lifecycle covering provisioning, periodic review, and de-provisioning. Key mandatory controls include: (1) Role-Based Access Control (RBAC) — all system access must be granted based on documented job roles with least-privilege principles; standing privileged access must be eliminated in favor of just-in-time (JIT) access; (2) Multi-Factor Authentication (MFA) — SAMA CSF requires MFA for all remote access, privileged accounts, and critical system interfaces; NCA ECC Article 2-5 further mandates MFA for administrative access to national infrastructure-connected systems; (3) Privileged Access Management (PAM) — privileged sessions must be recorded and stored for a minimum of 12 months; shared administrative accounts are prohibited; (4) Access Reviews — quarterly access certification reviews are expected for privileged users; annual reviews for standard users, with evidence retained for regulatory inspection; (5) Segregation of Duties (SoD) — SAMA CSF Control 3.3.3 explicitly requires SoD matrices to prevent conflicts such as a single user having both transaction initiation and approval rights; (6) Directory Hardening — Active Directory or equivalent IAM systems must be hardened per CIS Benchmarks, with service accounts inventoried and managed. Integration with a SIEM for failed login monitoring, account lockout alerting, and anomalous access detection is also required per SAMA CSF Control 3.3.6. Banks should target maturity Level 3 (defined and implemented) across all IAM sub-domains in their SAMA CSF self-assessment.
Under SAMA CSF Control 3.3.1 (Cybersecurity Awareness and Training), Saudi financial institutions are required to establish a formal, role-based security awareness program that covers all employees, contractors, and third parties with access to critical systems. The program must be conducted at least annually, with targeted sessions for privileged users and IT staff delivered more frequently — ideally quarterly.
A well-structured program should include: (1) onboarding training for new joiners before system access is granted; (2) annual refresher training for all staff covering phishing, social engineering, password hygiene, and data handling; (3) role-specific modules for developers (secure coding), finance teams (fraud awareness), and executives (cyber risk governance); and (4) simulated phishing exercises with measurable outcomes tracked over time.
SAMA expects institutions to document training completion rates, maintain evidence of attendance, and report gaps to senior management and the board. Completion rates below 90% across departments should trigger escalation. Additionally, per NCA ECC Article 2-6, awareness programs must align with the national cybersecurity culture framework.
Practically, platforms like the CISO Consulting GRC portal allow you to track training completion by department, generate audit-ready reports, and schedule automated reminders — helping you maintain continuous compliance posture rather than treating awareness as a one-time annual checkbox.
SAMA CSF Control 3.3.1 mandates that Member Organizations establish a formal cybersecurity awareness and training program tailored to roles and responsibilities. Here is a practical implementation roadmap:
1. Program Structure: Design a tiered training model — general staff receive foundational security awareness, IT teams get technical training, and executives and board members receive governance-focused briefings. All new hires must complete onboarding security training before accessing systems.
2. Mandatory Content Areas (per SAMA CSF):
- Phishing and social engineering recognition
- Acceptable use of information assets
- Password hygiene and multi-factor authentication
- Incident reporting procedures
- Data classification and handling
3. Delivery Frequency: SAMA expects at minimum annual training for all staff, with quarterly phishing simulations recommended. High-privilege users (system admins, privileged access holders) should receive role-specific training every six months.
4. Measurement and Metrics: Track completion rates (target: 100% within 30 days of assignment), phishing simulation click rates (benchmark: below 5% after 12 months), and post-training assessment scores. Report metrics to the CISO and board risk committee.
5. Documentation for Audit: Maintain training records including completion timestamps, assessment scores, and training material version history. SAMA examiners will request these during regulatory reviews.
6. Alignment with NCA ECC: NCA ECC Article 2-6 also requires cybersecurity culture promotion across the organization. A unified program satisfies both frameworks simultaneously.
Platforms like our GRC solution can automate training assignment, track compliance status per employee, and generate audit-ready reports aligned with SAMA CSF control evidence requirements.
A robust Cyber Incident Response Plan (CIRP) is not optional for Saudi financial institutions — it is a regulatory necessity under both SAMA CSF and NCA ECC, with specific reporting timelines that carry compliance consequences if missed.
SAMA CSF Requirements (Control 3.5 – Cybersecurity Incident Management): SAMA requires Member Organizations to maintain a documented CIRP that covers: preparation, detection and analysis, containment, eradication, recovery, and post-incident review. Critically, SAMA must be notified of significant cybersecurity incidents within 72 hours of detection. Material breaches may require escalation to the Financial Sector Cyber Threat Intelligence (FinCERT) platform.
NCA ECC Reporting Obligations (Article 2-9): NCA requires reporting of high-impact incidents to the National Cybersecurity Authority within 24 hours of identification. This creates a dual-reporting obligation — organizations must maintain separate notification workflows for SAMA and NCA.
Key CIRP Structural Elements:
- Incident Classification Matrix — define severity levels (P1–P4) with escalation thresholds tied to regulatory reporting triggers.
- Response Team (CSIRT) — assign roles: Incident Commander, Technical Lead, Legal/Compliance Liaison, Communications Officer, and Executive Sponsor.
- Playbooks — develop scenario-specific playbooks for ransomware, DDoS, insider threat, data exfiltration, and payment fraud.
- Communication Templates — pre-draft regulatory notification letters for SAMA, NCA, and PDPL authority (SDAIA) to minimize delay during crisis.
- Evidence Preservation — define chain-of-custody procedures for forensic artifacts; critical for post-incident regulatory inquiries.
- Post-Incident Review (PIR) — conduct within 14 days; document root cause, timeline, and corrective actions. SAMA examiners will review PIR reports.
Testing Frequency: Conduct tabletop exercises at least annually and full simulation drills every 18–24 months. Document results and remediation actions for regulatory evidence.
Our platform provides pre-built CIRP templates mapped to SAMA CSF controls, dual-reporting workflow automation for SAMA and NCA, and incident timeline tracking for regulatory evidence.
Third-party risk management is a critical compliance obligation for Saudi financial institutions. Under SAMA CSF Domain 4.3 (Third Party Management), regulated entities must establish a formal vendor risk assessment program before onboarding any third party with access to critical systems or data.
Key requirements include:
Pre-Onboarding: Conduct cybersecurity due diligence assessments covering the vendor's security posture, certifications (e.g., ISO 27001), and incident response capabilities. SAMA CSF Control 4.3.1 requires risk classification of all third parties based on data sensitivity and system access levels.
Contractual Controls: Embed cybersecurity clauses in all vendor contracts, including data handling obligations, breach notification timelines (aligned with PDPL's 72-hour notification requirement), audit rights, and right-to-terminate clauses.
Ongoing Monitoring: Per SAMA CSF Control 4.3.3, annual reassessments are mandatory for high-risk vendors. NCA ECC Article 2-5 further requires that critical infrastructure dependencies on third parties are documented and tested during business continuity exercises.
Cloud & SaaS Vendors: For cloud service providers, additional controls apply under the NCA Cloud Cybersecurity Controls (CCC-1), requiring data residency confirmation within the Kingdom or explicit SAMA approval for offshore processing.
Practical Steps: Maintain a live vendor inventory, tier suppliers by risk level (Critical/High/Medium/Low), and conduct annual or triggered reassessments. Use standardized questionnaires aligned with SAMA CSF and ISO 27001 Annex A.15. Ensure your TPRM policy is reviewed and approved by the board or relevant risk committee annually.
SAMA CSF Domain 3 (Cybersecurity Operations) and specifically Control 3.3 mandate that all regulated financial institutions maintain a formally documented and tested Cyber Incident Response Plan (CIRP). Non-compliance is a common finding during SAMA examinations and can result in significant regulatory consequences.
Core CIRP Requirements under SAMA CSF:
- Detection & Triage: Implement 24/7 security monitoring capabilities (SOC or managed SIEM) capable of detecting incidents within defined timeframes. SAMA CSF requires clear severity classification criteria aligned with impact to operations and customer data.
- Escalation & Notification: Critical incidents must be escalated to senior management and the Board within defined SLAs. Importantly, SAMA requires member institutions to report significant cybersecurity incidents to SAMA's Cyber Threat Intelligence Unit within 72 hours of discovery — failure to report is treated as a separate regulatory violation.
- Containment, Eradication & Recovery: Document specific technical playbooks for common attack scenarios (ransomware, data breach, DDoS, insider threat). NCA ECC Control 3-5 also requires maintaining forensic evidence integrity throughout the response process.
- Post-Incident Review: Conduct formal lessons-learned reviews within 30 days of incident closure, with findings feeding back into risk registers and control improvements.
Structural Recommendation: Your CIRP should reference and integrate with your Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP) to ensure seamless activation. Test the plan via tabletop exercises at least annually, with results documented for SAMA examiner review. For smaller fintechs, engaging a vCISO or managed security provider to maintain CIRP readiness is a cost-effective approach.
Third-party risk management (TPRM) is a critical compliance requirement for Saudi financial institutions. Under SAMA CSF Control 3.3 (Third-Party Management), organizations must establish a formal vendor risk program covering the entire vendor lifecycle — from onboarding and due diligence to ongoing monitoring and offboarding.
Key implementation steps include:
1. Vendor Classification & Risk Tiering: Classify vendors based on data access, criticality, and service nature. High-risk vendors (e.g., cloud providers, core banking system vendors) require deeper scrutiny per SAMA CSF Control 3.3.2.
2. Pre-Onboarding Due Diligence: Require vendors to complete cybersecurity questionnaires, provide ISO 27001 certificates or SOC 2 Type II reports, and sign Data Processing Agreements (DPAs) aligned with PDPL Article 29 obligations.
3. Contractual Security Requirements: Embed mandatory clauses covering incident notification timelines (per SAMA CSF Control 3.3.4), right-to-audit provisions, and minimum security baselines aligned with NCA ECC Article 2-7.
4. Continuous Monitoring: Conduct annual security assessments for critical vendors and quarterly reviews for high-risk ones. Use threat intelligence feeds to monitor vendor breach disclosures.
5. Concentration Risk Management: SAMA specifically flags risks from over-reliance on a single vendor for critical services — document contingency plans accordingly.
6. Offboarding Controls: Ensure secure data deletion, access revocation, and certificate/key rotation upon vendor termination.
Our platform provides automated vendor risk scorecards, pre-built questionnaire templates mapped to SAMA CSF and NCA ECC controls, and audit-ready reporting — helping your compliance team reduce manual effort while maintaining full regulatory traceability.
Incident reporting obligations in Saudi Arabia's financial sector are among the most stringent in the region, governed by multiple overlapping frameworks that CISOs must navigate carefully.
SAMA CSF Reporting Requirements (Control 3.4.3):
- Immediate notification (within 2 hours): Critical incidents involving core banking disruption, large-scale data breach, or ransomware affecting production systems must be reported to SAMA via the official incident reporting portal.
- Full incident report (within 72 hours): A comprehensive report detailing the nature, scope, affected systems, customer impact, and initial containment actions must be submitted.
- Post-incident report (within 30 days): A root cause analysis (RCA) with remediation plan and lessons-learned documentation is mandatory.
NCA Reporting Obligations: Under the National Cybersecurity Authority's Cybersecurity Event Management (CEM) framework, organizations operating Critical National Infrastructure (CNI) must report significant incidents to the National Cybersecurity Operations Center (NCOC) — with initial notification expected within 4 hours of detection.
PDPL Breach Notification (Article 19): If the incident involves personal data exposure, PDPL mandates notification to the Saudi Data & AI Authority (SDAIA) within 72 hours, and affected data subjects must be informed without undue delay if there is a high risk to their rights.
Practical Preparation Checklist:
- Maintain a pre-approved incident response retainer with 24/7 escalation contacts for SAMA and NCA.
- Document your Incident Classification Matrix aligned to SAMA CSF severity tiers.
- Conduct tabletop exercises simulating breach scenarios at least twice annually.
- Ensure your SIEM/SOAR platform timestamps and logs all detection-to-notification steps for audit evidence.
Failure to meet these timelines can result in regulatory sanctions, reputational damage, and heightened supervisory scrutiny.
Under SAMA CSF Control Domain 3.3 (Third-Party Management), Saudi banks must establish a comprehensive TPRM program that covers the full vendor lifecycle — from onboarding to offboarding. Key requirements include:
1. Risk-Based Vendor Classification: Categorize vendors by criticality (Critical, High, Medium, Low) based on data access, system connectivity, and service dependency. Vendors with access to core banking systems or customer PII require the highest scrutiny.
2. Pre-Engagement Due Diligence: Before contracting, conduct security assessments covering ISO 27001 certification status, data handling practices, incident response capabilities, and sub-contractor dependencies. Per SAMA CSF 3.3.2, banks must obtain documented security assurances before granting access.
3. Contractual Security Obligations: All vendor contracts must include cybersecurity clauses: right-to-audit, incident notification timelines (typically 72 hours under SAMA guidance), data return/destruction upon termination, and compliance with NCA ECC where applicable.
4. Ongoing Monitoring: Conduct annual reassessments for Critical/High-risk vendors and biennial reviews for others. Use questionnaires aligned with SAMA CSF and cross-reference with NCA ECC Article 2-6 controls for technology service providers.
5. Cloud and SaaS Vendors: For cloud providers, apply SAMA's Cloud Framework requirements alongside NCA's Cloud Cybersecurity Controls (CCC-1), ensuring data residency within KSA for sensitive financial data.
Practically, banks should maintain a central vendor registry within their GRC platform, automate assessment workflows, and produce board-level reports on third-party risk exposure. CISO Consulting's platform supports automated TPRM workflows mapped directly to SAMA CSF control requirements.
Security awareness is not optional — it is a formal regulatory requirement under SAMA CSF Domain 2 (Cybersecurity Leadership & Governance) and NCA ECC Article 3-3. A well-structured program goes far beyond annual e-learning modules.
Regulatory Baseline Requirements SAMA CSF Control 2.3 requires institutions to establish a cybersecurity awareness program covering all staff, contractors, and third parties with system access. Programs must be documented, tracked, and evidence must be available for SAMA examiners.
Program Structure Best Practices
Role-Based Training: Generic training is insufficient. Tailor content by role — developers need secure coding training, finance staff need phishing and social engineering awareness, executives need cyber risk governance modules.
Frequency: Conduct mandatory awareness training at onboarding and at minimum annually. Supplement with monthly micro-learning content, newsletters, and simulated phishing campaigns.
Phishing Simulations: SAMA expects evidence of phishing simulation exercises. Track click rates, report rates, and remedial training completion. Benchmark quarterly to demonstrate improvement.
Privileged User Training: Staff with elevated access (system admins, IT ops) require additional specialized training per SAMA CSF Control 3.3.7, covering insider threat, access abuse, and incident reporting obligations.
Metrics & Reporting: Report awareness program effectiveness to senior management and the board annually. Key metrics include training completion rates, phishing simulation improvement trends, and security incident attribution to human error.
Arabic Language Content: Ensure training materials are available in Arabic to maximize staff comprehension and regulatory credibility with SAMA auditors.
A mature awareness program demonstrably reduces your human-layer risk and provides auditable evidence of SAMA CSF compliance.
Third-party risk management (TPRM) is a critical obligation for Saudi financial institutions under SAMA CSF Domain 3.3 and NCA ECC-1:2-6.3. A compliant and mature TPRM program should be built around the following pillars:
1. Vendor Classification & Tiering: Categorize all third parties based on criticality, data access level, and service dependency. Vendors with access to customer data or core banking systems should be classified as Tier 1 and subjected to the most rigorous due diligence.
2. Pre-Onboarding Due Diligence: Before contracting, conduct a formal cybersecurity assessment covering the vendor's security posture, certifications (e.g., ISO 27001), incident history, and subcontractor dependencies. SAMA CSF Control 3.3.3 explicitly requires documented assessments prior to engagement.
3. Contractual Security Requirements: Ensure all vendor contracts include clauses on data protection obligations aligned with PDPL, incident notification timelines (typically within 72 hours), audit rights, and the right to terminate upon non-compliance.
4. Continuous Monitoring: TPRM is not a one-time exercise. Implement ongoing monitoring using threat intelligence feeds, periodic reassessments (at least annually for Tier 1), and automated alerts for changes in vendor risk profiles.
5. Offboarding Controls: Establish secure data return or destruction procedures when a vendor relationship ends, consistent with PDPL Article 19 on data retention and disposal.
A practical starting point is maintaining a centralized vendor risk register reviewed quarterly by the CISO and risk committee. Institutions that treat TPRM as a living program — not just a checkbox — are far better positioned during SAMA regulatory examinations.
Security awareness training is not optional for Saudi fintechs — it is explicitly mandated under SAMA CSF Control 3.2.2 and NCA ECC Article 2-10-1, which require institutions to establish a formal, recurring human security program. Here is how to build one that is both compliant and impactful:
1. Define a Training Policy: Start with a documented Cybersecurity Awareness Policy that sets scope, frequency, roles, and accountabilities. SAMA CSF requires this to be reviewed at least annually.
2. Role-Based Curriculum Design: Generic training fails. Design separate modules for: General staff (phishing, social engineering, password hygiene), IT/security teams (technical threat awareness, secure coding), and Senior management/Board (cyber risk governance, regulatory obligations). NCA ECC Control 2-10-2 specifically calls for tailored content by role.
3. Phishing Simulation Exercises: Run quarterly simulated phishing campaigns to test employee vigilance. Track click rates, credential submission rates, and reporting rates as measurable KPIs. SAMA examiners frequently request evidence of these exercises.
4. Onboarding & Refresher Training: All new employees must complete security awareness training before being granted system access. Existing staff should receive refresher training at least annually, with additional targeted sessions following any security incident.
5. Awareness Metrics & Reporting: Track completion rates, assessment scores, and phishing simulation outcomes. Report these metrics to senior management quarterly and include them in your annual SAMA self-assessment submission.
6. Regulatory & Cultural Localization: Ensure training content references Saudi-specific regulations (SAMA, NCA, PDPL) and uses Arabic-language materials where applicable to maximize comprehension and engagement among your workforce.
A mature awareness program transforms your employees from your greatest vulnerability into your most effective first line of defense.
Third-party risk management (TPRM) is a critical obligation under SAMA CSF Domain 3 (Cybersecurity Risk Management) and specifically referenced in Control 3.3, which mandates that member organizations establish a formal supplier and third-party risk management program.
Practical implementation steps include:
- Vendor Classification: Categorize all third parties by risk level — critical, high, medium, and low — based on the data they access, services they provide, and systemic impact if compromised.
- Pre-Onboarding Assessment: Before engagement, conduct cybersecurity due diligence using standardized questionnaires aligned with SAMA CSF controls, ISO 27001 Annex A, and NCA ECC requirements.
- Contractual Controls: Ensure all vendor contracts include cybersecurity clauses covering data protection (per PDPL obligations), incident notification timelines (typically within 72 hours), right-to-audit provisions, and acceptable use policies.
- Ongoing Monitoring: Perform annual reassessments for critical vendors and bi-annual reviews for high-risk suppliers. Use threat intelligence feeds and continuous monitoring tools to detect supply chain threats.
- Concentration Risk: SAMA specifically flags technology concentration risk — if a single vendor supports multiple critical functions, a dedicated contingency plan must exist.
- Cloud and SaaS Vendors: For cloud-hosted services, verify CSP compliance with NCA Cloud Cybersecurity Controls (CCC) and confirm data residency within the Kingdom where required.
Failure to maintain a documented TPRM program can result in SAMA examination findings, remediation obligations, and reputational damage. Institutions should maintain a live vendor register reviewed at least annually by the CISO and risk committee.
Security Awareness Training (SAT) is not optional for Saudi financial institutions — SAMA CSF Domain 2 (Leadership and Governance) and Control 3.2.1 explicitly mandate a formalized, role-based security awareness program reviewed at least annually.
Program Design Essentials:
- Audience Segmentation: Design differentiated training tracks for: general staff, IT and security personnel, privileged users, and the Board/C-suite. SAMA CSF distinguishes awareness needs across organizational levels.
- Mandatory Topics: At a minimum, cover phishing and social engineering, password hygiene, acceptable use of IT assets, data handling per PDPL obligations, and incident reporting procedures.
- Phishing Simulations: Conduct simulated phishing campaigns at least quarterly. Track click rates, credential submission rates, and remediation completion to demonstrate measurable risk reduction — a key expectation in SAMA examinations.
- Role-Specific Modules for High-Risk Roles: Treasury, payments, and customer-facing staff require specialized training on fraud, BEC (Business Email Compromise), and social engineering tactics given their exposure profile.
- Metrics and Reporting: Maintain training completion records (minimum 90% completion rate recommended), phishing simulation results, and trend analysis. Present these metrics to the Board Risk Committee at least annually per SAMA CSF governance requirements.
- Regulatory Alignment: NCA ECC Article 2-5 also mandates cybersecurity awareness as a foundational control. Align your SAT calendar with the broader cybersecurity governance cycle.
- Continuous Reinforcement: Move beyond annual training — use micro-learning, security newsletters, and real-incident case studies to embed security culture year-round.
A well-documented SAT program with evidence of effectiveness is increasingly scrutinized during SAMA regulatory examinations and demonstrates genuine cybersecurity maturity.
Under SAMA CSF Control Domain 3.3 (Third-Party Management), Saudi banks must establish a formal, risk-based vendor management program that covers the entire lifecycle of third-party relationships — from onboarding through offboarding.
Key requirements include:
- Risk Classification: Categorize all vendors by criticality (e.g., Tier 1 for core banking processors, cloud providers) based on data access, system integration depth, and regulatory exposure.
- Pre-Onboarding Due Diligence: Conduct cybersecurity assessments before contracting, including reviewing the vendor's ISO 27001 certification status, SOC 2 reports, and vulnerability management practices.
- Contractual Controls: Ensure all contracts include clauses mandating incident notification within defined timeframes (aligned with SAMA's 72-hour reporting window), the right to audit, and data return/deletion obligations consistent with PDPL Article 19.
- Continuous Monitoring: Perform annual reassessments for Tier 1 vendors and biennial reviews for lower-risk suppliers. Use threat intelligence feeds to monitor vendors for breaches disclosed externally.
- Concentration Risk: SAMA specifically flags risks arising from over-reliance on a single technology vendor — ensure contingency plans exist if a critical supplier fails.
- Offboarding Controls: Mandate secure data deletion and revoke all access credentials within 24 hours of contract termination.
Financial institutions should also cross-reference NCA ECC Article 2-14 (Supply Chain Security) when procuring technology services. Maintaining a centralised vendor register with real-time risk scores is a recommended best practice that simplifies SAMA examination responses.
Third-party risk management (TPRM) is a critical obligation for Saudi financial institutions under SAMA CSF Domain 3.3 (Third-Party Management) and NCA ECC-1:2018 Control 2-7. Institutions must implement a structured TPRM lifecycle covering vendor onboarding, ongoing monitoring, and offboarding.
Key requirements include:
- Risk-Based Classification: Classify all third parties by their access level to critical systems and sensitive data. Vendors with direct access to core banking infrastructure or customer PII should be categorized as high-risk and subject to enhanced due diligence.
- Contractual Security Obligations: Per SAMA CSF Control 3.3.3, all vendor contracts must include enforceable cybersecurity clauses covering incident notification timelines (typically within 24–72 hours), data handling standards, and the right to audit.
- Cybersecurity Assessments: Conduct annual cybersecurity assessments for critical vendors using standardized questionnaires aligned to ISO 27001 Annex A or NIST CSF. On-site audits should be reserved for Tier-1 suppliers.
- Concentration Risk Monitoring: SAMA expects institutions to identify and mitigate concentration risk where multiple critical functions rely on a single third party.
- Cloud and SaaS Vendors: NCA ECC Control 2-7-3 specifically addresses cloud service provider (CSP) oversight, requiring institutions to ensure CSPs meet local data residency and security standards before onboarding.
Practically, institutions should maintain a centralized Third-Party Risk Register, integrate TPRM into the annual risk assessment cycle, and assign clear ownership to a dedicated vendor risk team or the CISO's office. Automated GRC platforms can streamline evidence collection and continuous monitoring across your supplier ecosystem.
Third-party risk management (TPRM) is a critical obligation under SAMA CSF Domain 3.3, which requires financial institutions to establish a structured lifecycle for managing vendor relationships from onboarding through offboarding.
Key Requirements:
- Pre-onboarding Due Diligence: Per SAMA CSF Control 3.3.1, institutions must assess the cybersecurity posture of all third parties before engagement. This includes reviewing SOC 2 Type II reports, ISO 27001 certifications, and conducting vendor security questionnaires.
- Contractual Controls: SAMA CSF Control 3.3.2 mandates that contracts with third parties include explicit cybersecurity obligations, right-to-audit clauses, data breach notification timelines (aligned with PDPL Article 29), and incident response coordination procedures.
- Continuous Monitoring: Vendors must be re-assessed periodically — at minimum annually for critical vendors — using risk tiering to prioritize effort.
- Cloud and SaaS Providers: When outsourcing to cloud providers, NCA ECC Article 7 cloud security controls also apply, requiring data residency validation and access control reviews.
Practical Steps:
- Build a vendor inventory classified by criticality (critical, high, medium, low).
- Use standardized security questionnaires mapped to SAMA CSF and NCA ECC controls.
- Establish a vendor risk register and escalation thresholds.
- Include TPRM reporting in your board-level cybersecurity dashboards.
Failure to manage third-party risk exposes institutions to regulatory penalties and supply-chain breaches. SAMA has increasingly scrutinized vendor management during examination cycles, making this a top compliance priority for CISOs in 2024 and beyond.
Third-party risk management (TPRM) is a critical compliance obligation for Saudi financial institutions. Under SAMA CSF Control 3.3.1, institutions must establish a formal vendor risk management program that covers the entire vendor lifecycle — from onboarding and due diligence through to contract termination.
Key requirements include:
1. Pre-onboarding Due Diligence: Conduct cybersecurity assessments of all critical vendors, reviewing their ISO 27001 certifications, audit reports (SOC 2 Type II), and security policies before contract signing.
2. Contractual Obligations: Embed security clauses into vendor contracts mandating breach notification timelines (aligned with PDPL's 72-hour reporting obligation), right-to-audit provisions, and data handling requirements per PDPL Articles 19–21.
3. Continuous Monitoring: Per SAMA CSF Control 3.3.3, perform annual reassessments for critical vendors and quarterly reviews for those with access to sensitive financial or personal data. NCA ECC Article 2-14 also requires that outsourced services maintain equivalent security controls to those applied internally.
4. Concentration Risk: Assess single-vendor dependencies, especially for cloud providers, to avoid systemic exposure.
5. Fourth-Party Risk: Identify and assess subcontractors used by your primary vendors, particularly in cloud and SaaS environments.
Our GRC platform provides a structured vendor risk register, automated assessment workflows, and real-time compliance dashboards that map vendor risks directly to SAMA CSF and NCA ECC control requirements — enabling your compliance team to demonstrate regulatory adherence efficiently during SAMA examinations.
Third-party risk management is a critical compliance area under SAMA CSF Domain 3.4 and NCA ECC Article 2-7. Saudi financial institutions must establish a formal Third-Party Risk Management (TPRM) program that covers the entire vendor lifecycle — from onboarding to offboarding.
Key requirements include:
1. Pre-Engagement Due Diligence: Before contracting any vendor, conduct a cybersecurity risk assessment that evaluates the vendor's security posture, certifications (e.g., ISO 27001), and data handling practices. Per SAMA CSF Control 3.4.1, vendors with access to critical systems or sensitive data must undergo enhanced scrutiny.
2. Contractual Security Obligations: All vendor contracts must include cybersecurity clauses mandating compliance with SAMA CSF and PDPL data protection standards, incident notification timelines (typically within 72 hours per PDPL Article 20), right-to-audit provisions, and data return/destruction obligations upon contract termination.
3. Continuous Monitoring: SAMA CSF requires ongoing monitoring of critical vendors, not just point-in-time assessments. Implement automated vendor risk scoring using tools integrated with your GRC platform, and schedule periodic reassessments — at least annually for Tier-1 vendors.
4. Vendor Tiering and Criticality Classification: Classify vendors by criticality (Tier 1–3) based on data sensitivity and operational dependency. NCA ECC Article 2-7-3 specifically requires documented risk treatment plans for high-criticality third parties.
5. Cloud and SaaS Vendors: For cloud service providers, ensure compliance with NCA Cloud Cybersecurity Controls (CCC-1) in addition to standard TPRM controls.
A GRC platform like CISO Consulting automates vendor questionnaires, risk scoring, and compliance gap tracking, significantly reducing the manual burden on your security and procurement teams.
Third-party risk management (TPRM) is a critical obligation under both SAMA CSF (Domain 3.3 – Third Party Management) and NCA ECC (Control 2-14). Saudi financial institutions must establish a formal, risk-based vendor management program that covers the entire vendor lifecycle — from onboarding to offboarding.
Key implementation steps include:
- Vendor Classification: Categorize vendors by criticality and data access level. Vendors handling personal financial data or core banking infrastructure require the highest scrutiny.
- Pre-Onboarding Due Diligence: Conduct cybersecurity assessments before contracting. Request evidence of ISO 27001 certification, penetration test results, and SOC 2 reports where applicable.
- Contractual Obligations: Ensure all vendor contracts include cybersecurity clauses covering data protection (aligned with PDPL Article 21), incident notification timelines (typically 72 hours), audit rights, and right-to-terminate for security failures.
- Continuous Monitoring: Per SAMA CSF Control 3.3.4, institutions must conduct periodic reassessments — at minimum annually for critical vendors. Use automated vendor risk platforms or structured questionnaires (e.g., CAIQ, SIG).
- Concentration Risk: SAMA expects banks to identify and manage concentration risk where multiple critical functions rely on a single vendor or cloud provider.
- Offboarding Controls: Ensure secure data deletion, access revocation, and credential rotation when a vendor relationship ends.
Our GRC platform provides pre-built TPRM workflows mapped directly to SAMA CSF and NCA ECC controls, enabling compliance teams to automate assessments, track vendor risk scores, and generate audit-ready reports with minimal manual effort.
Security awareness training is a mandatory control under both SAMA CSF Domain 2 (Cybersecurity Leadership & Governance) and NCA ECC Control 1-3 (Cybersecurity Awareness and Training). For Saudi fintechs, building a compliant and effective program requires more than generic annual training — it demands a structured, role-based, and continuously measured approach.
Program Design Essentials:
1. Role-Based Training Tracks: Not all employees face the same threats. Separate training modules should be developed for general staff, IT/security teams, privileged users, executives, and board members. SAMA CSF specifically requires board-level cybersecurity awareness per Control 2.1.2.
2. Training Frequency: Annual training alone is insufficient. SAMA recommends at minimum annual formal training supplemented by monthly micro-learning, phishing simulations (quarterly), and just-in-time training triggered by security incidents or policy changes.
3. Content Requirements: Programs must cover phishing and social engineering, password hygiene, data handling aligned with PDPL obligations, acceptable use policies, incident reporting procedures, and secure remote work practices.
4. Phishing Simulation: Regular simulated phishing campaigns are considered a baseline control. Track click rates, report rates, and repeat offenders. Results should feed back into targeted remedial training.
5. Measurement & Reporting: SAMA CSF requires documented training completion rates and effectiveness metrics. These must be reported to senior management and can be requested during regulatory examinations.
6. New Employee Onboarding: Security training must be completed before new hires are granted system access, as required under SAMA CSF Control 3.3.2.
Our platform provides a pre-built awareness training framework with content mapped to SAMA, NCA, and PDPL requirements, automated scheduling, completion tracking, and executive dashboards for audit readiness.
Security awareness training is a foundational control under SAMA CSF Domain 2 (Cybersecurity Leadership & Governance), specifically Control 2.3, which mandates that all employees — regardless of role — receive structured, role-appropriate cybersecurity training.
Baseline Requirements:
- Frequency: General security awareness training must occur at least annually for all staff. Privileged users (system admins, developers, finance personnel) require more frequent, role-specific training — typically semi-annually.
- New Hire Onboarding: All new employees must complete security awareness training before or immediately upon gaining system access, per SAMA CSF 2.3.1.
- Phishing Simulations: SAMA CSF strongly recommends periodic simulated phishing campaigns to measure and improve employee resilience. Results should feed back into training content.
Content Requirements:
- Social engineering and phishing awareness
- Password hygiene and MFA usage
- Data classification and handling (aligned with PDPL obligations for personal data)
- Incident reporting procedures
- Acceptable use of IT systems and BYOD policies
- Remote work security practices
Governance & Documentation:
- Maintain training completion records for all employees — SAMA examiners frequently request these during assessments.
- Track completion rates via an LMS (Learning Management System) and report results to senior management and the Board Risk Committee at least annually.
- Tailor training for the Board and C-suite on cyber risk governance topics.
Maturity Consideration: Institutions targeting SAMA CSF Maturity Level 3+ should demonstrate measurable improvements in training effectiveness through metrics such as phishing click-rate reduction over time.
A well-executed awareness program significantly reduces the human-factor risk that remains the top attack vector for Saudi financial institutions.
Identity and Access Management (IAM) is a foundational requirement under SAMA CSF Domain 4 (Access Control), specifically controls 4.2 and 4.3, which mandate that financial institutions enforce least-privilege access, role-based access control (RBAC), and periodic access reviews. Here's a practical implementation roadmap:
1. Privileged Access Management (PAM): Deploy a PAM solution (e.g., CyberArk, BeyondTrust) to manage, monitor, and audit all privileged accounts. SAMA CSF Control 4.3.2 explicitly requires privileged access to be logged and reviewed.
2. Multi-Factor Authentication (MFA): Enforce MFA for all remote access, administrative consoles, and critical banking systems. This also aligns with NCA ECC-1:2018 Article 3-5-3.
3. Access Reviews: Conduct quarterly access recertification campaigns, ensuring managers formally approve or revoke user entitlements. Document all outcomes for audit evidence.
4. Segregation of Duties (SoD): Implement SoD controls, especially in core banking, treasury, and payment systems, to prevent fraud and unauthorized transactions.
5. Identity Lifecycle Management: Automate provisioning and de-provisioning workflows tied to your HR system. Terminated employees' accounts must be disabled within 24 hours per SAMA CSF guidelines.
6. Directory Services Hardening: Secure Active Directory or LDAP with tiered administration models and monitor for Kerberoasting, pass-the-hash, and lateral movement indicators.
Regular IAM audits, mapped against SAMA CSF maturity levels (1–5), will help identify gaps. Aim for at least Maturity Level 3 (Defined) for core IAM controls, with Level 4 (Managed) for privileged access in larger institutions.
Under SAMA CSF Control 3.3.1 and NCA ECC Article 2-7, Saudi financial institutions are required to establish a formal, risk-based Security Awareness Training (SAT) program that covers all employees, contractors, and privileged users. Here's how to structure it effectively:
Program Design:
- Conduct an annual training needs analysis aligned to your threat landscape and role-based risk profiles.
- Develop at least three training tiers: general staff, IT/security staff, and senior management/board.
- Include topics such as phishing recognition, social engineering, password hygiene, data classification under PDPL, and incident reporting procedures.
Delivery & Frequency:
- Mandatory onboarding training for all new joiners within 30 days.
- Annual refresher training for all staff, with quarterly phishing simulations.
- Role-specific deep-dives for privileged users at least twice annually.
Measurement & Reporting:
- Track completion rates, phishing simulation click-through rates, and post-training assessment scores.
- Report SAT effectiveness metrics to the CISO and Board Risk Committee at least semi-annually.
- Maintain training records for a minimum of 3 years to support SAMA examination requests.
Practical Tip: Integrate SAT outcomes into your SAMA CSF maturity assessment under Domain 3 (Human Resources Security). Low awareness scores can negatively impact your maturity level, so remediation plans should be documented and tracked. Linking the program to PDPL awareness—particularly around data handling and breach reporting obligations—adds dual compliance value.
Security Awareness Training is a mandatory control under SAMA CSF (Control 3.3.1) and NCA ECC (Article 2-7), requiring Saudi financial institutions to maintain a structured, ongoing awareness program for all staff. Here's how to implement one effectively:
Program Structure:
- Conduct a role-based training curriculum — differentiate between general staff, IT teams, executives, and privileged users. SAMA CSF requires tailored content for different user groups.
- Deliver training at least annually, with mandatory onboarding sessions for new hires. NCA ECC recommends quarterly refreshers for high-risk roles.
Required Content Areas:
- Phishing and social engineering recognition
- Password hygiene and multi-factor authentication (MFA) use
- Incident reporting procedures
- Acceptable use of organizational assets
- Data classification and handling (aligned with PDPL obligations)
Measurement and Evidence:
- Run simulated phishing campaigns at least quarterly to measure click rates and improve training effectiveness
- Track completion rates and maintain documented records — SAMA examiners will request training logs and completion evidence during assessments
- Conduct pre- and post-training assessments to measure knowledge improvement
Governance:
- Assign program ownership to the Information Security function with executive sponsorship
- Include SAT metrics in your quarterly security reporting to the Board Risk Committee, as required under SAMA CSF Control 3.1.2
Practical Tip: Integrate real-world Saudi-specific threat scenarios (e.g., SADAD phishing, WhatsApp-based fraud) to increase relevance and engagement. Localized Arabic content significantly improves training retention among staff.
Security awareness training is a mandatory control under SAMA CSF Domain 2 (Cybersecurity Leadership & Governance), specifically Control 2.4, which requires all staff — including board members and senior management — to receive role-appropriate cybersecurity education.
Structuring a compliant program involves:
- Audience Segmentation: Design separate training tracks for general staff, IT personnel, privileged users, and executive leadership. SAMA CSF distinguishes between general awareness and technical role-based training requirements.
- Training Frequency: Conduct mandatory awareness sessions at least annually, with additional targeted modules triggered by significant threat events, new regulatory guidance, or after a security incident. Phishing simulation exercises should run quarterly.
- Content Requirements: Programs must cover phishing recognition, social engineering, password hygiene, data handling per PDPL obligations, acceptable use policies, and incident reporting procedures. For fintech staff, include topics specific to open banking and API security risks.
- Measurement & Reporting: Track completion rates, phishing simulation click rates, and pre/post assessment scores. SAMA CSF Control 2.4.3 expects measurable outcomes — present these metrics in the quarterly Cybersecurity Risk Report to the board.
- New Hire Onboarding: Integrate security awareness into the onboarding process so new employees complete baseline training before accessing production systems.
- Documentation & Evidence: Maintain training records, attendance logs, and assessment results for at least three years to support SAMA examinations and ISO 27001 Annex A.7.2.2 audit evidence.
Institutions that gamify training content and integrate real-world threat scenarios relevant to Saudi banking (e.g., CEO fraud targeting remittance operations) typically achieve significantly higher engagement and retention rates.
A well-structured Cyber Incident Response Plan (CIRP) is a regulatory necessity, not just a best practice. Both SAMA CSF and NCA ECC impose specific, enforceable obligations around incident response.
SAMA CSF Requirements: Under SAMA CSF Domain 3 (Cyber Security Operations), Control 3.4 mandates that financial institutions maintain a documented CIRP that is tested at least annually through tabletop exercises or simulations. The plan must define clear escalation paths, incident classification tiers (low, medium, high, critical), and mandatory reporting to SAMA within specific timeframes — critical incidents must be reported within 3 hours of detection.
NCA ECC Requirements: Per NCA ECC Control 2-8 (Cybersecurity Incident and Threat Management), organizations must establish a Cyber Defense Center (CDC) or equivalent function capable of 24/7 monitoring, triage, and response. The ECC also requires post-incident reviews and lessons-learned documentation to be retained for a minimum of 5 years.
Key CIRP Components:
- Preparation: Defined roles (Incident Commander, Technical Lead, Legal/Compliance, Communications), contact lists, and pre-authorized response playbooks.
- Detection & Analysis: Integration with SIEM/SOAR tools; incident triage criteria aligned with SAMA's severity classification.
- Containment, Eradication & Recovery: Step-by-step procedures per incident type (ransomware, DDoS, insider threat, data breach).
- Notification: Regulatory reporting to SAMA and NCA; PDPL breach notification to SDAIA within 72 hours if personal data is involved.
- Post-Incident Review: Root cause analysis, control gap identification, and plan updates.
Regularly testing and refining your CIRP ensures both regulatory compliance and operational resilience.
Third-party risk management (TPRM) is a critical compliance obligation for Saudi financial institutions under SAMA CSF Domain 3.3 (Third-Party Management) and NCA ECC-1:2018 Article 3-3. Here is a structured approach:
1. Vendor Classification & Due Diligence Begin by classifying all vendors based on data sensitivity and criticality. SAMA CSF Control 3.3.1 requires institutions to assess cybersecurity posture before onboarding. Conduct pre-contract security assessments including SOC 2 Type II reviews, ISO 27001 certification checks, and questionnaire-based evaluations.
2. Contractual Obligations Embed cybersecurity clauses in all vendor contracts — covering incident notification timelines (typically within 24–72 hours), right-to-audit provisions, data handling obligations under PDPL Article 21, and minimum security baseline requirements aligned with NCA ECC controls.
3. Continuous Monitoring SAMA CSF Control 3.3.3 mandates ongoing monitoring of third-party performance. Use threat intelligence feeds, security ratings platforms (e.g., BitSight or SecurityScorecard), and conduct periodic reassessments — at least annually for critical vendors.
4. Offboarding Controls Establish secure data deletion and access revocation procedures when vendor relationships end, consistent with PDPL data retention principles.
5. CISO-Level Oversight Maintain a third-party risk register reviewed quarterly by the CISO or risk committee. Escalate critical findings to the board where required under SAMA governance expectations.
Organizations that treat TPRM as a checkbox exercise often discover supply-chain vulnerabilities during incidents. A mature TPRM program should be risk-based, continuously updated, and integrated into your overall cybersecurity governance framework.
Incident response (IR) is a foundational requirement under SAMA CSF Domain 3.6 and NCA ECC Domain 2-10. Saudi banks must maintain a documented, tested, and board-approved IR capability.
Mandatory IR Program Components (SAMA CSF 3.6):
- IR Policy and Plan: A formal Incident Response Plan (IRP) covering preparation, detection, containment, eradication, recovery, and lessons learned — aligned with the NIST CSF Respond function.
- IR Team Structure: Designate a Computer Security Incident Response Team (CSIRT) with clearly defined roles, escalation paths, and 24/7 contact availability for critical incidents.
- Incident Classification: Classify incidents by severity (Critical, High, Medium, Low) with corresponding response SLAs. SAMA expects Critical incidents to trigger immediate executive notification.
- Regulatory Reporting Obligations:
- SAMA: Report significant cyber incidents within 3 hours of detection for critical incidents, followed by a detailed report within 72 hours. SAMA's Cyber Incident Reporting portal (via REGTECH) must be used.
- NCA (via CERT-SA): Report incidents affecting national infrastructure or government-connected systems to CERT-SA promptly.
- PDPL: If the incident involves personal data breach, the National Data Management Office (NDMO) must be notified within 72 hours of discovery.
- Tabletop Exercises: SAMA CSF 3.6.5 requires IR exercises at least annually, with evidence of lessons learned integrated into plan updates.
- Forensic Readiness: Maintain forensic logging capabilities with at least 12 months of log retention to support post-incident investigation.
Failing to report a significant incident to SAMA within the required window is a serious compliance violation — ensure your SOC team has the reporting playbook ready and tested before an incident occurs.
Third-party risk management (TPRM) is a critical obligation under SAMA CSF Domain 3 (Cybersecurity Risk Management) and NCA ECC controls related to supply chain security. Here is a practical implementation approach:
1. Vendor Classification & Due Diligence Classify vendors by criticality — Tier 1 (critical systems access), Tier 2 (sensitive data access), Tier 3 (general services). Per SAMA CSF Control 3.3.1, conduct formal cybersecurity due diligence before onboarding any third party with access to your infrastructure or data.
2. Contractual Security Requirements Embed cybersecurity clauses in all vendor contracts covering: data protection obligations aligned with PDPL, minimum security baseline (ISO 27001 certification preferred), right-to-audit provisions, and breach notification timelines (within 72 hours per SAMA incident reporting guidelines).
3. Continuous Monitoring Do not treat TPRM as a one-time checkbox. Implement ongoing monitoring through annual security questionnaires, periodic penetration test evidence requests from critical vendors, and automated threat intelligence feeds tracking vendor exposure.
4. NCA ECC Alignment NCA ECC Article 2-14 requires organizations to enforce cybersecurity requirements on third parties and service providers operating within their environment. This includes cloud providers, managed security service providers (MSSPs), and software vendors.
5. Practical Tip Maintain a centralized vendor risk register within your GRC platform, updated at least quarterly. Assign ownership to each vendor relationship and escalate critical findings to the CISO and board risk committee.
Non-compliance in this area is one of the most frequently cited gaps in SAMA regulatory examinations.
Under SAMA CSF Domain 3 (Cybersecurity Risk Management), Saudi banks must establish a formal Third-Party Risk Management program that governs the entire vendor lifecycle — from onboarding to offboarding. Specifically, SAMA CSF Control 3.3 mandates that institutions assess the cybersecurity posture of all third parties who access, process, or store bank data.
Key program components include:
1. Vendor Classification: Tier vendors by criticality — critical (core banking, payment processors), high, medium, and low — with risk assessments scaled accordingly.
2. Pre-Onboarding Due Diligence: Require vendors to submit cybersecurity questionnaires, evidence of certifications (ISO 27001, SOC 2), and penetration test results before contract execution.
3. Contractual Obligations: Embed cybersecurity clauses covering data handling, incident notification (within 72 hours per PDPL Article 19), right-to-audit provisions, and compliance with NCA ECC Art. 2-3 where applicable.
4. Ongoing Monitoring: Conduct annual reassessments for critical vendors and trigger event-based reviews following any vendor security incident or significant operational change.
5. Offboarding Controls: Ensure secure data deletion, revocation of all access credentials, and documented confirmation of data return or destruction.
From a practical standpoint, banks should integrate their TPRM platform with the institution's GRC system to maintain a live vendor risk register. SAMA examiners increasingly scrutinize whether banks have real-time visibility into critical vendor posture rather than point-in-time assessments. Aligning TPRM with ISO 27001:2022 Annex A Control 5.19 (Information Security in Supplier Relationships) further strengthens audit readiness across multiple frameworks simultaneously.
Incident response in Saudi banking is governed by multiple overlapping frameworks, creating layered reporting obligations that CISOs must navigate carefully.
SAMA CSF Requirements (Domain 4 — Cybersecurity Resilience): SAMA CSF Control 4.1 requires banks to maintain a formally documented Incident Response Plan (IRP) covering preparation, detection, containment, eradication, recovery, and post-incident review. The IRP must be tested at least annually through tabletop exercises or simulations.
Regulatory Notification Timelines:
- SAMA: Banks must notify SAMA of significant cybersecurity incidents within 3 hours of detection via the SAMA Cybersecurity Notification Portal. A follow-up detailed report is required within 72 hours covering root cause, affected systems, data exposure, and remediation steps.
- PDPL (Article 19): If personal data of Saudi residents is compromised, the National Data Management Office (NDMO) must be notified within 72 hours, and affected individuals notified without undue delay where there is high risk to their rights.
- NCA ECC: Critical infrastructure entities must additionally report to the National Cybersecurity Authority through the CERT-SA reporting channel.
Practical Guidance: Banks should maintain pre-approved communication templates for each regulator to avoid delays under pressure. Designate a dedicated Incident Response Coordinator who owns regulatory notifications. Conduct quarterly reviews of the incident classification matrix to ensure all staff distinguish between a security event, incident, and crisis — each triggering different escalation paths. Align playbooks with NIST CSF's Respond function (RS.CO-2, RS.CO-3) to maintain internationally recognized standards alongside local compliance.
Under SAMA CSF Control Domain 3.5 (Third-Party Management), Saudi banks must establish a comprehensive TPRM program that covers the full vendor lifecycle — from onboarding to offboarding. Here is a practical framework to follow:
1. Vendor Classification & Risk Tiering: Categorize all vendors by criticality (Tier 1: critical, Tier 2: significant, Tier 3: low-risk). Critical vendors handling customer data or core banking functions require the most rigorous due diligence.
2. Pre-Onboarding Due Diligence: Before contracting, assess vendors against SAMA CSF controls, NCA ECC requirements, and ISO 27001 alignment. Request evidence of certifications, penetration test results, and data handling practices especially under PDPL obligations.
3. Contractual Safeguards: Contracts must include cybersecurity obligations, right-to-audit clauses, SLA definitions for incident notification (per SAMA CSF 3.5.3), data residency requirements, and exit/termination procedures.
4. Continuous Monitoring: Conduct annual reassessments for Tier 1 vendors and biennial reviews for Tier 2. Use automated tools to monitor vendor security posture, track vulnerability disclosures, and assess compliance drift.
5. Incident Notification Requirements: Vendors must notify the bank within defined timeframes (typically 24–72 hours) of any security incident that may impact bank systems or customer data.
6. Cloud & SaaS Vendors: For cloud service providers, additional controls per SAMA Cloud Computing Guidelines apply, including data classification, shared responsibility matrix documentation, and exit strategy planning.
A mature TPRM program not only satisfies SAMA CSF expectations but also reduces supply chain risk — a growing threat vector for Saudi financial institutions.
SAMA CSF dedicates a specific domain to third-party and outsourcing risk, requiring financial institutions to maintain a formal Vendor Risk Management (VRM) program that spans the entire vendor lifecycle — from onboarding through offboarding. Per SAMA CSF Control 3.3.1, institutions must conduct risk-based due diligence on all third parties before engagement, assessing their cybersecurity posture, data handling practices, and regulatory compliance status.
Key program components include:
1. Vendor Classification & Tiering: Categorize vendors by criticality (e.g., Tier 1 for core banking system providers, Tier 3 for low-risk suppliers). Apply proportionate controls based on the data and system access each vendor holds.
2. Contractual Security Requirements: All contracts must embed cybersecurity clauses covering incident notification timelines (typically ≤72 hours), right-to-audit provisions, data handling obligations aligned with PDPL, and compliance with NCA ECC where applicable.
3. Continuous Monitoring: Annual reassessments are insufficient for high-risk vendors. Implement continuous monitoring via security ratings platforms, periodic questionnaires, and mandatory penetration test evidence submission.
4. Concentration Risk: SAMA explicitly expects institutions to assess and mitigate concentration risk — where multiple critical functions depend on a single third party (e.g., a dominant cloud provider).
5. Fourth-Party Risk: Extend due diligence to subcontractors used by your vendors, particularly for outsourced IT and managed security services.
Practically, institutions should maintain a centralized vendor risk register, assign ownership to each vendor relationship, and report aggregated third-party risk exposure to the Board Risk Committee quarterly. Alignment with ISO 27001 Annex A.15 further strengthens your VRM framework and supports audit readiness.
SAMA CSF dedicates Domain 4 (Third-Party Management) to vendor risk, requiring financial institutions to establish a formal Third-Party Risk Management (TPRM) framework that covers the full vendor lifecycle — from initial due diligence to contract termination.
Key requirements include:
Pre-engagement: Conduct cybersecurity risk assessments before onboarding any vendor with access to systems or data. Classify vendors by criticality (critical, significant, standard) per SAMA CSF Control 4.1.2.
Contractual controls: Ensure contracts mandate security standards, right-to-audit clauses, incident notification obligations (typically within 72 hours), and data protection terms aligned with PDPL.
Ongoing monitoring: Perform periodic reassessments — at minimum annually for critical vendors. This includes reviewing SOC 2 Type II reports, ISO 27001 certificates, or conducting direct security assessments.
Concentration risk: SAMA specifically requires banks to assess and manage over-reliance on single vendors, particularly cloud and technology providers.
Exit strategy: Maintain documented exit plans for critical vendors to ensure business continuity under SAMA CSF Control 4.3.1.
Practically, build a vendor register categorizing all third parties, automate reassessment workflows through your GRC platform, and align your questionnaires with SAMA CSF, NCA ECC, and ISO 27001 Annex A.15 controls. Ensure your information security team signs off on all critical vendor engagements before the procurement team finalizes contracts. Many Saudi banks also require critical vendors to demonstrate NCA ECC compliance, especially when those vendors operate within the Kingdom.
Third-party risk management (TPRM) is a critical obligation under SAMA CSF Domain 4 (Third Party Management), which requires Saudi financial institutions to establish a formal, risk-based vendor governance framework. Here's how to structure it effectively:
1. Vendor Classification (SAMA CSF Control 4.1): Categorize all vendors by criticality — critical, high, medium, and low — based on data access, system integration depth, and business impact. Critical vendors supporting core banking or payment infrastructure require the most rigorous oversight.
2. Pre-Onboarding Due Diligence: Before contracting, conduct cybersecurity assessments covering ISO 27001 certification status, penetration testing history, data handling practices, and incident response capabilities. Require vendors to complete a standardized security questionnaire aligned with NCA ECC Art. 3-4 controls.
3. Contractual Security Obligations (SAMA CSF Control 4.3): Embed mandatory cybersecurity clauses covering right-to-audit, breach notification timelines (ideally within 24–72 hours), data residency requirements under PDPL, and compliance with SAMA's outsourcing regulations.
4. Continuous Monitoring: Implement ongoing risk monitoring using automated vendor risk scoring tools, periodic reassessments (annually for critical vendors, biennially for others), and real-time threat intelligence feeds related to your vendor ecosystem.
5. Incident and Exit Management: Define clear escalation paths if a vendor suffers a breach, and maintain documented exit strategies to ensure business continuity without vendor lock-in.
SAMA also requires that outsourced critical functions remain under the institution's effective control — meaning your internal team must retain oversight authority at all times. Document all TPRM activities in a centralized register reviewable by SAMA examiners during assessments.
SAMA CSF Domain 3.3 (Cybersecurity Incident Management) mandates that all Saudi banks and financial institutions maintain a formally documented and regularly tested incident response (IR) program. Here's what compliance requires and how CISOs should build it:
Mandatory IR Program Components (SAMA CSF Control 3.3.1–3.3.5):
- A formally approved Incident Response Plan (IRP) covering detection, containment, eradication, recovery, and lessons learned phases
- Defined severity classification levels aligned to business impact
- Clear escalation procedures, including board and executive notification thresholds
- Dedicated IR roles and responsibilities documented in a RACI matrix
Regulatory Notification Obligations: SAMA requires institutions to report significant cybersecurity incidents to SAMA within defined timelines. Incidents affecting critical financial infrastructure or customer data must be reported promptly — typically within 24 hours of discovery for high-severity events. Coordinate simultaneously with NCA's Cybersecurity Operations Center (CSOC) for incidents that may have national significance.
Practical Build-Out Steps for CISOs:
- Develop playbooks for your top 10 incident scenarios: ransomware, insider threat, DDoS on banking platforms, SWIFT fraud, mobile banking compromise, etc.
- Integrate your SIEM/SOAR with the IRP workflow to enable automated alerting and ticket creation
- Conduct tabletop exercises at minimum quarterly; full simulation exercises annually
- Align forensic evidence preservation procedures with Saudi legal requirements to maintain admissibility
- Cross-reference NIST CSF's Respond and Recover functions for international best-practice alignment
Document all exercises, incidents, and post-incident reviews in a centralized log available to SAMA examiners. Continuous improvement cycles are a key evaluation criterion during SAMA assessments.
SAMA CSF Domain 4.5 mandates that all Member Organizations establish a formal Cybersecurity Incident Management capability. For CISOs at Saudi banks and fintechs, this translates into a structured program with the following key requirements:
Regulatory Reporting Obligations: Per SAMA CSF Control 4.5.3 and SAMA's Cyber Incident Reporting Framework, significant incidents must be reported to SAMA within 72 hours of detection. Incidents affecting payment systems or customer data may also trigger parallel reporting to NCA (per ECC-2: 2-3) and SDAIA under PDPL Article 24.
IR Program Components (SAMA CSF 4.5):
- Documented Incident Response Plan (IRP) reviewed at least annually
- Defined incident classification matrix (P1–P4 severity levels)
- Designated Incident Response Team (IRT) with clear roles and escalation paths
- 24/7 monitoring capability or SOC coverage (in-house or managed)
- Evidence preservation and forensic investigation procedures
- Post-incident review and lessons-learned process
NIST CSF Alignment: Structure your IR capability around NIST's five functions — Identify, Protect, Detect, Respond, Recover — which maps well to SAMA CSF's control domains.
Tabletop Exercises: SAMA CSF requires periodic IR drills. Conduct at least one tabletop exercise annually, simulating scenarios such as ransomware, BEC fraud, or data exfiltration. Document results and remediation actions.
Practical Tip: Integrate your IR workflows directly into your GRC platform to auto-generate incident tickets, track SLA compliance with SAMA reporting timelines, and produce audit-ready evidence for SAMA examinations.
Under SAMA CSF Domain 4 (Third-Party Management), Saudi financial institutions must implement a structured, lifecycle-based approach to vendor risk. Here's a practical framework:
1. Pre-Onboarding Due Diligence Before contracting any third party, conduct a cybersecurity risk assessment covering the vendor's security posture, certifications (e.g., ISO 27001), and compliance with NCA ECC controls. Classify vendors by criticality — Tier 1 (critical systems access), Tier 2 (sensitive data access), Tier 3 (general services).
2. Contractual Security Requirements (per SAMA CSF 4.3) Ensure all vendor contracts include mandatory clauses for: data protection aligned with PDPL, incident notification within 72 hours, right-to-audit provisions, and minimum security baselines mirroring your internal standards.
3. Continuous Monitoring Establish quarterly security reviews for Tier 1 vendors and annual reviews for Tier 2/3. Use automated vendor risk platforms where possible. Review vendor access logs, patch compliance, and any reported breaches.
4. Concentration Risk SAMA also expects institutions to assess concentration risk — if multiple critical services rely on a single vendor (e.g., a cloud provider), your BCP must account for vendor failure scenarios.
5. Offboarding Controls Upon contract termination, revoke all access immediately, retrieve or securely destroy data per PDPL Article 19, and document the offboarding in your risk register.
A mature TPRM program integrates with your ISO 27001 Annex A.15 controls and feeds directly into your board-level risk reporting cycle. SAMA inspectors increasingly focus on vendor risk during regulatory examinations — treat this as a first-class risk domain.
SAMA CSF Domain 3 (Cybersecurity Operations & Resilience) mandates a formal, tested incident response capability. Here is what a CISO must build:
1. Documented IR Policy and Playbooks (SAMA CSF 3.3) Maintain a board-approved IR policy with specific playbooks for high-probability scenarios: ransomware, data breach, DDoS against banking systems, and insider threat. Each playbook must define roles, escalation paths, and communication templates.
2. Classification and Severity Thresholds Adopt a clear severity matrix (P1–P4). Critical incidents affecting customer funds, core banking availability, or involving confirmed data exfiltration must escalate to the CISO and CEO within 1 hour.
3. Regulatory Notification Obligations SAMA requires financial institutions to notify SAMA's cybersecurity team within 72 hours of detecting a significant cyber incident. Coordinate this with PDPL Article 26 obligations — if personal data is involved, the National Data Management Office (NDMO) must also be notified. Maintain a dual-notification checklist.
4. Digital Forensics and Evidence Preservation Ensure your SOC or retained IR firm follows a proper chain-of-custody process for digital evidence — this is critical if legal proceedings or regulatory investigation follow.
5. Post-Incident Review and Lessons Learned Within 2 weeks of incident closure, conduct a structured post-mortem. Findings must feed back into your risk register, control improvements, and training program per ISO 27001 Clause 10.1.
6. Annual IR Drills Conduct at least one tabletop exercise and one technical simulation annually. SAMA inspectors will ask for evidence of testing — document everything including attendance, scenarios, and action items.
SAMA CSF Domain 4 (Operational Resilience) mandates that financial institutions establish, document, and regularly test Business Continuity Plans (BCP) and Disaster Recovery Plans (DRP). Per SAMA CSF Control 4.3, institutions must define Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) for all critical systems, with annual testing at minimum.
Practical implementation steps include:
- Business Impact Analysis (BIA): Identify critical business processes and their dependencies, classifying systems by criticality tier. Core banking and payment systems typically require RTOs of less than 4 hours.
- Scenario-Based Testing: Conduct tabletop exercises, parallel run tests, and full failover drills. SAMA expects evidence of testing results, gaps identified, and remediation actions.
- Third-Party Dependencies: Map and test continuity plans for critical vendors and cloud providers, especially given SAMA's outsourcing guidelines.
- ISO 22301 Alignment: Aligning your BCP framework with ISO 22301 strengthens SAMA CSF compliance and provides an internationally recognized structure for documentation and audits.
- Board Reporting: SAMA CSF requires that BCP/DRP status and test results be reported to senior management and the Board Risk Committee annually.
Failure to demonstrate tested and effective continuity plans is one of the most common findings in SAMA cybersecurity assessments. Ensure your DRP includes cyber incident scenarios such as ransomware attacks, which are increasingly relevant for Saudi financial institutions.
Under SAMA CSF Domain 4 (Third-Party Management), Saudi banks must implement a structured, risk-based vendor oversight program covering the entire supplier lifecycle. Here's a practical implementation roadmap:
1. Vendor Classification & Risk Tiering Classify all third parties based on data access, system criticality, and service type. SAMA CSF Control 4.1.2 requires you to distinguish between critical, significant, and standard suppliers, applying proportionate controls accordingly.
2. Pre-Onboarding Due Diligence Before contracting, conduct security assessments that include: review of the vendor's ISO 27001 or equivalent certification, network architecture diagrams, incident response procedures, and PDPL compliance posture if they process personal data.
3. Contractual Security Requirements All vendor contracts must embed cybersecurity obligations per SAMA CSF Control 4.2.1, including: right-to-audit clauses, breach notification timelines (typically within 72 hours aligned with PDPL Article 28), data handling standards, and subcontractor disclosure requirements.
4. Continuous Monitoring Conduct annual security assessments for critical vendors and bi-annual assessments for significant ones. Use automated tools to monitor vendor risk scores, and track any changes in their security posture or regulatory standing.
5. Offboarding Controls Establish formal offboarding procedures ensuring secure data deletion, revocation of all access credentials, and documented confirmation of data return or destruction.
A common gap we see is treating third-party risk as a one-time procurement checklist rather than an ongoing governance function. Appoint a dedicated vendor risk owner and integrate third-party findings into your board-level cybersecurity reporting to demonstrate SAMA CSF maturity at Tier 3 and above.
Third-party risk management (TPRM) is a critical obligation under SAMA CSF Domain 3.3 and NCA ECC-1:2-6, requiring Saudi financial institutions to maintain a structured vendor risk program. Here's a practical implementation roadmap:
1. Vendor Classification & Tiering Categorize vendors by criticality — Tier 1 (critical system access), Tier 2 (significant data access), Tier 3 (limited exposure). SAMA CSF Control 3.3.1 mandates formal risk classification before onboarding.
2. Due Diligence & Contractual Controls Conduct pre-onboarding cybersecurity assessments including security questionnaires, ISO 27001 certification verification, and penetration testing results review. Contracts must include right-to-audit clauses, incident notification SLAs (typically 24–72 hours), and data handling obligations aligned with PDPL Articles 18–21.
3. Continuous Monitoring Implement ongoing monitoring using threat intelligence feeds and periodic reassessments (at minimum annually for Tier 1 vendors). NCA ECC requires evidence of vendor compliance documentation being maintained.
4. Concentration Risk SAMA specifically flags concentration risk where multiple critical services rely on a single vendor — this must be flagged in your risk register and escalated to the Board Risk Committee.
5. Exit Strategy Document vendor exit plans ensuring business continuity per SAMA CSF Control 3.3.6, including data recovery, transition timelines, and service continuity assurance.
Practically, your GRC platform should automate vendor risk scoring, track assessment lifecycles, and generate Board-ready TPRM dashboards to demonstrate regulatory compliance during SAMA examinations.
Third-party risk management (TPRM) is a critical obligation under SAMA CSF Domain 4 (Third-Party Management), requiring Saudi financial institutions to implement a structured, lifecycle-based approach to vendor oversight.
Key Requirements:
- Vendor Classification & Due Diligence (SAMA CSF 4.1): Classify vendors by criticality — Tier 1 (critical/core banking), Tier 2 (important), Tier 3 (standard). Conduct cybersecurity due diligence before onboarding, including reviewing SOC 2 Type II reports, ISO 27001 certifications, and penetration testing results.
- Contractual Controls (SAMA CSF 4.2): Embed mandatory cybersecurity clauses covering data protection, incident notification (within 24–48 hours), right-to-audit, and compliance with SAMA CSF and PDPL obligations.
- Continuous Monitoring: Perform annual security assessments for Tier 1 vendors and biennial reviews for Tier 2. Use automated threat intelligence feeds and vendor risk platforms to monitor ongoing risk posture.
- Concentration Risk: SAMA also expects institutions to assess concentration risk — over-reliance on a single vendor (e.g., a sole cloud provider) must be documented with contingency plans.
- Offboarding Controls: Ensure data deletion, access revocation, and exit procedures are formally managed upon vendor termination.
Practical Tip: Establish a Vendor Risk Committee with representation from IT, Legal, Procurement, and the CISO's office. Maintain a centralized vendor risk register updated quarterly. For fintechs relying heavily on SaaS providers, map each vendor's data access to PDPL Article 29 obligations to ensure cross-border data transfer compliance is addressed simultaneously.
Business Continuity Management (BCM) is a foundational requirement under SAMA CSF Domain 6 (Cyber Resilience) and strongly aligns with ISO 22301 (Business Continuity Management Systems). Saudi banks must treat BCM not as a checkbox exercise but as a living, tested program integrated with cybersecurity incident response.
SAMA CSF BCM Requirements (Domain 6):
- Business Impact Analysis (BIA): Identify critical business processes, systems (especially core banking, payment infrastructure, and SWIFT), and establish Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO). SAMA expects RTOs for Tier 1 systems to be less than 4 hours.
- BCM Policy & Governance: The BCM program must be approved at Board level, with a designated BCM Owner (often the COO or CISO) and reviewed annually.
- Disaster Recovery Plans (DRP): Technical recovery runbooks must exist for all critical systems, with documented failover procedures to geographically separated data centers (SAMA mandates primary and DR sites within the Kingdom).
- Crisis Communication Plans: Define communication trees for internal staff, SAMA notifications, customer communications, and media handling during a major disruption.
ISO 22301 Alignment:
- Conduct a formal gap assessment against ISO 22301 clauses 6–10 to identify BCM maturity gaps.
- ISO 22301 Clause 8.5 specifically addresses testing requirements — tabletop exercises, functional drills, and full failover tests.
Testing Cadence:
- Tabletop exercises: Twice annually.
- Technical DR failover tests: Annually.
- Full-scale business continuity exercises: Every two years.
Practical Tip: Integrate BCM testing scenarios with cybersecurity incident response drills. A ransomware simulation that triggers the DR plan is far more valuable than isolated testing. Document all lessons learned and update plans within 30 days post-exercise. Ensure SAMA is notified per CSF reporting timelines if a real incident triggers BCM activation.
Business continuity and cyber resilience represent one of the most rigorously assessed domains for Saudi financial institutions, with obligations spanning both SAMA CSF and NCA ECC frameworks.
SAMA CSF Requirements (Domain 3 — Cybersecurity Resilience): SAMA CSF Control 3.3 mandates that member organizations develop, maintain, and regularly test a Cyber Resilience Plan (CRP) that specifically addresses cyber-triggered disruptions — distinct from general IT disaster recovery. Key requirements include:
- Recovery Time Objectives (RTO): Core banking systems must have RTOs defined and tested, typically ≤4 hours for Tier-1 institutions.
- Recovery Point Objectives (RPO): Data recovery capabilities must be validated against defined RPOs with evidence of backup integrity testing.
- Tabletop and Simulation Exercises: At minimum annual cyber resilience exercises simulating ransomware, DDoS, or data breach scenarios involving senior leadership and the CISO.
- Third-Party Dependencies: BCP must document and test recovery procedures that account for critical vendor or cloud provider outages.
NCA ECC Alignment (Article 2-13 — Business Continuity): NCA ECC extends these requirements to government-affiliated financial entities and critical national infrastructure, mandating:
- Formal BCM policy approved at executive level.
- Annual BIA (Business Impact Analysis) reviews with cybersecurity scenarios explicitly included.
- Integration of cybersecurity incident response timelines within BCP documentation.
Practical Integration Steps:
- Map SAMA CSF CRP controls against ISO 22301 (Business Continuity Management) for international alignment.
- Include cloud failover and data sovereignty provisions in BCP for institutions using hyperscaler environments.
- Conduct joint exercises between cybersecurity and BCM teams — SAMA examiners look for this integration evidence.
Our vCISO consulting service helps institutions build, test, and document BCPs that satisfy both SAMA and NCA examiners.
Under SAMA CSF Domain 4 (Cybersecurity Resilience), Saudi banks must establish a robust Business Continuity Management program that addresses cyber-induced disruptions specifically — not just traditional operational risks.
Core Requirements:
- Business Impact Analysis (BIA): Identify critical systems, acceptable Recovery Time Objectives (RTO), and Recovery Point Objectives (RPO) per SAMA CSF Control 4.1. For core banking systems, SAMA typically expects RTOs under 4 hours.
- BCM Policy & Plans: Maintain documented Business Continuity Plans (BCP) and Disaster Recovery Plans (DRP) aligned with SAMA CSF Control 4.2, covering cyber incident scenarios such as ransomware, DDoS, and data destruction attacks.
- Crisis Communication: Define escalation paths, internal notification trees, and SAMA regulatory notification timelines (within 72 hours for major incidents per SAMA incident reporting guidelines).
Testing Requirements: SAMA CSF mandates annual testing at minimum, but best practice for Tier-1 banks includes:
- Tabletop exercises (quarterly) simulating cyber breach scenarios
- Functional drills testing failover to DR sites
- Full simulation tests annually involving IT, operations, legal, and senior management
Test results must be documented, gaps tracked as findings, and remediation plans presented to the Board Risk Committee.
NCA ECC Alignment: NCA ECC Article 2-14 also requires BCM integration with cybersecurity controls, so dual-framework mapping is recommended.
Our platform provides pre-built BCM control templates mapped to both SAMA CSF and NCA ECC, with automated testing schedule reminders and gap tracking dashboards.
SAMA CSF Control 3.3.1 mandates that all financial institutions implement a formal cybersecurity awareness and training program covering all employees, contractors, and third parties with system access. The program must be risk-based, role-specific, and conducted at least annually — with additional targeted training for privileged users and IT/security staff.
To build a compliant and effective program, Saudi banks and fintechs should:
1. Establish a Training Policy: Document objectives, target audiences, frequency, and measurement criteria aligned with SAMA CSF and NCA ECC Section 2-7.
2. Segment by Role: General staff should receive phishing awareness, password hygiene, and data handling training. IT teams need technical modules covering secure development, access control, and incident reporting. Executives require risk governance and regulatory obligation briefings.
3. Use Simulated Attacks: Run quarterly phishing simulations to measure human risk. Track click rates and report-to-IT rates as KPIs.
4. Integrate Regulatory Context: Include PDPL obligations (e.g., data subject rights, breach notification duties) to ensure employees understand their personal liability under Saudi law.
5. Maintain Records: SAMA examiners expect evidence of completion rates, assessment scores, and remediation actions for failed participants. Maintain audit-ready logs for at least three years.
6. Measure Effectiveness: Conduct pre/post assessments and annual program reviews. Link training metrics to your cybersecurity risk register.
A mature awareness program not only satisfies SAMA CSF compliance but also directly reduces the likelihood of social engineering attacks — the leading initial access vector in Saudi financial sector breaches.
Security awareness training is a foundational requirement under SAMA CSF and is critical for reducing human-factor risks in Saudi financial institutions.
SAMA CSF Requirements: Under SAMA CSF Domain 3 (Cybersecurity Governance), Control 3.2.2 mandates that all employees, contractors, and third-party users with access to organizational systems must complete role-based cybersecurity awareness training. The training program must be:
- Conducted at least annually for all staff
- Delivered upon onboarding for new employees
- Tailored to specific roles (e.g., privileged users, executives, IT staff)
- Documented with completion records maintained for audit purposes
Designing an Effective Program:
- Role-Based Curriculum: Develop separate training tracks for general staff (phishing awareness, password hygiene, social engineering), IT and security teams (secure coding, incident handling), and executives (cyber risk governance, regulatory obligations under SAMA and NCA)
- Phishing Simulations: Run quarterly simulated phishing campaigns and use click-rate data to measure human risk exposure. Link simulation results to targeted micro-training
- Regulatory Content Integration: Include modules specifically covering PDPL obligations, SAMA CSF responsibilities, and reporting duties under NCA ECC Art. 3-3 to build compliance literacy
- Metrics and Reporting: Track completion rates, simulation performance, and knowledge assessment scores. Report quarterly to the CISO and Board Risk Committee as part of your GRC dashboard
- Continuous Reinforcement: Supplement annual training with monthly security newsletters, awareness posters in Arabic, and real-time alerts following emerging threats relevant to the Saudi financial sector
An underdeveloped awareness program is consistently flagged during SAMA CSF assessments. Institutions scoring Maturity Level 1 or 2 in this domain face increased scrutiny and remediation requirements.
Security Awareness Training (SAT) is a mandatory control under both SAMA CSF (Domain 3.6 — Cybersecurity Awareness and Training) and NCA ECC (Control 2-6), and regulators increasingly scrutinize program maturity during assessments. A compliant and effective program should include the following elements:
Role-Based Training Curricula: Generic training is insufficient. Develop tailored content for executive leadership, IT and security staff, privileged users, and general employees. SAMA CSF 3.6.2 specifically requires role-specific awareness programs.
Mandatory Induction and Annual Refresh: All staff — including contractors and third parties with system access — must complete onboarding security training and annual refreshers. Track completion rates as a KPI for regulatory evidence.
Phishing Simulation Exercises: Conduct regular simulated phishing campaigns (at minimum quarterly) to measure real-world susceptibility. Results must be documented and used to refine training content. NCA ECC Control 2-6-3 references awareness exercises as a required activity.
Specialized Training for Security Teams: Your SOC analysts, incident responders, and CISO staff require advanced training covering threat intelligence, forensics, and framework-specific knowledge (SAMA CSF, NCA ECC). Align certifications like CISSP, CISM, or CEH to role requirements.
Metrics and Reporting: Report SAT metrics — completion rates, phishing click-through rates, and training effectiveness scores — to senior management and the board at least annually, as required under SAMA CSF 3.6.1.
Localization: Deliver content in Arabic to ensure comprehension and cultural relevance across your Saudi workforce. An Arabic-first approach significantly improves engagement and retention.
Business Continuity Management (BCM) is a mandatory compliance domain under SAMA CSF Control Domain 6, requiring Saudi banks to maintain resilient operations even during major cyber incidents or operational disruptions. Achieving maturity in this domain requires both a well-structured program and a rigorous testing cadence.
Program Design Requirements (per SAMA CSF 6.1–6.4):
- Conduct a formal Business Impact Analysis (BIA) to identify critical business functions and their Maximum Tolerable Downtime (MTD).
- Define Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) for each critical system — SAMA typically expects RTOs of 4 hours or less for core banking functions.
- Establish a documented Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP) that cover cyber incident scenarios, not just natural disasters.
- Ensure BCM governance is owned at the board and senior management level, with a designated BCM Officer.
Testing Requirements:
- SAMA CSF requires BCM tests at least annually, with results documented and reviewed by senior management.
- Testing types should progress from tabletop exercises to full simulation drills that include IT failover, data recovery validation, and communication tree activation.
- Penetration testing findings should feed directly into BCM scenario updates.
- Align BCM testing schedules with NCA ECC Article 3-7 resilience controls for government-regulated entities.
Practical Guidance:
- Maintain an always-current contact directory and escalation matrix.
- Test backup restoration — not just backup creation — at least quarterly.
- Ensure cloud-based recovery environments are validated against the same RTO/RPO commitments as on-premise systems.
- Document lessons learned after every test and track remediation actions to closure.
Business Continuity Management (BCM) is a critical obligation for Saudi financial institutions under SAMA CSF Domain 4 (Cyber Resilience) and specifically Control 4.3, which mandates that banks establish, test, and maintain robust BCM and Disaster Recovery (DR) programs aligned with cybersecurity risks.
Key requirements include:
1. Business Impact Analysis (BIA): Identify critical business processes, systems, and assets. Define Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) for each. Per SAMA CSF Control 4.3.2, RTOs must reflect the criticality of financial services.
2. BCM Policy and Plan: Develop a formal Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP) approved by senior management and the Board. Plans must cover cybersecurity incident scenarios, including ransomware and data breaches.
3. Testing and Exercises: SAMA CSF Control 4.3.5 requires regular BCM testing — at minimum annually — including tabletop exercises, simulation drills, and full failover tests. Results must be documented and gaps remediated.
4. Third-Party and Cloud Dependencies: BCM plans must address continuity risks from critical third-party providers and cloud platforms, ensuring contractual SLA alignment.
5. Regulatory Reporting: Any activation of the BCP due to a cyber incident must be communicated to SAMA within defined timelines per the Cyber Incident Reporting Framework.
Practical Tip: Integrate your BCM program with your ISO 22301 certification roadmap to demonstrate dual compliance. Use tabletop scenarios specific to Saudi banking threats — such as payment system outages and core banking disruptions — to make exercises realistic and regulatorily defensible.
SAMA CSF dedicates Domain 4 (Cyber Resilience) to Business Continuity Management, making it a mandatory capability for all regulated banks and financial institutions. A compliant BCM program must cover the following pillars: (1) Business Impact Analysis (BIA) — identify critical business functions, recovery time objectives (RTO), and recovery point objectives (RPO) per SAMA CSF Control 4.1. Critical banking systems (core banking, payment rails, internet banking) typically require RTOs under 4 hours. (2) BCM Policy and Plan Development — document Business Continuity Plans (BCP) and Disaster Recovery Plans (DRP) addressing cybersecurity-specific scenarios including ransomware, DDoS, and data center failure. Plans must integrate with the institution's Incident Response Plan per SAMA CSF Control 3.5. (3) Testing and Validation — SAMA CSF Control 4.3 mandates that BCM plans be tested at least annually. Testing types should progress from tabletop exercises and walkthrough drills to full simulation exercises involving IT, operations, and executive leadership. Results must be documented, gaps remediated, and plans updated accordingly. (4) Third-Party and Outsourcing Continuity — BCM must extend to critical service providers, ensuring their RTOs align with the bank's requirements. (5) Regulatory Reporting — significant disruptions must be reported to SAMA in accordance with the Cyber Incident Reporting Framework. Aligning BCM with ISO 22301 (Business Continuity Management Systems) provides an internationally recognized structure that satisfies SAMA's expectations and prepares institutions for regulatory examination. Annual SAMA inspections frequently assess BCM maturity using a 1–4 capability scale.
SAMA CSF Domain 4 — Resilience — mandates that member organizations establish, implement, and continuously improve a Business Continuity Management (BCM) program that directly integrates cybersecurity resilience. Here is how Saudi banks should approach this: (1) BIA and Risk Assessment — conduct a Business Impact Analysis (BIA) per SAMA CSF Control 4.1 to identify critical business processes, acceptable downtime (RTO), and data loss tolerances (RPO). Cybersecurity-driven scenarios — ransomware, DDoS, and insider sabotage — must be explicitly included. (2) BCP and DRP Documentation — develop Business Continuity Plans and Disaster Recovery Plans that are reviewed and updated at least annually or after significant changes, per SAMA CSF Control 4.3. (3) Cyber Incident Integration — BCM plans must be tightly linked to your Cyber Incident Response Plan (CIRP). SAMA expects that a cyber event triggering BCM activation follows defined escalation and communication protocols reaching executive and board level. (4) Testing Regime — SAMA CSF requires regular testing: tabletop exercises at minimum annually, and full simulation or failover tests at least every two years. Test results must be documented and remediation actions tracked to closure. (5) Third-Party Dependencies — BCM must account for critical vendor and infrastructure dependencies, particularly for payment processing, core banking, and cloud services. (6) Regulatory Reporting — SAMA expects BCM test summaries and any major incidents affecting continuity to be reportable. Practically, CISOs should ensure BCM ownership sits with a cross-functional team including IT, operations, legal, and communications, with CISO oversight on the cyber resilience components. Align BCM documentation with ISO 22301 to satisfy both SAMA expectations and international best practice simultaneously.
Business Continuity Management (BCM) for Saudi financial institutions is governed by multiple overlapping frameworks. SAMA CSF Subdomain 3.3 mandates a comprehensive BCM program, while NCA ECC Article 2-13 sets specific resilience requirements for critical national infrastructure entities — which includes major banks and payment processors.
Step 1 — Business Impact Analysis (BIA): Identify and prioritize critical business functions, systems, and interdependencies. Per SAMA CSF Control 3.3.1, institutions must define Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) for each critical process. Typical SAMA expectations for core banking systems are RTOs under 4 hours and RPOs under 1 hour.
Step 2 — Risk Assessment: Conduct a threat-based risk assessment covering cyber incidents, natural disasters, third-party failures, and pandemic scenarios. Link this to your existing SAMA CSF Risk Management framework (Subdomain 2.1).
Step 3 — Plan Development: Develop four interconnected plans: Business Continuity Plan (BCP), Disaster Recovery Plan (DRP), Crisis Communication Plan, and IT Incident Response Plan. NCA ECC requires these plans to address cyberattack scenarios specifically, not just physical disruptions.
Step 4 — Testing & Exercises: SAMA CSF Control 3.3.5 requires at minimum an annual full simulation exercise and quarterly tabletop exercises for critical systems. Results must be documented and remediation tracked.
Step 5 — Continuous Improvement: BCM plans must be reviewed after any significant incident, major system change, or annually. Appoint a dedicated BCM Owner and establish a Steering Committee with executive representation.
Also ensure alignment with SAMA's dedicated BCM circular (issued 2022) which introduced stricter testing documentation requirements for Tier-1 banks.
Under SAMA CSF Domain 4 (Resilience), Saudi banks must establish a comprehensive Business Continuity Management (BCM) program that addresses both operational resilience and cyber-specific recovery scenarios. Key requirements include:
Per SAMA CSF Control 4.1 – Business Continuity Planning:
- Define Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) for all critical systems, with SAMA typically expecting RTOs of 4 hours or less for core banking functions.
- Conduct Business Impact Analyses (BIA) annually or whenever significant changes occur to identify critical processes, dependencies, and acceptable downtime thresholds.
Per SAMA CSF Control 4.2 – Disaster Recovery:
- Maintain a tested, documented Disaster Recovery Plan (DRP) that is separate from but aligned with the BCP.
- DR environments must be geographically separated — SAMA recommends a minimum of 50km between primary and secondary data centers for systemically important banks.
- Full DR tests must be conducted at least annually, with results documented and gaps remediated within defined timelines.
Cyber-Specific BCM Additions:
- BCM plans must now explicitly address ransomware scenarios, including offline backups tested for integrity quarterly.
- Incident Response Plans (IRP) must be integrated into BCM workflows so cyber events trigger appropriate BCP activation.
Practical Guidance: Most Saudi banks fall short by treating BCM as an IT exercise rather than an enterprise-wide program. Involve business unit owners in BIA workshops, ensure executive sign-off on RPO/RTO commitments, and coordinate BCP drills with SAMA's supervisory expectations. Align your BCM documentation with ISO 22301 standards to demonstrate maturity during SAMA examinations.
Building a cyber incident response plan (IRP) for a Saudi financial institution requires aligning with SAMA CSF Control Domain 3.4 (Cyber Incident Management) and NCA's Cybersecurity Event Management guidelines. Both frameworks demand a formally documented, tested, and board-approved IRP that covers the full incident lifecycle.
Your IRP must define six core phases: Preparation, Identification, Containment, Eradication, Recovery, and Lessons Learned. Critically, it must include escalation thresholds and regulatory notification timelines. Under SAMA CSF Control 3.4.4, significant cybersecurity incidents must be reported to SAMA within 72 hours of detection, with an initial notification followed by detailed incident reports and a final root cause analysis.
NCA's CSCC (National Cybersecurity Operations Center) additionally requires reporting of incidents affecting critical information infrastructure (CII), with immediate notification for Severity 1 events. Your plan must define what constitutes a reportable event per NCA classification criteria, including unauthorized access, ransomware, data breaches, DDoS attacks, and system compromise.
Practically, the IRP should include: a designated Incident Response Team (IRT) with clearly assigned roles; pre-approved communication templates for regulators, customers, and media; integration with your SIEM/SOAR tools for automated alert triage; evidence preservation procedures aligned with forensic best practices; and a mandatory post-incident review process.
Regulatory examiners from both SAMA and NCA will assess whether your IRP is not just documented but operationally exercised — tabletop exercises and full simulation drills must occur at least annually. Our platform provides IRP templates pre-mapped to SAMA CSF and NCA requirements, automated notification workflows, and drill scheduling tools to keep your team audit-ready.
Business Continuity Management (BCM) is a critical compliance domain for Saudi financial institutions. SAMA CSF Control Domain 3.5 (Cybersecurity Resilience) and NCA ECC Control 2-18 jointly define the minimum expectations for BCM programs.
SAMA CSF Key Requirements (Domain 3.5):
- Develop and maintain a formal Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP) covering cyber-incident scenarios
- Define Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) for all critical systems, with SAMA expecting RTOs of 4 hours or less for Tier-1 banking services
- Conduct BCP/DRP testing at least annually, including tabletop exercises and full failover simulations
- Integrate cybersecurity incident response into BCM frameworks
NCA ECC Control 2-18 Requirements:
- Classify systems by criticality and ensure BCM plans align with national critical infrastructure protection goals
- Maintain geographically separated disaster recovery sites within the Kingdom
- Document and test backup and restoration procedures, ensuring data integrity post-recovery
Practical Implementation Steps:
- Conduct a Business Impact Analysis (BIA) to identify critical processes and maximum tolerable downtime
- Map IT dependencies for each critical business process
- Establish a Crisis Management Team with defined roles and escalation paths
- Integrate BCM testing results into SAMA's annual cybersecurity maturity assessment
- Ensure BCM documentation is reviewed and approved by the Board at least annually
Institutions that treat BCM as a standalone IT exercise — rather than an enterprise-wide governance function — consistently underperform in SAMA maturity evaluations.
Under SAMA CSF Domain 4 (Operational Resilience), Saudi banks and financial institutions are required to establish a comprehensive Business Continuity Management (BCM) program that ensures the availability and resilience of critical financial services. Key requirements include:
1. Business Impact Analysis (BIA): Per SAMA CSF Control 4.2, institutions must conduct a formal BIA to identify critical business functions, define Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO), and assess the financial and reputational impact of disruptions.
2. BCP and DRP Documentation: Documented Business Continuity Plans (BCP) and Disaster Recovery Plans (DRP) must cover IT systems, data centers, and operational processes. Plans must be reviewed and updated at least annually.
3. Testing and Exercises: SAMA requires regular BCP/DRP testing, including tabletop exercises and full failover simulations. Test results must be documented and gaps remediated within defined timelines.
4. Alternate Site Requirements: Banks must maintain geographically separated DR sites within the Kingdom to ensure data sovereignty and rapid failover capability, aligned with NCA ECC requirements on data residency.
5. Communication Plans: Clear escalation and communication protocols must be established for internal stakeholders, SAMA regulators, and customers during a disruption event.
Practical Tip: Integrate your BCM program with your Incident Response Plan to avoid response gaps. Map your RTO/RPO targets to specific SAMA CSF controls and conduct at least one full DR simulation annually, documenting outcomes for regulatory review. SAMA examiners will specifically request evidence of testing cycles and remediation plans during assessments.
Business Continuity Management (BCM) is a critical compliance domain under SAMA CSF Domain 4 (Resilience), which requires Saudi financial institutions to maintain robust continuity and recovery capabilities. Here are the key requirements and implementation steps:
SAMA CSF Requirements:
- Control 4.3.1–4.3.5: Institutions must establish a formal BCM framework covering Business Impact Analysis (BIA), Recovery Time Objectives (RTO), and Recovery Point Objectives (RPO).
- Control 4.4: Disaster Recovery Plans (DRPs) must be documented, tested at least annually, and aligned with the institution's risk appetite.
- Crisis communication plans must be defined, including escalation paths to SAMA and relevant stakeholders.
Implementation Guidance:
- Conduct a BIA: Identify mission-critical systems (core banking, payment switches, SWIFT connectivity) and define acceptable RTOs — typically 4 hours for tier-1 banking services.
- Develop BCP and DRP: Ensure these are not siloed documents but integrated into operational workflows and tested via tabletop exercises and full failover drills.
- Define Cyber Recovery Scenarios: Incorporate ransomware and DDoS scenarios into your BCP, as required by SAMA's cybersecurity resilience expectations.
- Third-Party BCP Alignment: Verify that critical vendors maintain BCPs aligned with your RTOs, as per SAMA CSF third-party risk controls.
- Annual Testing and Reporting: Document test results and remediation actions. SAMA may request evidence during regulatory examinations.
A mature BCM program not only satisfies SAMA CSF compliance but also strengthens your institution's overall cyber resilience posture.
Under SAMA CSF Domain 4 (Cybersecurity Operations), Saudi banks and financial institutions are required to maintain a formally documented Incident Response Plan (IRP) that covers detection, containment, eradication, recovery, and post-incident review phases. Per SAMA CSF Control 4.3, organizations must establish a 24/7 Security Operations Center (SOC) capability or an equivalent managed service to ensure continuous monitoring and rapid response.
Regarding reporting timelines, SAMA requires member organizations to notify SAMA of any significant cybersecurity incident within 72 hours of detection — a requirement that aligns with global best practices and mirrors PDPL Article 24 obligations for personal data breaches. Critical incidents affecting core banking systems or customer data must be escalated immediately to senior management and the Board Risk Committee.
Practically, your IRP should define clear severity classification levels (P1–P4), assign incident response roles (IR Lead, Legal, PR, IT), and include pre-approved communication templates for regulatory notifications. Tabletop exercises should be conducted at least annually per SAMA CSF Control 4.3.5 to validate response readiness.
Additionally, NCA ECC Article 3-6 requires government-affiliated financial entities to coordinate incident reporting with CERT-SA (cert.gov.sa) in parallel with SAMA notifications. Failure to meet these timelines can result in regulatory sanctions, reputational damage, and potential fines under PDPL if personal data is involved.
Our platform provides a built-in Incident Response workflow module that automates notification timelines, tracks SLA adherence, and generates SAMA-ready incident reports — reducing manual effort and ensuring you never miss a regulatory deadline.
Business Continuity Management (BCM) is one of the most scrutinized domains during SAMA regulatory examinations. SAMA CSF Subdomain 3.5 dedicates an entire control set to ensuring member organizations can maintain critical operations during and after a disruptive event — whether a cyberattack, ransomware incident, natural disaster, or major system failure.
Key SAMA CSF Requirements (Subdomain 3.5):
Business Impact Analysis (BIA): Banks must conduct a formal BIA to identify critical business functions, their dependencies, maximum tolerable downtime (MTD), Recovery Time Objectives (RTO), and Recovery Point Objectives (RPO). The BIA must be reviewed at least annually and after significant operational changes.
Business Continuity Plan (BCP) Development: The BCP must cover crisis communication protocols, roles and responsibilities, escalation procedures, and continuity strategies for critical processes. SAMA expects the plan to address both cyber-triggered disruptions and non-cyber scenarios.
Disaster Recovery Plan (DRP): The technical counterpart to the BCP, the DRP must document recovery procedures for critical IT systems, databases, and infrastructure. It should define failover mechanisms, backup restoration procedures, and alternative processing site activation. SAMA CSF Control 3.5.4 requires that recovery capabilities are tested regularly to validate that RTOs and RPOs can actually be achieved.
Testing Requirements:
- Tabletop exercises: At minimum annually, involving senior management and IT teams
- Functional drills: Testing specific components such as backup restoration or failover switching
- Full-scale simulations: At least every two years, simulating a complete site failure or major cyber incident
- Post-test reviews: Lessons learned must be documented and fed back into plan improvements
SAMA Examination Evidence: During SAMA assessments, examiners typically request BIA reports, BCP/DRP documents, test results, remediation logs, and board-level sign-off. Gaps in testing evidence are a common finding.
Our GRC platform provides BCM lifecycle management, test scheduling, evidence collection, and automated gap analysis against SAMA CSF Subdomain 3.5 controls.
Identity and Access Management is a foundational pillar under both SAMA CSF (Domain 3.3 – Access Control) and NCA ECC (ECC-1-3-4). Saudi banks must implement the following controls:
1. Privileged Access Management (PAM): All privileged accounts — including system administrators, DBAs, and network engineers — must be governed under a formal PAM program. SAMA CSF Control 3.3.4 explicitly requires time-limited, monitored, and logged privileged sessions.
2. Multi-Factor Authentication (MFA): MFA is mandatory for all remote access, administrative portals, and critical system interfaces. NCA ECC Article 3.4 reinforces this for all government-connected and critical infrastructure systems, which applies to licensed financial entities.
3. Least Privilege & Role-Based Access Control (RBAC): Access rights must be granted based on job function with quarterly access reviews. SAMA CSF 3.3.2 mandates formal access provisioning and de-provisioning workflows tied to HR processes.
4. Segregation of Duties (SoD): Conflicting roles — such as a developer having production access — must be identified and resolved. This aligns with SAMA CSF 3.3.5 and ISO 27001 Annex A.9.2.
5. Identity Lifecycle Management: Joiner-Mover-Leaver (JML) processes must be automated where possible, with orphaned accounts reviewed monthly. Dormant accounts inactive for 90+ days must be disabled per SAMA CSF guidance.
Practical Tip: Conduct a semi-annual IAM audit mapped against your SAMA CSF maturity assessment. Document all exceptions with risk acceptance sign-off from your CISO or designated authority to demonstrate regulatory readiness during SAMA inspections.
Under SAMA CSF Domain 4 (Operational Resilience), Saudi banks must establish a formally documented Business Continuity Management program that covers cyber-resilience scenarios. Key requirements include:
SAMA CSF Requirements:
- Control 4.3.1: Conduct annual Business Impact Analysis (BIA) identifying critical systems, maximum tolerable downtime (MTD), and recovery time objectives (RTO/RPO).
- Control 4.3.3: Develop, test, and update Business Continuity Plans (BCPs) and Disaster Recovery Plans (DRPs) at least annually, including cyber-incident scenarios.
- Control 4.3.5: Maintain offline/air-gapped backups of critical data with verified restoration testing every six months.
NCA ECC Alignment (Article 3-5): NCA ECC requires organizations to define BCM policies that integrate cybersecurity events, including ransomware and DDoS, as trigger scenarios. Banks must cross-reference their BCM with the NCA's cybersecurity incident classification levels to ensure response thresholds are consistent.
Practical Implementation Steps:
- Establish a BCM governance committee with CISO and COO representation.
- Map critical banking services (core banking, payment systems, mobile apps) to RTO targets — typically under 4 hours for Tier-1 systems.
- Conduct tabletop exercises simulating a ransomware attack or core-banking outage at least twice per year.
- Integrate BCM testing results into the annual SAMA CSF self-assessment submission.
- Ensure third-party vendors supporting critical systems have equivalent BCM capabilities documented in contracts.
Non-compliance with BCM requirements can result in SAMA supervisory action, including mandatory remediation timelines and increased regulatory scrutiny during annual assessments.
Saudi banks must establish a robust Business Continuity Management (BCM) program that satisfies both SAMA CSF Domain 4 (Operational Resilience) and NCA ECC controls on resilience planning.
SAMA CSF Requirements:
- Per SAMA CSF Control 4.1, banks must maintain a formally documented Business Continuity Plan (BCP) reviewed and approved by senior management at least annually.
- Control 4.2 mandates a Recovery Time Objective (RTO) and Recovery Point Objective (RPO) defined for all critical systems, typically aligned to SAMA's expectation of ≤4 hours RTO for core banking platforms.
- Control 4.3 requires regular BCP testing — at minimum an annual full-scale simulation and semi-annual tabletop exercises.
NCA ECC Alignment:
- NCA ECC Article 3.3.6 requires that cybersecurity continuity is embedded within the BCM program, ensuring cyber incident scenarios are explicitly included in BCP tests.
- Disaster Recovery (DR) sites must be geographically separated within the Kingdom unless SAMA grants specific exemptions.
Practical Guidance:
- Conduct a Business Impact Analysis (BIA) covering all critical business functions and their technology dependencies.
- Integrate your Cyber Incident Response Plan (CIRP) with the BCP to avoid response gaps during simultaneous cyber and operational disruptions.
- Ensure DR drills include ransomware recovery scenarios, as SAMA increasingly scrutinizes this area.
- Document lessons learned from each exercise and track remediation actions with defined owners and deadlines.
- Present BCP test results to the Board Risk Committee to satisfy SAMA's governance expectations.
Failure to maintain an operational BCM program can result in SAMA supervisory findings and mandatory corrective action plans.
Under SAMA CSF Domain 4 (Cyber Resilience), Saudi banks must establish a comprehensive Business Continuity Management program that ensures operational resilience against cyber disruptions. Key requirements include:
1. BIA and Risk Assessment (SAMA CSF Control 4.1): Conduct a Business Impact Analysis identifying critical systems, maximum tolerable downtime (MTD), and recovery time objectives (RTO/RPO). Financial institutions must document dependencies between business processes and underlying IT assets.
2. BCP and DRP Development (Control 4.2): Develop, document, and maintain Business Continuity Plans and Disaster Recovery Plans. Plans must cover ransomware scenarios, data center failures, and third-party outages. Per SAMA CSF, plans must be reviewed at least annually or after significant changes.
3. Testing and Exercises (Control 4.3): SAMA requires at least annual testing of BCM plans through tabletop exercises, functional drills, or full-scale simulations. Results must be documented, gaps remediated, and evidence retained for regulatory review.
4. Cloud and Outsourcing Considerations: If critical workloads run on cloud or third-party infrastructure, BCM must extend to service provider SLAs, failover capabilities, and contractual recovery commitments.
5. Regulatory Reporting: Any cyber incident impacting business continuity must be reported to SAMA within defined timeframes per the SAMA Cyber Incident Reporting Guidelines.
Practical Tip: Align your BCM program simultaneously with NCA ECC Article 3-6 controls on resilience and ISO 22301 for a unified, audit-ready framework. Maintain a living BCM document repository accessible to your crisis management team at all times.
SAMA CSF Control 3.3 mandates that Saudi financial institutions establish a formal, risk-based cybersecurity awareness and training program covering all staff, including senior management and the board. Key requirements include: (1) Annual baseline security awareness training for all employees, with role-specific training for IT, security, and privileged-access users; (2) Documented training records maintained for audit purposes; (3) Phishing simulation exercises conducted periodically to measure human risk; (4) Awareness content tailored to emerging threats such as social engineering, ransomware, and insider threats. CISOs should establish a training governance framework that links awareness outcomes to the institution's overall cyber risk posture. Training effectiveness must be measured using KPIs such as phishing click rates, quiz pass rates, and incident reduction trends. Board and C-suite training should specifically address cyber risk oversight responsibilities per SAMA CSF Control 3.2. Institutions are also encouraged to align their programs with NIST CSF's 'Protect' function (PR.AT) for a globally consistent approach. Practical tip: Integrate awareness campaigns with real-world threat intelligence relevant to the Saudi banking sector, including Business Email Compromise (BEC) and ATM fraud schemes, to increase relevance and engagement among staff.
Under SAMA CSF Control Domain 3.3 (Human Resources Security), Saudi financial institutions must establish a formal, risk-based cybersecurity awareness and training program covering all staff, contractors, and third parties with system access.
Key Requirements:
- Mandatory onboarding training: All new employees must complete cybersecurity awareness training before accessing institutional systems, per SAMA CSF Control 3.3.2.
- Annual refresher cycles: Recurring training must be conducted at least annually, with role-specific modules for IT, security, finance, and executive staff.
- Specialized training for privileged users: System administrators, developers, and security personnel require advanced training covering secure coding, access management, and threat response, aligned with SAMA CSF Control 3.3.4.
- Phishing simulation exercises: Institutions should conduct periodic simulated phishing campaigns to measure human risk and reinforce training outcomes.
- Metrics and reporting: Training completion rates, phishing simulation results, and awareness KPIs must be reported to senior management and the board.
Practical Guidance:
- Map training content to current threat landscapes relevant to Saudi banking, including social engineering, account takeover, and insider threats.
- Leverage e-learning platforms that support Arabic content to maximize staff engagement.
- Maintain documented training records for audit purposes — SAMA examiners will request evidence of completion rates and curriculum content.
- Align your program with NCA ECC Article 2-7 (Cybersecurity Awareness) for organizations also subject to NCA oversight.
A well-documented, measurable training program not only satisfies regulatory expectations but demonstrably reduces human-factor risk, which remains the leading cause of security incidents in the Saudi financial sector.
Under SAMA CSF Control 3.3.1 (Cybersecurity Awareness and Training), Saudi banks are required to establish a formal, risk-based security awareness program covering all staff, including senior management and the board. Here is how a CISO should approach building a compliant and effective program:
Mandatory Components:
- Annual baseline security awareness training for all employees
- Role-based training for IT, security, privileged users, and executives
- Documented training records and completion tracking
- Phishing simulation exercises conducted at least quarterly
Practical Implementation Steps:
- Conduct a Training Needs Analysis (TNA): Map roles to risk exposure and tailor content accordingly — a teller has different risks than a developer or an IT admin.
- Establish a Training Calendar: Schedule mandatory annual training with quarterly refreshers aligned to emerging threats (e.g., Business Email Compromise, deepfake fraud).
- Integrate Phishing Simulations: Run at minimum quarterly phishing campaigns with immediate coaching for employees who fail. Track click rates as a KPI.
- Measure Effectiveness: Use pre/post assessments, phishing simulation metrics, and incident reports to demonstrate program maturity to auditors.
- Board and Senior Management Engagement: SAMA expects governance-level awareness — conduct tailored briefings covering cyber risk appetite and regulatory obligations.
- Align with ISO 27001: Control A.7.2.2 of ISO 27001 reinforces the need for regular, documented awareness activities.
Document everything — SAMA examiners will request training plans, completion records, and simulation results during assessments. A mature awareness program also directly reduces your attack surface against social engineering, which remains the top threat vector for Saudi financial institutions.
Under SAMA CSF Control 3.3 (Identity and Access Management), Saudi banks must establish a robust IAM program that governs the entire lifecycle of user identities—from provisioning to deprovisioning. Key requirements include: enforcing multi-factor authentication (MFA) for all privileged and remote access, implementing the principle of least privilege, and conducting quarterly access reviews for all critical systems.
For Privileged Access Management (PAM) specifically, SAMA CSF Control 3.3.5 requires that privileged accounts be strictly controlled through dedicated PAM solutions such as CyberArk, BeyondTrust, or similar platforms. Banks must ensure that shared administrative credentials are eliminated, all privileged sessions are recorded and monitored, and just-in-time (JIT) access is granted where feasible.
From an NCA ECC perspective, ECC-1:2018 Article 2-7 reinforces these requirements by mandating separation of duties and periodic recertification of access rights. Practically, Saudi banks should:
- Maintain a centralized identity repository integrated with HR systems to automate provisioning and deprovisioning.
- Deploy a PAM solution with session recording for all Tier-1 infrastructure.
- Enforce MFA across all administrative consoles, VPN, and cloud management portals.
- Conduct semi-annual privilege access reviews and document findings for SAMA audit purposes.
- Align IAM policies with ISO 27001 Annex A Control 9 (Access Control).
Non-compliance can result in SAMA supervisory findings during annual cybersecurity assessments, making IAM one of the highest-scrutiny areas during regulatory reviews.
Under SAMA CSF Control 3.3, Saudi banks must establish a comprehensive Identity and Access Management program covering user provisioning, authentication, and privileged access governance. Key requirements include:
Privileged Access Controls (SAMA CSF 3.3.3):
- Implement Privileged Access Management (PAM) solutions to vault, rotate, and audit privileged credentials
- Enforce just-in-time (JIT) access for administrative accounts — no standing privileges
- Require multi-factor authentication (MFA) for all privileged and remote access, aligning with NCA ECC-1: 2-3.2
Practical Implementation Steps:
- Conduct a full access rights review at least quarterly and immediately upon role changes
- Segregate privileged accounts from standard user accounts — administrators should not use admin credentials for daily tasks
- Deploy session recording and real-time monitoring for all privileged sessions
- Establish a formal onboarding/offboarding process with HR integration to revoke access within 24 hours of termination
- Apply the principle of least privilege across all systems, enforced through role-based access control (RBAC)
NCA ECC Alignment: ECC-1: 2-3 further mandates that access to critical national infrastructure systems must be logged, reviewed, and protected against unauthorized elevation.
ISO 27001 Mapping: Annex A Control 8.2 (Privileged Access Rights) and 8.18 (Use of Privileged Utility Programs) directly support these obligations.
Banks should conduct annual PAM maturity assessments and report IAM control effectiveness to the Board-level cybersecurity committee as part of SAMA's governance reporting requirements under Control 2.1.
Under SAMA CSF Domain 3 (Cybersecurity Operations), specifically Controls 3.3.1 through 3.3.6, Saudi banks must establish a comprehensive Identity and Access Management program that enforces least-privilege principles, role-based access control (RBAC), and multi-factor authentication (MFA) for all critical systems.
Key Implementation Requirements:
Privileged Access Management (PAM): SAMA CSF Control 3.3.4 mandates that privileged accounts (domain admins, database admins, system administrators) be managed through a dedicated PAM solution with session recording, just-in-time access provisioning, and regular access reviews — conducted at least quarterly.
Multi-Factor Authentication: MFA must be enforced for all remote access, administrative consoles, internet-facing systems, and core banking platforms. This aligns with NCA ECC Article 2-14, which similarly mandates MFA for sensitive systems.
Access Reviews: Conduct formal access certification campaigns every 90 days for privileged users and every 6 months for standard users. Terminated or transferred employee access must be revoked within 24 hours per SAMA CSF Control 3.3.2.
Segregation of Duties (SoD): Conflicting roles — such as system administration and audit log management — must be separated to prevent insider threats.
Practical Steps:
- Deploy a PAM solution (e.g., CyberArk, BeyondTrust) integrated with your SIEM.
- Implement an Identity Governance and Administration (IGA) platform for automated provisioning/deprovisioning.
- Document an Access Control Policy mapped to SAMA CSF and ISO 27001 Annex A.9 controls.
- Conduct annual IAM audits and include findings in your SAMA CSF self-assessment reporting.
Non-compliance with SAMA CSF IAM controls can result in regulatory findings during SAMA examinations and reputational risk for the institution.
Under SAMA CSF Control Domain 3.4 (Third-Party Management), Saudi banks must establish a formal vendor risk management program that covers the entire vendor lifecycle — from onboarding through offboarding. Key mandatory requirements include:
Risk Tiering: Classify vendors into critical, high, medium, and low risk based on data access, system integration depth, and regulatory exposure. Critical vendors (e.g., core banking system providers, cloud hosting) require the most rigorous due diligence.
Pre-Onboarding Assessments: Before engaging any third party with access to sensitive systems or customer data, conduct a cybersecurity assessment aligned with SAMA CSF domains. This should include reviewing the vendor's ISO 27001 certification, SOC 2 Type II reports, and their own subcontractor (fourth-party) risk posture.
Contractual Controls (per SAMA CSF 3.4.3): All contracts must include clauses for data protection obligations (aligned with PDPL), right-to-audit provisions, incident notification timelines (typically within 72 hours), and exit/transition security requirements.
Ongoing Monitoring: Critical vendors must be reassessed annually at minimum. Implement continuous monitoring through questionnaires, threat intelligence feeds, and external attack surface monitoring tools.
NCA ECC Alignment: NCA ECC Article 2-6 reinforces these requirements for entities operating national infrastructure, mandating that vendor agreements explicitly address cybersecurity responsibilities and incident escalation paths.
Practical Tip: Build a vendor risk register within your GRC platform that maps each vendor to the SAMA CSF controls they impact. This simplifies annual regulatory examinations and demonstrates mature governance to SAMA inspectors.
Third-party risk management (TPRM) is a critical obligation under SAMA CSF Control Domain 3.3 and NCA ECC Article 2-9. Saudi banks must establish a formal vendor risk program that begins before onboarding any third party. Here is a practical framework:
1. Vendor Classification & Due Diligence: Classify vendors by criticality (critical, high, medium, low) based on data access and system integration. Per SAMA CSF Control 3.3.1, conduct cybersecurity due diligence before signing contracts, including reviewing the vendor's ISO 27001 certification, SOC 2 reports, or equivalent assurance.
2. Contractual Controls: Embed cybersecurity clauses covering right-to-audit, incident notification SLAs (within 72 hours per SAMA CSF 3.3.4), data handling obligations aligned with PDPL, and minimum security standards.
3. Continuous Monitoring: Conduct annual cybersecurity assessments for critical vendors and biannual reviews for high-risk vendors. Use standardized questionnaires aligned with SAMA CSF control domains.
4. Fourth-Party Risk: Identify your vendors' critical subcontractors. NCA ECC requires visibility into the supply chain, especially for cloud and managed security service providers.
5. Offboarding Controls: Ensure secure data deletion, access revocation, and certificate of destruction upon contract termination.
A common gap auditors identify is the lack of documented evidence for ongoing monitoring — banks often perform initial due diligence but fail to track vendor risk posture changes. Maintain a central vendor risk register with last assessment date, risk rating, and remediation status. This register should be reviewed quarterly by the CISO and reported to the Board Risk Committee annually.
An effective Cyber Incident Response Plan (CIRP) for Saudi banks must align with SAMA CSF Control Domain 3.6 and NCA ECC Articles 2-11 and 2-12. Here is how to build one that satisfies both frameworks:
1. Define Incident Severity Tiers: Establish at least four severity levels (P1–P4) with clear criteria. P1 events (e.g., ransomware, core banking system breach) trigger mandatory regulatory reporting. Map your severity matrix to SAMA's incident classification taxonomy.
2. Mandatory Reporting Timelines: Per SAMA CSF Control 3.6.5, critical incidents must be reported to SAMA within 72 hours of detection. NCA ECC Article 2-11 requires simultaneous notification to the National Cybersecurity Authority (NCA) via the Musaned/CERT-SA portal. Document your reporting workflow with named owners and escalation paths.
3. CIRP Core Phases: Structure your plan around six phases: Preparation → Identification → Containment → Eradication → Recovery → Post-Incident Review. Each phase must have documented runbooks, responsible parties (RACI matrix), and time-bound SLAs.
4. Evidence Preservation: Establish digital forensics procedures to preserve chain of custody — critical if the incident involves fraud or regulatory investigation. Use write-blockers and maintain forensic logs for a minimum of 12 months per SAMA CSF.
5. Communication Templates: Pre-draft notifications for SAMA, NCA, affected customers (per PDPL Article 24 — 72-hour breach notification), and media holding statements.
6. Tabletop Exercises: SAMA CSF Control 3.6.7 requires annual incident response testing. Conduct at least one full tabletop exercise and one technical simulation (e.g., red team scenario) annually. Document results, gaps, and improvement actions.
7. Lessons Learned Integration: Post-incident reports must feed back into your risk register and control framework within 30 days of incident closure.
SAMA CSF Control Domain 3.3 (Third-Party Management) mandates that Saudi banks establish a formal third-party risk management (TPRM) program covering the entire vendor lifecycle — from initial onboarding through contract termination. Per SAMA CSF Control 3.3.2, banks must conduct cybersecurity risk assessments before engaging any third party that accesses sensitive systems or customer data.
Key implementation steps include:
1. Vendor Classification: Categorize vendors by risk tier (Critical, High, Medium, Low) based on data access, system integration depth, and business criticality.
2. Pre-Onboarding Due Diligence: Require vendors to complete security questionnaires aligned to ISO 27001 Annex A controls and NCA ECC requirements. Critical vendors should provide SOC 2 Type II reports, ISO 27001 certificates, or equivalent third-party audit results.
3. Contractual Controls: Embed cybersecurity clauses covering incident notification timelines (within 24 hours per SAMA CSF 3.3.5), data handling obligations under PDPL Articles 21–22, right-to-audit provisions, and compliance with NCA ECC.
4. Ongoing Monitoring: Conduct annual reassessments for critical vendors and biennial reviews for others. Use automated vendor risk platforms to track security posture changes continuously.
5. Offboarding Procedures: Ensure secure data return or destruction and revocation of all access credentials upon contract termination.
SAMA examiners increasingly scrutinize TPRM programs during regulatory reviews, so maintaining a centralized vendor registry with documented risk ratings and assessment histories is essential for audit readiness. Financial institutions relying heavily on cloud or fintech partners should also align vendor oversight with NCA Cloud Cybersecurity Controls (CCC) requirements.
Third-party risk management is a critical compliance area under SAMA CSF Control Domain 3.3, which mandates that financial institutions establish a structured Vendor Risk Management (VRM) program. Here is how to implement it effectively:
1. Vendor Classification & Tiering Classify vendors based on data sensitivity, system access, and criticality. Tier-1 vendors (e.g., core banking providers, cloud platforms) require the most rigorous controls, including annual security assessments and contractual cybersecurity clauses.
2. Pre-Onboarding Due Diligence Before contracting, require vendors to complete a security questionnaire aligned with SAMA CSF and ISO 27001. Validate certifications such as ISO 27001 or SOC 2 Type II. Per SAMA CSF Control 3.3.2, you must assess a vendor's ability to protect your data before granting access.
3. Contractual Obligations Ensure contracts include clauses covering data protection (aligned with PDPL Articles 21–22), incident notification timelines (typically within 72 hours), right-to-audit provisions, and business continuity requirements.
4. Ongoing Monitoring Conduct periodic reassessments — at least annually for Tier-1 vendors. Use threat intelligence feeds to monitor for vendor breaches. Establish a vendor risk register tracked by your GRC platform.
5. Offboarding Controls When terminating vendor relationships, ensure data deletion certifications are obtained and access credentials are revoked immediately.
NCA ECC Article 2-14 further reinforces these obligations by requiring documented supplier security policies. Failure to maintain a robust VRM program is a common finding in SAMA examinations and can result in remediation requirements. Your GRC platform should automate vendor assessments, track remediation actions, and generate audit-ready reports.
Third-party risk management is a critical compliance area under both SAMA CSF (Domain 3.3 – Third Party Management) and NCA ECC (Control 2-7). Saudi banks and fintechs must implement a structured Vendor Risk Management (VRM) program covering the full supplier lifecycle.
Key Steps:
- Pre-onboarding Assessment: Before contracting, require vendors to complete a cybersecurity questionnaire aligned to SAMA CSF maturity levels. Evaluate their ISO 27001 certification status, data handling practices, and incident response capabilities.
- Contractual Obligations: Per SAMA CSF Control 3.3.3, contracts must include cybersecurity clauses covering data protection, audit rights, breach notification timelines (within 72 hours per PDPL Art. 25), and right-to-terminate provisions.
- Ongoing Monitoring: Classify vendors by risk tier (critical, high, medium, low). Critical vendors — those with access to core banking systems or personal data — must undergo annual security assessments, and you should review their SOC 2 Type II or equivalent reports.
- Fourth-Party Risk: SAMA CSF also requires visibility into sub-contractors. Ensure your vendor contracts mandate disclosure of any fourth parties with access to your data or systems.
- Offboarding Controls: Revoke access, retrieve or destroy data, and document the offboarding per NCA ECC Control 2-7-4.
Practically, maintain a centralized vendor registry with risk ratings updated at least annually. Your GRC platform should automate assessment workflows, track remediation, and generate audit-ready reports for SAMA examiners. Non-compliance in this domain has been a recurring finding in SAMA regulatory reviews.
Third-party risk management is a critical pillar of SAMA CSF compliance, addressed specifically under Domain 3 (Cybersecurity Risk Management) and Domain 6 (Third-Party Cybersecurity). Saudi banks must establish a formal Third-Party Risk Management (TPRM) program that covers the entire vendor lifecycle — from onboarding due diligence to offboarding controls.
Key requirements include:
Pre-Engagement: Conduct cybersecurity risk assessments before contracting any vendor with access to systems or data. Per SAMA CSF Control 3.3.1, risk classification must determine the level of scrutiny applied.
Contractual Obligations: All third-party contracts must include cybersecurity clauses covering data protection, incident notification timelines (typically within 72 hours), right-to-audit provisions, and minimum security standards aligned with NCA ECC controls.
Ongoing Monitoring: High-risk vendors (e.g., cloud providers, payment processors, core banking vendors) must undergo annual cybersecurity assessments, including questionnaires, evidence reviews, and where applicable, independent audits or penetration test results review.
Concentration Risk: SAMA also requires banks to assess dependency and concentration risk — particularly for critical outsourced services — to ensure business continuity is not compromised.
PDPL Alignment: If the third party processes personal data on your behalf, a Data Processing Agreement (DPA) must be in place per PDPL Article 29, designating them as a data processor with defined obligations.
Practical tip: Tier your vendors (Critical, High, Medium, Low) and apply proportionate controls. Use automated TPRM platforms integrated into your GRC system to track assessment cycles, remediation actions, and contract renewal dates efficiently.
Security Awareness Training is not optional for Saudi financial institutions — it is a mandatory control under both SAMA CSF (Domain 2: Cybersecurity Leadership and Governance, Control 2.4) and NCA ECC (Domain 2, Control 2-10). However, many organizations treat awareness training as a checkbox exercise rather than a behavioral change program. Here's how to do it right:
Program Foundations: Establish a formal SAT policy endorsed by the CISO and Board. Define target audiences — all staff, privileged users, third-party contractors, and board members each require tailored content. Per SAMA CSF Control 2.4.1, role-based training must address job-specific threats.
Core Content Modules Should Include:
- Phishing and social engineering recognition
- Secure handling of customer and financial data (PDPL-aligned)
- Password hygiene and MFA usage
- Incident reporting procedures
- Acceptable use of corporate systems
- Insider threat awareness
Phishing Simulation: Conduct monthly or quarterly simulated phishing campaigns. Track click rates, credential submission rates, and reporting rates as KPIs. Employees who fail should receive immediate remedial training — not punitive action.
Frequency and Format: Annual training alone is insufficient. Implement microlearning modules, monthly security tips, and event-driven training (e.g., after a major industry breach). NCA ECC recommends awareness activities be conducted at least annually, but leading practices suggest quarterly touchpoints.
Measuring Effectiveness: Report SAT metrics to senior management and the board annually, including training completion rates (target: 95%+), phishing simulation trends, and incident reports attributed to human error.
Regulatory Reporting: SAMA may request evidence of your SAT program during regulatory examinations. Maintain records of training completion, content versions, and assessment scores for at least three years.
Third-party risk management (TPRM) is a critical compliance obligation for Saudi financial institutions under SAMA CSF Domain 3.3 and NCA ECC Control 2-7. A robust TPRM program should follow these key steps:
1. Vendor Classification & Tiering: Categorize all third parties by criticality — Tier 1 (critical suppliers with access to core systems or sensitive data), Tier 2 (significant vendors), and Tier 3 (low-risk suppliers). SAMA CSF requires formal risk classification before onboarding.
2. Pre-Onboarding Due Diligence: Conduct security assessments including questionnaire-based reviews, evidence collection (ISO 27001 certificates, SOC 2 reports), and for Tier 1 vendors, independent security assessments or on-site audits per SAMA CSF Control 3.3.2.
3. Contractual Controls: Embed cybersecurity clauses covering data protection obligations, right-to-audit provisions, incident notification timelines (typically within 72 hours per PDPL Article 28), and compliance with SAMA and NCA requirements.
4. Ongoing Monitoring: Perform annual reassessments for Tier 1 vendors and biennial reviews for Tier 2. Monitor for adverse events such as breaches, regulatory sanctions, or financial instability.
5. Offboarding Procedures: Ensure secure data deletion, access revocation, and formal closure documentation when vendor relationships end.
6. Cloud & SaaS Providers: For cloud vendors, additionally verify alignment with NCA Cloud Cybersecurity Controls (CCC) and SAMA's cloud outsourcing guidelines, including data residency requirements within the Kingdom.
Maintain a centralized vendor register with risk ratings, assessment dates, and contractual status. SAMA expects this register to be available during regulatory examinations.
Identity and Access Management (IAM) is one of the most scrutinized control domains during SAMA and NCA regulatory examinations. Requirements are detailed under SAMA CSF Controls 3.3.5–3.3.7 and NCA ECC Controls 2-5 and 2-6.
Core IAM Requirements:
1. Least Privilege & Need-to-Know: All user access rights must be provisioned based on job function and strictly limited to what is necessary. Access requests must follow a formal approval workflow with documented justification.
2. Privileged Access Management (PAM): Privileged accounts (domain admins, database admins, root accounts) must be managed through a dedicated PAM solution. All privileged sessions must be recorded and monitored. Generic or shared admin accounts are prohibited per SAMA CSF.
3. Multi-Factor Authentication (MFA): MFA is mandatory for all remote access, privileged accounts, and access to critical systems. SAMA CSF specifically requires MFA for internet-facing portals and core banking system access.
4. Access Reviews: Formal quarterly access recertification is required for privileged accounts and semi-annual reviews for all other accounts. Results must be documented and actioned within defined remediation windows.
5. Joiners, Movers, Leavers (JML) Process: Access provisioning and deprovisioning must be tied to HR workflows. Leavers' access must be revoked within 24 hours of termination, with immediate revocation for involuntary departures.
6. Directory & Identity Governance: Maintain a central identity directory (e.g., Active Directory, Azure AD) integrated with HR systems. Orphaned accounts — accounts with no active owner — must be detected and disabled regularly.
Document all IAM policies, procedures, and evidence of control operation for regulatory examination readiness. SAMA expects IAM evidence to be produced within 48 hours of an examination request.
Third-party risk management (TPRM) is a critical compliance obligation under SAMA CSF Domain 4 (Third Party Cybersecurity), which requires Saudi banks and financial institutions to maintain a structured, lifecycle-based approach to vendor risk.
Key implementation steps include:
- Vendor Inventory & Classification: Maintain a complete register of all third parties with access to systems or data. Classify vendors by risk tier — critical, high, medium, low — based on access level, data sensitivity, and operational dependency.
- Pre-Onboarding Due Diligence: Per SAMA CSF Control 4.1, conduct cybersecurity assessments before onboarding. Require vendors to demonstrate compliance with recognized frameworks (ISO 27001, NCA ECC) and review their security policies, audit reports (SOC 2, ISAE 3402), and incident history.
- Contractual Safeguards: Embed cybersecurity clauses covering data handling, breach notification timelines (aligned with PDPL's 72-hour reporting), right-to-audit provisions, and minimum security standards.
- Continuous Monitoring: SAMA CSF requires ongoing oversight — not just point-in-time assessments. Use automated threat intelligence feeds, periodic reassessments (at least annually for critical vendors), and monitor for adverse news or certifications lapsing.
- Incident & Exit Management: Define clear procedures for vendor-side incidents, including escalation paths and contractual remediation obligations. Maintain exit strategies to ensure data return/destruction and service continuity.
NCA ECC Article 3-4 also mandates controls on third-party access to national infrastructure components, which overlaps for banks with cross-sector connectivity.
Platforms like CISO Consulting can help automate vendor questionnaires, risk scoring, and evidence collection to keep your TPRM program audit-ready year-round.
Human error remains the leading cause of cybersecurity incidents in financial institutions globally, and SAMA CSF Domain 2 (Human Resources Cybersecurity) mandates that Saudi banks establish a formal, measurable security awareness and training program for all staff.
Building a SAMA-compliant Security Awareness Program:
- Role-Based Training Design: Per SAMA CSF Control 2.3, training must be tailored to roles. General staff need phishing awareness and data handling basics; IT and security teams require technical deep-dives; executives and board members need governance-focused content on cyber risk and regulatory liability.
- Mandatory Onboarding & Annual Refreshers: All new employees must complete security awareness training before being granted system access. Annual refresher training is the minimum — quarterly micro-learning modules (5–10 minutes) significantly improve retention.
- Phishing Simulation Campaigns: Run regular simulated phishing exercises (at least quarterly) to baseline and track employee click rates. SAMA CSF expects documented evidence of these exercises, including remedial training triggers for employees who fail simulations.
- Metrics & Reporting: Track KPIs such as training completion rates (target: 100% for mandatory modules), phishing simulation failure rates (benchmark: below 5% after 6 months), and incident reports attributable to human error. Report these to the CISO and board-level risk committee.
- Regulatory & Policy Acknowledgements: Require staff to formally acknowledge key policies (Acceptable Use, Data Classification, Incident Reporting) annually — these acknowledgements serve as audit evidence under SAMA CSF and NCA ECC assessments.
- Specialized Training for Privileged Users: Admins and developers with elevated access must receive additional training on topics such as social engineering, secure coding (OWASP Top 10), and insider threat indicators.
A well-executed awareness program not only satisfies SAMA examiners but measurably reduces your organization's attack surface — making it one of the highest-ROI investments in your cybersecurity portfolio.
Security awareness and training is explicitly mandated under SAMA CSF Domain 3.1 (Cybersecurity Leadership and Governance), and it extends beyond a simple annual e-learning course. Here is how to build a program that satisfies regulators and actually reduces risk:
Mandatory Training Scope (SAMA CSF 3.1.4): All employees — including contractors and third-party staff with system access — must receive cybersecurity awareness training. New joiners must complete training within 30 days of onboarding. Board members and senior management require specialized training covering cyber risk governance, not just general awareness.
Frequency and Format: General staff: minimum annual training with quarterly micro-learning campaigns (phishing simulations, policy reminders). IT and security staff: role-specific technical training at least twice per year. Executives: annual cyber risk briefing aligned with the institution's risk appetite and threat landscape.
Phishing Simulation Requirements: SAMA CSF expects institutions to test employee resilience through simulated phishing campaigns. Run simulations quarterly, track click rates, and provide immediate remedial training to employees who fail. Document results for regulatory evidence.
Topics to Cover: Social engineering and phishing recognition, password hygiene and MFA usage, secure handling of customer data (PDPL obligations), incident reporting procedures, acceptable use of IT systems, and remote working security.
NCA ECC Alignment: NCA ECC Article 2-2 reinforces the need for cybersecurity awareness programs with documented evidence of completion. Training records must be maintained and available for NCA assessments.
Measurement and Reporting: Track training completion rates (target: 95%+ within compliance windows), phishing simulation click rates over time, and security incident reports attributed to human error. Present these metrics to the CISO and risk committee quarterly.
Documentation: Maintain training completion records, curriculum content, and assessment results for a minimum of three years to support SAMA and NCA audit requirements.
Identity and Access Management (IAM) is one of the most scrutinized control areas during SAMA and NCA regulatory examinations. Here are the mandatory requirements and best practices:
SAMA CSF Requirements (Domain 3.2 – Access Management)
- Implement role-based access control (RBAC) with least-privilege principles across all systems (SAMA CSF Control 3.2.1)
- Enforce Multi-Factor Authentication (MFA) for all privileged accounts and remote access without exception
- Conduct quarterly access reviews for privileged users and semi-annual reviews for standard users
- Disable or remove access within 24 hours of employee termination (SAMA CSF Control 3.2.4)
NCA ECC Controls (ECC-1:2-7.1 to 7.4) NCA mandates strict Privileged Access Management (PAM) controls including session recording, just-in-time access provisioning, and vault-based credential management for all administrative accounts.
Practical Implementation Steps:
- Deploy a PAM solution (CyberArk, BeyondTrust, or equivalent) for privileged account governance
- Integrate Identity Governance & Administration (IGA) tools to automate access certification campaigns
- Implement Single Sign-On (SSO) with federation protocols (SAML 2.0/OIDC) to centralize authentication
- Enforce conditional access policies based on device posture, location, and risk score
- Log all privileged sessions and integrate with SIEM for real-time anomaly detection
PDPL Consideration: Under PDPL Article 10, access to personal data must be restricted to authorized personnel only, making IAM controls a legal obligation beyond just cybersecurity best practice.
Regulatory examiners frequently test IAM controls through user access listing reviews — ensure your access matrix is current and audit-ready at all times.
Third-party risk management (TPRM) is a critical compliance area under SAMA CSF Domain 3 (Cybersecurity Risk Management) and specifically Control 3.3.6, which mandates that financial institutions maintain a structured program for assessing and monitoring vendors with access to systems or data.
Key requirements and practical steps:
- Vendor Classification: Categorize all vendors by risk tier — critical, high, medium, and low — based on data access, system connectivity, and service criticality. Cloud providers, core banking vendors, and payment processors typically fall in the critical tier.
- Pre-Onboarding Assessment: Before contracting, conduct a cybersecurity due diligence review covering ISO 27001 certification status, penetration test results, SOC 2 reports, and security policy documentation.
- Contractual Controls: Per SAMA CSF, contracts must include cybersecurity clauses covering data protection, incident notification timelines (typically 72 hours), audit rights, and compliance with Saudi regulations including PDPL.
- Continuous Monitoring: Implement ongoing monitoring through annual or semi-annual reassessments for critical vendors, automated threat intelligence feeds, and tracking of vendor security incidents.
- PDPL Alignment: When vendors process personal data, ensure Data Processing Agreements (DPAs) are in place per PDPL Article 29, defining the purpose, retention limits, and cross-border transfer restrictions.
- Exit Strategy: Maintain documented exit plans to ensure data recovery and service continuity if a vendor relationship is terminated.
A GRC platform centralizes vendor risk scoring, automates assessment workflows, tracks remediation, and generates SAMA-ready audit evidence — reducing manual effort significantly for compliance teams.
Under SAMA CSF Control 3.3.1 and supporting sub-controls, Saudi banks are required to establish a formal, documented cybersecurity awareness and training program that covers all employees, contractors, and privileged users. The program must be risk-based, role-specific, and conducted at least annually — with additional training triggered by significant threat changes or after security incidents.
An effective program should include the following components:
1. Role-Based Training Tracks: General staff receive phishing awareness, password hygiene, and social engineering modules. IT and security teams receive advanced technical training aligned with their functions. Executives and board members require governance-level sessions covering cyber risk appetite and regulatory obligations.
2. Phishing Simulation Campaigns: Conduct quarterly simulated phishing exercises and track click rates over time. SAMA CSF expects measurable improvement, so document baseline metrics and remediation steps for repeat offenders.
3. Onboarding Integration: New employees must complete cybersecurity awareness training before being granted access to systems, per SAMA CSF's access control requirements under Control 3.3.3.
4. Awareness Metrics and Reporting: Track completion rates, assessment scores, and simulation results. Report these metrics to senior management and the board as part of cybersecurity KPIs.
5. Arabic-Language Content: Given Saudi Arabia's workforce demographics, awareness materials must be available in Arabic to ensure comprehension and regulatory defensibility.
From an NCA ECC perspective, Article 2-6 also mandates cybersecurity awareness as a foundational control. Aligning your program to satisfy both frameworks simultaneously reduces duplication and strengthens audit readiness. Our platform provides pre-built, SAMA-aligned training modules, phishing simulation tooling, and automated completion tracking dashboards.
SAMA CSF Control 3.3.1 mandates that all employees, contractors, and third parties with access to organizational systems receive regular cybersecurity awareness training tailored to their roles. Banks must establish a formal, documented training program that is reviewed and updated at least annually.
An effective program should include the following components:
1. Role-Based Training: General staff receive foundational awareness covering phishing, social engineering, and password hygiene. IT and security teams require advanced technical training. Executives and board members need governance-focused modules aligned with their oversight responsibilities.
2. Phishing Simulation: Conduct quarterly simulated phishing campaigns to measure staff susceptibility. Track click-through rates and remediate with targeted coaching for repeat offenders.
3. Onboarding Integration: New hires must complete cybersecurity orientation before accessing production systems, per SAMA CSF Control 3.3.2.
4. Regulatory Alignment: Training content should reference PDPL obligations (e.g., data handling, breach reporting duties) and NCA ECC awareness requirements to ensure holistic compliance.
5. Metrics and Reporting: Track completion rates, assessment scores, and phishing simulation results. Report outcomes to the CISO and board risk committee at least semi-annually.
6. Culture Building: Beyond compliance, embed security into daily workflows through awareness campaigns, internal newsletters, and gamified learning modules in Arabic and English.
Failure to maintain an active training program is a common finding in SAMA regulatory examinations. Institutions should retain training records for a minimum of three years to demonstrate compliance during audits.
Third-party risk management is a critical compliance obligation for Saudi financial institutions under SAMA CSF Domain 3 (Cybersecurity Risk Management) and NCA ECC-1:2018 Article 3-4. A well-structured TPRM program should cover the following pillars:
1. Vendor Classification & Due Diligence Classify all third parties by risk tier — critical, high, medium, and low — based on data access, system integration, and operational dependency. SAMA CSF requires documented due diligence before onboarding any vendor with access to sensitive financial or personal data.
2. Contractual Security Requirements All vendor contracts must include cybersecurity clauses aligned with SAMA CSF Control 3.3, covering data handling, incident notification obligations (typically within 72 hours), right-to-audit provisions, and compliance with PDPL Article 29 for any data processing arrangements.
3. Continuous Monitoring Don't treat TPRM as a one-time assessment. NCA ECC recommends periodic reassessment cycles — annually for critical vendors and every two years for lower-risk suppliers. Use automated tools to track vendor security posture changes, certificate expirations, and breach notifications.
4. Exit Strategy & Data Return Include contractual provisions for secure data deletion or return upon contract termination, in line with PDPL data minimization principles.
5. Governance & Reporting TPRM findings should be escalated to the CISO and reported to the Board Risk Committee at least annually, as required under SAMA CSF governance controls.
Our platform provides a structured TPRM workflow with pre-built assessment templates mapped to SAMA CSF and NCA ECC controls, enabling your team to onboard, monitor, and offboard vendors with full audit traceability.
Third-party risk management is a critical compliance obligation for Saudi financial institutions. Under SAMA CSF Control 3.3 (Third-Party Management), banks must establish a formal TPRM program that covers the entire vendor lifecycle — from onboarding due diligence through contract termination and offboarding.
Key implementation steps include:
- Vendor Inventory & Classification: Maintain a comprehensive register of all third parties and classify them by criticality — critical, high, medium, and low — based on their access to systems, data sensitivity, and operational dependency.
- Pre-Engagement Due Diligence: Before contracting, assess vendors against cybersecurity posture, financial stability, regulatory compliance history, and geographic risk. SAMA CSF requires documented due diligence for critical vendors.
- Contractual Controls: Embed mandatory security clauses covering data protection (aligned with PDPL), incident notification timelines (typically 72 hours per SAMA guidance), audit rights, and right-to-terminate triggers.
- Ongoing Monitoring: Per NCA ECC Article 2-14, organizations must conduct periodic reassessments. Critical vendors should be reviewed at least annually, with continuous monitoring for high-risk suppliers.
- Concentration Risk: SAMA expects banks to identify and manage vendor concentration risk — where over-reliance on a single supplier could impact operational resilience.
- Fourth-Party Risk: Extend your program to cover subcontractors and sub-processors used by your vendors, especially in cloud and fintech supply chains.
A mature TPRM program should integrate with your broader GRC platform, enabling automated risk scoring, evidence collection, and audit-ready reporting for SAMA examinations.
Third-party risk management (TPRM) is a critical compliance obligation under SAMA CSF Domain 3 (Third-Party Management) and NCA ECC-1:2018 Control 3-3. Saudi banks must implement a structured, lifecycle-based approach covering vendor onboarding, ongoing monitoring, and offboarding.
Key requirements include:
- Risk-based vendor classification: Categorize suppliers based on data sensitivity, system criticality, and service dependency. Vendors with access to core banking or customer data require enhanced due diligence.
- Contractual security obligations (SAMA CSF Control 3.3.2): All third-party contracts must include mandatory cybersecurity clauses covering incident notification timelines (typically 72 hours), right-to-audit provisions, data handling obligations aligned with PDPL, and minimum security standards.
- Continuous monitoring: Implement annual security assessments for critical vendors and conduct surprise audits where contractually permitted. Use automated attack surface monitoring tools for real-time risk visibility.
- Concentration risk: SAMA expects banks to identify and mitigate vendor concentration risk, particularly for cloud and IT outsourcing providers. Document alternative arrangements and exit strategies.
- Board reporting: Senior management and board risk committees must receive regular TPRM dashboards reflecting vendor risk ratings, open findings, and remediation status.
Practical guidance: Establish a dedicated vendor risk register integrated with your GRC platform, ensure security questionnaires map explicitly to SAMA CSF and NCA ECC controls, and conduct tabletop exercises simulating a critical vendor failure. Non-compliance with TPRM requirements has been a recurring theme in SAMA regulatory findings, making this a top audit priority for 2024–2025.
Third-party risk management (TPRM) is a critical obligation under both SAMA CSF (Domain 4 – Third Party Risk Management) and NCA ECC (Control 2-14). Saudi financial institutions must establish a formal TPRM program covering the full vendor lifecycle: onboarding, ongoing monitoring, and offboarding.
Key requirements include:
- Risk-based classification: Categorize vendors by criticality and data sensitivity before engagement. SAMA CSF Control 4.1 mandates risk tiering to determine due diligence depth.
- Contractual obligations: All contracts with third parties must include cybersecurity clauses covering data protection, incident notification windows (typically 72 hours), right-to-audit provisions, and compliance with PDPL where personal data is processed.
- Security assessments: Conduct pre-onboarding security assessments and annual reviews for critical vendors. NCA ECC requires documented evidence of vendor compliance with applicable controls.
- Concentration risk: SAMA specifically flags cloud and outsourcing concentration risk — institutions must avoid over-dependence on a single vendor for critical services.
- Exit strategy: Maintain documented exit and transition plans to ensure business continuity if a vendor relationship is terminated.
Practical tip: Build a vendor risk register integrated into your GRC platform that tracks assessment status, residual risk ratings, contract renewal dates, and remediation actions. Automate vendor questionnaire distribution and scoring to reduce manual overhead and maintain audit-ready documentation for SAMA and NCA examinations.
Under SAMA CSF Domain 4 (Cybersecurity Resilience), Saudi banks and financial institutions must maintain robust Business Continuity Management (BCM) and Disaster Recovery (DR) capabilities. Key requirements include:
SAMA CSF Control 4.3 – Business Continuity Planning:
- Develop and maintain a Cyber Resilience Plan that aligns with the institution's overall BCM framework.
- Define Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) for all critical systems, ensuring RTO for Tier-1 banking systems typically does not exceed 4 hours.
- Conduct Business Impact Analyses (BIA) annually to identify critical assets and acceptable downtime thresholds.
SAMA CSF Control 4.4 – Testing & Exercising:
- Perform full DR drills at least once per year, with tabletop exercises conducted semi-annually.
- Document test results, identify gaps, and remediate findings within agreed timelines.
- Simulate ransomware or cyber-attack scenarios during DR exercises to assess real-world resilience.
Practical Guidance:
- Maintain offline, immutable backups tested regularly for integrity and restoration speed.
- Ensure DR sites (whether on-premises or cloud-based) comply with NCA ECC geographic data residency requirements — primary and backup data must remain within Saudi Arabia.
- Integrate your Incident Response Plan with BCM so that a declared cyber incident automatically triggers continuity procedures.
- Assign clear ownership: a Cyber Resilience Owner accountable to the CISO should oversee BCM testing and reporting.
Non-compliance with SAMA CSF resilience controls may trigger supervisory action, including mandatory remediation plans and increased inspection frequency.
NCA & Government 13
The NCA Essential Cybersecurity Controls (ECC) is a mandatory framework issued by the National Cybersecurity Authority of Saudi Arabia. It applies to all Saudi government entities, state-owned enterprises, and critical national infrastructure organizations. It contains 114 controls across 5 domains.
The NCA ECC covers: (1) Cybersecurity Governance — policies, roles, and strategy; (2) Cybersecurity Defense — technical controls for endpoints, servers, applications, and networks; (3) Cybersecurity Resilience — business continuity, incident response, and disaster recovery; (4) Third-Party & Cloud Cybersecurity — supplier management and cloud usage controls; (5) Industrial Control Systems — cybersecurity for OT/ICS environments.
The NCA Essential Cybersecurity Controls (ECC) place specific obligations on Saudi organizations regarding cryptography, addressed primarily under ECC Domain 2-14 (Cryptography and Encryption). Organizations must establish and enforce a documented cryptography policy that governs the use, management, and retirement of cryptographic keys and algorithms across all information systems. Approved cryptographic standards must align with internationally recognized frameworks such as NIST SP 800-57 and FIPS 140-2 (or FIPS 140-3 for newer deployments). This means deploying only vetted algorithms: AES-256 for symmetric encryption, RSA-2048 or ECDSA P-256 for asymmetric operations, and SHA-256 or higher for hashing. Weak or deprecated algorithms such as MD5, SHA-1, DES, and 3DES must be eliminated from all production systems. From a SAMA CSF perspective, Control 3.2.1 reinforces encryption mandates for data at rest and in transit across banking systems, payment channels, and customer-facing applications. Key management is a critical operational area: organizations must implement a formal Key Management Lifecycle covering key generation, distribution, storage, rotation, and destruction. Hardware Security Modules (HSMs) are strongly recommended — and in many cases expected by regulators — for protecting cryptographic keys used in payment processing and PKI environments. Public Key Infrastructure (PKI) should be managed with a clearly defined Certificate Lifecycle Management process, including automated alerting for certificate expiry to prevent outages. Practical steps include conducting a cryptographic asset discovery exercise to identify all certificates, keys, and encryption implementations across the environment, followed by a gap assessment against ECC and SAMA requirements. Organizations should also integrate certificate management tools such as Venafi or Keyfactor and schedule annual cryptographic reviews to ensure ongoing compliance as standards evolve.
NCA ECC-2 Article 3-8 (Cybersecurity Incident Management) sets explicit obligations for how Saudi organizations must detect, manage, and report cybersecurity incidents. For financial institutions, SAMA CSF Control Domain 3.6 adds additional sector-specific layers.
Reporting Timelines: Under NCA ECC, significant cybersecurity incidents must be reported to the National Cybersecurity Authority within 24 hours of detection. SAMA requires banks to additionally notify SAMA's Cybersecurity Division within the same window for incidents impacting financial services, customer data, or operational continuity.
Incident Classification: Establish a formal severity taxonomy (P1–P4) aligned to NCA ECC definitions. P1 incidents (full system compromise, ransomware, data breach affecting customer PII) trigger immediate escalation to executive leadership and regulators. PDPL Article 39 also mandates notification to SDAIA within 72 hours for breaches involving personal data.
IR Plan Components: Your Incident Response Plan must include: defined roles and responsibilities (RACI matrix), pre-approved communication templates for regulators and customers, evidence preservation procedures aligned to forensic best practices, and post-incident review (PIR) requirements. NCA expects IR plans to be tested via tabletop exercises at minimum annually.
Practical Guidance: Integrate your SIEM and SOAR platform to automate initial triage and alert escalation. Pre-register your institution on the NCA's National Cybersecurity Operations Center (NCOC) reporting portal. Maintain an up-to-date incident log with timestamps, containment actions, and regulatory notifications as permanent audit evidence. SAMA examiners routinely request IR documentation during on-site reviews.
The NCA Essential Cybersecurity Controls (ECC) — specifically ECC-2: 2-3 on Cybersecurity Operations — mandate that Saudi organizations operating critical national infrastructure, including banks and financial institutions, establish and operate a Security Operations Center (SOC) capable of continuous threat detection, monitoring, and response.
Key NCA ECC SOC Requirements:
1. 24/7 Monitoring Coverage: The SOC must provide round-the-clock monitoring of all critical systems, networks, and endpoints. This applies equally to in-house and outsourced managed SOC models.
2. SIEM Integration: A Security Information and Event Management (SIEM) platform must be deployed to aggregate, correlate, and analyze security events. Log retention must meet NCA requirements — typically 12 months online with extended archival.
3. Threat Intelligence Integration: Per NCA ECC, the SOC must consume and act on threat intelligence feeds, including those from CERT-SA, to detect emerging Saudi-specific threats such as targeted phishing campaigns and ransomware affecting Gulf financial entities.
4. Incident Detection & Escalation SLAs: Define Mean Time to Detect (MTTD) and Mean Time to Respond (MTTR) metrics. SAMA CSF additionally expects these KPIs to be reported to senior management periodically.
5. Integration with SAMA CSF Domain 3.4: SOC workflows must feed directly into the institution's Incident Response Plan, triggering regulatory notification processes when thresholds are breached.
6. SOC Maturity Assessment: NCA recommends periodic SOC maturity assessments against the SOC-CMM or equivalent model. Financial institutions should target at least Level 3 maturity.
Insourced vs. Outsourced SOC: Both models are acceptable under NCA ECC, provided the outsourced provider operates within Saudi Arabia and complies with data residency requirements under PDPL Article 29.
Our platform supports SOC teams with compliance dashboards, automated alert mapping to NCA ECC controls, and readiness assessments for SOC maturity uplift.
Vulnerability management is one of the most operationally intensive — yet most scrutinized — controls in Saudi financial regulation. Both NCA ECC (Article 2-7: Vulnerability Management) and SAMA CSF Control 3.3.5 set clear expectations for a continuous, risk-based vulnerability management lifecycle.
Building a Compliant Vulnerability Management Program:
- Asset Discovery & Coverage: You cannot protect what you don't know exists. Maintain a continuously updated asset inventory covering all IT, OT, cloud, and third-party-connected systems. This directly supports NCA ECC asset management requirements.
- Scanning Frequency: Internal vulnerability scans should run at minimum monthly; critical internet-facing assets and systems processing customer data require weekly or continuous scanning. New systems must be scanned before production deployment.
- Severity-Based Remediation SLAs: Establish documented SLAs aligned with risk classification:
- Critical (CVSS 9.0+): Remediate within 15 days
- High (CVSS 7.0–8.9): Remediate within 30 days
- Medium: 90 days
- Low: Next scheduled maintenance cycle
- Risk Acceptance Process: Where immediate remediation is not feasible, implement a formal risk acceptance and compensating controls process with CISO sign-off and documented review timelines.
- Patch Management Integration: Vulnerability management must feed directly into your patch management workflow. SAMA CSF expects evidence of patch tracking and exception management.
- Threat Intelligence Integration: Prioritize remediation based on active exploitation in the wild — CISA KEV catalog and Saudi-specific threat intelligence feeds are valuable inputs.
- Reporting to Senior Management: Produce monthly vulnerability posture reports for IT leadership and quarterly summaries for CISO and board-level reporting.
Ensure your GRC platform can auto-generate vulnerability aging reports and exception registers for SAMA regulatory submissions.
NCA uses a structured Cybersecurity Maturity Assessment (CMA) process. Entities submit self-assessments which are verified through NCA's review cycle. NCA may conduct on-site inspections, request evidence, and publish compliance ratings. Non-compliant entities receive remediation plans with deadlines.
NCA ECC (Essential Cybersecurity Controls) applies broadly to all government entities and is the baseline standard. NCA CSCC (Critical Sector Cybersecurity Controls) is a more stringent framework for critical national infrastructure sectors such as energy, water, telecommunications, and financial services. CSCC builds upon ECC with additional sector-specific requirements.
The NCA Essential Cybersecurity Controls (ECC-1:2018) includes specific provisions under Domain 4 (Cybersecurity Resilience) and Domain 2 (Cybersecurity Defense) that apply to organizations operating OT/ICS environments, such as utilities, critical infrastructure operators, and increasingly, large financial institutions with data center OT components.
Network Segmentation (ECC Control 2-8): OT and IT networks must be strictly segregated using firewalls, data diodes, or demilitarized zones (DMZ). Direct connectivity between corporate IT and OT environments is prohibited. Any integration points must go through validated, one-way data transfer mechanisms.
Asset Management (ECC Control 2-1): All OT/ICS assets must be inventoried and classified. Legacy systems that cannot be patched must be documented with compensating controls — air-gapping, application whitelisting, and enhanced monitoring are commonly accepted compensating measures.
Remote Access Controls: Remote access to OT environments must be tightly controlled, session-based, and require MFA. Permanent remote access connections to OT systems are generally prohibited without documented risk acceptance.
Vulnerability Management: Given that many ICS components run proprietary or legacy operating systems with infrequent patch cycles, organizations must implement a tailored OT vulnerability management program with vendor coordination. Virtual patching via industrial intrusion prevention systems (IPS) is an acceptable interim control.
Monitoring and Incident Detection: Passive network monitoring tools (e.g., Claroty, Dragos, Nozomi Networks) must be deployed to detect anomalies without disrupting OT operations. Active scanning is generally avoided due to risk of system disruption.
Practical Recommendation: Commission an OT-specific cybersecurity assessment using IEC 62443 as a complementary framework alongside NCA ECC, and map your findings into your GRC platform to track remediation progress and demonstrate compliance during NCA assessments.
The NCA Essential Cybersecurity Controls (ECC-1:2018) — specifically under Domain 2-7 (Cybersecurity Resilience) — mandate that organizations establish a formal, documented Cybersecurity Incident Response (IR) capability. For Saudi financial institutions, this overlaps with SAMA CSF Domain 5 (Cybersecurity Resilience) and must also align with reporting obligations to SAMA and NCA's national CERT (CERT-SA).
Core IR Program Components Required:
- Incident Response Policy & Plan: Define roles, responsibilities, escalation paths, and communication protocols. The plan must be approved by senior leadership and reviewed at least annually.
- Incident Classification Framework (ECC Art. 2-7-1): Categorize incidents by severity (P1–P4) to trigger proportionate responses. Cyber incidents affecting critical financial infrastructure may require escalation to CERT-SA.
- Detection & Analysis Capabilities: Deploy a Security Operations Center (SOC) or equivalent with 24/7 monitoring, SIEM integration, and threat intelligence feeds tailored to the Saudi financial sector's threat landscape.
- Containment, Eradication & Recovery: Document playbooks for common attack scenarios (ransomware, DDoS, insider threats, BEC fraud) specific to banking environments.
- Regulatory Reporting Obligations: SAMA requires notification of significant cyber incidents within defined timeframes. Coordinate with your Legal and Compliance teams to ensure timely, accurate disclosures.
- Post-Incident Reviews (PIR): Conduct structured lessons-learned sessions after every significant incident, and feed findings back into your risk register and control improvements.
Pro Tip: Conduct tabletop exercises at least twice per year simulating scenarios such as core banking system compromise or payment fraud, and document outcomes for SAMA and NCA audit evidence.
The NCA Essential Cybersecurity Controls (ECC-1:2018) dedicates a substantial section to Identity and Access Management (IAM) under Control Domain 2-4, outlining mandatory requirements for any entity falling under NCA's scope — including government agencies, critical national infrastructure operators, and state-affiliated organizations.
Core ECC IAM Requirements:
- ECC Control 2-4-1: Establish a formal IAM policy covering user lifecycle management — from provisioning to deprovisioning — with documented approval workflows.
- ECC Control 2-4-2: Enforce the principle of least privilege (PoLP) and role-based access control (RBAC) across all systems and applications.
- ECC Control 2-4-3: Mandate multi-factor authentication (MFA) for all privileged accounts, remote access sessions, and systems handling sensitive national data.
- ECC Control 2-4-4: Conduct quarterly access reviews and immediately revoke access upon role changes or employment termination.
Implementation Guidance:
- Deploy a centralized Identity Provider (IdP) — such as Microsoft Entra ID or a FIDO2-compliant solution — integrated with all critical systems.
- Implement Privileged Access Management (PAM) tools to monitor, record, and control privileged sessions.
- Establish a joiners-movers-leavers (JML) process with automated deprovisioning tied to HR systems.
- Maintain detailed access logs for a minimum of 12 months, aligned with NCA log retention requirements.
- For cloud environments, apply IAM controls consistent with NCA Cloud Cybersecurity Controls (CCC-1:2020).
Regular IAM audits should be documented and presented to the cybersecurity steering committee as evidence of ongoing compliance.
The NCA Essential Cybersecurity Controls (ECC) place cybersecurity governance at the foundation of organizational security maturity. Understanding and implementing these governance requirements is a starting point for any Saudi organization subject to NCA oversight.
NCA ECC Governance Requirements (Domain 1): ECC Domain 1 — Cybersecurity Governance — requires organizations to establish a formal cybersecurity governance framework that includes:
- A documented Cybersecurity Strategy aligned to business objectives (ECC Control 1-1).
- A dedicated Cybersecurity Function with defined roles and reporting lines, ideally reporting to C-suite or board level (ECC Control 1-2).
- A Cybersecurity Policy Framework covering all critical security domains (ECC Control 1-3).
- Cybersecurity roles and responsibilities formally defined and communicated across the organization (ECC Control 1-4).
- Board and senior management engagement in cybersecurity oversight and risk acceptance.
Building a Compliant Governance Structure:
- Appoint a CISO or equivalent: Designate a senior cybersecurity leader with direct access to executive management and the board.
- Establish a Cybersecurity Committee: A cross-functional committee (IT, Legal, Risk, Compliance, Business) that reviews cybersecurity risks and approves policies.
- Develop a Cybersecurity Policy Suite: Draft and approve policies covering access control, incident management, asset management, and acceptable use — mapped to ECC controls.
- Define a Cybersecurity Strategy: A 3–5 year roadmap aligned to NCA ECC maturity levels and business risk appetite.
- Conduct Annual Governance Reviews: Regularly assess governance effectiveness through internal audits and self-assessments using the NCA ECC assessment template.
- Integrate with ISO 27001: ISO 27001 Clause 5 (Leadership) and Clause 6 (Planning) closely mirror ECC Domain 1 requirements, enabling a unified governance approach.
Organizations that align their governance structures early reduce remediation effort during NCA compliance assessments and build a sustainable security culture from the top down.
The NCA Essential Cybersecurity Controls (ECC) explicitly addresses human-layer security through ECC Control 2-7 (Cybersecurity Awareness and Training), requiring Saudi organizations — including banks, fintechs, and government-linked entities — to implement a formal, ongoing security awareness program.
NCA ECC Mandatory Elements:
- Documented security awareness policy and annual training plan
- Role-based training tailored to job functions (e.g., developers, finance staff, executives)
- Phishing simulation exercises conducted regularly
- Awareness for third-party staff with access to organizational systems
- Metrics to measure program effectiveness
SAMA CSF Alignment: SAMA CSF Control 3.3.4 similarly requires awareness programs covering social engineering, password hygiene, data handling, and incident reporting procedures.
Building an Effective Program — Practical Steps:
- Baseline Assessment: Conduct a phishing simulation before launching the program to establish a click-rate baseline. Industry benchmarks suggest >30% click rates are common without training.
- Tiered Content: Develop role-specific modules — general staff receive phishing/password training, IT staff receive secure coding and access management content, and executives receive targeted social engineering and fraud awareness modules.
- Arabic-Language Content: Saudi regulators expect culturally relevant, Arabic-language training materials. Generic English-only platforms often fail to achieve the required engagement levels.
- Frequency: NCA ECC and best practices recommend at least annual formal training, monthly micro-learning, and quarterly phishing simulations.
- Documentation: Maintain training completion records, simulation results, and improvement metrics as audit evidence for NCA and SAMA reviews.
A GRC platform with integrated LMS capabilities can automate scheduling, track completions, generate compliance reports, and feed awareness metrics into your overall risk posture dashboard.
PDPL & Privacy 65
The Saudi Personal Data Protection Law (PDPL) was enacted by Royal Decree in September 2021 and officially entered into enforcement in September 2023 after a two-year transition period. Amendments were introduced in 2023 to align with global data protection best practices.
Under PDPL, organizations must: (1) Obtain explicit consent before collecting personal data; (2) Specify and limit the purpose of collection; (3) Implement appropriate security controls; (4) Honor data subject rights (access, correction, deletion, objection); (5) Report breaches within 72 hours to SDAIA; (6) Appoint a Data Protection Officer if processing large volumes; (7) Restrict cross-border data transfers.
Saudi Arabia's Personal Data Protection Law (PDPL), enforced by the Saudi Data and AI Authority (SDAIA), grants individuals a comprehensive set of rights over their personal data. For financial institutions—which process particularly sensitive categories such as financial records, national IDs, and biometric data—meeting these obligations requires both legal and technical readiness.
Key Data Subject Rights Under PDPL (Arts. 4–9):
- Right to Access: Individuals can request a copy of their personal data. Institutions must respond within a defined timeframe (typically 30 days).
- Right to Correction: Inaccurate or incomplete data must be corrected upon request.
- Right to Erasure: Data must be deleted when no longer necessary, subject to legal retention obligations (e.g., SAMA requires transaction records retained for 10 years).
- Right to Object: Individuals may object to processing for direct marketing or profiling purposes.
- Right to Data Portability: Emerging obligation requiring data to be provided in a structured, machine-readable format.
Technical Controls Required:
- Data Discovery & Mapping: Maintain an up-to-date Record of Processing Activities (RoPA) identifying where personal data resides across systems.
- Access Request Workflows: Implement automated Subject Access Request (SAR) handling within your GRC or DPM platform to track requests, deadlines, and responses.
- Consent Management: Deploy consent management platforms to record and honour withdrawal of consent in near real-time.
- Data Masking & Deletion Pipelines: Build automated pseudonymisation and secure deletion workflows, ensuring deletion is propagated across backup systems.
- Audit Trails: Maintain immutable logs of all data processing activities to demonstrate accountability to SDAIA during audits.
Note: Regulatory retention requirements under SAMA CSF and AML/CFT rules may create legitimate grounds to decline erasure requests—document these exceptions explicitly in your privacy notices and internal policies.
Under Saudi Arabia's Personal Data Protection Law (PDPL) and its Executive Regulations, data breaches triggering notification obligations are those that result in — or are likely to result in — harm to data subjects. Here is a structured response framework for fintechs:
Step 1 — Breach Detection and Internal Escalation (0–24 hours): Activate your Incident Response Plan (IRP). Assign a breach response lead (typically the DPO or CISO). Preserve evidence, isolate affected systems, and begin preliminary impact assessment: How many records affected? What categories of personal data? (financial details, national IDs, biometrics carry higher risk weighting.)
Step 2 — Regulatory Notification to SDAIA (Within 72 Hours): Per PDPL Article 24 and the Executive Regulations, you must notify the Saudi Data & AI Authority (SDAIA) within 72 hours of becoming aware of a breach that poses risk of harm. Your notification must include: nature of the breach, categories and approximate number of affected individuals, likely consequences, and measures taken or planned.
Step 3 — Data Subject Notification: If the breach is likely to cause direct harm to individuals (identity theft, financial fraud risk, reputational damage), you must notify affected data subjects without undue delay. The notification should explain what happened, what data was exposed, and what steps individuals can take to protect themselves.
Step 4 — Documentation and Post-Incident Review: PDPL requires maintaining a breach register documenting all incidents regardless of notification threshold. Conduct a post-incident review aligned with ISO 27001 Clause 10.1 and update your risk register and controls accordingly.
Key consideration for fintechs: If your platform processes payment data, you also have parallel notification obligations under SAMA CSF Incident Management controls and potentially PCI-DSS breach notification requirements. Coordinate these notifications carefully to avoid conflicting communications.
The Saudi Personal Data Protection Law (PDPL) grants individuals a set of enforceable rights over their personal data, and fintechs — given the volume of sensitive financial and identity data they process — must establish robust, documented processes to handle these requests effectively.
Key Data Subject Rights under PDPL:
- Right to Access: Individuals can request a copy of their personal data and information about how it is being processed.
- Right to Correction: Inaccurate or incomplete data must be corrected upon request.
- Right to Erasure: Data subjects can request deletion of their data when it is no longer needed or consent is withdrawn (subject to legal retention obligations).
- Right to Data Portability: Where applicable, data must be provided in a structured, machine-readable format.
- Right to Object: Individuals can object to certain types of processing, including direct marketing.
Operational Requirements:
- Establish a dedicated intake channel (e.g., a privacy portal or email) clearly communicated in your privacy notice.
- Define an internal SLA — PDPL requires responses within 30 days, with the possibility of a single extension.
- Implement an identity verification step before disclosing any personal data.
- Maintain a request log for audit purposes — ZATCA and the National Data Management Office (NDMO) may audit your compliance posture.
- Train customer service and security teams on how to recognize and escalate DSRs.
Intersection with Financial Regulations: Note that some erasure requests may conflict with SAMA's mandatory record retention requirements (typically 10 years). Fintechs must balance PDPL obligations with SAMA CSF and AML record-keeping rules, documenting the legal basis for retention overrides.
Saudi fintechs operating mobile applications that collect and process customer financial data face specific obligations under the Personal Data Protection Law (PDPL) and its Implementing Regulations. Here is a practical compliance breakdown:
1. Lawful Basis for Processing: Under PDPL Article 6, processing personal financial data requires a valid legal basis — typically explicit consent or contractual necessity. Consent must be granular, informed, and freely withdrawable. Pre-ticked boxes or bundled consent are non-compliant.
2. Privacy Notice Requirements: PDPL Article 11 mandates a clear, accessible privacy notice within the app, disclosed at the point of data collection. It must specify: categories of data collected, processing purposes, retention periods, and data subject rights.
3. Sensitive Financial Data Handling: Financial data — including transaction history, credit scores, and account details — may be classified as sensitive under PDPL. Apply enhanced controls including encryption at rest and in transit, strict access controls, and audit logging per ISO 27001 Annex A.8 controls.
4. Data Minimization: Collect only data strictly necessary for the stated service purpose. Avoid collecting excessive device permissions (e.g., contacts, location) without demonstrable necessity, as SAMA also scrutinizes this under its Open Banking Framework.
5. Data Subject Rights: PDPL grants customers rights to access, correct, and request deletion of their personal data. Fintechs must operationalize these rights within the app UI and back-end systems, with responses delivered within regulatory timeframes (30 days under PDPL Article 15).
6. Data Breach Notification: Per PDPL Article 27, notify the Saudi Data and Artificial Intelligence Authority (SDAIA) within 72 hours of discovering a breach affecting personal data, and notify affected individuals without undue delay.
7. DPO Appointment: Fintechs processing data at scale should appoint a Data Protection Officer (DPO) to oversee compliance, liaise with SDAIA, and maintain the Records of Processing Activities (RoPA).
The Saudi Personal Data Protection Law (PDPL), enforced by the Saudi Data & AI Authority (SDAIA), grants individuals a defined set of rights over their personal data. For fintechs processing customer data—including KYC information, transaction histories, and behavioral analytics—building robust request-handling processes is both a legal necessity and a competitive trust signal.
Rights Granted Under PDPL:
- Right to Access (Article 4): Individuals may request confirmation of whether their data is being processed and obtain a copy. Fintechs must respond within a reasonable timeframe (SDAIA guidance suggests 30 days).
- Right to Correction (Article 14): Customers may request correction of inaccurate or incomplete personal data. This is particularly relevant for KYC records and credit-related information.
- Right to Erasure (Article 15): Data subjects may request deletion of their data when the processing purpose is fulfilled or consent is withdrawn—subject to regulatory retention obligations under SAMA and FATF anti-money laundering rules.
- Right to Data Portability: Individuals may request transfer of their data in a structured, readable format.
- Right to Object: Data subjects may object to processing for direct marketing or automated decision-making purposes.
Practical Implementation for Fintechs:
- Establish a dedicated Data Subject Request (DSR) intake channel (web form or in-app)
- Assign ownership to a Data Protection Officer (DPO) or privacy lead
- Build a response workflow with internal SLAs aligned to PDPL timelines
- Document all requests, decisions, and outcomes in a DSR log
- Map tension points where PDPL erasure rights conflict with SAMA/AML data retention mandates, and document your legal basis for retention
Failure to respond to DSRs may attract regulatory scrutiny from SDAIA, including potential fines.
Saudi Arabia's Personal Data Protection Law (PDPL), enforced by the Saudi Data & AI Authority (SDAIA), imposes clear obligations on fintech companies regarding data classification and protection. Under PDPL Articles 5 and 6, organizations must identify all personal data they process, establish a lawful basis for processing, and implement proportionate technical and organizational safeguards.
A practical PDPL-compliant data protection framework for fintechs should include:
1. Data Inventory & Classification: Map all personal data flows across your systems — KYC records, transaction data, biometric identifiers, and credit information fall under general personal data. Health or financial distress information may qualify as sensitive data requiring heightened protection under PDPL Article 23.
2. Technical Controls: Encrypt personal data at rest and in transit (AES-256 and TLS 1.2+ minimum). Implement role-based access controls (RBAC) and data masking for non-production environments. Per NCA ECC Control 2-4, data classification labels must be enforced across storage and transmission systems.
3. Retention & Deletion: PDPL Article 18 mandates that personal data not be retained beyond its stated purpose. Establish automated data lifecycle policies with documented retention schedules.
4. Data Subject Rights: Build workflows to handle access, correction, and deletion requests within the PDPL-mandated timeframes (15 business days for most requests).
Non-compliance can result in fines of up to SAR 5 million, reputational damage, and suspension of operations. Fintechs regulated by SAMA should also cross-reference SAMA's Customer Data Protection guidelines to ensure alignment across both regulatory regimes.
Under Saudi Arabia's Personal Data Protection Law (PDPL) and its Executive Regulations, every processing activity must rest on a clearly identified and documented lawful basis. For fintech companies, this is a foundational compliance obligation that directly affects product design, onboarding flows, and data governance frameworks.
The Six Lawful Bases Under PDPL:
- Consent – Freely given, specific, informed, and unambiguous. Consent must be withdrawable at any time without penalty, and pre-ticked boxes are not valid.
- Contractual Necessity – Processing required to execute or fulfill a contract with the data subject (e.g., processing payment data to complete a transfer).
- Legal Obligation – Processing mandated by Saudi law, such as AML/CFT reporting requirements under SAMA guidelines.
- Vital Interests – Protecting the life or safety of the data subject or others.
- Public Interest – Relevant to licensed fintech activities serving the public.
- Legitimate Interests – Permitted only where the controller's interests do not override the individual's rights; requires a documented balancing test.
Practical Steps for Fintechs:
- Conduct a data mapping exercise to catalog all processing activities, data categories, and purposes.
- Assign a lawful basis to each processing activity in your Records of Processing Activities (RoPA).
- Review customer consent forms and app onboarding flows to ensure consent language meets PDPL Article 5 requirements.
- For sensitive data (financial history, biometrics), explicit consent is required unless a specific legal exemption applies.
- Appoint a Data Protection Officer (DPO) if your processing is large-scale or involves sensitive categories.
Regular review of your lawful bases is essential, especially as product features evolve or new data uses are introduced.
The Saudi Personal Data Protection Law (PDPL) and its Executive Regulations grant individuals a suite of enforceable rights over their personal data, and fintech companies must establish formal processes to manage these requests. Here is a compliance-focused breakdown:
Core Data Subject Rights Under PDPL:
- Right to Access (Article 4): Individuals can request a copy of their personal data held by the organization
- Right to Correction: Request correction of inaccurate or incomplete data
- Right to Erasure: Request deletion of data when processing is no longer justified
- Right to Data Portability: Receive data in a structured, usable format
- Right to Withdraw Consent: Where consent is the legal basis for processing
- Right to Object: Object to processing in certain circumstances
Response Timelines: The PDPL Executive Regulations require organizations to respond to data subject requests within 30 days. Complex requests may be extended, but the individual must be notified of the delay and the reason.
Practical Implementation Steps:
- Create a dedicated, accessible channel for submitting rights requests (web form, email, in-app)
- Establish an internal intake and routing workflow with clear ownership
- Verify the identity of the requester before disclosure
- Maintain a request log for audit purposes — PDPL enforcement by SDAIA/NCA may include reviewing request handling records
- Train customer-facing and HR teams on identifying and escalating rights requests
Penalties for Non-Compliance: Failure to honor data subject rights can result in fines up to SAR 1 million under PDPL, with higher penalties for aggravated violations.
Fintechs handling large volumes of customer data should automate this process through their GRC or privacy management platform to ensure consistent, timely responses.
Saudi Arabia's Personal Data Protection Law (PDPL), enforced by the Saudi Data & AI Authority (SDAIA), imposes specific obligations on fintechs operating mobile banking or payment applications. Non-compliance can result in fines of up to SAR 5 million and reputational damage under regulatory scrutiny from both SDAIA and SAMA.
Core PDPL Obligations for Mobile App Data Collection:
- Lawful Basis (Article 7): Every data processing activity must have a valid legal basis — typically explicit consent, contractual necessity, or a legal obligation. For mobile apps, consent must be granular, meaning users must be able to consent separately to different processing purposes (e.g., analytics vs. service delivery).
- Privacy Notice (Article 11): A clear, accessible privacy notice must be presented before or at the point of data collection. This must state the types of data collected, purposes, retention periods, and data subject rights in plain Arabic.
- Data Minimization: Collect only what is strictly necessary for the stated purpose. Avoid requesting excessive device permissions (contacts, location, microphone) unless technically justified and disclosed.
- Data Subject Rights (Articles 14–18): Users must be able to access, correct, request deletion of, and withdraw consent from their data. Your app must have a functioning mechanism (in-app or portal) to handle these requests within the PDPL-mandated timeframes.
- Data Retention: Define and enforce retention schedules. Personal data must not be retained beyond its legitimate processing purpose.
- Cross-Border Transfers (Article 29): If the app uses overseas cloud infrastructure or analytics services, ensure an adequate protection level or a Data Transfer Agreement is in place per PDPL requirements.
SAMA Intersection: SAMA CSF Control 3.1.4 requires financial institutions to classify and protect customer personal data, directly reinforcing PDPL obligations. Fintechs should align their Privacy Impact Assessments (PIAs) with both frameworks simultaneously.
Saudi Arabia's Personal Data Protection Law (PDPL), enforced by the Saudi Data & AI Authority (SDAIA), provides a specific and elevated category of protection for 'sensitive personal data.' Understanding this classification is critical for financial institutions handling customer information.
PDPL Definition of Sensitive Data (Article 2 & 23): Sensitive personal data includes: ethnic or racial origin, religious or political beliefs, criminal records, health and medical data, biometric data, credit and financial data revealing personal financial situations, and location data that could harm the individual if disclosed.
For Saudi banks and fintechs, this means customer credit scores, account balances when linked to identifiable individuals, biometric authentication data (fingerprints, facial recognition), and health-related insurance data all qualify as sensitive.
Additional Safeguards Required:
- Explicit Consent: Unlike regular personal data, sensitive data requires explicit, informed consent per PDPL Article 23 — implied or bundled consent is insufficient.
- Data Minimization: Collect only what is strictly necessary for the defined purpose; avoid retaining sensitive data beyond operational need.
- Encryption at Rest and in Transit: Apply strong encryption (AES-256 minimum) for all sensitive data storage and transmission, aligned with NCA ECC-2-14 data protection controls.
- Access Restrictions: Limit access to sensitive data to authorized personnel only, with full audit trails maintained.
- Data Protection Impact Assessment (DPIA): Conduct a DPIA before processing sensitive data at scale, especially for AI-driven credit scoring or biometric onboarding systems.
- Cross-Border Transfer Controls: Sensitive data transfers outside the Kingdom require SDAIA approval or adequacy assessment under PDPL Article 29.
Practical Tip: Map all sensitive data flows in your institution's data inventory and tag them distinctly in your Data Classification Policy to trigger enhanced controls automatically.
Cross-border data transfers are one of the most operationally complex PDPL obligations for Saudi financial institutions, especially those with international correspondent banking relationships, global cloud providers, or offshore IT operations.
PDPL Baseline Requirements: Under PDPL Article 29, transferring personal data outside the Kingdom is only permitted if adequate protection is ensured in the destination country — equivalent to PDPL standards — and one of the following conditions is met:
- The transfer serves a public interest or fulfils a legal obligation.
- The transfer is necessary to protect the vital interests of the data subject.
- The data subject has given explicit, informed consent.
- A Data Transfer Agreement (DTA) is in place, approved by the competent authority (SDAIA).
For Financial Institutions Specifically: SAMA CSF Control 3.3.8 adds a further layer: customer financial data is considered critical and subject to data localization requirements. This means even if PDPL permits a transfer, SAMA may require the primary copy of financial data to remain within the Kingdom.
Practical Compliance Steps:
- Conduct a Data Transfer Impact Assessment (DTIA) for each cross-border data flow — map the data type, volume, destination country, legal basis, and protective measures.
- Establish SCCs (Standard Contractual Clauses) or equivalent DTAs with all international recipients.
- Implement technical safeguards: encryption in transit (TLS 1.2+), data minimization, and pseudonymization where feasible.
- Maintain a Register of International Transfers updated quarterly and available for SDAIA inspection.
- For cloud providers, explicitly verify data residency guarantees and include contractual audit rights.
Key Risk: SDAIA can impose fines up to SAR 5 million for unlawful data transfers. Financial institutions should treat this as a board-level compliance risk, not just an IT issue.
Data retention and secure disposal represent a critical compliance intersection for Saudi financial institutions, governed simultaneously by the Personal Data Protection Law (PDPL), SAMA CSF, and applicable SAMA circulars on records management.
PDPL Retention Obligations: Under PDPL Article 18, personal data must not be retained beyond the period necessary for the purpose for which it was collected, unless a legitimate legal basis exists for extended retention. Financial institutions typically rely on regulatory and legal obligations as their retention justification. Upon expiry of the retention period, data must be permanently deleted or anonymized in a manner that prevents re-identification.
SAMA CSF Requirements: SAMA CSF Control 3.3.6 (Data and Information Management) requires institutions to establish and enforce a formal Data Retention Policy that defines retention periods by data category, aligns with regulatory minimums, and mandates secure disposal procedures. SAMA circulars generally require financial records to be retained for a minimum of 10 years.
Secure Disposal Standards: For digital media, SAMA CSF requires data sanitization methods compliant with recognized standards such as NIST SP 800-88 (Clear, Purge, or Destroy methods depending on data sensitivity). Physical media destruction must be documented with chain-of-custody records.
Practical Implementation Steps:
- Develop a Data Retention Schedule mapping each data category to its retention period and legal basis
- Implement automated data lifecycle management tools to trigger deletion workflows
- Maintain a Disposal Certificate log for auditor evidence
- Conduct annual reviews of the retention schedule as regulations evolve
- Ensure third-party processors contractually commit to equivalent disposal standards per PDPL Article 15
Failure to comply with PDPL disposal requirements can result in fines of up to SAR 5 million, while SAMA supervisory findings may trigger remediation orders.
Using customer personal data for marketing and personalization is one of the highest-risk processing activities under Saudi Arabia's Personal Data Protection Law (PDPL) and its Executive Regulations. Financial institutions must navigate this carefully.
Legal Basis for Processing (PDPL Article 5) Marketing and personalization generally cannot rely on contractual necessity. Institutions must obtain free, informed, and specific consent from customers. Pre-ticked boxes or bundled consent within T&Cs are non-compliant. Consent must be documented and easily withdrawable.
Data Minimization & Purpose Limitation (PDPL Article 9) Only collect data strictly necessary for the declared marketing purpose. Using transaction data collected for fraud detection to build marketing profiles violates purpose limitation principles unless customers are explicitly informed and consent obtained separately.
Right to Opt-Out (PDPL Article 11) Customers have the right to withdraw consent and object to direct marketing at any time. Financial institutions must implement a functional opt-out mechanism within their apps, websites, and call centers, with processing stopped within a reasonable timeframe — best practice is 5 business days.
Cross-Border Data Transfers (PDPL Article 29) If personalization engines or marketing platforms are hosted outside Saudi Arabia, a Data Transfer Impact Assessment (DTIA) is required, and transfers must only proceed to jurisdictions with adequate protection levels as determined by SDAIA.
Practical Controls:
- Implement a Consent Management Platform (CMP) integrated with your CRM.
- Conduct a Data Processing Impact Assessment (DPIA) for high-risk profiling activities.
- Maintain a Record of Processing Activities (ROPA) documenting lawful basis per PDPL Article 14.
- Train marketing teams on PDPL obligations annually.
Non-compliance can result in fines up to SAR 5 million under PDPL enforcement provisions.
Under Saudi Arabia's Personal Data Protection Law (PDPL), financial institutions face strict obligations around data residency and cross-border transfers that intersect with SAMA CSF and NCA ECC requirements.
Data Residency: PDPL Article 29 mandates that personal data collected within the Kingdom must generally be stored and processed on Saudi soil. SAMA CSF Control 3.3.5 reinforces this by requiring that critical financial data remain within SAMA-supervised infrastructure unless an explicit exception is granted.
Cross-Border Transfers: Any transfer of personal data outside Saudi Arabia requires one of the following conditions to be met:
- The transfer serves a legitimate public interest or is necessary to fulfill a contractual obligation
- The receiving country provides an adequate level of data protection as assessed by the Saudi Data & AI Authority (SDAIA)
- Explicit, informed consent is obtained from the data subject
- Binding contractual clauses or standard data protection agreements are in place with the recipient entity
Practical Steps for Compliance:
- Conduct a data mapping exercise to identify all personal data flows, including those to cloud providers and third-party processors
- Review vendor contracts to ensure Data Processing Agreements (DPAs) are in place per PDPL Article 32
- Implement technical controls such as data encryption in transit and at rest, and tokenization for sensitive financial identifiers
- Register cross-border transfer activities with SDAIA where required
- Align your data governance policy with NCA ECC Art. 2-1 controls on asset classification
Non-compliance can result in fines up to SAR 5 million, reputational damage, and regulatory sanctions from both SDAIA and SAMA. Institutions should conduct an annual PDPL gap assessment as part of their GRC program.
Saudi financial institutions handling customer personal data must comply with the Personal Data Protection Law (PDPL) issued under Royal Decree M/19 and its implementing regulations. Key obligations include: (1) Lawful Basis for Processing — you must establish a legitimate purpose before collecting data, such as contractual necessity or explicit consent; (2) Data Minimization — collect only what is strictly necessary for the defined purpose, avoiding excessive data retention; (3) Transparency & Notice — inform customers clearly about what data is collected, how it is used, retention periods, and their rights before or at the point of collection; (4) Data Subject Rights — honor requests for access, correction, and deletion within regulatory timelines, typically 30 days; (5) Cross-Border Transfers — transfers outside Saudi Arabia require SDAIA approval or must meet adequacy conditions, a critical control for banks using global cloud or SaaS providers; (6) Data Breach Notification — notify SDAIA and affected individuals without undue delay upon discovering a personal data breach; and (7) Data Protection Impact Assessments (DPIAs) — mandatory for high-risk processing activities, including profiling, credit scoring, or large-scale sensitive data processing. Practically, CISOs should map all personal data flows, maintain a Records of Processing Activities (RoPA) register, and embed privacy-by-design principles into product development and IT projects. Fintechs operating under SAMA's regulatory sandbox must simultaneously satisfy PDPL requirements alongside SAMA CSF's data protection controls (Domain 3), making integrated compliance planning essential rather than treating PDPL and SAMA CSF as separate workstreams.
Using customer personal data in AI/ML models for credit scoring or fraud detection creates significant obligations under Saudi Arabia's Personal Data Protection Law (PDPL) and its Executive Regulations. Here is what fintech compliance officers must address: 1. Lawful Basis for Processing: Under PDPL Article 7, processing personal data for credit scoring requires either explicit consent or a legitimate interest justification. Automated decision-making that significantly affects individuals (e.g., loan rejection) typically requires explicit consent and must be disclosed in the privacy notice. 2. Data Minimization & Purpose Limitation: PDPL Article 9 requires that only data strictly necessary for the stated purpose is collected. Fintechs must document which data fields feed their AI models and justify each one — regulators may scrutinize over-collection. 3. Automated Decision-Making Transparency: Customers have the right to be informed when a decision is made solely by automated means and to request human review. Your privacy notice must explicitly disclose AI-based decisioning per PDPL Article 13. 4. Data Retention: Model training datasets must comply with PDPL retention limits. Personal data should be anonymized or pseudonymized once it is no longer needed for its original purpose — retaining raw PII indefinitely for model retraining is non-compliant. 5. SAMA Intersection: SAMA's Open Banking Framework and consumer protection guidelines add requirements around consent management and data sharing with third-party AI vendors. Conduct a Data Protection Impact Assessment (DPIA) before deploying any new AI model that processes personal data at scale. 6. SDAIA Oversight: The Saudi Data & AI Authority (SDAIA) oversees PDPL enforcement; fintechs should align their AI governance policies with SDAIA's published guidelines on responsible AI.
Saudi Arabia's Personal Data Protection Law (PDPL), issued by Royal Decree M/19, establishes a distinct category of 'sensitive personal data' that attracts heightened regulatory obligations. Under Article 2 of the PDPL and further elaborated in the Implementing Regulations, sensitive personal data includes: genetic and biometric data, health and medical information, financial data revealing credit status, criminal records, ethnic or racial origin, religious beliefs, and political opinions.
For Saudi banks and fintechs, financial data — including credit scores, account details, and transaction histories — is explicitly classified as sensitive. This triggers the following additional obligations:
1. Explicit Consent: Processing sensitive data requires clear, specific, and informed consent (Article 5), which cannot be bundled with general terms and conditions.
2. Purpose Limitation: Data may only be used for the purpose explicitly stated at collection. Secondary use without fresh consent is prohibited.
3. Data Protection Impact Assessments (DPIAs): High-risk processing activities involving sensitive data require a formal DPIA before processing begins.
4. Cross-Border Transfer Restrictions: Transferring sensitive data outside Saudi Arabia requires SDAIA approval or must meet adequacy conditions under Article 29 of the PDPL.
5. Breach Notification: Data breaches involving sensitive personal data must be reported to SDAIA within 72 hours of discovery.
6. Retention Limits: Sensitive data must not be retained beyond the period necessary for the stated purpose, with secure deletion protocols in place.
Our platform maps PDPL obligations directly to your data processing activities, automates DPIA workflows, and provides breach notification templates — ensuring your institution meets PDPL requirements alongside SAMA CSF data protection controls.
The Saudi Personal Data Protection Law (PDPL) and its implementing regulations impose clear obligations on financial institutions regarding how long personal data may be retained and the manner in which it must be securely deleted once retention purposes are fulfilled. This is particularly complex for banks and fintechs that must simultaneously satisfy PDPL requirements alongside data retention mandates from SAMA, SOCPA, and FATF anti-money laundering guidelines.
Core PDPL Obligations: Under PDPL Article 18, personal data must not be retained beyond the period necessary to achieve the original processing purpose. Once that purpose expires, data must be anonymized or securely destroyed. Data subjects also hold the right to request deletion under PDPL Article 12, subject to legitimate exceptions.
Balancing Conflicting Retention Requirements: SAMA regulations and AML/CFT obligations typically mandate retention of customer transaction records and KYC data for a minimum of 10 years. Institutions must document the legal basis for extended retention in their data inventory and Records of Processing Activities (RoPA), clearly identifying which data is retained under a legal obligation versus consent.
Practical Implementation Steps:
- Conduct a comprehensive data mapping exercise to identify all personal data categories, storage locations, and current retention periods.
- Establish a Data Retention Schedule that maps each data category to its legal basis and maximum retention period.
- Implement automated deletion or anonymization workflows within core banking systems, CRMs, and data warehouses.
- Ensure third-party processors (cloud providers, analytics vendors) are contractually bound to equivalent deletion obligations per PDPL Article 29.
- Log all deletion activities for audit trail purposes.
- Review and update the retention schedule annually or when regulatory requirements change.
Appointing a Data Protection Officer (DPO) — or engaging a vCISO with PDPL expertise — is strongly recommended to oversee policy compliance.
Saudi Arabia's Personal Data Protection Law (PDPL), enforced by the National Data Management Office (NDMO), imposes significant obligations on fintech companies processing personal data of Saudi residents. Non-compliance can result in fines up to SAR 5 million and reputational damage.
Core PDPL Obligations for Fintechs:
- Lawful Basis for Processing: Under PDPL Article 5, you must establish a lawful basis before processing personal data. For fintechs, this is typically contractual necessity (onboarding, KYC) or explicit consent for marketing purposes.
- Privacy Notice: Article 11 requires a clear, plain-language privacy notice informing customers what data is collected, why, how long it's retained, and whether it's shared with third parties (e.g., credit bureaus, SAMA-regulated entities).
- Data Subject Rights: Articles 13–18 grant customers rights to access, correct, and request deletion of their data. Fintechs must establish workflows to respond within 30 days.
- Cross-Border Data Transfers: Article 29 restricts transferring personal data outside Saudi Arabia unless the destination country provides adequate protection or NDMO approval is obtained — critical for fintechs using global cloud providers.
- Data Breach Notification: Article 20 requires notifying NDMO of personal data breaches within 72 hours of discovery if the breach poses risk to data subjects.
Practical Compliance Steps:
- Appoint a Data Protection Officer (DPO) or assign DPO responsibilities to your compliance function.
- Conduct a Data Mapping exercise to inventory all personal data flows across your platform.
- Implement Privacy by Design principles in product development cycles.
- Review all third-party data processing agreements (DPAs) to ensure PDPL-compliant clauses.
- Align your PDPL program with ISO 27701 for a structured privacy management framework recognized by regulators.
Data classification is a foundational control required under both the Saudi Personal Data Protection Law (PDPL) and SAMA CSF, and getting it right is critical for Saudi banks and fintechs managing vast volumes of customer financial and personal data.
SAMA CSF Requirements (Control Domain 3.6 — Data and Information Asset Management):
- Establish a formal data classification policy with defined sensitivity tiers (e.g., Public, Internal, Confidential, Restricted).
- Assign data ownership accountability to specific business units.
- Implement controls proportional to classification level: encryption, access restrictions, masking, and data loss prevention (DLP) tools.
- Per SAMA CSF Control 3.6.3, financial institutions must maintain a data inventory mapping sensitive data to systems, storage locations, and processing flows.
PDPL Obligations (Articles 5, 9, and 21):
- Personal data must only be collected and processed for a declared, legitimate purpose.
- Sensitive personal data (health, financial, biometric) requires heightened protection and explicit consent or a lawful basis.
- Data must not be retained longer than necessary — institutions must define and enforce data retention schedules.
- Cross-border transfers of personal data require PDPL-compliant safeguards, especially relevant for cloud-hosted platforms.
Practical Implementation Steps:
- Conduct a data discovery and inventory exercise across all systems and cloud environments.
- Apply classification labels using automated tools where possible (e.g., Microsoft Purview).
- Enforce encryption at rest (AES-256) and in transit (TLS 1.2+) for Confidential and Restricted data.
- Implement role-based access control (RBAC) aligned to data classification tiers.
- Document your data processing activities register (DPAR) to satisfy both PDPL audit requirements and SAMA examiner expectations.
Integrating PDPL and SAMA CSF data governance into a unified framework reduces duplication and creates a stronger, audit-ready data protection posture.
Saudi financial institutions must navigate overlapping data governance obligations from both the Personal Data Protection Law (PDPL) and SAMA CSF, making a unified data classification framework essential.
Data Classification Framework:
SAMA CSF Control 3.1.4 requires member organizations to implement a formal data classification policy. Recommended tiers for financial institutions include:
- Confidential/Restricted: Customer PII, financial transaction records, credit data, authentication credentials.
- Internal: Internal policies, employee records, operational procedures.
- Public: Marketing materials, published annual reports.
PDPL Obligations (Articles 5–9): Personal data — defined as any information that directly or indirectly identifies a natural person — must be:
- Collected for a specific, declared purpose.
- Processed only to the extent necessary (data minimization).
- Retained no longer than required for the stated purpose, with documented retention schedules.
- Protected using technical and organizational measures proportionate to the risk.
Practical Implementation Steps:
- Conduct a Data Discovery and Mapping exercise to identify all personal and sensitive financial data across systems (core banking, CRM, data lakes).
- Implement data classification labels (manual or automated via Microsoft Purview or similar tools).
- Define Data Retention and Destruction Schedules aligned with SAMA CSF and PDPL requirements.
- Establish a Data Governance Committee with a designated Data Protection Officer (DPO) or equivalent role.
- Integrate classification outputs into your DLP (Data Loss Prevention) policies and SIEM alert rules.
Note that PDPL violations can attract fines up to SAR 5 million, with potential criminal liability for intentional breaches — making proactive data governance a business-critical priority.
Data classification is the foundational pillar that bridges your SAMA CSF compliance obligations and your PDPL data protection duties. SAMA CSF Domain 3.2 (Information Asset Management) requires all member organizations to establish a formal data classification policy with at least three tiers: Public, Confidential, and Restricted — though most banks adopt a four-tier model adding 'Internal Use' for greater granularity.
For PDPL alignment, your classification framework must specifically tag datasets containing personal data as defined under PDPL Article 2, and flag special-category data (health, financial, biometric) for enhanced controls.
Recommended Classification-to-Control Mapping:
- Restricted / Special-Category Personal Data: End-to-end encryption at rest (AES-256) and in transit (TLS 1.3+), strict need-to-know access, mandatory audit logging, Data Loss Prevention (DLP) rules, and explicit consent documentation per PDPL Article 5.
- Confidential / Personal Data: Role-based access controls, encryption, retention schedules aligned with PDPL Article 18 (data must not be kept beyond its purpose), and annual data inventory reviews.
- Internal / Non-Personal: Standard access controls and basic monitoring.
Practical Steps:
- Conduct a comprehensive data discovery and inventory exercise — automated tools like Varonis or Microsoft Purview can accelerate this.
- Embed classification labels into document management systems and email platforms.
- Map data flows across third parties per SAMA CSF Control 3.2.3 and PDPL's data processor obligations.
- Define retention and disposal schedules and enforce them technically, not just procedurally.
The Saudi Data & AI Authority (SDAIA) and SAMA both expect documented, enforced classification schemes — not just policy documents.
Data Loss Prevention (DLP) sits at the intersection of cybersecurity and privacy compliance, making it doubly important for Saudi financial institutions that must satisfy both SAMA CSF and the Personal Data Protection Law (PDPL). Here is how to approach DLP implementation practically:
Understanding Your Regulatory Obligations SAMA CSF Control 3.2 requires data classification and protection controls proportionate to data sensitivity. PDPL Articles 5, 9, and 14 mandate that personal data be processed lawfully, protected from unauthorized access, and not transferred outside Saudi Arabia without meeting the cross-border transfer conditions.
Step 1 – Data Discovery & Classification Begin with a comprehensive data inventory. Classify all data assets into tiers — public, internal, confidential, and restricted (e.g., customer PII, payment card data, credit records). This classification drives your DLP policy configuration.
Step 2 – DLP Policy Design Configure DLP rules across three key channels: endpoint (laptops, USB), network (email, web uploads), and cloud (SaaS applications like M365, Google Workspace). Policies must block or alert on unauthorized transmission of PII, financial records, or confidential business data.
Step 3 – Integration with IAM & SIEM DLP tools must be integrated with your Identity and Access Management system to apply context-aware policies (e.g., stricter rules for contractors vs. full-time employees) and with your SIEM for real-time incident correlation.
Step 4 – PDPL-Specific Considerations Under PDPL, any DLP alert involving personal data leakage must trigger your privacy incident workflow, with potential notification obligations to the Saudi Data and Artificial Intelligence Authority (SDAIA) and affected individuals.
Step 5 – Ongoing Tuning & Reporting DLP effectiveness must be measured and reported to the CISO quarterly. Tune policies regularly to reduce false positives while maintaining high detection accuracy. Annual DLP audits aligned with ISO 27001 Annex A.8 controls are strongly recommended.
PDPL penalties include: fines up to SAR 5 million for violations of data subject rights or inadequate security controls; fines up to SAR 10 million for unauthorized cross-border data transfer; fines up to SAR 3 million for failure to notify of breaches. Repeat violations can result in doubled fines. Criminal prosecution may apply in cases of deliberate misuse.
Yes. PDPL applies to any entity that processes personal data of individuals residing in Saudi Arabia, regardless of whether the entity is based inside or outside the Kingdom. Foreign companies targeting Saudi consumers or processing data of Saudi residents must comply with PDPL requirements.
Cross-border data transfers are one of the most operationally complex requirements under Saudi Arabia's Personal Data Protection Law (PDPL) and its Implementing Regulations, particularly for fintechs that rely on global cloud providers, payment processors, or overseas analytics platforms.
Legal Basis for Transfer (PDPL Article 29): Transferring personal data outside the Kingdom is prohibited unless one of the following conditions is satisfied:
- The transfer is necessary to fulfill a contractual obligation with the data subject
- The transfer serves a vital interest of the data subject
- The destination country provides an adequate level of data protection as determined by the Saudi Data & AI Authority (SDAIA)
- A binding agreement exists that ensures equivalent protection standards
- Explicit consent has been obtained from the data subject
Practical Controls for Fintechs:
- Data Mapping & Flow Inventory: Document all data flows that cross borders — including API calls to foreign services, backup replication to non-Saudi cloud regions, and third-party analytics tools.
- Transfer Impact Assessment (TIA): Before initiating any cross-border transfer, conduct a TIA to assess the legal framework and security posture of the destination jurisdiction.
- Contractual Safeguards: Implement Data Processing Agreements (DPAs) with international vendors containing clauses that mirror PDPL protections, including breach notification, sub-processor controls, and data deletion rights.
- Localization Strategy: For sensitive financial data categories, consider data residency in Saudi-based cloud regions (e.g., AWS, Azure, or Google Cloud regions in KSA) to minimize transfer exposure.
- Consent Management: Build granular consent mechanisms in your customer onboarding flows for any data that may be processed abroad.
SDIA continues to publish guidance on adequacy decisions, so fintechs should monitor regulatory updates closely and integrate PDPL transfer compliance into their broader ISO 27001 and SAMA CSF programs.
Saudi PDPL (Royal Decree M/19, enforced July 2023) creates important obligations specifically around employee data processing — an area where HR, Legal, and Cybersecurity teams must align closely. Legal bases for processing employee personal data under PDPL include: (1) Contractual necessity — processing required to fulfill the employment contract (payroll, benefits, legal compliance); (2) Legal obligation — processing required by Saudi labor law, GOSI, HRDF, or regulatory reporting mandates; (3) Legitimate interest — security monitoring, fraud prevention, and business continuity activities, provided they are proportionate and documented; (4) Explicit consent — required for any processing that goes beyond contractual or legal necessity, particularly for sensitive categories such as biometrics, health data, or financial details beyond compensation. Key practical implications for Security Teams: Employee monitoring programs (endpoint DLP, email monitoring, access logs, CCTV in workplaces) must be disclosed in a transparent privacy notice and must have a documented legal basis. Covert surveillance without a legal basis is a PDPL violation. All employee data transfers outside KSA — including to global HR platforms, cloud tools, or parent company systems — require either an adequacy decision or appropriate safeguards per PDPL transfer rules. For HR teams: Update employment contracts and onboarding documentation to include PDPL-compliant privacy notices. Define and document your data retention schedules for ex-employee records. Employees have the right to access and correct their personal data. Align your HR data governance with ISO 27001 Annex A.6 (Human Resource Security) for a unified compliance posture. PDPL enforcement is overseen by SDAIA — fines reach SAR 5 million for violations.
The Saudi Personal Data Protection Law (PDPL) and its implementing regulations introduce meaningful obligations for fintech companies that deploy AI-driven or automated decision-making systems — such as credit scoring engines, fraud detection models, customer onboarding bots, or behavioral analytics platforms.
Key PDPL Obligations for Automated Processing:
1. Lawful Basis for Processing: Per PDPL Article 8, processing personal data through automated systems requires a valid legal basis — typically contractual necessity, legitimate interest, or explicit consent. For sensitive financial data, consent must be explicit and documented.
2. Transparency & Disclosure: PDPL Article 11 mandates that individuals be informed about the existence of automated decision-making processes that significantly affect them, the logic involved, and the potential consequences. Your privacy notice must clearly describe AI-driven decision systems.
3. Right to Object & Human Review: Individuals have the right to request human review of decisions made solely by automated systems, particularly when such decisions produce legal or similarly significant effects (e.g., loan denial, account suspension). Fintechs must establish a process to handle such requests within the regulatory timeframe.
4. Data Minimization: Only the personal data strictly necessary for the AI model's purpose should be processed. Avoid feeding models with unnecessary sensitive attributes — a principle directly aligned with PDPL Article 14.
5. Data Retention & Deletion: Define and enforce clear retention periods for data used in AI training and inference. Data should not be retained beyond its stated purpose per PDPL Article 18.
6. DPIA Requirement: High-risk processing activities — including large-scale AI profiling of customers — require a Data Protection Impact Assessment (DPIA) before deployment. Document risks and mitigations thoroughly.
Intersection with SAMA CSF: SAMA's customer data protection controls (Domain 3.5) complement PDPL requirements and expect financial institutions to implement technical safeguards around automated processing systems including access controls, audit logs, and explainability mechanisms.
Fintechs should engage their Data Protection Officer (DPO) early in AI product design cycles to ensure privacy-by-design principles are embedded from the outset.
Saudi Arabia's Personal Data Protection Law (PDPL), enforced by the Saudi Data & AI Authority (SDAIA), places direct obligations on fintech companies to implement a structured data classification and protection framework. Non-compliance can result in fines of up to SAR 5 million for first offenses, with doubling for repeat violations.
Step 1 – Data Discovery and Classification: Conduct a thorough data inventory mapping all personal data your platform collects, processes, or stores. Under PDPL Article 6, data must be classified at minimum into: General Personal Data, Sensitive Personal Data (including financial data, health records, biometric data, and national ID numbers), and data of minors.
Step 2 – Lawful Basis Determination: For each data category, establish and document the lawful processing basis per PDPL Article 5 — consent, contractual necessity, legal obligation, or legitimate interest (the latter must be balanced against data subject rights).
Step 3 – Technical and Organizational Controls:
- Encrypt sensitive personal data at rest and in transit (AES-256 and TLS 1.2+ as baseline).
- Implement role-based access controls (RBAC) with least-privilege principles.
- Maintain detailed processing records (PDPL Article 12 requires Record of Processing Activities — ROPA).
- Establish data retention and deletion schedules aligned to PDPL Article 18.
Step 4 – Breach Notification: PDPL Article 19 requires notifying SDAIA within 72 hours of discovering a personal data breach that poses risk to data subjects.
Intersection with SAMA CSF: For licensed fintechs, SAMA CSF Control 3.3.9 (Data and Information Protection) aligns closely with PDPL — a unified data protection policy satisfies both regulators simultaneously.
Saudi Arabia's Personal Data Protection Law (PDPL), enforced by the National Data Management Office (NDMO), establishes clear obligations around data minimization and retention — principles that fintech companies must embed into both their technical architecture and operational processes.
Under PDPL Article 8, personal data must be collected only to the extent necessary for the declared purpose. Fintechs must avoid over-collection and ensure that data fields captured during onboarding, transactions, or KYC processes are strictly justified by a legitimate business or regulatory need. This requires conducting a Data Protection Impact Assessment (DPIA) for high-risk processing activities before deployment.
For retention, PDPL Article 14 requires that personal data not be retained beyond the period necessary to fulfill the processing purpose. In the fintech context, this intersects with SAMA's AML/CFT retention requirements (typically 10 years for transaction records), creating a layered compliance obligation. CISOs and compliance officers must map retention schedules per data category and align them with both PDPL and applicable financial regulations.
Practical implementation steps include:
- Building a data inventory and classification framework identifying all personal data assets
- Configuring automated data lifecycle policies in storage systems to trigger deletion or anonymization upon retention expiry
- Reviewing API integrations and third-party data processors to ensure downstream data handling aligns with minimization principles
- Documenting lawful retention justifications for each data category in your Record of Processing Activities (RoPA)
- Establishing a periodic review cycle — at least annually — to reassess whether retained data remains necessary
Non-compliance can result in fines up to SAR 5 million under PDPL, making proactive governance essential for Saudi fintechs.
The Saudi Personal Data Protection Law (PDPL) and its implementing regulations impose specific obligations on fintechs deploying AI systems or automated decision-making (ADM) tools that process personal data — an area of rapidly growing regulatory scrutiny.
Lawful Basis for AI Processing: Under PDPL Article 7, any AI system processing personal data must have a clearly identified lawful basis — typically contractual necessity or explicit consent. For credit scoring, fraud detection, or behavioral profiling, consent must be granular, informed, and revocable.
Transparency Requirements: PDPL Article 11 requires that individuals be informed when automated decisions are being made about them, the logic involved, and the potential consequences. Fintechs must provide clear, plain-language disclosures in their privacy notices — not buried in terms and conditions.
Right to Contest Automated Decisions: While Saudi PDPL is still maturing in this area, SDAIA's implementing regulations signal alignment with international standards giving data subjects the right to request human review of decisions made solely by automated means — particularly for loan approvals, account restrictions, or KYC rejections.
Data Minimization & Purpose Limitation: PDPL Articles 9 and 14 prohibit processing more data than necessary or using it for purposes beyond what was disclosed. AI models trained on customer behavioral data must be scoped and governed to prevent purpose creep.
Data Protection Impact Assessment (DPIA): High-risk AI processing — such as biometric data, financial profiling, or large-scale behavioral analysis — requires a DPIA before deployment. This must include risk assessment, mitigation controls, and documentation retained for regulatory review.
SAMA Intersection: SAMA's Open Banking Framework and Consumer Protection Principles further require fintechs to ensure algorithmic fairness and non-discrimination in financial product recommendations.
Our platform provides PDPL-aligned DPIA templates and AI governance checklists tailored for Saudi fintech environments.
Saudi fintechs operating mobile applications that collect and process customer financial data carry significant obligations under the Personal Data Protection Law (PDPL) and its Executive Regulations, enforced by the Saudi Data & AI Authority (SDAIA).
Lawful Basis and Consent (PDPL Article 5–7): Processing personal financial data requires a clear lawful basis — typically explicit, informed consent or contractual necessity. Consent must be granular: users should separately consent to data collection, processing, profiling, and marketing. Pre-ticked boxes or bundled consent clauses are non-compliant.
Transparency and Privacy Notices (PDPL Article 11): Mobile apps must display a clear, accessible Arabic-language privacy notice disclosing: categories of data collected, processing purposes, retention periods, third-party sharing, and user rights. The notice must be presented before or at the point of data collection.
Data Subject Rights (PDPL Article 14–18): Fintechs must operationalize user rights within the app or via a designated channel: the right to access, correct, delete (right to erasure subject to regulatory retention requirements), and withdraw consent. Response timelines must not exceed 30 days per PDPL Executive Regulations.
Data Minimization and Retention: Only data strictly necessary for the stated purpose should be collected. Financial transaction data may have mandatory retention periods under SAMA regulations (typically 10 years), which can override the PDPL erasure right — fintechs must document this conflict resolution in their Records of Processing Activities (RoPA).
Security Controls: PDPL Article 19 requires appropriate technical and organizational safeguards. For financial apps, this includes end-to-end encryption, certificate pinning, secure API authentication (OAuth 2.0/FAPI), and regular DAST/SAST testing of the mobile codebase.
Fintechs should appoint a Data Protection Officer (DPO) if processing is large-scale or involves sensitive financial profiles, and register processing activities with SDAIA as required.
The Saudi Personal Data Protection Law (PDPL), enforced by the Saudi Data and Artificial Intelligence Authority (SDAIA), imposes clear obligations on organizations when a personal data breach occurs. This is especially critical for banks and fintechs that process large volumes of sensitive financial and personal data.
Notification Obligations Under PDPL: Article 23 of the PDPL requires that organizations notify SDAIA of any personal data breach that could result in harm to data subjects. The notification must be submitted without undue delay — in practice, regulators expect notification within 72 hours of becoming aware, aligning with international best practices.
If the breach poses a high risk to individuals (e.g., exposure of financial account numbers, national ID data, or biometrics), data subjects must also be individually notified with clear information about the nature of the breach and protective steps they can take.
DPO Responsibilities Upon Breach:
- Contain: Immediately isolate affected systems and revoke compromised credentials.
- Assess: Determine the scope — which data categories, how many individuals, and what risk level.
- Document: Record the breach in the internal data breach register with timeline, cause, and impact details.
- Notify SDAIA: Submit a formal breach notification via the SDAIA portal including: nature of breach, categories/volume of data, likely consequences, and remediation measures taken.
- Notify Subjects: Where required, issue clear communications — avoid vague language that may increase legal exposure.
- Coordinate with SAMA: For financial institutions, simultaneously notify SAMA per CSF Control 3.4.2 (Cybersecurity Incident Management), as dual regulatory reporting is mandatory.
- Post-Incident Review: Conduct a root cause analysis within 30 days and update DPIAs and security controls accordingly.
Failure to comply with PDPL breach notification obligations can result in fines up to SAR 5 million, with repeated violations attracting doubled penalties.
Using AI for credit scoring in Saudi Arabia creates a complex intersection of PDPL obligations, SAMA CSF data governance requirements, and emerging AI ethics considerations. Here is what fintech compliance teams must address: (1) Legal Basis for Processing — Under PDPL Article 5, processing personal financial data for credit scoring must rest on a valid legal basis, typically contractual necessity or legitimate interest. Where sensitive inferences are drawn (e.g., financial vulnerability), explicit consent may be required. (2) Transparency and Notification — PDPL Articles 11-12 require individuals to be informed about automated decision-making processes affecting them, including credit decisions. Privacy notices must explicitly disclose AI-based scoring and the data inputs used. (3) Data Minimization — Only data directly relevant to creditworthiness assessment should be collected and processed. Behavioral or social data inputs must be legally justified and proportionate per PDPL principles. (4) Right to Explanation — While PDPL does not yet mandate a full 'right to explanation' equivalent to GDPR Article 22, SAMA CSF Control 3.3.7 on data governance expects institutions to maintain explainability of automated decisions affecting customers. (5) Retention Limits — Financial data used in scoring models must be retained only for the period necessary, with documented retention schedules reviewed annually. (6) Cross-Border Transfers — If AI models are trained or hosted outside Saudi Arabia, PDPL Article 29 transfer controls apply. Ensure adequate protection measures are contractually enforced with overseas processors. Engage your Data Protection Officer early in AI model design to embed privacy-by-design principles from inception.
Saudi fintech companies operate at the intersection of two major regulatory regimes — the Personal Data Protection Law (PDPL) and SAMA CSF — each with distinct but complementary breach response obligations. Building a unified response plan is both a compliance necessity and an operational best practice.
PDPL Obligations (SDAIA Oversight): Under PDPL Article 24, data controllers must notify the Saudi Data and Artificial Intelligence Authority (SDAIA) of any personal data breach that harms or is likely to harm data subjects, within a timeframe specified by the Implementing Regulations (currently expected within 72 hours of discovery for high-risk breaches). Affected individuals must also be notified when there is a direct risk to their rights or interests.
SAMA CSF Obligations: SAMA CSF Control 3.5.4 requires documented incident response procedures, including breach detection, containment, eradication, recovery, and post-incident review. Incidents impacting customer data or system availability must be reported to SAMA within defined timeframes — critical incidents typically within 24 hours.
Building a Unified Response Plan:
- Classify breach severity upfront: Define thresholds for when PDPL notification, SAMA reporting, and customer communication are triggered.
- Establish a response team: Include Legal, DPO, CISO, Operations, and Communications roles with clear RACI assignments.
- Maintain evidence logs: Preserve forensic evidence, access logs, and communication records throughout the incident lifecycle.
- Test regularly: Conduct tabletop exercises at least twice yearly simulating data breach scenarios.
- Coordinate notifications: Use pre-approved notification templates for SDAIA, SAMA, and affected customers to avoid delays under pressure.
A synchronized response plan not only ensures regulatory compliance but significantly reduces financial and reputational exposure in the event of a breach.
Saudi fintech companies face a dual compliance obligation when a data breach occurs: satisfying the Personal Data Protection Law (PDPL) administered by the Saudi Data and AI Authority (SDAIA), and meeting SAMA CSF incident reporting requirements. Aligning both is critical to avoid regulatory penalties and reputational damage.
PDPL Obligations (Articles 25–27): Upon discovering a personal data breach, organizations must notify SDAIA without undue delay — interpretive guidance suggests within 72 hours of awareness — if the breach poses a risk to data subjects' rights. If high risk is confirmed, affected individuals must also be notified with clear, plain-language communication describing the nature of the breach, data categories impacted, and steps taken.
SAMA CSF Obligations (Control 3.6 — Cyber Security Incident Management): SAMA requires financial institutions to report cybersecurity incidents to SAMA within specific timeframes based on severity. Critical incidents must be reported immediately (within 2 hours of detection), with a full post-incident report due within 72 hours. Fintechs must maintain an incident log and evidence chain throughout.
Practical Alignment Steps:
- Build a unified Incident Response Plan (IRP) that maps PDPL and SAMA notification triggers to the same detection-to-report workflow.
- Establish a data breach triage process that simultaneously evaluates personal data exposure (PDPL) and operational/financial system impact (SAMA).
- Designate a Data Protection Officer (DPO) and CISO with clear ownership over regulatory notifications.
- Conduct tabletop exercises simulating breach scenarios covering both regulators.
- Maintain pre-approved notification templates for SDAIA, SAMA, and affected customers to accelerate response times.
Proactive alignment reduces the risk of conflicting timelines and ensures regulatory trust is maintained across both frameworks.
Saudi Arabia's Personal Data Protection Law (PDPL), enforced by the Saudi Data & AI Authority (SDAIA), grants data subjects a defined set of rights that financial institutions must operationalize — not just acknowledge. Failure to establish response mechanisms is a direct compliance gap.
Core Data Subject Rights under PDPL:
- Right to Access (Article 10): Individuals can request access to their personal data held by the institution, including the purposes of processing. Banks must respond within a reasonable timeframe (SDAIA guidelines suggest 30 days).
- Right to Correction (Article 11): Data subjects can request correction of inaccurate or incomplete data.
- Right to Erasure (Article 12): Individuals may request deletion of their data when it is no longer needed for its original purpose — subject to legal retention obligations under SAMA and AML regulations, which may override this right.
- Right to Withdraw Consent (Article 7): Where processing is consent-based, withdrawal must be as easy as granting consent.
- Right to Object to Automated Decisions: Data subjects can contest decisions made solely through automated processing that affect them significantly.
Operationalization for Banks:
- Establish a Data Subject Request (DSR) portal or formal intake process accessible to customers and employees.
- Define an internal SLA of 20 business days to allow buffer before regulatory deadlines.
- Map all personal data repositories so requests can be fulfilled accurately across core banking, CRM, and marketing systems.
- Document legal retention obligations (e.g., SAMA requires transaction records for minimum 10 years) that may lawfully restrict erasure requests.
- Train customer-facing staff and the DPO on response procedures.
- Log all DSR activities for audit purposes — SDAIA may request evidence of compliance during inspections.
Saudi Arabia's Personal Data Protection Law (PDPL), enforced by the National Data Governance Authority (NDGA), establishes clear obligations for data breach notification. Under PDPL Article 24 and its Implementing Regulations, organizations — including fintechs — must notify the competent authority (NDGA) without undue delay upon discovering a breach that affects personal data confidentiality, integrity, or availability. The notification must include: the nature of the breach, categories and approximate number of data subjects affected, likely consequences, and measures taken or proposed. If the breach poses a high risk to data subjects, individuals must also be notified directly and promptly. Practical Steps for Fintechs: (1) Detect and Contain: Activate the incident response plan immediately. Isolate affected systems and preserve forensic evidence. (2) Internal Escalation: Notify the DPO and CISO within hours. Engage legal counsel to assess notification obligations under PDPL and, where applicable, SAMA CSF incident reporting timelines (SAMA requires notification within 72 hours for significant cyber incidents). (3) NDGA Notification: File a formal breach notification with NDGA, ensuring completeness and accuracy. Document the timeline of discovery, assessment, and notification. (4) Affected Individuals: Assess whether the breach creates high risk for data subjects (e.g., exposure of financial or identity data) and send clear, plain-language notifications if required. (5) Post-Breach Review: Conduct a root cause analysis, update controls, and document lessons learned. PDPL violations can result in fines of up to SAR 5 million, with aggravated penalties for repeated offences. Maintaining a breach response runbook aligned to both PDPL and SAMA requirements is strongly recommended.
Saudi Arabia's Personal Data Protection Law (PDPL), enforced by the National Data Management Office (NDMO), has direct implications for how banks and fintechs deploy cookies and tracking technologies on their digital platforms. While the PDPL does not use the word 'cookies' explicitly, Articles 4, 5, and 6 govern the lawful collection of personal data, which cookies often constitute when they capture identifiers, behavioral data, or device fingerprints.
Consent Requirements: Under PDPL Article 5, consent must be explicit, informed, and freely given before deploying non-essential cookies (analytics, advertising, behavioral tracking). Consent banners must clearly distinguish between essential cookies (exempt) and non-essential categories. Pre-ticked boxes or implied consent do not satisfy PDPL requirements.
Purpose Limitation: Data collected via cookies may only be used for the specific purpose disclosed at collection time (PDPL Article 7). Using session data for unrelated profiling or selling behavioral data to third-party ad networks would constitute a violation.
Cross-Border Transfers: If your analytics tools (e.g., Google Analytics, Adobe Analytics) transmit cookie data to servers outside Saudi Arabia, this triggers PDPL Article 29 cross-border transfer restrictions. You must ensure adequate data protection safeguards or obtain NDMO approval.
Retention Policies: Cookie data must not be retained beyond its stated purpose. Implement automated purging schedules and document data retention periods in your Records of Processing Activities (RoPA).
Practical Steps: Conduct a cookie audit of all your web and mobile properties, categorize each cookie, update your privacy notice to reflect PDPL-compliant disclosures, and implement a Consent Management Platform (CMP) that logs consent with timestamps for audit evidence.
Cross-border personal data transfers are among the most legally sensitive compliance areas for Saudi financial institutions under the Personal Data Protection Law (PDPL). Articles 29–30 of the PDPL and the implementing regulations set strict conditions for transferring personal data outside the Kingdom. Legal Bases for Transfer: (1) Adequacy Determination — Transfers are permitted to countries deemed by the Saudi Data & AI Authority (SDAIA) to provide an adequate level of data protection, comparable to the PDPL's standards. (2) Contractual Safeguards — Where adequacy is not established, institutions must execute SDAIA-approved standard contractual clauses (SCCs) with the receiving entity, ensuring equivalent protections are maintained abroad. (3) Explicit Consent — In the absence of adequacy or SCCs, explicit, informed consent from the data subject must be obtained specifically for the international transfer, with clear disclosure of the destination country and risks involved. (4) Vital Interests or Legal Obligations — Transfers may occur without consent if necessary to protect the individual's vital interests or to fulfil a legal obligation. Financial Sector Specifics: Banks and fintechs using international cloud providers, payment processors, or correspondent banking partners must map all cross-border data flows, maintain a Transfer Impact Assessment (TIA), and ensure contractual provisions are audited annually. SAMA CSF Control 3.3.7 also requires that data classification drives decisions on permissible cross-border transfers. Penalties: Non-compliant transfers can attract fines up to SAR 5 million under PDPL. Institutions should establish a Data Transfer Governance Committee with legal, compliance, and IT security representation to review and approve all outbound data flows quarterly.
The Saudi Personal Data Protection Law (PDPL), enforced by the National Data Management Office (NDMO), applies to all personal data processing activities — including employee data — conducted by Saudi-based financial institutions. This is an often-overlooked compliance gap in HR departments.
Key PDPL Obligations for Employee Data:
- Lawful Processing Basis: Under PDPL Article 8, processing employee data is permissible when necessary to fulfill employment contract obligations or comply with legal requirements. Reliance on consent alone is problematic in employment contexts due to the inherent power imbalance.
- Data Minimization: Institutions must collect only the minimum employee data necessary for the employment relationship. Excessive collection of biometric, health, or financial data without a clear purpose violates PDPL Article 5.
- Employee Rights Notification: Per PDPL Articles 4 and 14, employees must be formally notified of what data is collected, how it is used, how long it is retained, and their rights to access or correct their data. This is typically delivered via an internal Employee Privacy Notice.
- Retention Schedules: HR departments must define documented data retention periods. Employee records may be retained for the duration of employment plus a legally defensible period (commonly 5–7 years) aligned to Saudi Labor Law requirements.
- Cross-Border Transfers: If employee data is processed by overseas HR systems or payroll providers, PDPL Article 29 requires that the recipient country provide an adequate level of data protection or that appropriate contractual safeguards are in place.
- Data Breach Obligations: Employee data breaches must be reported to NDMO within 72 hours if they pose a risk of harm.
Institutions should conduct an HR-specific Data Protection Impact Assessment (DPIA) and update their internal HR policies to reflect PDPL requirements as a priority compliance action.
Cross-border data transfer is one of the most operationally complex obligations under Saudi Arabia's Personal Data Protection Law (PDPL), particularly for financial institutions that rely on global cloud providers, correspondent banking relationships, or international outsourcing arrangements.
Legal Basis Under PDPL Article 29 of the PDPL governs international data transfers. A transfer is only permitted when one or more of the following conditions are met:
- The destination country provides an adequate level of protection comparable to Saudi Arabia's standards (assessed by SDAIA).
- A contractual agreement exists ensuring equivalent protections are enforced.
- The transfer is necessary to execute a contract with the data subject (e.g., international payment processing).
- Explicit consent has been obtained from the data subject — noting this is the weakest legal basis and should not be relied upon as a primary mechanism.
SAMA-Specific Considerations SAMA CSF Control 3.3.5 and its Cloud Computing Guidelines add a financial-sector overlay: customer financial data classified as sensitive must not leave Saudi jurisdiction without SAMA's prior approval, regardless of PDPL permissions. This effectively creates a stricter dual-compliance requirement.
Practical Compliance Steps
- Map all data flows that cross Saudi borders — including subprocessors and cloud infrastructure regions.
- Classify data by sensitivity (PDPL personal data vs. SAMA-regulated financial data).
- Execute Data Transfer Agreements (DTAs) with vendors handling personal data abroad.
- Obtain SAMA no-objection for financial data transfers.
- Document transfer impact assessments and retain records for SDAIA and SAMA audit readiness.
Failure to comply exposes institutions to PDPL penalties of up to SAR 5 million and potential SAMA supervisory action.
Saudi Arabia's Personal Data Protection Law (PDPL), enforced by the Saudi Data & AI Authority (SDAIA), grants data subjects a set of enforceable rights that fintechs must operationalize systematically. Under PDPL Articles 4–7, individuals have the right to access, correct, and request deletion of their personal data, and organizations must respond within defined timeframes.
Operationalizing DSAR Handling:
1. Establish a DSAR Intake Process: Create a dedicated, accessible channel (web form, email, in-app) for receiving requests. Clearly communicate this in your privacy notice as required by PDPL Article 11.
2. Verify Identity Before Disclosure: Before processing any DSAR, verify the requester's identity using at least two factors to prevent unauthorized data disclosure. This step is critical for financial data held by fintechs.
3. Response Timelines: PDPL regulations require responses within 30 days of receiving a valid request. If the request is complex or high-volume, a 30-day extension may apply, but the requester must be notified within the initial period.
4. Scope of Disclosure: Provide data in a structured, commonly used format. For fintechs, this includes transaction records, KYC data, and behavioral profiling data — but must exclude data that could compromise third-party rights or regulatory confidentiality obligations.
5. Deletion vs. Retention Obligations: PDPL allows data subjects to request deletion, but SAMA CSF and FATF AML obligations may require you to retain certain financial records for up to 10 years. Document these conflicts in your Records Retention Policy.
6. SDAIA Complaint Risk: Failure to respond appropriately can result in SDAIA complaints and administrative penalties. Maintain an audit log of all DSARs and their outcomes for regulatory review.
Saudi Arabia's Personal Data Protection Law (PDPL), enforced by the National Data Management Office (NDMO) and the Saudi Data and AI Authority (SDAIA), grants data subjects several enforceable rights that financial institutions must operationalize through formal procedures.
Under PDPL Articles 4–8, individuals have the right to access, correct, and request deletion of their personal data. For banks and fintechs, this creates specific obligations:
Response Timelines:
- Access and correction requests must be fulfilled within 30 days of receipt.
- If complexity warrants an extension, the institution must notify the requester within the original 30-day window and may extend by a further 30 days, with written justification.
Practical Compliance Steps:
- Request Intake Process: Establish a dedicated, secure channel (portal or email) for receiving DSARs with identity verification mechanisms to prevent unauthorized disclosure.
- Data Mapping Prerequisite: Maintain an updated Record of Processing Activities (RoPA) — this is foundational, as you cannot fulfill access requests without knowing where personal data resides.
- Financial Sector Exceptions: PDPL allows withholding data where disclosure would conflict with AML/CFT obligations (per SAMA's AML rules), legal hold requirements, or national security interests.
- Audit Trail: Log all DSARs, responses, extensions, and any denied requests with documented justifications — SDAIA auditors may request these records.
- Integration with ISO 27001: Align DSAR procedures with your Information Security Management System's access control and asset management controls.
Failure to comply may result in fines of up to SAR 5 million under PDPL enforcement provisions. Our platform provides automated DSAR workflow management with deadline tracking and audit logging.
Saudi Arabia's Personal Data Protection Law (PDPL), enforced by the National Data Management Office (NDMO), imposes significant obligations on fintechs processing personal financial data — which qualifies as sensitive personal data under PDPL Article 23 due to its financial nature.
Key PDPL Obligations for Fintechs:
- Lawful Basis for Processing (Article 8): Financial data processing must be based on explicit consent, contractual necessity, or a legitimate interest that does not override individual rights. Passive consent mechanisms are insufficient.
- Data Minimization & Purpose Limitation (Article 9): Collect only data strictly necessary for the declared service purpose. Repurposing transaction data for marketing analytics requires fresh, specific consent.
- Data Subject Rights (Articles 13–17): Customers have rights to access, correction, and erasure. Fintechs must respond within 30 days and maintain documented request-handling procedures.
- Cross-Border Data Transfers (Article 29): Transferring financial data outside Saudi Arabia requires NDMO approval or adequate protection guarantees — critical for fintechs using international cloud providers or payment processors.
- Data Breach Notification (Article 24): Notify NDMO within 72 hours of discovering a breach affecting personal data, and notify affected individuals if there is high risk of harm.
Penalties: Violations can attract fines up to SAR 5 million, with repeat violations doubling the penalty. Intentional breaches involving sensitive data may result in criminal referral.
Practical Steps:
- Conduct a PDPL gap assessment mapped to your data flows
- Appoint a Data Protection Officer (DPO) if processing at scale
- Align PDPL controls with SAMA CSF data protection requirements to avoid duplicate compliance efforts
Saudi Arabia's Personal Data Protection Law (PDPL), enforced by the Saudi Data and Artificial Intelligence Authority (SDAIA), imposes specific obligations on financial institutions collecting and processing customer personal data. Key requirements include:
Lawful Basis for Processing: Under PDPL Article 4, institutions must establish a clear legal basis before processing personal data — typically contractual necessity, legal obligation, or explicit consent. For sensitive financial data such as credit scores or biometric authentication, explicit consent is mandatory.
Privacy Notice Requirements: Article 11 requires transparent disclosure to data subjects about the purpose of collection, retention periods, data sharing practices, and their rights — including the right to access, correct, and request deletion of their data.
Data Minimization & Retention: Institutions must collect only data strictly necessary for the stated purpose and define clear retention schedules. Retaining customer data beyond the defined period without justification is a direct violation.
Cross-Border Data Transfers: Article 29 restricts transferring personal data outside Saudi Arabia unless the destination country provides adequate protection or SDAIA approval is obtained. This is especially critical for banks using offshore cloud providers or international payment processors.
Data Breach Notification: In the event of a breach affecting personal data, institutions must notify SDAIA within 72 hours of discovery and inform affected individuals if significant harm is likely.
Practical Steps: Conduct a Data Protection Impact Assessment (DPIA) for high-risk processing activities, maintain a comprehensive Records of Processing Activities (RoPA) register, appoint a Data Protection Officer (DPO) if processing is large-scale, and align your PDPL program with your existing ISO 27001 information security controls for an integrated governance approach.
Saudi Arabia's Personal Data Protection Law (PDPL), enforced by the National Data Management Office (NDMO) and overseen by the Saudi Data and Artificial Intelligence Authority (SDAIA), imposes significant obligations on all organizations operating in the Kingdom that process personal data.
Core Obligations for Financial Institutions:
1. Lawful Basis for Processing (PDPL Article 5): Organizations must establish a valid legal basis before processing personal data. For banks and fintechs, this typically includes contractual necessity (e.g., account opening), legal obligation (e.g., AML/KYC requirements), and — less preferably — explicit consent. Relying solely on consent for operational data processing is risky since individuals may withdraw it at any time.
2. Data Subject Rights (PDPL Articles 4–9): Individuals have rights to access, correct, and request deletion of their personal data. Financial institutions must establish clear processes to respond to these requests within 30 days. Note: data retention requirements under SAMA and FATF may override deletion requests for regulatory records.
3. Cross-Border Data Transfer Restrictions (PDPL Article 29): Personal data may only be transferred outside Saudi Arabia if the destination country provides an adequate level of protection, or if NDMO approval is obtained. This has significant implications for cloud-hosted applications and offshore customer service operations.
4. Data Breach Notification: Organizations must notify SDAIA/NDMO within 72 hours of discovering a personal data breach that poses a risk to data subjects. Affected individuals must also be notified without undue delay.
5. Privacy by Design: New systems and processes must incorporate privacy controls at the design stage — not as an afterthought. Conduct Data Protection Impact Assessments (DPIAs) for high-risk processing activities.
Practical Tip: Map all personal data flows — including employee HR data, customer onboarding records, and marketing databases — before conducting a gap assessment against PDPL requirements. Appoint a Data Protection Officer (DPO) if your organization processes sensitive data at scale.
Saudi Arabia's Personal Data Protection Law (PDPL) and its Executive Regulations impose specific obligations on fintechs leveraging customer personal data for AI-powered credit scoring, behavioral analytics, or personalized financial product recommendations. This is an area of growing regulatory scrutiny.
Lawful Basis for Processing (PDPL Article 6 & 13): Fintechs must establish a clear lawful basis before processing personal data for AI/ML purposes. Consent is the most common basis, but it must be:
- Explicit, informed, and freely given
- Granular — separate consent for scoring versus marketing
- Easily withdrawable at any time
Automated Decision-Making (PDPL Article 15): PDPL restricts fully automated decisions that significantly affect individuals (e.g., credit denial). Customers have the right to:
- Request human review of automated credit decisions
- Receive a meaningful explanation of the decision logic
- Challenge outcomes they believe are inaccurate
This aligns with SAMA's Open Banking and consumer protection frameworks, which require transparent algorithmic decision disclosures.
Data Minimization & Purpose Limitation: Only data directly relevant to the scoring purpose may be processed. Using behavioral data collected for one purpose (e.g., app usage) to feed credit models without fresh consent likely constitutes a PDPL violation.
Cross-Border Data Transfers: If AI models are hosted outside KSA (e.g., on international cloud platforms), PDPL Articles 29–30 require either SDAIA-approved adequacy decisions or appropriate contractual safeguards.
Practical Steps for Fintechs:
- Conduct a Data Protection Impact Assessment (DPIA) before deploying AI scoring models
- Maintain an updated Record of Processing Activities (RoPA) covering all AI use cases
- Appoint a Data Protection Officer (DPO) if processing is large-scale or high-risk
- Publish a clear AI/data use disclosure in your privacy notice
- Implement model governance controls to detect and remediate bias
The Saudi Personal Data Protection Law (PDPL) grants individuals a set of enforceable rights over their personal data, and financial institutions must have a structured, documented process to honor these rights within legally mandated timeframes. Under PDPL Articles 4 and 7–9, data subjects have the right to access their data, request correction, demand deletion (where applicable), and object to certain processing activities. Here is how to build a compliant process: (1) Establish a dedicated intake channel — a secure portal, email address, or in-branch form — specifically for data subject requests (DSRs), ensuring it is accessible and clearly communicated in your privacy notice; (2) Define internal SLAs aligned to PDPL requirements: responses must generally be provided within 30 days, extendable by an additional 30 days in complex cases with notice to the requestor; (3) Implement identity verification protocols before processing any request to prevent unauthorized data disclosure — balance security with accessibility; (4) Map which systems hold personal data so that your team can locate, retrieve, or delete records efficiently — a data inventory and Record of Processing Activities (RoPA) is essential here; (5) Log every DSR with timestamps, actions taken, and outcomes for accountability and regulatory audit readiness; (6) Train customer-facing staff and the compliance team on DSR handling procedures. For Saudi banks, be aware that some deletion requests may conflict with CBE/SAMA record retention requirements — document your legal basis for retention clearly when declining a deletion request. The PDPL's supervisory authority (NDMO/SDAIA) may audit your DSR handling, so evidence of a functioning process is critical.
The Saudi Personal Data Protection Law (PDPL), enforced by the Saudi Data and AI Authority (SDAIA), imposes specific and stringent obligations on fintech companies handling customer financial data. Non-compliance can result in fines up to SAR 5 million. Here is what fintech CISOs and compliance officers must address:
1. Lawful Basis for Processing: Under PDPL Articles 5 and 6, fintechs must establish a clear lawful basis before processing any personal data. For financial services, this typically includes contractual necessity, legal obligation, or explicit consent. Consent must be specific, informed, and revocable — pre-ticked boxes are not acceptable.
2. Data Minimization and Purpose Limitation: Fintechs may only collect data that is strictly necessary for the defined purpose (e.g., credit assessment, KYC, payment processing). Repurposing data without new consent is prohibited under PDPL Article 7.
3. Sensitive Financial Data: PDPL classifies financial data as sensitive personal data requiring heightened protection. This means implementing strong encryption (AES-256 at rest, TLS 1.2+ in transit), strict access controls, and comprehensive audit logging.
4. Data Subject Rights: Fintechs must provide mechanisms for customers to access, correct, and request deletion of their personal data. Responses to data subject requests must be handled within 30 days.
5. Cross-Border Data Transfer: Transferring customer financial data outside Saudi Arabia requires SDAIA approval or confirmation that the recipient country provides an adequate level of protection — critical for fintechs using global cloud providers.
6. Privacy by Design: New products and features must undergo a Data Protection Impact Assessment (DPIA) before launch, embedding privacy controls from the outset.
Practical Tip: Map your data flows end-to-end, document your lawful bases for each processing activity in a Records of Processing Activities (RoPA) register, and align your privacy notices with PDPL Article 11 disclosure requirements.
Saudi Arabia's Personal Data Protection Law (PDPL), enforced by the Saudi Data & AI Authority (SDAIA), establishes a heightened protection regime for 'sensitive personal data' under Article 2. This category explicitly includes genetic and biometric data, health and medical records, financial and credit information, religious beliefs, criminal records, and any data relating to minors.
For Saudi banks, fintechs, and financial institutions — which routinely process credit scores, transaction histories, biometric authentication data (e.g., fingerprints for mobile banking), and KYC documents — virtually all core datasets fall under this sensitive classification.
The additional obligations triggered for sensitive data under PDPL include:
1. Explicit Consent (Article 5): Processing requires explicit, informed, and purpose-specific consent — not merely implied consent embedded in general terms and conditions.
2. Data Minimization & Purpose Limitation (Article 9): You may only collect the minimum data necessary and must not repurpose it without renewed consent.
3. Privacy Impact Assessments (Article 14): High-risk processing activities involving sensitive data require a formal Data Protection Impact Assessment (DPIA) before commencement.
4. Breach Notification (Article 24): Breaches involving sensitive personal data must be reported to SDAIA and affected individuals promptly — regulators expect notification within 72 hours.
5. Cross-Border Transfer Restrictions (Article 29): Transferring sensitive data outside Saudi Arabia requires SDAIA approval or adequate safeguard mechanisms.
Non-compliance exposes institutions to fines of up to SAR 5 million for standard violations and up to SAR 10 million for aggravated breaches. Integration with SAMA CSF Domain 2 (Cybersecurity Risk Management) is essential to ensure technical controls match PDPL's legal obligations.
Saudi Arabia's Personal Data Protection Law (PDPL), enforced by the National Data Management Office (NDMO) and overseen by the Saudi Data and AI Authority (SDAIA), imposes binding obligations on all fintech platforms that process personal data of Saudi residents — regardless of where the company is headquartered.
Pre-Launch Obligations:
- Lawful Basis for Processing: Under PDPL Article 5, fintechs must establish a valid legal basis for every data processing activity — typically explicit consent, contractual necessity, or regulatory obligation. Consent must be informed, specific, and freely given.
- Privacy Notice: A clear, Arabic-language privacy notice is required per PDPL Article 11, explaining data categories collected, purposes, retention periods, and data subject rights.
- Data Protection Impact Assessment (DPIA): Required before launching any high-risk processing activity — such as credit scoring algorithms, biometric authentication, or behavioral profiling — per PDPL implementing regulations.
- Data Minimization and Purpose Limitation: Fintechs may only collect data strictly necessary for the declared purpose. Repurposing data without re-consent is prohibited.
- Cross-Border Transfer Controls: PDPL Article 29 restricts transferring personal data outside Saudi Arabia. Transfers require NDMO approval or must meet adequacy standards. This is critical for fintechs using international cloud providers or global analytics platforms.
- Data Subject Rights Mechanism: Systems must support rights to access, correction, and erasure with defined SLA windows.
Intersection with SAMA: Fintechs licensed by SAMA must also align PDPL compliance with SAMA CSF data classification and protection controls (Domain 3.2), creating a unified data governance program.
Non-compliance carries fines up to SAR 5 million and potential license implications.
Saudi financial institutions face dual notification obligations when personal data breaches occur — one under the Personal Data Protection Law (PDPL) enforced by the Saudi Data & AI Authority (SDAIA), and another under SAMA CSF's incident reporting requirements. Managing both effectively is critical.
PDPL Obligations (Article 24): Upon discovering a breach affecting personal data, organizations must notify SDAIA without undue delay — SDAIA's implementing regulations specify notification within 72 hours of becoming aware of the breach if it poses a risk to individuals' rights or interests. The notification must describe: the nature of the breach, categories and approximate number of data subjects affected, likely consequences, and measures taken or proposed to address it.
Data Subject Notification: If the breach is likely to result in high risk to individuals — such as exposure of financial data, national ID numbers, or sensitive personal data — affected data subjects must also be notified directly and promptly, unless law enforcement considerations apply.
SAMA CSF Requirements (Control 3.4.3 & 3.4.4): SAMA requires regulated entities to report cybersecurity incidents — including data breaches — to SAMA within defined timeframes. Critical incidents impacting customer data require immediate escalation. Institutions must maintain a documented Cyber Incident Response Plan (CIRP) that explicitly covers personal data breach scenarios.
Practical Steps:
- Activate your CIRP immediately upon breach detection.
- Conduct a rapid data impact assessment to determine PDPL applicability.
- Engage your Data Protection Officer (DPO) and Legal team simultaneously.
- File notifications to SDAIA and SAMA within required windows.
- Document all decisions, timelines, and communications meticulously.
Institutions should conduct tabletop exercises simulating data breach scenarios to ensure cross-functional readiness across IT, Legal, Compliance, and Communications teams.
Saudi Arabia's Personal Data Protection Law (PDPL), enforced by the National Data Management Office (NDMO) and now overseen by the Saudi Data and AI Authority (SDAIA), imposes significant obligations on fintechs processing personal data of Saudi residents.
Core Processing Obligations:
- Lawful Basis (Art. 5): Processing must be based on explicit consent, contractual necessity, legal obligation, or legitimate interest. Consent must be clear, specific, and withdrawable.
- Purpose Limitation (Art. 6): Data collected for KYC cannot later be used for marketing without separate consent.
- Data Minimization: Only collect data strictly necessary for the stated purpose.
- Retention Limits (Art. 18): Personal data must be deleted or anonymized once the processing purpose is fulfilled, unless otherwise required by SAMA or AML regulations.
- Data Subject Rights (Art. 4): Individuals have rights to access, correct, and request deletion of their data. Fintechs must respond within 30 days.
- Cross-Border Transfer (Art. 29): Transferring personal data outside Saudi Arabia requires SDAIA approval or that the recipient country ensures adequate protection.
SAMA Intersection: SAMA CSF and Open Banking Framework layer additional requirements on customer data confidentiality, mandating encryption in transit and at rest.
Penalties for Non-Compliance: Violations can result in fines up to SAR 5 million, rising to SAR 50 million for repeat offenders or deliberate breaches. Reputational damage and regulatory license risk compound financial penalties.
Practical Tip: Conduct a Data Protection Impact Assessment (DPIA) before launching new products, and maintain a Records of Processing Activities (RoPA) register to demonstrate accountability.
Data classification and access control form a critical intersection between Saudi Arabia's Personal Data Protection Law (PDPL) and the NCA Essential Cybersecurity Controls (ECC). Here's how to build a unified, compliant approach:
Data Classification (NCA ECC Control 2-1 & PDPL Article 5): Establish a formal data classification policy with at least four tiers: Public, Internal, Confidential, and Restricted. Personal data and sensitive personal data under PDPL (health, financial, biometric) must automatically classify as Restricted. Label all data assets accordingly and enforce handling procedures per classification level.
Access Control Architecture (NCA ECC Control 2-5): Implement Role-Based Access Control (RBAC) aligned with least-privilege principles. Privileged Access Management (PAM) solutions must govern administrator accounts. NCA ECC mandates multi-factor authentication (MFA) for all privileged access and remote connections.
PDPL-Specific Obligations: Under PDPL Articles 12–14, access to personal data must be limited to authorized personnel with a documented legitimate purpose. Data processors must operate under formal agreements restricting use beyond the stated purpose. Maintain access logs for personal data systems and review them periodically.
Practical Implementation Steps:
- Deploy a Data Loss Prevention (DLP) solution to enforce classification policies automatically.
- Conduct quarterly access reviews for systems housing personal or sensitive data.
- Map personal data flows and document them in a Record of Processing Activities (RoPA) as required by PDPL.
- Cross-reference your access control matrix with NCA ECC Annex controls for audit readiness.
A unified data governance framework serving both PDPL and NCA ECC reduces duplication and strengthens your overall security posture.
Cross-border data transfers are one of the most operationally impactful aspects of Saudi Arabia's Personal Data Protection Law (PDPL), governed under Article 29 and its implementing regulations issued by the Saudi Data & AI Authority (SDAIA).
When is a cross-border transfer permitted?
A transfer of personal data outside Saudi Arabia is only lawful if one or more of the following conditions is met:
- The destination country offers an adequate level of data protection as determined by SDAIA.
- The transfer is necessary to fulfill a contractual obligation to the data subject.
- The transfer is required to protect the vital interests of the data subject.
- The data subject has given explicit, informed consent to the transfer.
- The transfer serves a compelling public interest approved by SDAIA.
Practical compliance steps:
- Data Mapping: Identify all personal data flows leaving KSA — including SaaS platforms, cloud backups, and analytics tools processing Saudi resident data abroad.
- Transfer Impact Assessment (TIA): Conduct a formal assessment evaluating the legal framework, security standards, and enforcement capability of the destination country.
- Contractual Safeguards: Where no adequacy decision exists, implement binding data transfer agreements containing SDAIA-approved standard contractual clauses (SCCs).
- SDAIA Notification: Certain sensitive data transfers may require prior notification or approval from SDAIA. Track regulatory guidance updates as implementing regulations continue to evolve.
- Record Keeping: Maintain a Register of International Transfers documenting the legal basis, data categories, destination, and safeguards applied — auditable upon request.
Non-compliance penalties under PDPL can reach SAR 5 million for violations involving cross-border transfer infractions. Organizations should treat international data flows as a high-priority compliance risk.
Data classification is a foundational control that sits at the intersection of PDPL compliance obligations and SAMA CSF requirements. Getting this right protects institutions from both regulatory penalties and operational security breaches.
PDPL Requirements: Saudi Arabia's Personal Data Protection Law (PDPL), enforced by the National Data Management Office (NDMO), requires organizations to identify all personal data, define lawful processing bases, implement proportionate protection controls, and restrict access on a need-to-know basis. Special categories of data — including health, financial, and biometric data — require heightened protection and explicit consent in most cases.
SAMA CSF Alignment: SAMA CSF Control 3.1.1 mandates a formal Information Asset Management program, which includes maintaining an asset register with data classification labels. The framework requires at minimum three classification tiers: Public, Internal/Confidential, and Restricted/Secret — though institutions may adopt more granular schemes.
Practical Implementation Steps:
- Conduct a data discovery exercise to map all data stores, including structured databases, unstructured files, and cloud repositories.
- Apply classification labels based on sensitivity, regulatory scope (PDPL personal data, SAMA-regulated financial data), and business impact.
- Implement technical controls per classification: encryption at rest and in transit for Restricted data (AES-256 minimum), DLP policies, and access controls enforced via IAM systems.
- Define retention and disposal policies aligned with PDPL Article 19, which limits personal data retention to the period necessary for the original processing purpose.
- Conduct annual classification reviews and integrate classification into data lifecycle processes.
Failure to comply with PDPL can result in fines up to SAR 5 million, with repeat violations attracting doubled penalties per Article 35.
Saudi fintechs leveraging AI for credit scoring, fraud detection, customer onboarding, or loan decisioning face specific PDPL obligations that many organizations overlook. This is an emerging and critical compliance area.
Automated Decision-Making Under PDPL The Saudi Personal Data Protection Law (PDPL), enforced by the Saudi Data and AI Authority (SDAIA), addresses automated processing in Article 15. When a fintech uses AI to make decisions that significantly affect individuals — such as denying a loan, flagging fraud, or setting credit limits — the following obligations apply:
1. Transparency and Disclosure Data subjects must be informed that automated decision-making is occurring. Your privacy notice (required under PDPL Art. 11) must clearly disclose the use of AI systems, the type of data processed, and the logic applied in general terms.
2. Right to Explanation Customers have the right to request a meaningful explanation of how an automated decision was reached. Your AI system must be designed to provide human-interpretable outputs — black-box models with no explainability mechanism create direct PDPL exposure.
3. Human Review Mechanism For high-impact decisions, PDPL expects that individuals can request human review of automated decisions. Build an escalation workflow where compliance or operations teams can review and override AI decisions.
4. Data Minimization (PDPL Art. 9) AI models should only process personal data that is necessary for the stated purpose. Audit your model's feature set to ensure no excessive or sensitive attributes (e.g., gender, location proxies) are used in ways that could create discriminatory outcomes.
5. SAMA CSF Alignment SAMA's guidance on technology risk (Control 3.3.10) also requires risk assessment of automated financial decision systems. Conduct a Data Protection Impact Assessment (DPIA) before deploying any customer-facing AI system.
Engage your DPO and legal counsel early when deploying AI in customer journeys to ensure PDPL readiness.
Effective data classification is the foundation of both PDPL compliance and SAMA CSF's data governance domain (Control 3.2). Saudi financial institutions must implement a structured, enterprise-wide data classification framework that satisfies both regulatory regimes simultaneously.
Classification Tiers to Implement:
- Confidential/Restricted: Personal financial data, credit scores, national ID numbers, biometric data, and transaction records — classified as sensitive personal data under PDPL Article 23, requiring explicit consent for processing.
- Internal: Operational data, internal policies, non-public business information.
- Public: Marketing materials, published financial reports.
SAMA CSF Requirements (Controls 3.2.1–3.2.4): Institutions must document a data classification policy, assign data owners for each category, apply technical controls (encryption, access restrictions, DLP tools) proportionate to classification level, and conduct periodic data inventories.
PDPL Obligations: Per PDPL Articles 5 and 6, financial institutions must identify a lawful basis for each personal data processing activity. For sensitive categories, explicit consent or specific legal necessity is required. Data minimization principles must be embedded in classification decisions.
Practical Implementation Steps:
- Conduct a data discovery and mapping exercise across all systems and third-party integrations.
- Deploy Data Loss Prevention (DLP) tools integrated with your classification labels.
- Encrypt all Confidential data at rest (AES-256) and in transit (TLS 1.2+).
- Establish data retention and deletion schedules per PDPL Article 18.
- Document the data register and make it available for SAMA and SDAIA inspections.
Align your classification taxonomy with ISO 27001 Annex A Control 5.12 for a unified governance approach.
Saudi financial institutions face overlapping data governance obligations under PDPL and SAMA CSF, requiring a unified data classification and handling framework. Data Classification Tiers: SAMA CSF Control 3.2.1 mandates a formal classification policy. Best practice aligns four tiers — Public, Internal, Confidential, and Restricted — with PDPL's distinction between general personal data and sensitive personal data (Article 23 PDPL), which includes financial records, health data, and biometric information. PDPL Obligations: Sensitive personal data requires explicit consent for processing (Article 6), purpose limitation, and storage only for as long as operationally necessary. Financial institutions must appoint a Data Protection Officer (DPO) if processing is large-scale or involves sensitive categories. SAMA CSF Data Handling Controls: Per SAMA CSF 3.2.3, classified data must have documented handling procedures covering storage encryption (AES-256 minimum), secure transmission (TLS 1.2+), clean-desk policies, and secure disposal aligned with NIST SP 800-88. Data Inventory: Maintain a live data inventory or Record of Processing Activities (RoPA) mapping data types to systems, custodians, retention periods, and legal basis — a requirement under both PDPL and ISO 27001 Annex A.8.1. Practical Steps: Implement a Data Loss Prevention (DLP) solution integrated with email and endpoint controls; tag documents using classification labels enforced by Microsoft Purview or equivalent. Annual data classification audits are recommended to ensure alignment with evolving regulatory expectations.
Saudi financial institutions face overlapping obligations from both PDPL (Personal Data Protection Law) and SAMA CSF when it comes to data classification and protection. Getting this right is foundational to overall compliance posture.
Under PDPL Article 5 and Article 29, organizations must identify all categories of personal data they process, with special categories—such as financial records, biometric data, and health information—requiring heightened protection measures. Consent must be obtained for processing, and data must only be retained for as long as necessary for the stated purpose.
SAMA CSF Control 3.2 (Information Asset Management) requires banks to maintain a formal data classification policy with at minimum four tiers: Public, Internal, Confidential, and Restricted. Customer financial data, payment card information, and authentication credentials must be classified as Restricted, triggering the highest levels of encryption, access control, and audit logging requirements.
Practical implementation steps include:
- Conduct a full data discovery and mapping exercise to identify where personal and sensitive financial data resides across on-premises and cloud environments.
- Label all data assets according to your classification policy and enforce controls through Data Loss Prevention (DLP) tools.
- Encrypt all Restricted-class data at rest (AES-256) and in transit (TLS 1.2 or higher), per SAMA CSF Control 3.6.
- Implement data masking and tokenization for non-production environments.
- Establish a formal data retention and disposal schedule aligned with PDPL Article 18 and SAMA record-keeping requirements.
- Ensure your Data Protection Officer (DPO), required under PDPL Article 30 for high-risk processors, is empowered to oversee these controls.
Regular audits of data flows and third-party data sharing arrangements are also critical to maintaining compliance.
Building a compliant data governance framework for Saudi financial institutions requires harmonizing PDPL obligations with SAMA CSF data classification requirements and NCA ECC data protection controls.
Data Classification (SAMA CSF 3.6.1): SAMA requires banks to define a formal data classification policy with at least the following tiers:
- Confidential / Restricted: Customer PII, financial records, authentication credentials
- Internal: Operational data, internal communications
- Public: Marketing materials, published reports
PDPL Obligations (Articles 5, 8, and 21):
- Personal data must be collected for a specific, legitimate purpose and not retained beyond what is necessary
- Sensitive categories (health, financial, biometric data) require explicit consent under PDPL Article 6 and additional safeguards
- Data processors (third parties) must be bound by contractual data processing agreements ensuring PDPL compliance
Practical Implementation Steps:
- Deploy a Data Discovery and Classification tool (e.g., Microsoft Purview, Varonis) to identify and tag sensitive data assets automatically
- Establish a Data Retention and Disposal Schedule aligned with SAMA CSF 3.6.3 — financial records typically require 10-year retention per SAMA banking regulations
- Implement Data Loss Prevention (DLP) controls on endpoints, email, and cloud environments
- Map all personal data flows in a Record of Processing Activities (RoPA) as required by PDPL Article 15
- Appoint a Data Protection Officer (DPO) — mandatory for organizations processing large-scale or sensitive personal data
NCA ECC Alignment: ECC-1: 3-4 mandates data classification and handling procedures for all critical sector entities.
Conduct annual data governance audits and include data classification compliance in your ISO 27001 internal audit scope under Annex A Control 5.12.
Data classification is a foundational control required by both SAMA CSF (Control 3.2.1) and the Personal Data Protection Law (PDPL Article 5), and it directly underpins data protection, access control, and incident response capabilities.
Step 1 – Establish a Data Classification Policy: Define at minimum four tiers: Public, Internal, Confidential, and Restricted. Under PDPL, any data that qualifies as 'personal data' or 'sensitive personal data' (e.g., financial records, national IDs, biometrics) must be mapped to the Restricted tier with enhanced protections.
Step 2 – Conduct a Data Discovery and Inventory Exercise: Map all data assets across on-premises systems, cloud environments, and third-party processors. SAMA CSF requires that this inventory be maintained and reviewed at least annually. Include data flows to identify cross-border transfers, which require explicit PDPL Article 29 compliance assessment.
Step 3 – Apply Technical Controls by Classification Tier:
- Restricted: Encryption at rest and in transit (AES-256 minimum), strict role-based access, DLP enforcement, and audit logging.
- Confidential: Encryption, need-to-know access, and periodic access reviews.
- Internal/Public: Standard access controls and monitoring.
Step 4 – Label and Handle Data Consistently: Implement automated labeling tools integrated with document management systems and email platforms to enforce classification at the point of creation.
Step 5 – Review and Audit: SAMA CSF requires periodic reviews of classification accuracy. Conduct semi-annual audits and align findings with your ISO 27001 Annex A.8 asset management controls.
Our GRC platform includes a pre-built data classification framework mapped to PDPL, SAMA CSF, and ISO 27001, with workflow automation to track classification reviews and exceptions.
vCISO & Consulting 11
A Virtual CISO (vCISO) is an experienced cybersecurity executive who provides strategic leadership on a fractional or contract basis. Organizations benefit from a vCISO when they: lack a full-time CISO, need regulatory compliance expertise (SAMA/NCA), are preparing for an audit or certification, or want to build a cybersecurity program cost-effectively without a full executive salary.
For Saudi fintechs — especially those operating under SAMA's Fintech regulatory sandbox or holding payment licenses — achieving full SAMA CSF and NCA ECC compliance without a full-time CISO is a common challenge. A vCISO engagement offers a practical, scalable solution. Here's how to maximize its value:
Why vCISO Makes Sense for Fintechs: Full-time CISOs with deep knowledge of SAMA CSF, NCA ECC, and PDPL command significant salaries (SAR 400K–700K+ annually). A vCISO delivers equivalent expertise at a fraction of the cost, with flexible engagement models (part-time, project-based, or retainer).
Key Deliverables a vCISO Should Provide:
1. Gap Assessment & Roadmap: Conduct a structured gap analysis against SAMA CSF (all five domains) and NCA ECC (all 29 sub-domains). Prioritize gaps by regulatory risk and remediation effort, producing a board-ready compliance roadmap.
2. Policy & Framework Development: Draft and implement the required policy suite — Information Security Policy, Acceptable Use, Incident Response, Business Continuity — aligned to SAMA CSF Control 3.1 requirements.
3. SAMA Regulatory Engagement: Support preparation for SAMA self-assessments (annual requirement) and regulatory examinations. A seasoned vCISO understands SAMA's assessment methodology and can position the organization favorably.
4. Risk Management: Establish a cyber risk register aligned to ISO 27001 Annex A and NIST CSF, feeding into the organization's overall risk appetite framework.
5. Ongoing Governance: Chair monthly security steering committee meetings, produce quarterly risk reports for the board, and maintain awareness training programs.
Selecting the Right vCISO Partner: Look for demonstrable experience with Saudi financial regulators, bilingual capability (Arabic/English), and a GRC platform to centralize evidence management — critical for audit readiness.
Building a compliant and effective security awareness program for a Saudi fintech requires aligning with SAMA CSF Control Domain 3.2 (Human Resources Security) and NCA ECC Article 2-5 (Cybersecurity Awareness and Training).
Foundational Steps:
1. Needs Assessment: Begin with a role-based training gap analysis. Identify three audience tiers: general staff, technical teams, and the Board/C-Suite. Each tier requires tailored content and frequency.
2. Mandatory Training Topics: Per SAMA CSF, your program must cover: phishing and social engineering, secure handling of customer financial data (linked to PDPL obligations), password hygiene, mobile device security, and incident reporting procedures. NCA ECC Article 2-5 additionally requires coverage of nation-state threat awareness for critical sector employees.
3. Frequency and Format:
- All employees: Annual foundational training + monthly micro-learning modules
- Technical staff: Quarterly deep-dive sessions on emerging threats (e.g., API security, cloud misconfigurations)
- Board members: Biannual cyber risk briefings aligned to strategic risk appetite
4. Phishing Simulations: Conduct simulated phishing campaigns at least quarterly. Track click rates, reporting rates, and improvement trends. SAMA examiners frequently request this data as evidence of program effectiveness.
5. Metrics and Documentation: Maintain training completion records for all employees — this is a direct examination artifact. Report awareness KPIs (completion rates, simulation performance, incident reports by staff) to the Board Risk Committee at least semi-annually.
6. Localization: Deliver content in both Arabic and English to ensure comprehension across your workforce — a practical necessity in Saudi fintech environments with diverse teams.
A virtual CISO (vCISO) is an experienced cybersecurity executive engaged on a fractional or advisory basis, providing strategic leadership without the cost and commitment of a full-time hire. For Saudi financial institutions — particularly mid-sized banks, fintechs, and insurance companies — a vCISO can be a highly effective solution to meet SAMA CSF governance mandates.
SAMA CSF Governance Requirements Addressed:
- Control 1.1 (Cybersecurity Leadership): SAMA CSF explicitly requires a designated cybersecurity function with clear accountability at the executive level. A vCISO formally fulfills this role, reporting to the CEO or Board Risk Committee.
- Control 1.2 (Cybersecurity Strategy): The vCISO develops and maintains a multi-year cybersecurity roadmap aligned to SAMA CSF maturity targets and NCA ECC requirements.
- Control 1.3 (Policies and Procedures): A vCISO leads the development, review, and approval of the full cybersecurity policy suite required by SAMA.
- Control 1.5 (Compliance Monitoring): Ongoing SAMA CSF gap assessments, NCA ECC compliance tracking, and PDPL readiness are core vCISO responsibilities.
Practical Value for Saudi Institutions:
- Regulatory Liaison: Experienced vCISOs have direct familiarity with SAMA examination processes and can prepare institutions for supervisory reviews.
- Board Reporting: They translate complex cybersecurity risks into board-level language, satisfying SAMA's expectation that cyber risk is reported to governance bodies quarterly.
- Cost Efficiency: Particularly valuable for fintechs and smaller licensed entities that cannot justify a SAR 400,000+ annual CISO salary but still face full SAMA CSF obligations.
- Rapid Deployment: A vCISO can be mobilized quickly following a SAMA finding or regulatory deadline.
When selecting a vCISO, institutions should verify hands-on experience with Saudi regulatory frameworks, not just international certifications like CISSP or CISM.
For Saudi fintechs — particularly those operating under SAMA's Regulatory Sandbox or holding payment service provider licenses — the mandate to maintain a qualified cybersecurity leadership function is real but often financially challenging to fulfill through a full-time CISO hire. A virtual CISO (vCISO) provides the strategic and regulatory expertise on a fractional basis, delivering enterprise-grade security governance without the overhead of a senior executive salary.
How a vCISO accelerates SAMA CSF and NCA ECC compliance:
- Baseline Assessment & Gap Analysis: A vCISO conducts an initial maturity assessment against SAMA CSF's five domains and NCA ECC's control families, producing a prioritized roadmap with clear timelines and resource estimates — essential before your first regulatory examination.
- Policy & Framework Development: SAMA CSF requires documented policies across 22+ cybersecurity sub-domains. A vCISO drafts, tailors, and socializes these policies to match your business model, whether you're a BNPL provider, remittance platform, or digital bank.
- Regulatory Liaison: vCISOs experienced in the Saudi market can directly support interactions with SAMA examiners and NCA auditors, helping you respond to findings with confidence and credibility.
- Security Awareness Program: Both SAMA CSF (Control 3.4) and NCA ECC require documented staff training programs. A vCISO designs and tracks these programs to satisfy audit evidence requirements.
- Board & Audit Committee Reporting: SAMA CSF requires cybersecurity reporting to senior management and the board. A vCISO prepares executive-level dashboards and committee reports that translate technical risk into business language.
Engaging a vCISO typically reduces time-to-compliance by 40-60% compared to building an internal team from scratch, making it a highly strategic investment for early and growth-stage fintechs.
A SAMA CSF gap assessment typically takes 4–8 weeks depending on the size and complexity of the organization. The process involves document review, interviews with key stakeholders, technical control testing, evidence collection, scoring against all 251 sub-controls, and delivering a remediation roadmap with prioritized findings.
A comprehensive cybersecurity assessment should deliver: (1) Executive Summary for board/management; (2) Detailed gap analysis report; (3) Current maturity score per domain; (4) Risk-prioritized remediation roadmap; (5) Control evidence matrix; (6) Compliance heatmap; (7) Quick wins vs. long-term recommendations; (8) Compliance percentage per regulatory framework.
A virtual CISO (vCISO) is an experienced cybersecurity executive engaged on a fractional, part-time, or project basis to provide strategic security leadership without the overhead of a full-time hire. For Saudi financial institutions — particularly emerging fintechs, payment service providers, and mid-sized banks — a vCISO can be a highly pragmatic solution that accelerates compliance and security maturity.
When a vCISO Makes Sense:
- Early-Stage Fintechs: Companies preparing for SAMA licensing or SAMA Open Banking compliance often lack the security infrastructure and governance maturity SAMA CSF demands. A vCISO can build the security program from scratch and guide the licensing process.
- Compliance Acceleration: Organizations facing urgent SAMA CSF, NCA ECC, or ISO 27001 audit deadlines benefit from a vCISO who has executed these programs before and can deploy proven frameworks rapidly.
- Budget Constraints: A full-time CISO in Saudi Arabia commands a significant salary package. A vCISO delivers comparable strategic value at 30–60% of the cost, making it viable for institutions that need executive-level security oversight without the full headcount cost.
- Interim Coverage: During CISO transitions or while a permanent hire is recruited, a vCISO maintains continuity of governance, vendor relationships, and regulatory engagement.
- Specialized Expertise: When specific expertise is needed — such as PDPL implementation, SWIFT CSCF compliance, or board-level cybersecurity reporting — a vCISO with that specialization can be engaged precisely.
What to Expect from a vCISO: A qualified vCISO should own the security strategy, manage the GRC program, engage regulators (SAMA, NCA, SDAIA), lead incident response oversight, and report to the Board or Audit Committee. They should be contractually bound by confidentiality and conflict-of-interest safeguards.
For institutions on a growth trajectory, a vCISO also serves as an ideal bridge — building internal capability while the organization prepares to onboard a full-time CISO.
A Virtual CISO (vCISO) is an experienced cybersecurity executive engaged on a fractional or contract basis to provide strategic leadership, governance oversight, and compliance programme management — without the cost and commitment of a full-time hire. For Saudi financial institutions, this model offers a compelling path to accelerating regulatory compliance.
Why the vCISO Model Works for Saudi Banks and Fintechs:
Many mid-tier Saudi banks and growing fintechs face a dual challenge: mounting regulatory pressure from SAMA CSF and NCA ECC compliance obligations, combined with a shortage of qualified senior cybersecurity talent in the Kingdom. A vCISO bridges this gap by providing immediate, deployable expertise.
Key vCISO Contributions to Compliance Programmes:
- SAMA CSF Maturity Assessment: A vCISO can rapidly conduct a gap assessment against SAMA CSF domains (Governance, Risk, Operations, Third Party) to establish a current maturity baseline and build a prioritized remediation roadmap.
- NCA ECC Programme Leadership: The vCISO can lead the design and implementation of ECC controls (covering 29 main controls and 114 sub-controls) and prepare the institution for NCA assessments.
- Board and EXCO Reporting: SAMA CSF Domain 1 (Cybersecurity Leadership) requires cybersecurity reporting to senior management. A vCISO delivers board-ready risk reporting, translating technical findings into business-impact language.
- Policy and Framework Development: Developing the mandatory policy suite required by SAMA CSF (Cybersecurity Policy, Acceptable Use, BCMP, Incident Response) is a core vCISO deliverable.
- Regulator Liaison: Experienced vCISOs understand SAMA and NCA examination processes and can support institutions during regulatory assessments and audits.
Cost Efficiency: Engaging a vCISO typically costs 30–60% less than hiring a full-time CISO at market rates in Saudi Arabia, while providing access to broader expertise across multiple compliance frameworks including ISO 27001, NIST CSF, and PDPL.
Practical Recommendation: Structure the vCISO engagement with defined quarterly milestones tied to SAMA CSF maturity level improvements, ensuring measurable progress toward your target maturity score.
A virtual CISO (vCISO) is an experienced cybersecurity executive engaged on a fractional or outsourced basis, providing strategic security leadership without the cost of a full-time hire. For Saudi fintechs — which are typically resource-constrained but face the same regulatory obligations as large banks — a vCISO offers a highly practical compliance and security governance model.
How a vCISO adds value for Saudi fintechs:
1. Regulatory Roadmap Development: A vCISO familiar with the Saudi regulatory landscape maps your current security posture against SAMA CSF's five domains (Cybersecurity Leadership, Policies, People, Technology, and Third-Party) and NCA ECC's control categories, producing a prioritized compliance roadmap with realistic timelines.
2. Policy & Documentation Framework: SAMA CSF requires documented policies covering at minimum: information security, access control, incident response, and business continuity. A vCISO drafts and owns this documentation suite, ensuring it reflects actual operations rather than generic templates.
3. SAMA Regulatory Liaison: vCISOs with SAMA experience can prepare your institution for SAMA's Cyber Risk Supervision assessments, coordinate evidence collection, and represent your cybersecurity posture to regulators and auditors.
4. Security Program Execution: Beyond compliance checkboxes, a vCISO operationalizes controls — from standing up a vulnerability management process to overseeing penetration testing per SAMA CSF Control 3.3.8 and selecting fit-for-purpose security tools.
5. Board & C-Suite Reporting: Translating technical risk into business language for board-level reporting is a core vCISO function, satisfying SAMA CSF's cybersecurity governance requirements under Domain 3.1.
Cost Comparison: A full-time CISO in Saudi Arabia commands SAR 400K–800K+ annually. A vCISO engagement typically costs 20–40% of that, making it the rational choice for fintechs pre- or post-SAMA licensing.
Look for vCISOs who hold CISSP, CISM, or equivalent certifications and have direct experience with SAMA and NCA regulatory interactions.
A virtual CISO (vCISO) is an experienced cybersecurity executive engaged on a fractional or advisory basis to provide strategic security leadership without the cost and commitment of a full-time hire. For Saudi banks, fintechs, and financial institutions, a vCISO offers a compelling model — particularly given the Kingdom's persistent shortage of senior cybersecurity talent and the increasingly complex regulatory landscape.
When to Consider a vCISO:
- Startups and growth-stage fintechs licensed by SAMA that must demonstrate cybersecurity governance but cannot yet justify a full-time CISO salary.
- Mid-sized banks undergoing digital transformation or preparing for SAMA CSF assessments, NCA ECC gap analyses, or PDPL readiness reviews.
- Institutions post-incident needing rapid leadership to stabilize response, manage regulator communications, and rebuild the security program.
- Organizations expanding into new services (e.g., open banking, embedded finance) requiring security architecture oversight.
What a vCISO Delivers: A qualified vCISO aligned to Saudi regulatory requirements will own and drive the cybersecurity strategy, oversee SAMA CSF compliance across all 3 domains and 22 sub-domains, manage NCA ECC control implementation, advise on PDPL data governance obligations, and represent the security function to the board and regulators.
They will establish key programs including risk management frameworks, security awareness, incident response planning (aligned to SAMA CSF Control 3.4), vendor risk governance, and business continuity plans per SAMA guidelines.
vCISO vs. Full-Time CISO: The vCISO model typically offers 40–60% cost savings while providing access to broader expertise across multiple industries and regulatory environments. Engagements are scalable — from a few days per month to near full-time during critical periods.
Our vCISO consulting service pairs your institution with Saudi-market experts who have direct experience with SAMA, NCA, and SDAIA regulatory engagements.
Penetration Testing 86
Yes. Both SAMA CSF and NCA ECC require periodic penetration testing. SAMA requires at least annual penetration testing of critical systems, applications, and infrastructure. NCA ECC similarly mandates regular vulnerability assessments and penetration tests. Results must be documented and remediation tracked.
Under SAMA CSF Control 3.3.6 (Vulnerability Assessment and Penetration Testing), Saudi banks and financial institutions are required to conduct penetration testing as part of a structured vulnerability management program. Here are the key requirements:
Frequency:
- External penetration testing: At minimum annually, and after any significant infrastructure change
- Internal network penetration testing: At least once per year
- Application-level testing (including internet-facing banking apps): Annually or post major releases
Scope Requirements:
- Tests must cover critical assets including core banking systems, payment infrastructure, and internet-facing applications
- Social engineering and phishing simulations should be included as part of a holistic assessment
- Red team exercises are encouraged for mature security programs
Methodology & Documentation:
- Testing must follow a recognized methodology such as PTES, OWASP, or NIST SP 800-115
- All findings must be formally documented, risk-rated, and tracked through to remediation
- SAMA expects evidence of remediation timelines and sign-off by senior management
Third-Party Testers:
- SAMA CSF recommends using qualified, independent third-party testers to ensure objectivity
- Testers should hold relevant certifications (OSCP, CREST, CEH)
Practical Tip: Align your penetration testing schedule with your annual SAMA CSF self-assessment cycle to ensure findings feed directly into your compliance reporting. Maintain a dedicated vulnerability register and present remediation status in CISO board reports.
Under SAMA CSF Control Domain 3.3 (Cybersecurity Risk Management) and specifically Control 3.3.2, Saudi banks and financial institutions are required to conduct regular penetration testing as part of their vulnerability management program. SAMA mandates at minimum an annual external penetration test, with internal penetration testing also required on at least an annual basis. However, best practice — and what most SAMA examiners expect — is semi-annual testing for Tier 1 institutions, and after any major infrastructure change.
Key requirements include:
Scope: Tests must cover external-facing systems, internal networks, web and mobile banking applications, APIs, and increasingly, cloud environments.
Methodology: SAMA expects testing to follow recognized methodologies such as OWASP, PTES, or NIST SP 800-115. Tests should include both automated scanning and manual exploitation attempts.
Testers: Engagements should be conducted by qualified third-party firms (not internal teams alone) with demonstrable credentials such as OSCP, CREST, or equivalent certifications.
Remediation Tracking: Findings must be risk-rated, remediated within defined SLAs (critical findings typically within 15–30 days), and validated through re-testing. All results must be formally reported to the CISO and Board Risk Committee.
NCA ECC Alignment: NCA ECC Article 2-7 (Cybersecurity Assessment) reinforces penetration testing obligations for critical national infrastructure entities, which includes licensed financial institutions.
Practical tip: Maintain a penetration testing register within your GRC platform, tracking scope, findings, remediation status, and attestation sign-offs to demonstrate compliance during SAMA regulatory examinations.
Penetration testing is a mandatory control under both SAMA CSF (Domain 4 – Cybersecurity Operations, Control 4.3) and NCA ECC (Article 3-14), and must be conducted with a structured, risk-based approach.
Frequency & Scope: SAMA CSF requires financial institutions to perform penetration tests at least annually, and after any significant infrastructure change. Tests must cover external-facing systems, internal networks, critical applications, and payment systems. NCA ECC extends this to include OT/ICS environments where applicable.
Methodology: Tests should follow recognized frameworks such as PTES, OWASP (for web applications), or TIBER-EU adapted for Saudi context. All test phases — reconnaissance, exploitation, post-exploitation, and reporting — must be documented.
Authorization & Governance: A formal Rules of Engagement (RoE) document must be signed before testing begins, clearly scoping in-bounds and out-of-bounds systems. SAMA expects board-level visibility on penetration testing outcomes.
Vendor Requirements: Third-party penetration testing vendors must meet SAMA CSF's third-party assurance criteria. Firms should hold recognized certifications such as CREST, OSCP, or equivalent. NCA-approved vendors are preferred for government-linked entities.
Remediation Tracking: Findings must be risk-rated (Critical, High, Medium, Low) and tracked through a formal remediation plan with defined SLAs. SAMA expects retesting of critical findings within 30 days.
Reporting: Executive summaries should be presented to senior management and the CISO, with detailed technical reports retained for regulatory review upon request.
Our platform helps teams manage the full pentest lifecycle — from vendor selection and scoping to finding remediation tracking aligned with SAMA and NCA expectations.
Under SAMA CSF Control 3.3.8 (Vulnerability Management) and Control 3.3.9 (Penetration Testing), Saudi banks are required to conduct structured penetration testing as part of their cybersecurity assurance program. Key requirements include:
Frequency: External penetration tests must be performed at least annually, while critical systems and internet-facing infrastructure should be tested more frequently — ideally every six months or after significant changes.
Scope: Tests must cover network infrastructure, web applications, mobile banking platforms, APIs, and internal segmentation controls. Social engineering and physical security assessments are strongly recommended.
Methodology: SAMA expects tests to follow internationally recognized methodologies such as OWASP, PTES, or NIST SP 800-115. All findings must be risk-rated and tracked through formal remediation workflows.
Third-Party Testers: SAMA CSF recommends using qualified independent testers for external assessments. Testers should hold recognized certifications (e.g., OSCP, CREST, CEH).
Reporting & Remediation: Critical and high-severity findings must be remediated within defined SLAs — typically 30 days for critical vulnerabilities. Results must be reported to the CISO and Board Risk Committee.
Regulatory Reporting: Significant vulnerabilities discovered during testing may trigger mandatory notification obligations, especially if they expose customer data, potentially intersecting with PDPL breach notification requirements.
Banks should maintain a penetration testing register and integrate results into their overall risk register to demonstrate continuous compliance during SAMA regulatory examinations.
Saudi financial institutions must conduct penetration testing as a core component of their cybersecurity assurance program. Under SAMA CSF Control 3.3.5, member organizations are required to perform regular penetration tests covering network infrastructure, applications, and critical systems—at minimum annually, and after any significant change to the environment. NCA ECC Article 2-14 similarly mandates ethical hacking exercises to validate the effectiveness of implemented controls.
Key requirements include:
Scope Definition: Tests must cover external perimeter, internal network segments, web and mobile banking applications, APIs, and SWIFT infrastructure where applicable.
Qualified Testers: Engagements should be conducted by certified professionals (OSCP, CEH, GPEN) from approved vendors, with clear scoping agreements and rules of engagement signed before testing begins.
Methodology: Follow a structured methodology such as PTES or OWASP Testing Guide. Social engineering and phishing simulations are strongly encouraged to test human controls.
Reporting & Remediation: Findings must be risk-rated, reported to senior management, and tracked to closure. SAMA CSF requires documented evidence of remediation for critical and high findings within defined SLAs.
Red Team Exercises: For Tier-1 banks, full-scope red team operations (simulating advanced persistent threats) are recommended at least every two years to satisfy the spirit of SAMA's continuous assurance requirements.
All penetration test reports and remediation records should be retained for regulatory review and presented during SAMA onsite examinations. Integrating pentest findings into your risk register ensures traceability across your GRC platform.
Under SAMA CSF Control 3.3.5 (Vulnerability Management) and Control 3.3.6 (Penetration Testing), Saudi banks and financial institutions are required to conduct structured penetration tests at defined intervals — at minimum annually, and additionally following any major infrastructure change, new product launch, or significant system upgrade.
Key requirements include:
Scope: Tests must cover external-facing assets, internal network segments, web applications, mobile banking platforms, APIs, and critical backend systems such as core banking and payment infrastructure.
Methodology: Engagements should follow recognized methodologies such as OWASP for applications, PTES, or TIBER-EU (adapted for Saudi context). Tests must include both black-box and gray-box scenarios.
Qualified Testers: SAMA expects tests to be conducted by qualified third-party providers or a sufficiently independent internal red team. Testers should hold recognized certifications such as OSCP, CREST, or CEH.
Reporting & Remediation: Post-test, findings must be formally documented with severity ratings (CVSS scoring recommended), root-cause analysis, and a tracked remediation plan. Critical and high findings typically require remediation within 30–90 days depending on SAMA's risk classification.
Evidence Retention: Reports and remediation evidence must be retained and made available to SAMA during regulatory examinations.
Practically, your platform should maintain a penetration testing calendar, track open findings against SLA timelines, and generate evidence packages for auditor review. Integrating pentest findings into your risk register ensures they feed into SAMA's broader risk management cycle.
Saudi financial institutions are required to conduct regular penetration testing as a core component of their cybersecurity assurance programs. Under SAMA CSF Control 3.3.6, member organizations must perform penetration testing at least annually and after any significant infrastructure change. NCA ECC-1:2018 Article 3-7 reinforces this by mandating vulnerability assessments and ethical hacking exercises for critical systems.
Key requirements include:
Scope & Methodology: Tests must cover external perimeter, internal networks, web applications, APIs, and mobile banking platforms. Methodology should align with industry standards such as OWASP and PTES.
Qualified Testers: Engagements must be conducted by certified professionals (OSCP, CEH, or equivalent) from vendors with demonstrable financial-sector experience. SAMA expects independence — internal teams should not test their own systems without oversight.
Reporting & Remediation: All critical and high findings must be remediated within defined SLAs — typically 30 days for critical vulnerabilities. Results must be documented and presented to the board-level cybersecurity committee.
Red Team Exercises: For Tier-1 banks and systemically important institutions, SAMA increasingly expects threat-led penetration testing (TLPT) inspired by frameworks like TIBER-EU, simulating advanced persistent threat (APT) scenarios.
Retesting: After remediation, retesting is mandatory to confirm closure of vulnerabilities.
Practical tip: Maintain a penetration testing register that tracks scope, findings, remediation status, and retest outcomes. This register serves as critical evidence during SAMA regulatory examinations and NCA audits, demonstrating a proactive and structured approach to offensive security assurance.
Under SAMA CSF Control Domain 3.3 (Cybersecurity Operations), Saudi banks and financial institutions are required to conduct regular penetration testing as part of their vulnerability management and threat assessment programs. Here are the key requirements:
Frequency Requirements:
- External penetration tests: At minimum annually, or after any significant infrastructure change
- Internal network penetration tests: At minimum annually
- Application-level testing (web, mobile, API): Before major releases and at least once per year
- Red team exercises: Recommended every 18–24 months for Tier 1 institutions
Scope Considerations: Tests must cover internet-facing systems, core banking platforms, payment infrastructure, and SWIFT environments. Per SAMA CSF Control 3.3.5, identified vulnerabilities must be remediated within defined SLAs based on severity: Critical (15 days), High (30 days), Medium (90 days).
Tester Qualification: SAMA expects tests to be performed by qualified and independent parties. Internal teams may conduct routine assessments, but external, independent testers are required for annual formal engagements. Testers should hold recognized certifications such as OSCP, CEH, or CREST.
Reporting & Governance: Penetration test results must be formally documented, reviewed by the CISO, and reported to the Board Risk Committee where material findings exist. Retesting must confirm remediation effectiveness.
NCA ECC Alignment: NCA ECC Article 2-12 also mandates technical vulnerability assessments, so aligning your pentest program satisfies both frameworks simultaneously, reducing compliance overhead significantly.
Under SAMA CSF Control 3.3.7 (Vulnerability Management), Saudi banks and financial institutions are required to conduct regular penetration testing as part of a comprehensive vulnerability management program. SAMA mandates at minimum an annual external penetration test, with internal assessments recommended bi-annually. For critical internet-facing systems and core banking platforms, more frequent testing is strongly advised.
Key requirements include:
Scope: Tests must cover external perimeters, internal networks, web applications, mobile banking apps, APIs, and social engineering vectors. ATM infrastructure and payment switching systems require dedicated assessments.
Methodology: Engagements should follow recognized frameworks such as PTES, OWASP WSTG, or TIBER-SA (the Saudi adaptation of threat intelligence-based ethical red teaming).
Provider Qualification: Testers must hold relevant certifications (OSCP, CREST, CEH) and ideally be accredited by NCA or SAMA-recognized bodies. Avoid using internal staff for external assessments to maintain objectivity.
Reporting & Remediation: All critical and high findings must be remediated within 30 days per SAMA CSF expectations. A formal remediation tracking register should be maintained and reviewed by the CISO.
Board Reporting: Results must be escalated to the Board-level Risk Committee or equivalent, per SAMA CSF governance requirements (Control 3.1.4).
Beyond SAMA, NCA ECC Article 2-5 also requires vulnerability assessments and red team exercises for entities classified as critical national infrastructure. Aligning both frameworks in a unified pentest schedule reduces duplication and demonstrates mature security governance to regulators.
Saudi financial institutions are required to conduct regular penetration testing as a core component of their cybersecurity assurance programs. Under SAMA CSF Control 3.3.5, member organizations must perform threat-led penetration testing at least annually, and after any significant infrastructure or application change. NCA ECC Article 2-7 similarly mandates vulnerability assessments and penetration tests as part of ongoing technical security evaluations.
Key requirements include:
Scope Definition: Tests must cover external-facing systems, internal networks, critical applications (including mobile banking and payment platforms), and API endpoints.
Qualified Testers: Engagements must be conducted by certified professionals (e.g., OSCP, CREST, CEH) or approved third-party security firms. SAMA expects institutions to verify vendor credentials before engagement.
Methodology: Tests should follow recognized frameworks such as PTES or OWASP for web/API testing. Results must be documented with CVSS-scored findings, proof-of-concept evidence, and remediation timelines.
Remediation Tracking: Critical and high findings must be remediated within defined SLAs — typically 30 days for critical vulnerabilities per SAMA expectations. Evidence of remediation must be retained for audit purposes.
Reporting to Board/Senior Management: Summarized results should be escalated to the CISO and board-level risk committees as part of cybersecurity KPI reporting.
Retesting: A formal retest must validate that identified vulnerabilities have been effectively closed before sign-off.
Financial institutions should also consider Threat-Led Penetration Testing (TLPT) frameworks like TIBER-SA, which SAMA has been aligning with for advanced institutions. Maintaining a penetration testing register with dates, scope, findings, and remediation status is considered best practice and will be reviewed during SAMA regulatory inspections.
Penetration testing for Saudi fintechs must satisfy both SAMA CSF Control 3.4.5 (Vulnerability and Penetration Testing) and NCA ECC Control 2-8 (Technical Vulnerability Management). Here is a structured compliance-driven approach: (1) Frequency Requirements — SAMA CSF mandates external penetration testing at least annually and after significant infrastructure changes. Internal testing should occur semi-annually. NCA ECC aligns with this cadence for Critical National Infrastructure-adjacent entities. (2) Scope Definition — Tests must cover external-facing applications, APIs, mobile banking apps, internal network segments, and social engineering vectors. For fintechs handling payment data, cardholder environment testing may also trigger PCI DSS scope considerations. (3) Qualified Testers — SAMA expects tests to be performed by independent, qualified personnel. Internally, testers should hold certifications such as OSCP, CEH, or GPEN. External providers should demonstrate familiarity with Saudi regulatory expectations. (4) Reporting Standards — Reports must include executive summaries, technical findings categorized by CVSS severity, evidence screenshots, and remediation roadmaps with defined SLAs. SAMA examiners will review these reports during assessments. (5) Remediation Tracking — Critical and High findings must be remediated within 30 days per SAMA CSF expectations, with evidence of closure documented. (6) Retesting — Conduct mandatory retesting after critical vulnerability remediation to confirm closure. Maintain a penetration testing register with historical results to demonstrate program maturity to regulators and auditors.
Under SAMA CSF Control 3.3.5 (Vulnerability Assessment and Penetration Testing), Saudi banks and financial institutions are required to conduct structured penetration testing as part of their broader cybersecurity assurance program. Here are the key requirements and practical guidance:
Frequency Requirements:
- External penetration tests: At minimum annually, and after any significant infrastructure or application change
- Internal penetration tests: At least once per year
- Red team exercises: Recommended every 18–24 months for mature security programs
Scope Considerations: Tests must cover internet-facing systems, core banking applications, SWIFT environments, mobile banking apps, and internal network segments. API security testing is increasingly critical for fintechs.
Vendor Qualification: SAMA expects tests to be conducted by qualified third-party providers with demonstrable certifications (OSCP, CREST, CEH) or by a sufficiently independent internal red team. Results must not be self-assessed without independent validation.
Reporting and Remediation: Findings must be formally documented, risk-rated (Critical/High/Medium/Low), and remediated within defined SLAs — Critical findings typically within 15–30 days. Evidence of remediation must be retained for audit purposes.
NCA ECC Alignment: NCA ECC Article 2-10 on cybersecurity testing reinforces these requirements for entities under NCA scope, including financial sector entities dual-regulated by both SAMA and NCA.
Practical Tip: Integrate penetration test findings into your risk register and track them through your GRC platform to demonstrate continuous compliance posture to SAMA examiners during regulatory reviews.
Saudi banks must conduct penetration testing as a core component of their cybersecurity assurance program, with obligations rooted in both SAMA CSF Control 3.3.7 and NCA ECC Domain 2-7. Here is what compliance teams need to know:
Frequency and Scope:
- SAMA CSF requires at least annual penetration testing for critical systems, with additional testing after significant infrastructure changes.
- NCA ECC mandates testing across internal networks, external-facing applications, and critical assets.
Methodology Requirements:
- Tests must follow recognized methodologies such as PTES, OWASP, or TIBER-EU for threat-led exercises.
- Both black-box and gray-box approaches should be included depending on asset criticality.
Tester Qualifications:
- Testers must be independent — either a qualified internal red team or an accredited third-party firm.
- Preferred certifications include OSCP, CEH, and CREST, with the testing firm ideally registered with NCA-approved service providers.
Reporting and Remediation:
- A formal report must document findings by severity (Critical, High, Medium, Low).
- SAMA expects remediation of critical and high findings within defined SLAs — typically 30 days for critical vulnerabilities.
- Evidence of remediation must be retained for audit purposes.
Regulatory Submission:
- Summary results and remediation status may be required during SAMA examinations.
- NCA assessments may also request penetration test reports as part of ECC compliance evidence.
Practical tip: Maintain a penetration testing register that tracks scope, findings, remediation deadlines, and closure evidence. This significantly simplifies regulatory examination cycles.
Penetration testing for Saudi fintechs is not optional — it is a regulatory obligation under both SAMA CSF Control 3.3.6 and NCA ECC Control 2-13. Getting it right requires deliberate planning across scope, methodology, and reporting.
Regulatory Baseline:
- SAMA CSF requires vulnerability assessments and penetration tests to be conducted at least annually and after any significant system change.
- NCA ECC Article 2-13 mandates technical vulnerability management including periodic penetration testing for entities under NCA scope.
Scope Considerations for Fintechs: Your testing scope should cover: web and mobile applications (open banking APIs, payment gateways), internal network infrastructure, cloud environments (AWS, Azure, or local providers), and any SWIFT or card-processing integrations.
Methodology Standards: Use recognized methodologies such as OWASP Testing Guide for applications, PTES or OSSTMM for infrastructure, and TIBER-SA guidelines if applicable for threat-intelligence-led testing in the financial sector.
Tester Qualification: SAMA expects testers to be independent — either a qualified internal red team or an accredited third-party firm. NCA recommends using certified professionals (OSCP, CEH, or equivalent). Testers must sign NDAs and operate under formal rules of engagement.
Reporting & Remediation: Deliverable reports must include executive summaries for board-level reporting, technical findings mapped to CVSS scores, and remediation timelines. SAMA expects critical findings to be remediated within 30 days.
Continuous Testing: Beyond annual tests, fintechs should integrate automated scanning (DAST/SAST) into CI/CD pipelines to catch vulnerabilities before production deployment, demonstrating a mature DevSecOps posture to regulators.
Saudi financial institutions must conduct penetration testing as a core control under both SAMA CSF (Control 3.3.6 – Vulnerability Management) and NCA ECC (Domain 2-7: Penetration Testing). Here is what compliance teams need to know:
Frequency Requirements:
- External penetration testing: At minimum annually, and after any significant infrastructure change
- Internal network testing: At least once per year
- Web application and API testing: Before major releases and annually thereafter
Scope Considerations: Tests must cover internet-facing assets, internal network segments, critical banking applications (core banking, payment gateways), and increasingly, mobile banking apps. SAMA expects testing to extend to systems that process, store, or transmit customer financial data.
Provider Requirements: SAMA CSF recommends engaging qualified third-party providers. Testers should hold recognized certifications (OSCP, CEH, CREST) and operate under a formal rules of engagement document signed by senior management.
Reporting & Remediation: Findings must be categorized by severity (Critical, High, Medium, Low). Critical and High findings require documented remediation plans with tracked timelines — typically 30 days for Critical issues per SAMA expectations. Evidence of remediation must be retained for audit purposes.
Regulatory Reporting: Material vulnerabilities discovered during testing that pose systemic risk may trigger notification obligations to SAMA under the cybersecurity incident reporting framework.
Practical Tip: Integrate penetration testing results into your GRC platform's risk register to ensure findings feed directly into your risk treatment process and board-level reporting cycles.
Under SAMA CSF Control 3.3.7, Saudi banks and financial institutions are required to conduct regular penetration testing as part of a comprehensive vulnerability management program. At a minimum, penetration tests must be performed annually and after any significant infrastructure or application changes. SAMA expects tests to cover both external and internal attack surfaces, including network infrastructure, web applications, APIs, and mobile banking platforms.
For practical implementation, your penetration testing program should include: (1) Scope definition covering all critical assets as classified under your asset management policy; (2) Use of qualified testers — SAMA recommends CREST-accredited or equivalently certified providers; (3) Methodology aligned with OWASP, PTES, or NIST SP 800-115; (4) Full documentation of findings with CVSS-scored vulnerabilities; and (5) A remediation tracking process with defined SLAs — critical findings typically require remediation within 30 days.
Results must be presented to senior management and the Board Risk Committee. Retesting after remediation is mandatory to close the loop. NCA ECC Article 2-7 also reinforces these requirements for entities under NCA jurisdiction. Fintech firms licensed by SAMA should align their testing cadence with their risk profile — higher-risk platforms may require quarterly assessments. Our platform supports end-to-end pentest lifecycle management, from scope planning to remediation tracking and regulatory reporting.
Under SAMA CSF Control 3.3.6 (Vulnerability Assessment and Penetration Testing), Saudi banks and financial institutions are required to conduct penetration testing as a core component of their cybersecurity assurance program. Key requirements include:
Frequency: External penetration tests must be conducted at least annually, while critical systems and internet-facing applications should be tested after every significant change or release. Internal network assessments are recommended semi-annually for high-risk environments.
Scope: Tests must cover external perimeters, internal networks, web and mobile banking applications, APIs, and increasingly cloud-hosted infrastructure. Social engineering and phishing simulations are also expected under SAMA's broader cyber resilience expectations.
Methodology: SAMA expects assessments to follow recognized methodologies such as OWASP (for applications), PTES, or NIST SP 800-115. Red team exercises are encouraged for mature organizations to simulate advanced persistent threats.
Qualified Testers: Engagements should be conducted by qualified third parties with relevant certifications (OSCP, CEH, CREST) and must maintain independence from the development and operations teams.
Remediation Tracking: Findings must be risk-rated, tracked to closure, and evidenced for SAMA examination. Critical and high findings typically require remediation within 30–90 days depending on risk appetite.
Reporting: Results must be formally documented and presented to senior management and the Board Risk Committee where applicable.
Integrating penetration testing into your GRC platform allows automated tracking of findings, remediation workflows, and audit-ready reporting aligned to SAMA examination cycles.
Saudi banks must conduct penetration testing as a mandatory security assurance activity under both SAMA CSF (Control 3.3.6) and NCA ECC (Control ECC-2-1-3). Here is what compliance teams need to know:
Frequency & Scope: SAMA CSF requires penetration testing at least annually, and after any significant infrastructure or application change. Tests must cover external perimeter, internal network, web applications, mobile banking apps, and critical APIs.
Methodology: Tests should follow recognized frameworks such as PTES, OWASP Testing Guide (for applications), or TIBER-SA — the Saudi adaptation of the TIBER-EU threat intelligence-based ethical red teaming framework, which SAMA has increasingly encouraged for mature institutions.
Tester Qualifications: Engagements must be conducted by qualified professionals holding certifications such as OSCP, CEH, or CREST, and ideally performed by independent third parties to avoid conflicts of interest.
Remediation Obligations: SAMA CSF requires that findings be risk-rated, remediated within defined SLAs based on severity (critical findings typically within 15–30 days), and tracked to closure with evidence.
Reporting: Results must be reported to senior management and the board-level risk committee. NCA ECC further requires that critical vulnerabilities discovered are reported through appropriate governance channels.
Practical Tip: Maintain a penetration testing register within your GRC platform, linking each test to the relevant assets, findings, remediation tickets, and retesting evidence. This creates an auditable trail for both SAMA examiners and NCA assessors during compliance reviews.
Under SAMA CSF Control 3.3.4 and the broader Vulnerability Assessment and Penetration Testing (VAPT) domain, Saudi banks and financial institutions are required to conduct penetration testing as a core component of their cyber resilience program. SAMA mandates that penetration tests be performed at least annually for external-facing systems, and additionally after any significant infrastructure change, system upgrade, or merger and acquisition activity.
Key requirements include:
Scope: Tests must cover external perimeters, internal networks, critical applications (including internet banking and mobile platforms), and SWIFT environments where applicable.
Methodology: Engagements should follow recognized standards such as PTES (Penetration Testing Execution Standard), OWASP for application testing, and TIBER-SA for threat intelligence-led red team exercises, which SAMA increasingly encourages for Tier-1 institutions.
Provider Qualification: Third-party penetration testing firms must be assessed for technical competency. SAMA expects institutions to verify tester credentials (e.g., OSCP, CREST, CEH) and ensure testers sign appropriate NDAs and data handling agreements aligned with PDPL obligations.
Reporting & Remediation: All critical and high findings must be remediated within defined SLAs — typically 30 days for critical vulnerabilities. Findings must be tracked, risk-accepted with CISO sign-off where necessary, and reported to the Board Risk Committee.
Retesting: A formal retest must validate remediation effectiveness before closure.
Our GRC platform automates the tracking of VAPT findings, links them to SAMA CSF controls, and generates board-ready remediation status reports — ensuring your compliance posture remains audit-ready at all times.
The NCA Essential Cybersecurity Controls (ECC) — specifically ECC-2: 1-2 (Cybersecurity Assessment) — require organizations to conduct regular penetration testing as part of a broader vulnerability assessment program. Here is how to build a compliant, effective pentest program:
1. Frequency and Scope Requirements NCA ECC mandates at minimum annual penetration testing of critical systems. For financial institutions also under SAMA CSF Control 3.2, testing should occur: annually for infrastructure, after any major system change, and following significant security incidents. Scope must include external-facing assets, internal network segments, and web/mobile banking applications.
2. Methodology Standards Adopt recognized methodologies — PTES (Penetration Testing Execution Standard), OWASP Testing Guide for web applications, and TIBER-EU or CBEST framework principles for advanced threat simulation in financial contexts. Document your chosen methodology in your pentest policy.
3. Vendor Qualification Engaging a qualified, independent pentest provider is mandatory — avoid internal-only testing for compliance purposes. Preferred vendors should hold CREST accreditation or equivalent, and testers should carry certifications like OSCP, CEH, or GPEN. Verify they have experience in Saudi financial sector environments.
4. Rules of Engagement and Legal Authorization Before any test begins, obtain written authorization covering all in-scope systems. For cloud-hosted systems on AWS, Azure, or Alibaba Cloud (popular in KSA), obtain provider-specific pentest authorization to remain compliant with cloud agreements.
5. Remediation Tracking and Reporting All critical and high findings must be remediated within 30 days, medium findings within 90 days. Track remediation in your vulnerability management system and conduct a retest to verify closure. Submit findings summary to your CISO and risk committee — NCA may request evidence during audits.
6. Red Team vs. Pentest For mature organizations, consider graduating to red team exercises that simulate nation-state or advanced persistent threat (APT) actors — aligned with SAMA's expectations for Tier 1 banks.
Penetration testing (pentest) is explicitly required under both SAMA CSF and NCA ECC, and Saudi financial institutions must go beyond basic vulnerability scanning to satisfy regulators. Here is the mandatory framework:
SAMA CSF Requirements (Control 3.3.5 & Vulnerability Management Domain): SAMA mandates that financial institutions conduct comprehensive penetration tests at least annually and after any significant infrastructure change. Tests must cover external perimeter, internal network, web applications, and mobile banking platforms. Findings must be risk-rated, remediated within defined SLAs (critical findings typically within 30 days), and evidence submitted during SAMA examinations.
NCA ECC Requirements (ECC-1: 2-7 & Threat Management Controls): NCA ECC requires threat-informed testing that simulates real-world attack scenarios relevant to Saudi Arabia's threat landscape — including supply chain attacks, credential harvesting, and API abuse targeting open banking environments.
Mandatory Scope Elements:
- External network and internet-facing assets (including cloud-hosted systems)
- Web and mobile application testing (OWASP Top 10 methodology)
- Internal network segmentation validation
- Social engineering and phishing simulations
- SWIFT/payment infrastructure testing for banks
- API security testing for fintechs under SAMA Open Banking Framework
Tester Qualifications: SAMA strongly recommends using qualified third-party testers holding OSCP, CREST, or equivalent certifications. Internal red team exercises can supplement but not replace independent assessments.
Reporting: Deliverable reports must include executive summaries, technical findings with CVSS scoring, proof-of-concept evidence, and a remediation roadmap. Retain pentest reports for a minimum of 5 years per SAMA record-keeping requirements.
For fintechs under SAMA's regulatory sandbox, penetration testing is a prerequisite before obtaining a full operating license.
Both SAMA CSF and NCA ECC impose explicit penetration testing obligations on Saudi financial institutions, making this a non-negotiable compliance activity rather than an optional security exercise. Under SAMA CSF Control 3.3.5 (Vulnerability Management), member organizations must conduct regular penetration tests against their critical systems, applications, and network infrastructure. NCA ECC Article 2-14 similarly mandates periodic penetration testing as part of the broader vulnerability management lifecycle. Key requirements and scoping guidance: (1) Frequency — SAMA expects penetration tests at least annually for critical systems and after significant infrastructure changes, new product launches, or major application updates. NCA ECC aligns with this cadence for government-linked financial entities. (2) Scope Definition — tests must cover external-facing assets (internet-exposed applications, APIs, VPNs), internal network segments, Active Directory environments, and mobile/web banking applications. Scope should map directly to your asset inventory register. (3) Methodology — tests should follow recognized methodologies such as PTES (Penetration Testing Execution Standard), OWASP (for web and API testing), and TIBER-SA principles for threat-intelligence-led red team exercises at advanced maturity levels. (4) Tester Independence — SAMA strongly recommends using qualified external testers with relevant certifications (OSCP, CREST, CEH) to ensure objectivity. Internal red teams may supplement but not replace external assessments. (5) Remediation Tracking — findings must be risk-rated, remediated within defined SLAs (critical within 30 days is common practice), and re-tested to validate fixes. (6) Executive Reporting — results must be reported to senior management and the board risk committee, per SAMA's governance expectations. Fintechs should also consider API-specific penetration testing given their heavy reliance on open banking interfaces, ensuring OAuth flows, token management, and data exposure points are thoroughly assessed.
Saudi banks are required to conduct penetration testing as a core component of their cybersecurity assurance program. Under SAMA CSF Control 3.3.6, member organizations must perform regular penetration tests on critical systems, applications, and network infrastructure to identify exploitable vulnerabilities before threat actors do. NCA ECC-1:2018 Article 3.3.6 similarly mandates vulnerability assessments and ethical hacking exercises as part of the broader Cyber Threat Management domain.
Key requirements include:
Frequency: External penetration tests must be conducted at least annually, with additional tests required after major system changes, infrastructure upgrades, or post-incident remediation. Internal network assessments should follow a risk-based schedule.
Scope: Tests must cover external-facing assets (internet banking portals, APIs, mobile applications), internal networks, Active Directory environments, and critical financial systems such as core banking platforms and SWIFT infrastructure.
Methodology: Tests should follow recognized frameworks such as PTES (Penetration Testing Execution Standard), OWASP for web applications, and TIBER-EU principles where applicable. Red team exercises are strongly encouraged for mature security programs.
Provider Requirements: Penetration testing providers must be qualified, and findings must be formally documented, risk-rated, and tracked through to remediation. SAMA expects evidence of closure during regulatory examinations.
Reporting: Executive summaries and technical reports must be presented to the CISO and Board Risk Committee, with critical findings remediated within defined SLAs — typically 30 days for critical and 90 days for high-severity vulnerabilities.
Our platform helps you schedule, track, and evidence your penetration testing lifecycle in a single GRC dashboard, ensuring audit-ready documentation for SAMA and NCA examinations.
Saudi banks must conduct penetration testing as a mandatory control under both SAMA CSF (Control 3.3.12) and NCA ECC (Domain 2-13). Here is what compliance requires in practice:
Frequency Requirements:
- External penetration testing: At minimum annually, and after any significant infrastructure change
- Internal network penetration testing: At least once per year
- Web application and API testing: After every major release or change to critical systems
- Red team exercises: Recommended biannually for Tier 1 banks
Scope Expectations: Tests must cover internet-facing assets, internal networks, critical banking applications (core banking, SWIFT, payment gateways), and mobile banking platforms. SAMA expects scoping documents to be retained as evidence during examinations.
Provider Requirements: Penetration testing providers must be qualified. SAMA CSF strongly implies use of certified professionals (OSCP, CREST, CEH). NCA further requires that for government-linked entities, providers may need to hold NCA-recognized accreditation.
Reporting and Remediation: Findings must be documented in a formal report with CVSS scoring. Critical and high vulnerabilities must be remediated within defined SLAs — typically 30 days for critical findings per SAMA guidance. Evidence of remediation must be retained.
Regulatory Reporting: If penetration testing uncovers an active exploit or evidence of prior breach, this may trigger SAMA's cyber incident notification obligations under SAMA CSF Control 3.6.2, requiring timely reporting to SAMA.
Banks should maintain a penetration testing register as part of their vulnerability management program and present results during SAMA's annual cybersecurity maturity assessments.
Saudi banks must conduct penetration testing as a core component of their cybersecurity assurance program under SAMA CSF Control 3.3.7 and NCA ECC-1: 2-7. Regulatory expectations include the following:
Frequency & Scope: External and internal penetration tests must be performed at least annually, and additionally after any significant infrastructure change, major application release, or merger/acquisition activity. Critical internet-facing systems — including online banking portals, APIs, and mobile applications — require more frequent testing cycles.
Methodology: Tests should follow recognized methodologies such as PTES (Penetration Testing Execution Standard) or OWASP for web/mobile applications. Both black-box and grey-box approaches are acceptable; however, SAMA expects tests to simulate realistic threat actor behavior relevant to the Saudi financial sector.
Third-Party Testers: SAMA CSF strongly recommends using qualified independent third-party penetration testers who hold certifications such as OSCP, CREST, or equivalent credentials. Internal red team exercises may supplement but generally cannot replace third-party assessments for regulatory purposes.
Remediation & Reporting: All identified findings must be risk-rated (Critical, High, Medium, Low), assigned to system owners, and remediated within defined SLAs — typically 30 days for Critical and 90 days for High findings. A formal remediation report must be documented and retained.
Executive Reporting: Results must be reported to senior management and the board's Risk Committee, with evidence retained for regulatory examination.
Financial institutions that treat penetration testing as a checkbox exercise risk regulatory findings during SAMA audits. A mature program integrates test results into vulnerability management, threat modeling, and business continuity planning cycles.
Penetration testing is a formal requirement under SAMA CSF (Control 3.3 – Vulnerability Management) and NCA ECC (Control 2-8), and Saudi financial institutions are expected to maintain a structured, risk-based testing program — not just ad-hoc assessments.
Regulatory requirements:
- SAMA CSF requires annual penetration testing for critical systems and networks, with additional tests mandated after significant infrastructure changes or major incidents.
- NCA ECC Control 2-8 specifies that penetration tests must be conducted by qualified personnel or accredited third parties, covering network, application, and social engineering vectors.
- Tests must simulate real-world threat actors relevant to the Saudi financial sector — including APT-style scenarios given the region's threat landscape.
Scope considerations:
- Internet-facing applications, core banking systems, APIs, mobile banking apps, internal networks, and Active Directory/identity infrastructure should all be in scope.
- Red team exercises (adversary simulation) are increasingly expected by SAMA examiners for Tier 1 banks, going beyond standard pentest scope.
Finding management:
- All findings must be risk-rated (Critical, High, Medium, Low) and entered into a formal remediation tracking register.
- Critical and High findings require remediation within 30 and 90 days respectively, with documented evidence.
- Retest evidence must be retained to demonstrate closure — this is a key artifact during SAMA and NCA compliance examinations.
- Integrate pentest findings into your risk register and GRC platform for continuous visibility and trend analysis across assessment cycles.
A Vulnerability Assessment (VA) identifies and classifies security weaknesses in systems without actively exploiting them — it tells you what vulnerabilities exist. A Penetration Test (PT) goes further by actively attempting to exploit discovered vulnerabilities to determine the real-world impact — it tells you what an attacker could actually achieve. For regulatory compliance, both are often required.
For SAMA-regulated institutions, at minimum annually for all critical systems. For NCA ECC entities, at least annually. Best practice recommends: external PT annually, internal PT annually, web application PT for every major release, red team exercises every 1–2 years, and continuous vulnerability scanning.
Under SAMA CSF Control 3.3.5 (Vulnerability Management), Saudi banks and financial institutions are required to conduct penetration testing as part of a broader vulnerability management program. At a minimum, external penetration tests must be performed annually, while internal tests and application-level assessments are recommended at least once per year or after any significant infrastructure or application change.
Key requirements include:
Scope: Testing must cover external-facing systems, internal networks, critical applications (including mobile banking and APIs), and any newly deployed cloud infrastructure.
Methodology: Tests should follow recognized methodologies such as OWASP for web/API testing, PTES, or NIST SP 800-115 guidelines. Red team exercises simulating advanced persistent threats (APTs) are strongly recommended for Tier-1 banks.
Qualified Testers: Engagements must be conducted by qualified, independent professionals — either internal teams with proper segregation or NCA-licensed third-party providers.
Reporting & Remediation: A formal remediation plan must be produced post-assessment, with critical and high findings remediated within defined SLAs (typically 30 days for critical findings). Evidence of remediation must be documented for regulatory review.
NCA Alignment: NCA ECC Article 2-7 also mandates technical assessments including penetration testing for entities under its scope, requiring findings to be tracked through a formal risk register.
Best practice recommendation: Integrate penetration testing results into your GRC platform to automatically update risk ratings, trigger remediation workflows, and generate audit-ready reports ahead of SAMA and NCA regulatory examinations.
Under SAMA CSF Control 3.3.6 (Vulnerability Management), Saudi banks and financial institutions are required to conduct penetration testing as part of a structured vulnerability management program. The framework mandates at minimum an annual external and internal penetration test, with additional tests triggered by significant infrastructure changes, new system deployments, or post-incident reviews.
Key requirements include:
Scope: Tests must cover external-facing assets, internal network segments, web applications, APIs, and critical banking systems such as core banking platforms and payment gateways.
Methodology: Engagements should follow recognized methodologies such as PTES, OWASP Testing Guide, or NIST SP 800-115 to ensure consistency and thoroughness.
Qualified Testers: SAMA expects tests to be performed by qualified, independent parties — either certified internal teams (OSCP, CEH, CREST) or approved external vendors. Independence is critical; the testing team must not have been involved in building or maintaining the tested systems.
Reporting & Remediation: Findings must be formally documented with risk ratings (Critical, High, Medium, Low), root cause analysis, and actionable remediation guidance. SAMA CSF requires that critical and high findings be remediated within defined SLAs — typically 30 days for critical vulnerabilities.
Evidence for Audits: All penetration test reports, remediation evidence, and retesting results must be retained and made available to SAMA examiners upon request.
Practical tip: Align your penetration testing calendar with your annual SAMA CSF self-assessment cycle so that test results can directly inform your compliance posture and risk register updates.
Under SAMA CSF Control Domain 3.3 (Vulnerability Assessment and Penetration Testing), Saudi banks and financial institutions are required to conduct structured penetration testing as part of their ongoing cybersecurity assurance program. Key requirements include:
Frequency: External penetration tests must be performed at least annually, while critical systems and internet-facing applications should be tested after any significant change or major release. Internal network penetration testing is also required on a periodic basis.
Scope: Tests must cover external perimeter, internal network segments, web applications (including mobile banking apps), and APIs. Social engineering assessments may also be included.
Methodology: SAMA expects tests to follow recognized methodologies such as OWASP Testing Guide, PTES, or NIST SP 800-115. Findings must be risk-rated and tracked to remediation.
Third-Party Testers: SAMA recommends engaging qualified, independent external parties for penetration testing to ensure objectivity. Internal red team exercises can supplement but should not replace external assessments.
Remediation & Reporting: Critical and high findings must be remediated within defined SLAs — typically 30 days for critical vulnerabilities. Results must be documented and reported to senior management and the board's audit or risk committee.
NCA ECC Alignment: NCA ECC Article 2-7 also mandates vulnerability assessments and penetration testing for critical national infrastructure operators, including banks classified under CNI.
Practical tip: Build a penetration testing calendar aligned to your change management cycle, ensuring post-deployment tests are triggered automatically for high-risk system changes.
Under SAMA CSF Control Domain 3.3 (Cybersecurity Assessment), Saudi banks and financial institutions are required to conduct regular penetration testing as part of their broader vulnerability management and assurance program. Key requirements include: Frequency: External penetration tests must be performed at least annually, while critical internet-facing systems and core banking platforms should be tested more frequently — ideally semi-annually or after any significant infrastructure change. Scope: Tests must cover network infrastructure, web applications, mobile banking apps, internal systems, and social engineering vectors. SAMA expects tests to simulate realistic threat actor behavior relevant to the financial sector. Methodology: Tests should follow recognized methodologies such as OWASP, PTES, or NIST SP 800-115. Both black-box and gray-box approaches are acceptable, but gray-box is generally preferred for depth. Qualified Testers: Engagements must be conducted by qualified third parties or an internal red team with demonstrable competency. Certifications such as OSCP, CREST, or CEH are commonly referenced. Remediation Tracking: All critical and high findings must be remediated within defined SLAs (typically 30–60 days for critical), with evidence documented for SAMA examination. Reporting to Board: Per SAMA CSF Control 3.1, significant security findings from penetration tests must be escalated to senior management or the board's risk committee. Complement your penetration testing program with NCA ECC Article 2-4 controls around vulnerability assessments to ensure dual-framework alignment and avoid gaps during regulatory inspections.
Saudi financial institutions are required to conduct regular penetration testing as part of their cybersecurity assurance activities. Under SAMA CSF Control 3.3.7, member organizations must perform threat-led penetration testing at least annually, covering both internal and external attack surfaces, including web applications, APIs, network infrastructure, and critical business systems. NCA ECC-1:2018 Article 3-5 further mandates vulnerability assessments and penetration tests as part of a continuous cybersecurity evaluation cycle.
Practically, your penetration testing program should include:
• Scope definition: Cover internet-facing assets, internal networks, SWIFT environments, mobile banking apps, and OT/IoT where applicable. • Methodology: Align with recognized standards such as PTES, OWASP, or TIBER-EU (increasingly referenced by SAMA for threat intelligence-led testing). • Qualified testers: Use certified professionals (OSCP, CREST, or equivalent) — ideally from an approved third-party firm independent of your IT team. • Remediation tracking: All critical and high findings must have documented remediation plans with defined SLAs, typically 30 days for critical issues per SAMA expectations. • Reporting to governance: Results and remediation status should be reported to the CISO and Board Risk Committee as part of cybersecurity KPI reporting.
Financial institutions undergoing SAMA CSF maturity assessments will be evaluated on the frequency, depth, and follow-up quality of their penetration testing activities. Failing to demonstrate a mature testing program is one of the most common gaps identified during SAMA examinations. Integrating your pentest findings into your risk register and vulnerability management workflow ensures continuous improvement and audit readiness.
Under SAMA CSF Control 3.3.6 (Vulnerability Management) and Control 3.4.3 (Penetration Testing), Saudi banks and financial institutions are required to conduct structured penetration testing as part of their ongoing cybersecurity assurance program.
Minimum Requirements:
- Frequency: Full-scope penetration tests must be conducted at least annually, with targeted assessments triggered by major infrastructure changes, new application deployments, or post-incident reviews.
- Scope: Tests must cover external perimeter, internal network, web and mobile banking applications, APIs, and critical payment systems (including SWIFT environments).
- Methodology: Tests should follow recognized methodologies such as PTES, OWASP Testing Guide, or TIBER-EU (increasingly adopted by SAMA for systemic banks).
- Testers: Engagements must be conducted by qualified third-party specialists or a sufficiently independent internal red team. SAMA expects clear independence — internal IT staff conducting their own tests is not considered sufficient.
- Remediation Tracking: All identified findings must be risk-rated, assigned to owners, and remediated within defined SLAs — critical findings typically within 30 days.
- Reporting to Board: Summary results and remediation status should be reported to the Cybersecurity Committee and Board Risk Committee at least annually per SAMA CSF governance requirements.
Practical Tip: Align your penetration testing calendar with your SAMA CSF self-assessment cycle so that test results feed directly into your maturity scoring. NCA ECC Article 2-9 also independently mandates periodic technical assessments, so a single well-scoped engagement can satisfy both frameworks simultaneously.
Under SAMA CSF Control 3.3.6 (Vulnerability Management) and Control 3.3.7 (Penetration Testing), Saudi banks and financial institutions are required to conduct comprehensive penetration testing as part of a formal, risk-based cybersecurity program. SAMA mandates that penetration tests be performed at least annually, and additionally whenever significant changes occur to critical systems, infrastructure, or applications.
The scope of testing must cover external-facing assets, internal networks, web and mobile banking applications, APIs, and critical backend systems. Tests should be conducted by qualified third-party providers with recognized certifications such as OSCP, CREST, or equivalent. Banks are also expected to maintain clear rules of engagement, scoping documents, and formal remediation tracking.
Following each test, institutions must produce a detailed findings report and implement a remediation plan with defined timelines — typically critical findings within 15 days, high findings within 30 days, per SAMA's supervisory expectations. Retesting to verify remediation is strongly recommended.
Beyond annual testing, SAMA CSF encourages adopting a continuous threat-led penetration testing (TLPT) approach, aligned with frameworks like TIBER-EU adapted for the Saudi context. The NCA ECC Article 2-14 also reinforces vulnerability assessment and penetration testing obligations for entities under its jurisdiction.
Practically, CISOs should ensure penetration testing is integrated into the annual security calendar, budgeted appropriately, and findings are escalated to the Board-level Risk Committee as required under SAMA's governance expectations. Maintaining a remediation register and sharing anonymized threat intelligence with SAMA and FINCYBER further demonstrates a mature security posture.
Saudi financial institutions are required to conduct regular penetration testing as part of their cybersecurity posture management. Under SAMA CSF Control 3.3.4, member organizations must perform technical vulnerability assessments and penetration tests at least annually, and after any significant change to critical systems or infrastructure. NCA ECC Article 2-14 reinforces this by mandating ethical hacking exercises for entities classified under national critical infrastructure.
Key requirements include:
Scope Definition: Tests must cover external-facing assets, internal network segments, web and mobile banking applications, APIs, and SWIFT-connected systems. Social engineering and phishing simulations should also be included.
Methodology: Use recognized frameworks such as OWASP, PTES, or TIBER-EU adapted for Saudi context. Tests must simulate real-world threat actors relevant to the financial sector.
Provider Qualification: Penetration testing providers should be qualified and, where possible, certified under recognized bodies (CREST, OSCP, CEH). SAMA expects firms to use independent third parties rather than internal teams for objective assessments.
Remediation Tracking: Findings must be risk-rated, remediated within defined SLAs (critical findings within 30 days per SAMA guidance), and retested to confirm closure.
Reporting to Governance: Results must be reported to the CISO and Board-level risk committee, with trends tracked over time.
Fintechs operating under SAMA's regulatory sandbox should align with the same controls, even in early stages, to avoid compliance gaps upon full licensing. Maintaining a penetration testing register and integrating findings into your risk register are practical steps toward demonstrating continuous compliance.
Under SAMA CSF Control Domain 3.3 (Cyber Security Operations), financial institutions are required to conduct regular penetration testing as part of a comprehensive vulnerability management program. SAMA mandates that penetration tests be performed at least annually, with additional tests triggered by significant infrastructure changes, new application deployments, or post-incident assessments.
Key requirements include:
Scope: Tests must cover external-facing systems, internal networks, web and mobile banking applications, and API endpoints. Social engineering assessments are strongly recommended.
Qualified Testers: Engagements must be conducted by qualified professionals holding recognized certifications such as OSCP, CEH, or CREST. External testers must be vetted and bound by strict NDAs.
Methodology: Tests should align with industry frameworks such as OWASP (for applications) and PTES or NIST SP 800-115 for infrastructure. NCA ECC Article 2-14 further requires that findings be classified by severity and remediated within defined SLAs.
Reporting and Remediation: All critical and high findings must be remediated within 30 days, with documented evidence presented to the Board Risk Committee. SAMA expects that remediation status is tracked in a formal register.
Red Team Exercises: Mature institutions are encouraged to move beyond standard pen testing toward threat-led red team operations aligned with TIBER-SA or CBEST frameworks.
Failure to meet penetration testing obligations can result in SAMA supervisory action, including mandatory remediation orders or increased regulatory scrutiny during annual assessments. Our platform helps you schedule, track, and document all penetration testing activities within a unified GRC dashboard.
Under SAMA CSF Control 3.3.7 (Vulnerability Management) and Control 3.3.8 (Penetration Testing), Saudi banks and financial institutions are required to conduct penetration testing as part of a structured vulnerability management program. Key requirements include:
Frequency: External penetration tests must be performed at least annually, while internal tests should align with significant infrastructure changes, major application releases, or post-incident reviews. High-risk systems such as internet banking platforms, payment gateways, and core banking infrastructure warrant more frequent testing.
Scope: Tests must cover network infrastructure, web and mobile applications, API endpoints, and internal systems. Social engineering and phishing simulation exercises are also encouraged under the broader security assurance program.
Methodology: SAMA expects tests to follow recognized methodologies such as OWASP Testing Guide, PTES, or NIST SP 800-115. Both black-box and gray-box approaches may be applicable depending on the target system.
Qualified Testers: Testing must be conducted by qualified professionals — either internal red teams with verifiable credentials or third-party firms approved and vetted through the bank's vendor risk process. NCA also recommends testers hold certifications such as OSCP, CEH, or equivalent.
Reporting and Remediation: Findings must be documented in a formal report with risk-rated vulnerabilities. Critical and high findings should follow a remediation SLA — typically 30 days for critical issues per SAMA's risk appetite guidelines. Evidence of remediation must be retained for audit purposes.
Non-compliance with SAMA CSF penetration testing requirements can result in regulatory findings during SAMA examinations, so maintaining a test register with clear scheduling, scope, and remediation tracking is essential.
Saudi banks must conduct penetration testing as a core component of their cybersecurity assurance program. Under SAMA CSF Control 3.3.6, member organizations are required to perform regular penetration tests covering both internal and external attack surfaces, including network infrastructure, web applications, and APIs. NCA ECC Article 2-14 further mandates that critical national infrastructure entities — which includes Tier-1 banks — conduct penetration testing at least annually, and after any significant system change.
Practically speaking, your penetration testing program should:
- Scope comprehensively: Cover internet-facing applications, internal network segments, privileged access systems, and SWIFT infrastructure if applicable.
- Use qualified testers: Engage certified professionals (OSCP, CEH, CREST-certified) or approved third-party firms. SAMA expects evidence of tester qualifications.
- Follow a methodology: Align with PTES, OWASP Testing Guide, or NIST SP 800-115 to ensure structured and repeatable results.
- Test frequency: At minimum annually for full-scope tests; quarterly vulnerability assessments are considered best practice for high-risk systems.
- Remediate and re-test: SAMA CSF requires documented remediation plans with defined timelines. Critical findings (CVSS ≥ 9.0) should be remediated within 30 days.
- Report to governance: Summarized findings must be presented to the CISO and Board Risk Committee as part of the cybersecurity oversight cycle.
Importantly, red team exercises (adversary simulation) are increasingly expected by SAMA examiners as a maturity indicator beyond standard penetration testing. Maintaining a register of all testing activities, findings, and remediation evidence is essential for regulatory examination readiness.
Under SAMA CSF Control Domain 3.3 (Cyber Security Operations), Saudi banks and financial institutions are required to conduct regular penetration testing as part of a robust vulnerability management program. Specifically, SAMA CSF mandates that penetration tests be performed at least annually, and additionally after any significant infrastructure changes, major application releases, or material changes to the network architecture. Tests must cover external-facing assets, internal network segments, web and mobile banking applications, and critical back-office systems.
The scope should align with TIBER-SA (Threat Intelligence-Based Ethical Red Teaming) guidelines for systemically important institutions, simulating advanced persistent threat (APT) actor techniques. Findings must be risk-rated, documented, and remediated within defined SLAs — critical findings typically within 30 days per SAMA expectations.
Practically, your penetration testing program should:
- Engage CREST-accredited or equivalent qualified testers.
- Produce a formal report submitted to senior management and the Board Risk Committee.
- Track remediation through your GRC platform with evidence of closure.
- Feed results back into your risk register and threat intelligence cycle.
NCA ECC-1:2018 Article 2-13 also reinforces the need for periodic technical assessments. Non-compliance can trigger SAMA supervisory actions, so maintaining documented evidence of test cycles and remediation is critical for regulatory examinations.
Under SAMA CSF Control 3.3.7 (Vulnerability Assessment and Penetration Testing), Saudi banks and financial institutions are required to conduct structured penetration testing as part of their ongoing cybersecurity assurance program. Key requirements include: Frequency: External penetration tests must be performed at least annually, while internal assessments should align with major infrastructure changes or new system deployments. Scope: Tests must cover external-facing systems, internal networks, web applications, APIs, and mobile banking channels. Social engineering assessments are also strongly recommended. Methodology: Tests should follow recognized frameworks such as PTES, OWASP, or NIST SP 800-115. Red team exercises are increasingly expected for Tier 1 banks. Independence: SAMA expects engagements to be conducted by qualified, independent third-party providers — not solely internal teams. Providers should hold certifications such as OSCP, CREST, or equivalent. Reporting & Remediation: Findings must be formally documented, risk-rated (Critical/High/Medium/Low), and presented to senior management. Remediation timelines for Critical and High findings typically should not exceed 30 and 90 days respectively. Regulatory Notification: Critical vulnerabilities discovered during testing that indicate active exploitation risk may trigger SAMA's incident notification obligations. Banks should also cross-reference NCA ECC Article 2-14 on technical vulnerability management, which reinforces the requirement for periodic testing across government-affiliated financial entities. Maintaining a penetration testing register and tracking remediation progress is essential for demonstrating compliance during SAMA assessments.
Saudi financial institutions are required to conduct structured penetration testing programs under both SAMA CSF (Control 3.3.3) and NCA ECC (Domain 2-7). Here is what your organization must implement:
Frequency and Scope:
- External and internal penetration tests must be performed at least annually, and after any significant infrastructure change.
- Scope should cover internet-facing assets, internal networks, core banking systems, mobile/web applications, and APIs used for open banking or fintech integrations.
Methodology: Tests must follow recognized methodologies such as OWASP, PTES, or NIST SP 800-115. Red team exercises simulating advanced persistent threats (APTs) are strongly recommended for Tier-1 banks.
Provider Requirements:
- Testers must be qualified (OSCP, CEH, CREST-certified preferred) and independent from the internal IT team.
- SAMA expects that external providers are vetted through your third-party risk management process.
Reporting and Remediation:
- All findings must be documented with risk ratings (Critical/High/Medium/Low).
- Critical and High findings must be remediated within 30 and 90 days respectively, with evidence provided to your CISO and compliance function.
- Retesting must confirm remediation closure before sign-off.
Documentation for Regulators: Maintain penetration test reports, remediation logs, and closure evidence for a minimum of five years, as SAMA examiners routinely request this during assessments.
A mature program also integrates penetration test findings into your risk register and feeds lessons learned back into your security awareness and architecture review processes.
Under SAMA CSF Control 3.3.5 (Vulnerability Management) and Control 3.4 (Penetration Testing), Saudi banks and financial institutions are required to conduct structured penetration tests at defined intervals and upon significant changes to their IT environment.
Minimum Frequency Requirements:
- External penetration testing: At least annually
- Internal network penetration testing: At least annually
- Application-layer testing (web, mobile, API): After every major release or significant code change
- Red team exercises: Recommended every 18–24 months for Tier-1 institutions
Scope Considerations: Tests must cover all critical systems including core banking platforms, internet banking portals, mobile applications, SWIFT interfaces, and payment gateways. NCA ECC Article 2-4-1 further reinforces this by requiring vulnerability assessments and ethical hacking exercises as part of an organization's ongoing cyber hygiene.
Practical Guidance:
- Engage CREST-accredited or equivalent qualified testing firms
- Ensure test scope is formally approved by the CISO before engagement begins
- Document all findings in a remediation register with risk-rated priorities
- Critical and high findings should be remediated within 30 and 90 days respectively, per SAMA expectations
- Retain all penetration test reports for at least 5 years for audit purposes
Retesting: SAMA expects evidence of remediation verification — simply closing tickets is insufficient. Formal retesting or compensating control documentation is required.
Financial institutions should integrate penetration testing results into their risk register and report significant findings to the board-level risk committee, ensuring governance visibility into technical vulnerabilities.
Under SAMA CSF Control 3.3.7, Saudi banks and financial institutions are required to conduct regular penetration testing as part of their vulnerability management program. The framework mandates at minimum an annual external and internal penetration test, with additional testing triggered by significant infrastructure changes, new application deployments, or post-incident reviews.
Practically, most mature financial institutions conduct:
- External network penetration tests: At least annually, targeting internet-facing assets, APIs, and open banking interfaces.
- Internal network tests: Annually or after major network topology changes.
- Web and mobile application testing: Per SAMA CSF 3.3.6, critical applications such as core banking systems and mobile banking apps should be tested at least annually or before major releases.
- Red team exercises: Recommended biennially for Tier 1 banks to simulate advanced persistent threats.
Tests must be performed by qualified, independent third parties — ideally CREST-accredited or holding equivalent certifications recognized by SAMA. Findings must be formally documented, risk-rated, and remediated within defined timelines: critical vulnerabilities typically within 15–30 days per internal SLA benchmarks.
Remediation evidence must be retained and made available during SAMA regulatory examinations. Additionally, NCA ECC Article 2-7 aligns with these requirements, mandating periodic technical assessments to identify exploitable weaknesses.
A key gap often found during audits is the absence of re-testing after remediation — ensure your program includes a formal verification cycle. Integrating penetration test findings into your risk register and board reporting cycle demonstrates governance maturity that both SAMA examiners and NCA auditors look for.
Saudi financial institutions are required to conduct penetration testing as a core component of their cybersecurity assurance programs. Under SAMA CSF Control 3.3.5, member organizations must perform regular penetration testing across all critical systems, applications, and network infrastructure to identify exploitable vulnerabilities before adversaries do. Testing must be risk-based, covering external and internal threat scenarios.
NCA ECC Article 2-13 reinforces this by mandating periodic technical assessments including red team exercises and vulnerability assessments for entities classified under national critical infrastructure.
Practical requirements include:
- Annual minimum frequency for full-scope penetration tests, with additional testing after significant system changes or new deployments.
- Scope coverage: web applications, APIs, internal networks, Active Directory environments, and SWIFT interfaces where applicable.
- Qualified testers: Engagements should be conducted by certified professionals (OSCP, CREST, CEH) or accredited third-party firms approved by the institution's risk committee.
- Remediation tracking: All critical and high findings must have documented remediation plans with defined SLAs — typically 30 days for critical, 90 days for high severity.
- Retest validation: Remediated vulnerabilities must be retested to confirm closure before sign-off.
- Reporting to board: SAMA CSF requires that penetration testing results and remediation status be reported to senior management and the board risk committee.
Financial institutions should also consider including social engineering and phishing simulations to test human-layer defenses. Maintaining a pentest register and evidence trail is essential during SAMA regulatory examinations.
Saudi financial institutions must conduct penetration testing as a core component of their cybersecurity assurance programs. Under SAMA CSF Control 3.3.9, member organizations are required to perform regular penetration tests covering internal networks, external-facing systems, web applications, and critical infrastructure. Tests must be conducted at least annually, and additionally after any significant infrastructure or application change.
NCA ECC-1:2018 Article 3.3 reinforces this by mandating vulnerability assessments and penetration tests for national critical systems, with findings tracked to closure. For financial institutions classified as critical national infrastructure, the frequency expectation is higher — often semi-annual.
Practical guidance for compliance teams:
- Scope broadly: Include core banking systems, payment gateways, APIs, mobile banking apps, and cloud environments.
- Use qualified providers: Engage testers certified under OSCP, CREST, or equivalent, and verify the firm is approved by NCA or holds recognized accreditations.
- Define rules of engagement: Document scope, testing windows, emergency contacts, and out-of-scope systems before testing begins.
- Track remediation: SAMA CSF requires evidence that identified vulnerabilities are remediated within defined SLAs — critical findings typically within 30 days.
- Report to governance: Share summarized findings with the Board Risk Committee or CISO as part of your cybersecurity assurance reporting.
Red team exercises simulating advanced persistent threats (APT) are increasingly expected for Tier 1 banks. Ensure your penetration testing program feeds directly into your vulnerability management lifecycle to demonstrate continuous improvement to regulators.
Penetration testing is a mandatory cybersecurity control under both SAMA CSF and NCA ECC, and Saudi financial institutions must meet specific requirements across scope, frequency, and reporting.
SAMA CSF Requirements (Control 3.3.5 – Vulnerability Management) SAMA expects Member Organizations to conduct external and internal penetration tests at least annually, and additionally after significant infrastructure changes. Tests must cover network infrastructure, web applications, mobile banking apps, APIs, and critical internal systems.
NCA ECC Requirements (ECC-1: 2-5 Vulnerability Assessment) NCA ECC mandates regular vulnerability assessments and penetration testing as part of the organization's security assurance program. Government-affiliated financial entities may also be subject to the National Penetration Testing Framework (NPTF) guidelines.
Scope Recommendations for Banks & Fintechs:
- External network penetration testing (internet-facing assets)
- Internal network segmentation testing
- Web and mobile application testing (OWASP Top 10)
- API security testing for open banking interfaces
- Social engineering and phishing simulations
- ATM and POS security assessments (for retail banks)
Testing Frequency Best Practice:
- Full penetration test: Annually at minimum
- Critical application testing: After every major release
- Vulnerability scans: Monthly or quarterly
- Red team exercises: Every 18–24 months for Tier-1 institutions
Reporting & Remediation: All penetration test reports must be retained and made available during SAMA or NCA audits. Critical and high-severity findings must be remediated within 30 and 90 days respectively, with documented evidence of closure.
Practical Tip: Ensure your penetration testing provider is qualified (CREST-accredited or equivalent) and that your Rules of Engagement (RoE) document is signed before testing begins to protect both parties legally.
Under SAMA CSF Control Domain 3.3 (Cybersecurity Operations), Saudi banks are required to conduct regular penetration testing as part of a comprehensive vulnerability management program. Specifically, SAMA CSF mandates the following:
Frequency Requirements:
- External penetration testing: at minimum annually, and after any significant infrastructure change
- Internal penetration testing: at minimum annually
- Critical systems (e.g., core banking, payment gateways): recommended semi-annually
- Web application penetration testing: before any major release and annually thereafter
Scope Expectations: Tests must cover network infrastructure, web and mobile applications, APIs, and social engineering vectors. Red team exercises are strongly encouraged for Tier-1 institutions.
Testing Standards: SAMA expects tests to follow recognized methodologies such as OWASP Testing Guide, PTES, or NIST SP 800-115. Testers should hold relevant certifications (OSCP, CREST, CEH).
Remediation Obligations: Critical and high findings must be remediated within defined SLAs — typically 15 days for critical vulnerabilities. All findings must be tracked, with evidence provided to internal audit and SAMA examiners upon request.
Reporting: A formal penetration test report must be reviewed by senior management and the CISO. Residual risk acceptance must be documented and approved.
NCA ECC Article 2-7 similarly mandates vulnerability assessments and ethical hacking exercises for government-affiliated entities. Aligning both frameworks in a unified testing calendar reduces duplication and ensures comprehensive coverage across all regulatory obligations.
Under SAMA CSF Control 3.3.8, Saudi banks and financial institutions are required to conduct regular penetration testing as part of their vulnerability management program. Here are the critical requirements:
Frequency & Scope:
- External and internal penetration tests must be performed at least annually
- Tests should also be triggered after significant infrastructure changes, major application releases, or following a security incident
- Scope must cover internet-facing systems, internal networks, core banking applications, and mobile/web channels
Methodology & Standards:
- Tests should follow recognized methodologies such as OWASP, PTES, or OSSTMM
- Red team exercises are encouraged for mature security programs to simulate advanced persistent threats (APTs)
- NCA ECC Control 2-5-3 further reinforces the need for periodic technical assessments
Provider Requirements:
- SAMA expects penetration testing to be conducted by qualified, independent parties — internal teams alone are generally insufficient for compliance evidence
- Testers should hold relevant certifications (OSCP, CREST, CEH) and ideally be approved by a recognized body
Remediation & Reporting:
- Critical and high findings must be remediated within defined SLAs — typically 30 days for critical vulnerabilities
- A formal remediation tracking process must be documented and evidence retained for SAMA examination
- Retest validation is mandatory to confirm fixes are effective
Practical Tip: Integrate penetration testing results into your risk register and present them to the board-level risk committee to demonstrate governance alignment per SAMA CSF Domain 3.
Under SAMA CSF Control 3.3.4 (Vulnerability Management) and Control 3.3.5 (Penetration Testing), Saudi banks and financial institutions are required to conduct penetration testing as part of a formal, risk-based security assessment program. SAMA mandates at minimum an annual external and internal penetration test, with additional testing triggered after significant infrastructure changes, new product launches, or major system upgrades.
Key requirements include:
Scope: Tests must cover network infrastructure, web applications, mobile banking platforms, APIs, and critical internal systems. SWIFT environments require dedicated testing per SWIFT CSCF controls.
Methodology: Tests should follow recognized frameworks such as PTES, OWASP, or OSSTMM, ensuring both black-box and grey-box scenarios are covered.
Qualified Testers: SAMA expects tests to be conducted by qualified, independent third parties or an internal red team with verifiable certifications (e.g., OSCP, CEH, CREST). Testers must be separate from the teams that built or manage the tested systems.
Reporting & Remediation: Findings must be formally documented, risk-rated (Critical/High/Medium/Low), and remediated within defined SLAs — typically 30 days for Critical findings and 90 days for High. Evidence of remediation must be retained for audit purposes.
Board Visibility: Per SAMA CSF governance requirements, penetration testing results and remediation status should be reported to senior management or the Board Risk Committee at least annually.
Financial institutions should also align their penetration testing program with NCA ECC Article 2-11 (Security Assessment and Testing), which reinforces similar expectations for all critical national infrastructure entities. A mature program treats pen testing not as a checkbox exercise but as a continuous intelligence-gathering mechanism to validate defensive controls.
Under SAMA CSF Control 3.3.7, Saudi banks and financial institutions are required to conduct regular penetration testing as part of their vulnerability management and cyber resilience programs. At minimum, banks must perform: (1) Annual full-scope penetration tests covering external perimeter, internal network, web applications, and APIs; (2) Targeted tests following any significant infrastructure change, application release, or major incident; (3) Red team exercises at least once every two years for Tier-1 institutions. Tests must be conducted by qualified third-party providers or a certified internal team — testers must hold recognized certifications such as OSCP, CREST, or equivalent. Methodology should align with industry standards like OWASP Testing Guide and PTES. Critical findings (Critical/High severity) must be remediated within 30–90 days depending on risk rating, and evidence of remediation must be documented and retained. Results must be reported to the CISO and Board Risk Committee. Additionally, NCA ECC Article 2-14 reinforces the requirement for periodic technical assessments. Our platform supports this by automating finding tracking, generating SAMA-aligned remediation reports, and maintaining a full audit trail for regulatory review.
Under SAMA CSF Control 3.3.5 (Vulnerability Management), Saudi banks and financial institutions are required to conduct regular penetration testing as part of a comprehensive vulnerability management program. The framework mandates at minimum an annual external and internal penetration test, with additional tests triggered by significant infrastructure changes, new application deployments, or post-incident reviews.
Key requirements include:
Scope & Coverage: Tests must cover external-facing systems, internal networks, critical banking applications (core banking, payment gateways, mobile apps), and OT/SWIFT environments where applicable.
Methodology: SAMA expects testing aligned with recognized methodologies such as OWASP for web applications and PTES or OSSTMM for infrastructure assessments. NCA ECC Article 2-14 further reinforces the need for structured technical assessments.
Qualified Testers: Tests should be conducted by qualified internal teams or CREST/CHECK-accredited third-party providers. Independence from the development and operations team is essential.
Reporting & Remediation: Findings must be formally documented, risk-rated, and tracked through a remediation plan. Critical and high-risk vulnerabilities should be remediated within 30 days, with evidence submitted to relevant governance committees.
Red Team Exercises: For larger institutions, SAMA increasingly expects adversary simulation (red team) exercises aligned with frameworks like TIBER-SA to test detection and response capabilities beyond standard pentest scope.
Practical Tip: Maintain a penetration testing register that logs test dates, scope, findings, remediation status, and retesting results. This register is commonly requested during SAMA regulatory examinations.
Penetration testing in Saudi financial institutions must satisfy both SAMA CSF (Control 3.3.7 – Vulnerability Management) and NCA ECC (Article 2-8, Technical Vulnerability Management). Here is a practical framework: Frequency: Conduct external penetration tests at least annually and after any major system change. Internal network and application-layer tests should also follow an annual cycle, with critical internet-facing assets tested more frequently. Scope Definition: Define scope to cover internet-facing applications, internal networks, ATM/POS infrastructure, APIs, and mobile banking apps. SAMA examiners expect evidence that scope covers crown-jewel systems. Methodology: Use recognized methodologies such as PTES, OWASP (for web/mobile), and NIST SP 800-115. Red team engagements simulating APT scenarios are increasingly expected by SAMA for Tier-1 banks. Vendor Qualification: Engage only qualified providers — ideally holding CREST accreditation or equivalent. NCA additionally requires that vendors operating on government-linked infrastructure be assessed for supply chain risk. Remediation Tracking: All critical and high findings must have a documented remediation plan with ownership and deadlines. SAMA expects critical findings to be remediated within 30 days. Retest all critical and high vulnerabilities before closing findings. Reporting and Retention: Maintain penetration test reports, remediation evidence, and retesting records for a minimum of five years per SAMA data retention guidelines. Share executive summaries with the board's Risk or Audit Committee annually.
Under SAMA CSF Control 3.3.6, Saudi banks and financial institutions are required to conduct regular penetration testing as a core component of their vulnerability management program. The framework mandates at minimum an annual external penetration test, while internal network testing should align with significant infrastructure changes or at least annually. Institutions with internet-facing applications — particularly mobile banking and open banking APIs — should conduct application-layer penetration tests (including OWASP Top 10 coverage) before major releases and at least semi-annually in production. Tests must be performed by qualified, independent parties — either accredited third-party firms or a sufficiently independent internal red team. Key requirements include: (1) scoping that covers all critical assets identified in your asset register per SAMA CSF Control 3.2.1; (2) a formal remediation plan with SLA-tracked closure of critical and high findings within 30 and 90 days respectively; (3) executive and board-level reporting of results; and (4) retesting to validate remediation. NCA ECC Article 2-5 similarly requires periodic technical assessments including penetration testing for entities under its scope. Findings must feed directly into your risk register and be tracked through your GRC platform. Avoid treating penetration testing as a checkbox — integrate results into your threat intelligence cycle and use them to validate your security controls against real-world attack scenarios relevant to the Saudi financial sector.
Under SAMA CSF Control 3.3.4 (Vulnerability Management) and Control 3.3.5 (Penetration Testing), Saudi banks and financial institutions are required to conduct penetration testing as part of a structured vulnerability management program. Key requirements include:
Frequency: External penetration tests must be conducted at least annually, while critical systems and internet-facing applications should be tested more frequently — ideally after any major infrastructure or application change.
Scope: Tests must cover network infrastructure, web and mobile banking applications, internal systems, and social engineering vectors. API security testing is increasingly important for fintechs.
Methodology: Tests should follow recognized methodologies such as OWASP Testing Guide, PTES, or NIST SP 800-115. Both black-box and grey-box approaches are acceptable, but SAMA expects realistic threat simulation.
Qualified Testers: Engagements must be conducted by qualified professionals holding certifications such as OSCP, CEH, or CREST, and preferably by a third-party firm independent from your internal security team.
Remediation Tracking: Findings must be risk-rated, remediated within defined SLAs (critical findings typically within 15–30 days), and tracked to closure. Evidence of remediation must be retained for audit purposes.
Reporting to Board: Material findings should be escalated to the CISO and risk committee. SAMA examiners will review pen test reports during regulatory assessments.
Aligning your penetration testing program with NCA ECC Article 2-14 additionally ensures broader compliance coverage for institutions subject to both frameworks.
Under SAMA CSF Control Domain 3.3 (Cybersecurity Resilience), Saudi banks and financial institutions are required to conduct regular penetration testing as part of their cybersecurity assurance program. Specifically, SAMA CSF mandates annual penetration tests for all critical systems and applications, with additional testing required following significant infrastructure changes, new product launches, or post-incident remediation.
The testing scope must cover external and internal network infrastructure, web and mobile banking applications, APIs, and any third-party integrated systems. Assessments should follow recognized methodologies such as PTES (Penetration Testing Execution Standard) or OWASP for application-layer testing.
Key requirements include:
- Testing by qualified, independent parties: Internal teams may conduct routine assessments, but annual tests must be performed by certified third-party firms (CREST or equivalent).
- Remediation timelines: Critical findings (CVSS ≥ 9.0) must be remediated within 30 days; high findings within 90 days per SAMA CSF guidance.
- Retesting validation: Remediated vulnerabilities must be re-verified before closure.
- Reporting to board/senior management: Penetration test results and remediation status must be reported to the CISO and relevant governance committees.
NCA ECC Article 3-5 also reinforces these obligations for entities operating critical national infrastructure. Aligning your penetration testing program with both SAMA CSF and NCA ECC ensures dual compliance and reduces regulatory risk. Maintain all test reports, remediation evidence, and retesting records for a minimum of five years to satisfy audit and regulatory review requirements.
Penetration testing is explicitly required under SAMA CSF Control 4.4.2 and NCA ECC-2: 1-7, making it a non-negotiable compliance activity for Saudi banks, fintechs, and financial institutions. Here is how to build a compliant and effective penetration testing program:
Frequency Requirements:
- SAMA CSF mandates at least annual penetration testing for critical systems
- Tests must also be triggered after significant infrastructure changes, major application releases, or post-incident remediation
- NCA ECC recommends Red Team exercises for Tier-1 critical national infrastructure entities
Scope Definition: Define scope to cover external-facing assets (internet-exposed applications, APIs, portals), internal network segments, core banking platforms, and payment systems. SAMA expects coverage of all critical business services.
Vendor Requirements: Engage only qualified, certified penetration testing providers. Preferred certifications include OSCP, CREST, CHECK, or equivalent. For Saudi financial institutions, vendors should be familiar with SAMA's regulatory environment and possess a valid CITC/NCA approved provider status where applicable.
Methodology: Follow recognized standards — PTES (Penetration Testing Execution Standard), OWASP Testing Guide for web applications, and TIBER-EU/TIBER-SA (threat intelligence-based) for advanced red team exercises.
Reporting & Remediation: All critical and high findings must be remediated within defined SLAs (typically 30 days for critical). Maintain a formal remediation tracking register and conduct retesting to verify fixes.
Audit Evidence: SAMA examiners will request pentest reports, remediation logs, and sign-off evidence. Ensure reports are stored securely and accessible through your GRC platform with appropriate access controls to protect sensitive vulnerability information.
Penetration testing is a mandatory control under SAMA CSF Domain 3.2 (Cybersecurity Risk Management) and Control 3.2.5, requiring Saudi banks to conduct structured and periodic offensive security assessments.
Regulatory Baseline Requirements
- External and internal penetration tests must be conducted at least annually, or following significant infrastructure changes.
- Tests must be performed by qualified, independent parties — internal teams may conduct supplemental tests but cannot satisfy the independence requirement alone.
- Results, remediation plans, and retesting evidence must be documented and retained for regulatory review.
Recommended Scoping Approach Scope should align with your asset criticality register. At minimum, include: internet-facing applications and APIs, core banking system interfaces, SWIFT/payment infrastructure, Active Directory and identity systems, and OT/network perimeter where applicable.
Methodology Standards Adopt recognized frameworks such as PTES (Penetration Testing Execution Standard), OWASP Testing Guide for web applications, and MITRE ATT&CK for adversary simulation. For financial sector relevance, TIBER-EU and CBEST-aligned threat-led testing is increasingly expected by SAMA examiners.
Red Team vs. Pen Test For Tier 1 banks, SAMA increasingly expects Red Team exercises simulating sophisticated, persistent adversaries — not just point-in-time vulnerability exploitation. Red Team engagements should target detection and response capability, not just technical controls.
Reporting & Remediation All Critical and High findings must have remediation timelines defined within the report. SAMA expects evidence of tracked remediation in your GRC system, with Board or Risk Committee visibility on unresolved critical findings.
Ensure your pentest vendor provides CVSS-scored findings mapped to SAMA CSF controls for direct GRC platform integration.
Penetration testing is a mandatory control under both SAMA CSF (Control 3.3.7 – Vulnerability Management) and NCA ECC (Article 2-13 – Technical Vulnerability Management), requiring Saudi financial institutions to conduct regular, structured adversarial testing of their environments.
Mandatory Frequency:
- External penetration testing: At minimum annually, and after any major infrastructure change.
- Internal penetration testing: Annually.
- Application-layer testing (web/mobile/API): After every major release or annually, whichever is more frequent.
- Red Team exercises: SAMA CSF recommends advanced threat simulation for Tier 1 institutions at least every two years.
Scoping Best Practices:
- Define scope clearly: Include internet-facing assets, core banking APIs, mobile banking apps, SWIFT interfaces, and internal network segments handling cardholder or customer PII data.
- Rules of Engagement (RoE): Establish explicit RoE documenting permitted attack techniques, out-of-scope systems (e.g., live production ATMs), escalation procedures, and emergency contacts.
- Methodology alignment: Tests should follow recognized methodologies — PTES, OWASP Testing Guide for web apps, OWASP Mobile Security Testing Guide for mobile apps, and NIST SP 800-115.
- Third-party vs. internal: SAMA CSF expects external, independent testers for critical systems. Internal teams may conduct supplementary testing but should not be the sole testers.
Remediation & Reporting: All critical and high-severity findings must be remediated within 30 days. A formal remediation report should be submitted to the CISO and Board-level Risk Committee. NCA ECC requires findings to feed into the organization's vulnerability register and risk treatment plan.
Practical Tip: Engage CREST-accredited or Saudi CITC-approved testing firms to ensure regulatory acceptance of results.
Saudi banks must establish a structured, risk-based penetration testing program that satisfies both SAMA CSF Control 3.3.7 (Vulnerability Management) and NCA ECC-1:2018 Article 3-3 (Technical Vulnerability Management). At minimum, your program should include the following elements:
Frequency & Scope: Conduct full-scope external and internal penetration tests at least annually, and after any significant infrastructure or application change. SAMA CSF requires continuous vulnerability assessments, while NCA ECC mandates periodic technical evaluations of critical national infrastructure components.
Methodology: Use internationally recognized methodologies such as OWASP Testing Guide for web applications, PTES (Penetration Testing Execution Standard) for network and infrastructure, and TIBER-EU or CBEST frameworks for advanced threat intelligence-led red team exercises — which SAMA increasingly expects from Tier-1 banks.
Scoping: Ensure scope covers internet-facing assets, internal network segments, SWIFT infrastructure (per SWIFT CSCF), mobile banking applications, ATM networks, and third-party-connected systems. Do not exclude legacy systems — regulators pay close attention here.
Qualified Testers: SAMA CSF and NCA ECC both require tests to be conducted by qualified, independent parties. Testers should hold recognized credentials (OSCP, CREST, CEH) and should not have been involved in building or administering the tested systems.
Remediation & Reporting: Critical and high findings must be remediated within defined SLAs — typically 15 days for critical, 30 days for high. Maintain a formal remediation tracking register and evidence of retesting. SAMA may request this documentation during examinations.
Executive Reporting: Produce both technical reports (for security teams) and executive summaries (for the Board and Risk Committee) to fulfill SAMA CSF governance reporting obligations.
The NCA Essential Cybersecurity Controls (ECC) mandate a structured approach to vulnerability assessment and penetration testing (VAPT) for all entities under its scope, including government bodies, semi-government entities, and operators of critical national infrastructure (CNI). These requirements are anchored primarily in ECC Domain 2 (Cybersecurity Defense) and related annexes.
Core NCA ECC Penetration Testing Requirements:
1. Scope and Frequency (ECC 2-13): Organizations must conduct penetration tests at least annually and after any significant change to the IT/OT environment — including major system upgrades, infrastructure changes, or post-incident recovery. Ad-hoc tests must be risk-justified and documented.
2. Qualified Testers: NCA strongly recommends using licensed penetration testing firms, ideally those holding NCA-recognized certifications or CREST accreditation. Internal red team capabilities are acceptable if independence and skill can be demonstrated.
3. Scope Coverage: Tests must cover external perimeter, internal network, web applications, APIs, and — for CNI operators — OT/ICS environments where applicable. Social engineering components (phishing simulations) should be included per ECC 2-14.
4. Methodology Alignment: Align testing methodology with recognized standards such as PTES (Penetration Testing Execution Standard), OWASP WSTG for web applications, and IEC 62443 for ICS/OT environments.
5. Remediation Tracking: ECC requires that all critical and high findings be remediated within defined SLAs and that a formal remediation report be submitted. Open vulnerabilities must be tracked in your vulnerability management system.
6. Reporting to NCSC: For CNI operators, significant findings — especially those exploiting production systems — may require disclosure to the NCA National Cybersecurity Operations Center (NCOC).
Practical Tip: Maintain a penetration testing charter document that defines scope, rules of engagement, and approval authority. This satisfies both NCA ECC audit requirements and demonstrates governance maturity during SAMA CSF assessments.
Under SAMA CSF Domain 4 (Cybersecurity Operations), Saudi banks and financial institutions must conduct penetration testing as a core component of their vulnerability management and threat assessment program. Specifically, SAMA CSF Control 4.3 mandates that member organizations perform penetration testing at least annually, and additionally after any significant infrastructure change, major application release, or following a material cybersecurity incident.
Tests must cover all critical assets including internet-facing systems, core banking platforms, internal networks, and mobile/web applications. SAMA expects engagements to follow a recognized methodology such as OWASP, PTES, or TIBER-EU for advanced threat simulation. Testers must be qualified — either certified internal red team professionals (OSCP, GPEN, CEH) or approved third-party firms.
Key practical requirements include:
- Scoping: Cover external, internal, and application layers.
- Reporting: Findings must be risk-rated, remediation timelines assigned, and results presented to senior management and the Board Risk Committee.
- Remediation Tracking: Critical and high findings must be remediated within 30–90 days depending on severity, with evidence documented.
- Retesting: Mandatory retesting after remediation to confirm closure.
- NCA ECC Alignment: NCA ECC Article 2-7 further requires that penetration test reports and remediation plans be maintained as audit evidence available to regulators upon request.
For fintechs under SAMA's regulatory sandbox, similar obligations apply with proportional scoping based on risk profile. Our platform automates pentest scheduling, finding intake, remediation workflows, and audit-ready reporting to keep your institution continuously compliant.
Penetration testing is a mandatory control under both SAMA CSF and NCA ECC, and Saudi banks must approach it as a structured, risk-driven program — not a checkbox exercise.
SAMA CSF Requirements (Control 3.3.6 – Vulnerability Management):
- External penetration testing: annually at minimum, plus after significant infrastructure changes
- Internal network penetration testing: annually
- Application-level testing (OWASP-based) for all customer-facing banking applications: before major releases and annually
- Red team exercises for Tier-1 banks: recommended biannually to simulate advanced persistent threats (APTs)
NCA ECC Requirements (Article 2-7 – Cybersecurity Assessment):
- NCA mandates periodic security assessments including penetration tests for entities classified as Critical National Infrastructure (CNI). Most major Saudi banks fall under CNI classification.
- Tests must cover network, application, and physical security layers.
- Testers must hold recognized certifications such as OSCP, CREST, or equivalent.
Scope Considerations for Banks:
- Core banking systems (CBS), mobile banking apps, APIs, SWIFT infrastructure, and ATM networks must all be in scope
- Social engineering tests (phishing simulations) should complement technical testing
- Cloud-hosted environments require separate cloud penetration testing scope
Findings Management: SAMA CSF requires a formal remediation process:
- Critical/High findings: Remediate within 30 days
- Medium findings: Remediate within 90 days
- Low findings: Track in risk register with defined timelines
All pentest reports, remediation evidence, and exception approvals must be retained for at least 5 years and be available for SAMA regulatory inspection.
Our platform provides pentest program templates, finding trackers integrated with your risk register, and pre-mapped control evidence for SAMA and NCA audit cycles.
The NCA Essential Cybersecurity Controls (ECC) mandate penetration testing as a core technical assurance activity under Control Domain 2-5 (Cybersecurity Resilience — Penetration Testing). Here is a comprehensive guide for Saudi organizations:
NCA ECC Requirements: Control 2-5-1 requires organizations to conduct penetration tests on all critical systems, applications, and network infrastructure. Tests must be performed by qualified, independent testers — internal or accredited third-party specialists. The NCA expects evidence of findings, remediation actions, and retesting validation.
Mandatory Frequency: NCA ECC stipulates penetration tests must be conducted at least annually. However, additional tests are required following significant changes such as major system upgrades, new application deployments, network architecture changes, or after a confirmed security incident.
Scoping Your Engagement: Effective scoping should cover: External perimeter testing (internet-facing assets, APIs, web applications), Internal network testing (lateral movement, privilege escalation), Application-layer testing (OWASP Top 10 for web and mobile apps), Social engineering assessments (phishing simulations), and Wireless network security assessments. For financial institutions, also include SWIFT environment testing and payment system interfaces.
Methodology Standards: Adopt recognized methodologies such as PTES (Penetration Testing Execution Standard), OWASP Testing Guide, or NIST SP 800-115. These align with NCA expectations for structured, repeatable, and evidence-based testing.
Reporting & Remediation: Pentest reports must include a risk-rated finding register (Critical/High/Medium/Low), root cause analysis, and actionable remediation guidance. Organizations should track remediation through a formal vulnerability management process and complete retest validation before closing high-severity findings.
Always ensure your pentest provider signs a formal Rules of Engagement (RoE) document and obtains written authorization before testing begins.
Penetration testing is a critical control activity mandated across both SAMA CSF and NCA ECC for Saudi financial institutions. Understanding the specific requirements — and how to operationalize results — is essential for compliance and genuine risk reduction.
SAMA CSF Requirements: Under Control Domain 3 (Cybersecurity Operations), SAMA requires financial institutions to conduct penetration tests on all critical systems and internet-facing applications at least annually, and following any significant infrastructure change. The scope must include external network testing, internal network testing, and application-layer testing (web and mobile). Results must be formally reported to senior management.
NCA ECC Requirements: NCA ECC Article 3-9 mandates that organizations conduct technical vulnerability assessments and penetration tests as part of their continuous risk management cycle. For entities classified under critical national infrastructure, testing frequency expectations may increase to semi-annual.
Scope and Methodology Guidance:
- Engage only CREST-certified or equivalent qualified firms with verifiable Saudi financial sector experience.
- Define scope to include APIs, mobile banking apps, core banking interfaces, ATM networks, and SWIFT connectivity where applicable.
- Red team exercises simulating advanced persistent threats (APT) should supplement standard penetration tests annually.
- Ensure Rules of Engagement (RoE) are legally documented before testing begins.
Results Management:
- Classify findings by CVSS score and business risk impact — do not rely on severity alone.
- Critical and High findings must have remediation plans within 30 days per SAMA expectations.
- Track all findings in your GRC platform with owner assignment, due dates, and evidence of closure.
- Re-test remediated vulnerabilities formally — verbal confirmation is insufficient for audit purposes.
- Retain penetration test reports for a minimum of 5 years to support regulatory examination requests.
Under SAMA CSF Control 3.3.5 (Vulnerability and Penetration Testing), Saudi financial institutions are required to conduct penetration testing at least annually, and after any significant system changes or new infrastructure deployments. The scope must cover all critical systems including core banking platforms, internet-facing applications, internal networks, and APIs.
Key requirements include:
Scoping: Tests must encompass external perimeter, internal network, web applications, and mobile banking apps. Social engineering and phishing simulations are also recommended under the same control domain.
Methodology: Engagements should follow recognized methodologies such as PTES, OWASP Testing Guide, or NIST SP 800-115. Tests must be conducted by qualified, independent parties — internal red teams or certified external providers (CREST, OSCP-certified testers).
Reporting: Findings must be classified by severity (Critical, High, Medium, Low), mapped to CVSS scores, and remediation timelines defined. Critical and High findings typically require remediation within 30–90 days per SAMA expectations.
Remediation Validation: SAMA CSF expects re-testing after remediation to confirm vulnerabilities are resolved — not just marked closed.
Documentation: All test results, remediation actions, and sign-offs must be retained and made available to internal audit and SAMA examiners upon request.
NCA ECC Article 2-7 further reinforces penetration testing obligations for entities within the national critical infrastructure scope, which overlaps with Tier-1 and Tier-2 banks.
Best practice is to run quarterly automated vulnerability scans between annual pen tests to maintain continuous assurance and satisfy both SAMA CSF and NCA ECC expectations.
SAMA CSF Control 3.4 (Cybersecurity Assessment) mandates that Saudi banks conduct regular penetration testing as part of a broader vulnerability management program. Here is what a fully compliant penetration testing program looks like: Frequency Requirements — External-facing systems and internet banking applications must be tested at minimum annually, with additional testing required after significant infrastructure changes, new product launches, or post-incident remediation. Critical systems may warrant bi-annual testing. Scope and Methodology — Tests must cover external perimeters, web applications, internal networks, and where applicable, mobile banking apps and APIs. Methodology should align with recognized standards such as PTES (Penetration Testing Execution Standard), OWASP Testing Guide for applications, and OSSTMM for network layers. Social engineering and phishing simulations should be included to assess human-layer controls per SAMA CSF Control 3.3.5. Tester Qualifications — SAMA expects tests to be conducted by qualified independent parties. Relevant certifications include OSCP, CREST, CEH, or GPEN. Internal red team exercises can supplement but typically do not replace third-party assessments for regulatory purposes. Compliant Report Structure — A SAMA-ready pentest report must include: executive summary with risk ratings, detailed technical findings mapped to CVE/CVSS scores, proof-of-concept evidence, business impact assessment per finding, and a prioritized remediation roadmap with defined timelines. Findings should be mapped to SAMA CSF controls and NCA ECC domains where applicable. Remediation Tracking — Critical and high findings must be remediated within 30–90 days, with evidence of closure verified through retesting. Maintain an audit trail of all findings and remediations for SAMA inspection readiness.
Both SAMA CSF and NCA ECC mandate regular penetration testing as a core component of a mature cybersecurity program. Here is how Saudi banks should structure their annual program:
Regulatory Requirements:
- SAMA CSF Control 3.3.4 requires member organizations to conduct regular penetration tests on critical systems, networks, and applications, with findings tracked to remediation.
- NCA ECC-1: 2-4 mandates periodic penetration testing covering infrastructure, applications, and network perimeters, with results reported to senior management.
Program Design Essentials:
- Scope Definition: Cover internet-facing applications, internal network segments, core banking systems, ATM infrastructure, mobile banking apps, and APIs. Prioritize assets classified as critical under your asset management framework.
- Frequency: Conduct external penetration tests at minimum annually; internal tests semi-annually. Trigger additional tests after significant infrastructure changes, major releases, or post-incident.
- Methodology: Require testers to follow recognized methodologies such as PTES, OWASP Testing Guide for web apps, and MITRE ATT&CK for adversary simulation scenarios relevant to the financial sector.
- Tester Qualification: Engage OSCP, CREST, or CEH certified professionals. For critical systems, use independent third-party firms rather than internal teams to ensure objectivity.
- Remediation Tracking: All critical and high findings must have documented remediation plans with owners and deadlines. Conduct verification retests within 30–60 days.
- Reporting to Board: Summarize findings and remediation status in quarterly risk committee reports, as expected under SAMA CSF governance requirements.
A well-structured pen test program not only satisfies regulators but directly reduces your exploitable attack surface.
Penetration testing is a mandatory control under both SAMA CSF and NCA ECC, yet many Saudi financial institutions either conduct tests infrequently or fail to meet the scope and methodology standards expected by regulators.
SAMA CSF Requirements (Control 3.3 – Vulnerability Management):
- External penetration tests must be conducted at least annually by an independent, qualified third party. SAMA expects testers to hold recognized certifications such as OSCP, CEH, or CREST.
- Internal penetration tests should be performed at least once per year, and after any significant infrastructure changes.
- Results must be formally documented, risk-rated, and remediated within defined SLAs — critical findings within 30 days, high findings within 90 days.
NCA ECC Requirements (ECC-1-4-2 – Penetration Testing):
- NCA mandates that penetration testing cover all external-facing systems, internal network segments, and web/mobile applications.
- Red team exercises simulating advanced persistent threats (APT) are expected for entities classified as critical national infrastructure.
- Test reports must be retained for a minimum of 5 years and be available for NCA inspection.
Recommended Testing Scope for Banks:
- External perimeter (internet-facing assets, APIs, web portals)
- Core banking application layers
- Mobile banking applications (iOS and Android)
- Internal network segmentation and lateral movement paths
- Social engineering and phishing simulations
- SWIFT and payment infrastructure (where applicable)
Key Pitfall to Avoid: Do not reuse the same penetration testing firm year after year without rotation. SAMA examiners look for evidence of independent, objective assessments. Establish a vendor rotation policy every 2–3 years to maintain test integrity.
Under SAMA CSF Control 3.3.8 (Vulnerability Management), Saudi banks and financial institutions are required to conduct penetration testing as a core component of their cybersecurity assurance program. The framework mandates at minimum an annual external and internal penetration test, with additional tests triggered by significant infrastructure changes, new product launches, or post-incident recovery. Tests must cover all critical assets including internet-facing systems, core banking platforms, APIs, and mobile banking applications.
Practically, your penetration testing program should follow a structured methodology such as PTES or OWASP, and must be performed by qualified third-party testers — ideally certified with OSCP, CEH, or equivalent credentials. Findings must be formally documented, risk-rated, and remediated within defined SLAs based on severity: Critical findings typically within 15 days, High within 30 days, and Medium within 90 days.
NCA ECC-1:2018 Article 3-4-1 further reinforces this by requiring periodic technical assessments of systems and networks. Results and remediation plans must be reviewed by senior management and reported to the board-level cybersecurity committee. For fintechs regulated under SAMA's Fintech regulations, the same cadence applies but scope is calibrated to your specific service footprint.
Our platform helps you track pentest findings, assign remediation owners, monitor SLA compliance, and generate audit-ready reports that satisfy both SAMA and NCA examiners during regulatory assessments.
Penetration testing (pentesting) is a mandatory control under SAMA CSF and is referenced in NCA ECC-1:2018 as part of the Protect and Detect domains. Here is how Saudi financial institutions should approach it:
Frequency Requirements: SAMA CSF Control 3.3.12 requires external penetration testing at least annually and after any major infrastructure change. Internal network testing and application-layer assessments should align with the same cadence.
Scope Definition: Scope must cover internet-facing assets (web portals, APIs, mobile banking apps), internal network segments, core banking interfaces, and SWIFT connectivity infrastructure. Excluding any critical system without documented justification creates compliance gaps.
Provider Qualification: Engage testers who hold recognized certifications (OSCP, CREST, CEH) and are ideally accredited by NCA's national cybersecurity ecosystem. Contracts must include confidentiality clauses, data handling obligations aligned with PDPL, and clear rules of engagement.
Methodology Alignment: Testing should follow established methodologies such as PTES, OWASP Top 10 (for applications), and NIST SP 800-115. Red team exercises simulating APT-style attacks add maturity beyond standard compliance-driven pentests.
Reporting & Remediation: Findings must be risk-rated (Critical/High/Medium/Low), assigned to system owners, and tracked to closure within defined SLAs — typically 15 days for critical findings. Remediation evidence must be retained for audits.
Regulatory Evidence: Pentest reports, remediation trackers, and re-test confirmations serve as primary audit artifacts for both SAMA inspections and NCA ECC assessments. Store them securely for a minimum of three years.
Under SAMA CSF Control Domain 3.3 (Cybersecurity Operations), Saudi banks are required to conduct regular penetration testing as part of their vulnerability management and threat assessment obligations. Specifically, SAMA CSF mandates that financial institutions perform external and internal penetration tests at least annually, and additionally after any significant infrastructure change, major application release, or following a security incident.
Key requirements include:
Scope & Coverage: Tests must cover network perimeter, internal systems, web and mobile banking applications, APIs, and critical payment infrastructure. SWIFT-connected environments require dedicated testing per SWIFT CSCF obligations.
Methodology: Tests should follow recognized methodologies such as OWASP Testing Guide for applications and PTES or NIST SP 800-115 for infrastructure. Red team exercises are increasingly expected for Tier-1 banks.
Qualified Testers: SAMA expects testing to be conducted by qualified, independent parties — either certified internal teams or accredited third-party firms. NCA ECC Article 2-14 further reinforces independence requirements.
Reporting & Remediation: Findings must be formally documented, risk-rated (Critical/High/Medium/Low), and tracked through a remediation plan with defined timelines. Critical findings typically require remediation within 15–30 days.
Board Visibility: Material findings should be escalated to the CISO and reported to the Board Risk Committee as part of the cybersecurity posture update.
Practically, banks should maintain a rolling penetration testing calendar, integrate findings into their risk register, and use results to validate security control effectiveness — feeding back into SAMA CSF maturity assessments.
Saudi banks and fintechs must conduct penetration testing as a core compliance obligation under both SAMA CSF and NCA ECC. Under SAMA CSF Control 3.3.5, organizations are required to perform regular penetration tests on all critical systems, applications, and network infrastructure — at minimum annually, and following any significant system change. NCA ECC Article 3-2-6 reinforces this by mandating that penetration testing be performed by qualified, independent parties using recognized methodologies such as PTES or OWASP. Practically, your program should include: (1) External and internal network penetration tests targeting perimeter defenses and lateral movement paths; (2) Web and mobile application testing covering OWASP Top 10 vulnerabilities, especially for customer-facing banking apps; (3) Social engineering and phishing simulations to test human controls; (4) Red team exercises for mature organizations to simulate advanced persistent threat (APT) scenarios. All findings must be tracked in a formal remediation plan with defined SLAs — critical findings typically require remediation within 30 days per SAMA guidance. Reports should be reviewed by the CISO and presented to the board risk committee. Retain testing evidence and reports for a minimum of five years to support regulatory examination requests from SAMA or NCA. Engaging a CREST-accredited or SAMA-recognized testing provider strengthens your compliance posture and ensures findings are defensible during audits.
Under SAMA CSF Control 3.3.5 (Vulnerability Management) and Control 3.3.6 (Penetration Testing), Saudi banks and financial institutions are required to conduct structured penetration testing as part of their cybersecurity assurance program. The key requirements include: (1) Frequency: External penetration tests must be conducted at least annually, while critical systems or those undergoing significant changes require testing before go-live and after major updates. (2) Scope: Tests must cover external-facing infrastructure, internal networks, web and mobile banking applications, APIs, and SWIFT-connected systems. (3) Methodology: Testing must follow recognized methodologies such as OWASP, PTES, or NIST SP 800-115, and must be performed by qualified, independent testers — either certified internal staff (OSCP, CREST) or accredited third-party firms. (4) Reporting: A formal report with risk-rated findings, remediation timelines, and evidence of retesting must be maintained and made available to SAMA upon request. (5) Red Team Exercises: Mature organizations are encouraged to supplement annual pen tests with threat-led red team assessments aligned with TIBER-SA principles. Remediation of critical and high findings must follow defined SLAs — typically 30 days for critical vulnerabilities. All penetration testing activities, findings, and closure evidence must be documented within your GRC platform for audit readiness and regulatory examination cycles.
Penetration testing is a mandatory compliance obligation for Saudi financial institutions and critical infrastructure entities under both SAMA CSF and NCA ECC. Here is a structured approach to ensure your testing program meets regulatory expectations:
Regulatory Basis:
- SAMA CSF Control 3.3.5 mandates regular vulnerability assessments and penetration testing for member organizations.
- NCA ECC-1:2018 Article 3.3 requires periodic technical security assessments, including penetration testing of external and internal systems.
Scope and Frequency:
- External penetration testing must be conducted at minimum annually, and after any major infrastructure change.
- Internal network penetration testing, web application testing, and API security assessments should be included in scope for banks and fintechs.
- Red Team exercises are recommended for Tier 1 banks to simulate advanced persistent threats (APTs).
Methodology Requirements:
- Testing must follow a recognized methodology such as PTES, OWASP Testing Guide, or TIBER-EU (adapted for Saudi context).
- Testers must be qualified — ideally holding OSCP, CEH, or equivalent certifications — and the engagement must be governed by a formal Rules of Engagement (RoE) document.
Reporting and Remediation:
- Findings must be risk-rated (Critical, High, Medium, Low) and mapped to relevant SAMA/NCA controls.
- A remediation plan with defined timelines is required. Critical findings typically demand remediation within 30 days per SAMA expectations.
- Retest validation reports must be retained for regulatory audits.
Key Tip: Engage a SAMA-recognized or NCA-approved cybersecurity service provider to conduct assessments, as regulators may request evidence of provider qualifications during examinations.
The NCA Essential Cybersecurity Controls (ECC-1:2018) mandate penetration testing as a core security assurance activity under Domain 3 (Cybersecurity Resilience), specifically Sub-control 3-2-1, which requires organizations to conduct vulnerability assessments and penetration tests to evaluate the effectiveness of implemented cybersecurity controls.
NCA ECC Penetration Testing Requirements:
Frequency: NCA ECC requires pen testing to be conducted at a minimum annually, and additionally following any significant infrastructure change, major application release, or post-incident remediation — a requirement that mirrors SAMA CSF Domain 4 operational testing obligations.
Scope Definition: Your pen test scope must cover all critical assets as defined in your asset inventory (ECC Sub-control 1-1-1). For financial institutions, this typically includes: internet-facing applications and APIs, internal network segments, Active Directory/IAM infrastructure, core banking system interfaces, mobile banking applications, and cloud environments.
Methodology Standards: NCA does not prescribe a specific methodology, but best-practice alignment with OWASP Testing Guide (for web/API), PTES (Penetration Testing Execution Standard), and TIBER-EU (for financial sector threat-intelligence-based testing) is widely accepted by Saudi regulators. SAMA additionally encourages Threat-Led Penetration Testing (TLPT) for systemically important banks.
Tester Independence: Both NCA ECC and SAMA CSF require that penetration testing be conducted by qualified professionals independent from the teams responsible for the systems under test. External testers must hold recognized certifications such as OSCP, CEH, or CREST.
Reporting and Remediation: Post-test, a formal report must classify findings by severity (Critical, High, Medium, Low) with a documented remediation plan. Critical and High findings must be remediated within defined SLAs — typically 30 and 90 days respectively for regulated entities. Remediation evidence must be retained for audit purposes.
Retesting: NCA ECC implicitly requires verification that critical vulnerabilities have been remediated. Schedule retests within 30 days of critical finding remediation.
A mature pen test program integrates findings into your risk register, tracks remediation through your GRC platform, and feeds lessons learned back into your security architecture reviews.
Penetration testing is a mandatory technical control under both SAMA CSF and NCA ECC, and financial institutions must conduct it systematically to remain compliant and genuinely secure. Here's how to structure a compliant penetration testing program:
Regulatory Requirements:
- SAMA CSF Control 3.3.7: Requires vulnerability assessments and penetration testing to be conducted on critical systems at least annually, and after significant changes to infrastructure or applications.
- NCA ECC Art. 2-7-3: Mandates regular penetration testing covering networks, applications, and supporting infrastructure with results formally documented and remediated.
Testing Scope and Methodology:
- Scoping: Include internet-facing assets (web portals, APIs, mobile apps), internal networks, core banking applications, SWIFT infrastructure, and cloud environments.
- Methodology: Align with recognized standards such as PTES (Penetration Testing Execution Standard), OWASP for web/API testing, and OSSTMM for network testing.
- Testing Types: Conduct external and internal network pentests, web application pentests, API security testing, social engineering assessments, and — for mature programs — red team exercises simulating advanced persistent threats (APTs).
- Qualified Testers: Use NCA-approved or CREST/OSCP-certified testers. SAMA expects testers to be independent from the teams responsible for the systems being tested.
Post-Testing Obligations:
- Produce a formal report with CVSS-scored findings, proof-of-concept evidence, and remediation recommendations.
- Remediate critical and high-severity findings within 30 days; medium-severity within 90 days.
- Conduct re-testing to validate remediation effectiveness.
- Retain pentest reports for regulatory review — SAMA examiners routinely request these during assessments.
Advanced Practice: Integrate pentest findings into your risk register and track them through your GRC platform for continuous compliance visibility.
SAMA CSF Domain 4 (Cybersecurity Operations), specifically Controls 4.2 and 4.3, mandates a structured vulnerability assessment and penetration testing (VAPT) program for all licensed Saudi financial institutions. Here is what compliance requires in practice:
Frequency Requirements:
- External penetration testing: At minimum annually, and after any significant infrastructure change
- Internal penetration testing: At minimum annually
- Red Team exercises: Recommended biennially for Tier-1 banks with complex environments
- Application security testing (DAST/SAST): For every major application release or significant update
Scope: SAMA expects testing to cover external perimeter (internet-facing assets), internal network segments, critical applications (core banking, mobile banking, SWIFT infrastructure), and cloud environments. NCA ECC Article 3-4 further requires government-affiliated entities to include OT/SCADA systems where applicable.
Methodology: Engagements must follow recognized methodologies such as PTES (Penetration Testing Execution Standard), OWASP Testing Guide, or TIBER-EU (increasingly referenced for Saudi systemically important banks). Testers must hold recognized certifications (OSCP, CREST, CEH) and must operate under a formally signed Rules of Engagement (RoE) document.
Finding Remediation & Tracking: SAMA CSF Control 4.2.5 requires that all critical and high findings be remediated within 30 days, medium findings within 90 days, and low findings within 180 days. A formal Vulnerability Management register must track finding status, ownership, and closure evidence. Unmitigated critical findings must be reported to the CISO and Board Risk Committee with documented risk acceptance rationale.
Our platform provides an integrated VAPT tracking module with SAMA-aligned SLA dashboards, automated remediation workflows, and audit-ready closure reports — ensuring your penetration testing program satisfies regulatory scrutiny end-to-end.
Saudi financial institutions are required to conduct regular penetration testing as part of their cybersecurity assurance programs. Under SAMA CSF Control 3.3.3 (Vulnerability Assessment and Penetration Testing), banks and fintechs must perform comprehensive penetration tests at least annually, and additionally after any significant infrastructure change, system upgrade, or major application release.
The scope must cover external-facing systems, internal networks, web and mobile banking applications, APIs, and SWIFT environments. SAMA expects institutions to engage qualified third-party testers — ideally CREST-certified or equivalent — to ensure objectivity. Internal red team exercises are encouraged but do not substitute external assessments.
Under NCA ECC Article 3-5 (Security Testing), entities must document pentest findings in a formal report, classify vulnerabilities by criticality, and remediate critical and high findings within defined SLAs — typically 30 days for critical issues. Evidence of remediation must be retained for audit purposes.
For PDPL compliance, testers must handle any personal data encountered during testing under strict data minimization and confidentiality obligations. A formal Rules of Engagement (RoE) document must be signed prior to testing.
Practically, institutions should define a pentest charter that includes scope, methodology (OWASP, PTES, or TIBER-EU for advanced scenarios), escalation procedures, and executive reporting. Results should feed directly into the Risk Register and be reviewed by the board-level Risk Committee. Our platform helps track pentest cycles, manage findings remediation workflows, and generate SAMA-aligned evidence packages for regulatory submissions.
Saudi banks must conduct penetration testing as a core component of their cybersecurity assurance program. Under SAMA CSF Control 3.3.3, financial institutions are required to perform regular penetration tests on all critical systems, applications, and network infrastructure — at minimum annually, and after any significant change to the environment. NCA ECC Article 2-14 further mandates vulnerability assessments and penetration testing as part of the organization's Cybersecurity Operations framework.
Key requirements include:
Scope: All internet-facing systems, internal networks, critical banking applications (core banking, payment gateways, mobile apps), and API endpoints must be included.
Methodology: Tests should follow recognized frameworks such as OWASP, PTES, or TIBER-EU. SAMA expects both external and internal penetration testing perspectives.
Testers: Engagements must be conducted by qualified and independent security professionals. SAMA recommends using certified testers (e.g., OSCP, CREST-certified) who are not involved in the design or management of the systems under test.
Reporting & Remediation: Findings must be formally documented, risk-rated, and remediated within defined SLAs. Critical vulnerabilities typically require remediation within 30 days. Evidence of remediation must be retained for regulatory inspection.
Red Team Exercises: For Tier-1 banks, SAMA may require advanced red team exercises simulating real-world threat actors, aligned with TIBER-SA guidelines.
Our platform helps you track penetration test schedules, manage findings through their full remediation lifecycle, and produce audit-ready reports that map directly to SAMA CSF and NCA ECC control references — ensuring you remain inspection-ready at all times.
Saudi financial institutions are subject to explicit penetration testing mandates under both SAMA CSF and NCA ECC. Under SAMA CSF Control 3.3.5, member organizations must conduct penetration testing at least annually, and additionally after any significant infrastructure change, application release, or following a major security incident. NCA ECC-1:2018 Article 3-4 further reinforces this by requiring vulnerability assessments and ethical hacking exercises as part of a continuous threat management program.
Key requirements include:
Scope: Testing must cover external-facing systems, internal networks, critical banking applications (core banking, mobile banking, payment gateways), and API endpoints. Social engineering and phishing simulations are strongly recommended.
Methodology: Tests should follow recognized frameworks such as PTES (Penetration Testing Execution Standard) or OWASP for web/mobile applications. Black-box, grey-box, and white-box approaches should be risk-calibrated.
Qualified Testers: SAMA expects testing to be performed by independent, qualified professionals — ideally holding certifications such as OSCP, CEH, or CREST. Internal teams may conduct routine assessments, but annual tests should involve a third-party firm.
Reporting & Remediation: Findings must be documented, risk-rated (per CVSS scoring), and remediated within defined SLAs — critical findings typically within 30 days per SAMA CSF guidance. Evidence of remediation must be retained for regulatory review.
Regulatory Reporting: Any critical vulnerability discovered that represents an active threat must be reported to SAMA per the Cyber Incident Reporting framework.
Our platform helps you track pentest schedules, manage findings workflows, assign remediation owners, and generate audit-ready reports aligned with SAMA CSF and NCA ECC expectations.
Saudi banks and financial institutions are required to conduct regular penetration testing as a core component of their cybersecurity assurance programs. Under SAMA CSF Control 3.3.6, member organizations must perform penetration testing at least annually and following any significant infrastructure change, application release, or major security incident. Tests must cover both external and internal attack surfaces, including web applications, APIs, network infrastructure, and social engineering vectors.
NCA ECC-1:2018 Article 3.3.4 further mandates that penetration testing be conducted by qualified, independent parties — either a licensed third-party firm or a sufficiently segregated internal red team. For critical financial infrastructure, external testers must hold recognized certifications such as OSCP, CREST, or equivalent.
Practically, your penetration testing program should include: (1) scoping aligned to crown-jewel assets such as core banking systems, payment gateways, and SWIFT interfaces; (2) a rules-of-engagement document approved by senior management; (3) formal remediation tracking with SLA-driven closure timelines; and (4) executive reporting for board-level visibility.
Findings must be risk-rated, remediated within defined timelines based on severity, and retested to confirm closure. Evidence of completed tests, remediation actions, and sign-off must be retained for regulatory inspection. SAMA examiners frequently request penetration test reports during supervisory reviews, so maintaining a clean audit trail is critical.
Our platform's GRC module includes a dedicated Penetration Testing Management workflow that tracks test cycles, findings, remediation owners, and regulatory submission deadlines — ensuring your program stays audit-ready year-round.
Saudi banks and financial institutions are required to conduct penetration testing as a core component of their cybersecurity assurance programs under multiple regulatory frameworks.
SAMA CSF Requirements: Per SAMA CSF Control 3.3.5 (Vulnerability Management) and Control 3.3.6 (Penetration Testing), member organizations must perform penetration testing at least annually, and additionally after any significant infrastructure or application changes. Tests must cover external-facing systems, internal networks, critical applications, and payment processing infrastructure.
NCA ECC Requirements: Under NCA ECC Article 2-5-3, organizations must conduct periodic penetration tests using qualified personnel or approved third-party providers. The NCA mandates that critical national infrastructure sectors — including banking — perform tests at minimum annually, with vulnerability assessments on a quarterly basis.
Practical Implementation Guidance:
- Engage only CREST-certified or Saudi CITC-approved penetration testing providers
- Scope must include web applications, APIs, mobile banking apps, internal network segmentation, and social engineering simulations
- Retest all critical and high-severity findings within 30–90 days of remediation
- Maintain formal penetration testing reports for regulatory inspection — SAMA examiners routinely request these during supervisory reviews
- Integrate findings into your risk register and track remediation through your GRC platform
- For fintechs operating under SAMA's Fintech regulatory sandbox, additional application-layer testing cadence may apply
Ensure your penetration testing scope aligns with your Crown Jewels analysis and business impact assessment to demonstrate risk-based prioritization to regulators.
Saudi banks and financial institutions are obligated to conduct regular penetration testing as part of their cybersecurity assurance activities. Under SAMA CSF Control 3.3.7, member organizations must perform technical vulnerability assessments and penetration tests to identify and remediate exploitable weaknesses across their infrastructure, applications, and network perimeters. NCA ECC Article 3-3-3 further reinforces this by requiring periodic technical assessments of critical systems.
Key requirements include:
Frequency: At minimum annually for full-scope penetration tests, and after any significant infrastructure changes, new application deployments, or post-incident remediation activities.
Scope: Tests must cover external network perimeters, internal network segments, web and mobile banking applications, APIs, and critical backend systems including core banking platforms.
Methodology: Engagements should follow recognized methodologies such as PTES, OWASP Testing Guide, or TIBER-EU (increasingly adopted for red team exercises in Gulf financial institutions).
Qualified Testers: SAMA CSF emphasizes using qualified and independent testers. Internal teams may conduct routine scans, but formal penetration tests should be performed by certified external parties holding credentials such as OSCP, CREST, or equivalent.
Remediation Tracking: Findings must be risk-rated, assigned to owners, and tracked to closure with defined SLAs — critical findings typically within 30 days, high findings within 90 days.
Reporting to Governance: Test results and remediation status must be reported to the CISO and Board Risk Committee as part of ongoing cybersecurity governance.
Fintechs operating under SAMA's regulatory sandbox should apply equivalent standards proportionate to their risk profile and the criticality of services offered.
Saudi banks and financial institutions are required to conduct penetration testing as a core component of their cybersecurity assurance programs. Under SAMA CSF Control 3.3.5 (Vulnerability Management), institutions must perform regular penetration tests on critical systems, applications, and network infrastructure. NCA ECC-1:2018 Article 3.3.5 further mandates ethical hacking exercises across externally facing assets.
Frequency Requirements:
- Annual minimum: Full-scope penetration tests covering network, application, and social engineering vectors
- Post-major change: Testing must be repeated after significant infrastructure or application changes
- Continuous: Automated vulnerability scanning must complement manual testing year-round
Scope Considerations: Tests must cover internet-facing systems, internal network segmentation, payment processing environments (especially PCI-DSS scoped systems), mobile banking apps, and API endpoints. SAMA expects red team exercises for systemically important banks.
Tester Qualifications: SAMA CSF requires testers to be independent — either a qualified third-party firm or an internal team with verified separation from system owners. Certifications such as OSCP, CREST, or CEH are recognized benchmarks.
Remediation Obligations: Critical and high findings must be remediated within 30–90 days depending on severity, with evidence submitted during SAMA examinations. Unresolved findings must be formally risk-accepted by senior management.
Practical Tip: Maintain a penetration testing register documenting scope, methodology, findings, and remediation status. This is frequently reviewed during SAMA regulatory inspections and NCA compliance audits.
Cloud Security 56
NCA Cloud Cybersecurity Controls (CCC) require Saudi government entities to: obtain NCA approval before adopting cloud services; use only NCA-approved cloud service providers; implement a shared responsibility model; maintain data sovereignty for classified data; apply encryption for data at rest and in transit; implement cloud access security and monitoring.
Financial institutions in Saudi Arabia operating in the cloud must satisfy overlapping requirements from both SAMA CSF and NCA ECC, making cloud security governance a multi-layered compliance challenge. Under NCA ECC Article 2-10 (Cloud Computing Security), entities must conduct a formal cloud risk assessment before migration, classify data according to sensitivity, and ensure that critical and sensitive data is hosted within the Kingdom unless explicit regulatory approval is granted for cross-border transfer. SAMA reinforces this through its Cloud Computing Framework, which mandates that banks obtain prior SAMA approval before migrating core banking workloads to public cloud environments. Shared responsibility models must be clearly documented — defining what the cloud service provider (CSP) secures versus what the institution remains responsible for. Key technical controls required include encryption at rest and in transit (AES-256 minimum), multi-factor authentication for cloud console access, continuous cloud posture monitoring (CSPM tooling), and network segmentation. Incident response plans must be updated to include cloud-specific scenarios. From a PDPL perspective, cross-border data transfers require adequate safeguards — either contractual clauses or confirmation that the destination country offers equivalent protection. Institutions should also maintain a Cloud Asset Register, conduct annual cloud penetration tests, and perform configuration audits quarterly. Our platform maps your cloud controls against SAMA CSF Domain 3.4 and NCA ECC requirements, providing a unified compliance dashboard.
Cloud adoption in Saudi financial institutions is governed by a layered regulatory framework. Here is what you must technically implement to remain compliant: NCA ECC (Art. 2-3 & Cloud Controls Sub-domain): Data classified as 'National' or 'Sensitive' must reside within KSA borders or in approved sovereign cloud environments. You must conduct a formal cloud risk assessment before migration and maintain a cloud asset register. SAMA CSF Cloud Requirements: Before adopting any cloud service, regulated entities must perform due diligence on the Cloud Service Provider (CSP), verify their compliance with recognized standards (ISO 27001, SOC 2 Type II, CSA STAR), and ensure contractual right-to-audit provisions. Mandatory Technical Controls include: (1) Encryption at rest and in transit using AES-256 and TLS 1.2+ minimum; (2) Identity and Access Management with MFA enforced for all privileged and administrative accounts; (3) Cloud Security Posture Management (CSPM) tools to continuously detect misconfigurations; (4) Network segmentation and micro-segmentation within cloud environments; (5) Logging and SIEM integration — all cloud activity logs must feed into your SOC with minimum 12-month retention; (6) Data Loss Prevention (DLP) controls to prevent unauthorized data exfiltration; (7) Vulnerability management cadence for cloud workloads. Practical note: Many Saudi banks and fintechs use hyperscalers (AWS, Azure, Google Cloud) through their KSA regions. While this satisfies data residency, you remain fully responsible for the 'shared responsibility model' gaps. Engage your vCISO or cloud security team to map your controls against both SAMA CSF and NCA ECC before go-live.
When Saudi banks migrate workloads to public cloud environments, SAMA CSF Section 3.3 (Technology Security) mandates a comprehensive cloud security governance framework. Key requirements include: (1) Cloud Risk Assessment — Conduct a formal risk assessment prior to migration, classifying data sensitivity and evaluating provider controls per SAMA CSF Control 3.3.7. (2) Contractual Safeguards — Cloud service agreements must include data residency clauses confirming storage within the Kingdom or in jurisdictions approved by SAMA, right-to-audit provisions, and clear incident notification SLAs. (3) Shared Responsibility Model — Banks must formally document which controls are managed by the CSP versus the bank itself, covering identity management, encryption, and logging. (4) Encryption Standards — All data at rest and in transit must be encrypted using FIPS 140-2 validated algorithms; key management must remain under the bank's control. (5) Continuous Monitoring — SIEM integration with cloud-native logs (e.g., AWS CloudTrail, Azure Monitor) is required to satisfy SAMA CSF's logging and monitoring controls. (6) Exit Strategy — A documented cloud exit plan must exist to ensure operational resilience. NCA ECC Article 7-2 additionally requires that critical national infrastructure workloads avoid public cloud unless specific security criteria are met. Fintechs licensed under SAMA should also align with the SAMA Open Banking Framework's cloud guidance. Practically, banks should appoint a dedicated Cloud Security Officer, establish a Cloud Centre of Excellence, and perform quarterly cloud security posture assessments using tools like CSPM platforms.
When Saudi banks migrate workloads to public cloud environments, SAMA CSF requires a structured cloud security governance approach across several control domains.
Key Requirements:
1. Cloud Risk Assessment (SAMA CSF Control 3.3.1): Before any migration, conduct a formal cloud risk assessment covering data classification, residency requirements, and shared responsibility model gaps. Sensitive customer data (e.g., PII, financial records) must be evaluated for suitability in cloud environments.
2. Data Residency & Sovereignty: SAMA and NCA both require that critical financial data remain within the Kingdom unless explicit regulatory approval is obtained. Validate that your cloud provider offers Saudi or GCC-region data centers with contractual data residency guarantees.
3. Identity & Access Management (SAMA CSF Control 3.4.2): Enforce privileged access management (PAM), multi-factor authentication (MFA), and zero-trust principles for all cloud console access. Disable default service accounts and enforce least-privilege policies.
4. Encryption Standards: All data at rest and in transit must use strong encryption (AES-256 / TLS 1.2+). Maintain customer-managed encryption keys (CMEK) where possible to retain cryptographic control.
5. Continuous Monitoring & SIEM Integration: Cloud-native logs (e.g., AWS CloudTrail, Azure Monitor) must feed into your Security Operations Center (SOC) and SIEM. SAMA CSF Control 3.6.1 mandates continuous monitoring of security events.
6. Third-Party Cloud Provider Assessment: Treat your cloud provider as a critical third party. Review their ISO 27001, CSA STAR, and SOC 2 Type II certifications annually.
Practical Tip: Use a Cloud Security Posture Management (CSPM) tool to automate compliance checks against SAMA CSF and NCA ECC controls continuously.
Before migrating any workload to public cloud, Saudi banks must satisfy a layered set of regulatory and security requirements spanning SAMA CSF and NCA ECC.
SAMA CSF Requirements: Per SAMA CSF Control 3.3 (Technology Risk), banks must conduct a formal Cloud Risk Assessment that evaluates data classification, sovereignty, and residency obligations. Sensitive and critical data — especially customer financial records — must remain within the Kingdom unless explicit regulatory approval is obtained. A Cloud Governance Policy is mandatory, covering provider due diligence, contractual security obligations, and exit strategies.
NCA ECC Requirements: Under NCA ECC Domain 2.7 (Cloud Computing Security), organizations must ensure CSPs (Cloud Service Providers) comply with NCA-approved standards, maintain data within Saudi borders for critical systems, and implement continuous monitoring. Shared responsibility matrices must be formally documented and reviewed annually.
Practical Implementation Steps:
- Classify all workloads using a data classification framework aligned with both SAMA and PDPL sensitivity levels.
- Conduct a Cloud Security Assessment (CSA STAR or ISO 27017-aligned) of the chosen provider.
- Implement CASB (Cloud Access Security Broker) solutions for visibility and policy enforcement.
- Establish Identity and Access Management (IAM) controls with MFA and privileged access management in the cloud environment.
- Define logging, monitoring, and incident response playbooks specific to cloud infrastructure.
- Include cloud security clauses in contracts — SLAs must reference RTO/RPO aligned with SAMA BCM requirements.
Engaging a vCISO familiar with both SAMA CSF and NCA ECC during cloud migration significantly reduces compliance gaps and accelerates regulatory approval timelines.
Before migrating critical workloads to the cloud, Saudi banks must satisfy a layered set of regulatory and technical requirements. Under SAMA CSF Domain 4 (Technology Security), banks must conduct a formal cloud risk assessment covering data classification, residency, and sovereignty — ensuring that data classified as sensitive or critical remains within the Kingdom unless explicit regulatory approval is obtained. NCA ECC Article 3-2 mandates that cloud service providers (CSPs) used by financial entities must be evaluated against NCA's Cloud Cybersecurity Controls (CCC), and contracts must include binding security SLAs, audit rights, and incident notification clauses. Practically, banks should: (1) classify workloads using a documented data classification policy aligned with PDPL personal data categories; (2) perform a vendor due diligence assessment of the CSP covering ISO 27001, SOC 2 Type II, and CSA STAR certifications; (3) implement identity federation, privileged access management (PAM), and encryption at rest and in transit (TLS 1.2+ and AES-256 minimum); (4) establish a shared responsibility matrix clearly delineating security ownership between the bank and CSP; (5) ensure logging, monitoring, and SIEM integration for cloud-native events per SAMA CSF Control 3.3.6. SAMA also expects that cloud adoption be reviewed by the bank's CISO and Board Risk Committee before go-live. Failure to comply can trigger supervisory action, including suspension of cloud migration plans.
Saudi banks migrating to public cloud must satisfy overlapping requirements under SAMA CSF Domain 4 (Technology Security) and NCA ECC Article 3-4 (Cloud Computing Security). Key obligations include:
1. Pre-Migration Risk Assessment: Per SAMA CSF Control 4.3.1, conduct a formal cloud risk assessment covering data classification, residency, and sovereignty. Sensitive financial and customer data must be evaluated before any workload is moved.
2. Data Residency: NCA ECC and SAMA guidance strongly favour in-Kingdom or SAMA-approved data hosting. Confirm your Cloud Service Provider (CSP) operates a certified Saudi data centre or an approved region.
3. Shared Responsibility Model: Clearly document which security controls are owned by the bank versus the CSP. SAMA CSF Control 3.3.5 requires formal agreements defining cybersecurity responsibilities.
4. Identity & Access Management: Enforce Multi-Factor Authentication (MFA) for all privileged cloud access. SAMA CSF Control 4.2.6 mandates strict privileged access management aligned with least-privilege principles.
5. Continuous Monitoring & SIEM Integration: Cloud audit logs (e.g., AWS CloudTrail, Azure Monitor) must feed into your Security Operations Centre (SOC) per NCA ECC Control 2-15.
6. Encryption: All data at rest and in transit must be encrypted using FIPS 140-2 validated algorithms. Encryption key management must remain under the bank's control, not delegated solely to the CSP.
7. Exit Strategy: SAMA requires documented cloud exit and portability plans to avoid vendor lock-in that could threaten operational resilience.
Engage your vCISO team early in the cloud strategy phase to build a compliance-by-design architecture rather than retrofitting controls post-migration.
Before migrating critical workloads, Saudi banks must satisfy requirements across both SAMA CSF and NCA ECC. Under SAMA CSF Domain 4 (Technology Security), institutions must conduct a formal cloud risk assessment that evaluates data sovereignty, residency obligations, and the shared responsibility model with the Cloud Service Provider (CSP). Critically, SAMA CSF Control 4.4 requires that sensitive customer and financial data be stored within the Kingdom of Saudi Arabia unless explicit regulatory approval is obtained.
NCA ECC-1:2018, Article 3-2 (Cloud Computing Security), mandates that organizations classify workloads by criticality prior to migration, ensuring only appropriately secured environments host Tier-1 systems. Banks must also ensure CSPs hold recognized certifications such as ISO 27001 and CSA STAR, and that contractual agreements include the right to audit, incident notification SLAs (within 24 hours per SAMA guidance), and clear exit strategies.
From a practical standpoint, compliance teams should:
- Complete a Cloud Security Risk Assessment aligned with SAMA CSF Domain 4.
- Obtain SAMA's no-objection or approval for outsourcing arrangements involving critical systems.
- Map CSP controls to NCA ECC Article 3-2 requirements and document gaps.
- Implement CSPM (Cloud Security Posture Management) tools for continuous compliance monitoring.
- Establish a data classification policy under PDPL to ensure personal data processed in the cloud meets localization and protection standards.
Failure to address these requirements before migration exposes institutions to regulatory sanctions and heightened operational risk.
Migrating core banking workloads to the cloud in Saudi Arabia requires satisfying a layered set of regulatory obligations before go-live.
SAMA CSF Requirements: Under SAMA CSF Domain 4 (Technology Security), institutions must conduct a formal Cloud Risk Assessment covering data classification, residency, shared-responsibility boundaries, and exit strategy. SAMA CSF Control 4.3 requires that cloud service providers (CSPs) undergo due-diligence reviews equivalent to third-party risk assessments, including review of SOC 2 Type II or ISO 27001 certifications. Data classified as 'Confidential' or 'Restricted' must remain within Saudi Arabia or approved jurisdictions unless explicit regulatory approval is obtained.
NCA ECC Requirements: NCA ECC-1:2018 Article 3-15 mandates that entities using cloud services must ensure contractual clauses covering data sovereignty, audit rights, and incident notification within 24 hours. CSPs must be evaluated against NCA's Cloud Cybersecurity Controls (CCC) framework, which complements ECC for government-adjacent financial entities.
Practical Steps:
- Complete a Cloud Readiness Assessment mapping workloads by sensitivity tier.
- Validate CSP compliance with NCA CCC and obtain SAMA's written non-objection for critical system migration.
- Establish a Cloud Security Posture Management (CSPM) tool to provide continuous control monitoring.
- Define and test a cloud-specific incident response runbook integrated with your SAMA-required IR plan.
- Ensure encryption key management remains under the institution's control (Bring Your Own Key — BYOK).
Financial institutions that skip the pre-migration approval step frequently face SAMA examination findings, making upfront regulatory engagement essential.
Cloud adoption in Saudi banking is growing, but it comes with strict regulatory conditions. Before migrating any workload, financial institutions must satisfy requirements across SAMA CSF Domain 3 (IT Operations & Resilience), NCA ECC-1:2018 controls, and SAMA's Cloud Computing Guidelines.
1. Regulatory Pre-Approval SAMA requires formal notification and, for material systems, prior approval before cloud migration. Define what constitutes 'material' based on SAMA's outsourcing framework — typically core banking, payment systems, and customer data platforms.
2. Data Residency Sensitive financial and personal data must reside within Saudi Arabia unless SAMA grants explicit cross-border approval. This aligns with PDPL Article 29 on cross-border data transfers and NCA data localization guidelines.
3. Cloud Provider Assessment Only use Cloud Service Providers (CSPs) that meet NCA's Cloud Cybersecurity Controls (CCC-1:2020). Confirm the CSP holds relevant certifications (ISO 27001, CSA STAR) and has passed NCA assessment where required.
4. Shared Responsibility Model Document clearly which security controls the bank owns versus the CSP. SAMA examiners expect an explicit shared responsibility matrix covering identity management, encryption, logging, and incident response.
5. Encryption & Key Management Data at rest and in transit must be encrypted. Critically, encryption keys should remain under the bank's control — avoid CSP-managed key scenarios for regulated data.
6. Exit Strategy SAMA Cloud Guidelines mandate a documented exit/portability plan to avoid vendor lock-in and ensure operational continuity.
Our platform maps your cloud architecture controls directly to SAMA CSF and NCA CCC requirements, giving you a real-time compliance posture.
Cloud adoption in Saudi financial institutions is governed by a layered regulatory framework combining SAMA CSF, NCA ECC, and SAMA's Cloud Computing Guidance. Compliance requires addressing the following key areas:
Regulatory Pre-Approval:
- SAMA requires prior approval before migrating any material systems or customer data to the cloud. Submit a Cloud Risk Assessment and a Third-Party Outsourcing Notification per SAMA CSF Control 3.3.5 and the Outsourcing Risk Management Guidelines.
- NCA ECC (Article 3-2) mandates that cloud services used by critical national infrastructure must be evaluated against national security considerations.
Data Residency:
- Customer financial data and personally identifiable information (PII) must remain within the Kingdom of Saudi Arabia, consistent with PDPL Article 29 and SAMA's data localization directives. Confirm that your cloud provider offers a certified KSA region (e.g., AWS, Azure, Google Cloud all have local regions).
Shared Responsibility Model:
- Define and document the security responsibilities split between your institution and the cloud service provider (CSP). Map CSP controls to your SAMA CSF and ISO 27001 control requirements.
Key Technical Controls:
- Encryption at rest and in transit using approved cryptographic standards
- Identity and Access Management (IAM) with least-privilege enforcement and MFA
- Cloud Security Posture Management (CSPM) tools for continuous compliance monitoring
- Log centralization and SIEM integration for threat detection
Ongoing Governance:
- Conduct annual cloud security assessments and maintain a Cloud Asset Inventory
- Include cloud environments in your penetration testing scope
- Establish exit strategy documentation to avoid vendor lock-in risks, as recommended by SAMA outsourcing guidelines
Saudi banks must treat cloud service providers (CSPs) as critical third parties under SAMA CSF Domain 4 (Third-Party Management) and NCA ECC-1:2018 Article 3-4. Here is a practical framework:
1. Pre-Onboarding Due Diligence Conduct a Cloud Security Risk Assessment before signing any contract. Verify the CSP holds recognized certifications (ISO 27001, SOC 2 Type II, CSA STAR). Per SAMA CSF Control 3.3.7, all outsourcing arrangements must be approved by senior management.
2. Contractual Controls Ensure contracts explicitly address data residency (data must remain within KSA unless SAMA pre-approves offshore storage), incident notification SLAs (typically within 24 hours per SAMA CSF 3.3.14), right-to-audit clauses, and exit/transition plans.
3. Ongoing Monitoring Conduct annual cloud security assessments and continuous control monitoring. NCA ECC Article 3-4-2 requires periodic reviews of third-party compliance. Use automated Cloud Security Posture Management (CSPM) tools to detect misconfigurations in real time.
4. Data Classification Alignment Map data stored or processed by the CSP against your PDPL classification tiers and SAMA's data sensitivity categories. Prohibit storage of Tier 1 sensitive customer data on non-approved international platforms.
5. Incident Response Integration Incorporate the CSP into your Incident Response Plan and conduct joint tabletop exercises annually.
Failure to comply can result in SAMA supervisory action and NCA penalties. Engaging a vCISO with cloud GRC expertise can accelerate framework implementation significantly.
Before migrating any workloads to public cloud, Saudi banks must satisfy several regulatory and security requirements. Under SAMA CSF Control 3.3.6, financial institutions must conduct a formal cloud risk assessment that evaluates data classification, residency requirements, and third-party provider controls. Data classified as 'Confidential' or 'Restricted' must generally remain within the Kingdom unless explicit regulatory approval is obtained.
From the NCA ECC perspective, Article 2-14 mandates that cloud service providers used by critical sectors meet NCA's Cloud Cybersecurity Controls (CCC). Banks should verify that their chosen CSP holds a valid NCA compliance attestation or has undergone a recognized third-party audit aligned with CCC requirements.
Practically, institutions should establish a Cloud Security Framework covering: (1) a pre-migration security review and threat modeling, (2) a shared responsibility matrix defining security obligations between the bank and the CSP, (3) encryption of data at rest and in transit using approved algorithms per SAMA guidelines, (4) continuous cloud posture management using CSPM tools, and (5) a cloud-specific incident response runbook.
Additionally, contracts with CSPs must include right-to-audit clauses, incident notification SLAs of no more than 72 hours (aligning with PDPL breach notification obligations), and exit strategy provisions. SAMA also expects banks to maintain an updated inventory of all cloud-hosted assets and integrate them into the institution's broader cyber risk register. Engaging a vCISO or GRC platform with pre-built SAMA and NCA cloud control mappings can significantly accelerate compliance readiness.
Saudi banks adopting cloud services must establish a robust Cloud Security governance framework that satisfies both SAMA CSF Domain 4 (Technology Security) and NCA ECC-1:2018 controls, particularly Articles 3-2 and 3-3 covering cloud computing security.
Key governance requirements include:
1. Cloud Risk Assessment: Conduct a formal risk assessment before onboarding any cloud service provider (CSP), evaluating data classification, residency obligations, and sovereignty risks. SAMA CSF Control 3.3.5 requires institutions to assess third-party cloud risks as part of their overall risk management program.
2. Data Residency & Sovereignty: SAMA mandates that critical banking data remain within the Kingdom of Saudi Arabia unless explicit regulatory approval is obtained. Work with CSPs to ensure data localization contractual clauses are enforceable.
3. Shared Responsibility Model: Define and document the security responsibilities split between your institution and the CSP. Map CSP capabilities to NCA ECC controls to identify gaps requiring compensating controls.
4. Continuous Monitoring: Implement Cloud Security Posture Management (CSPM) tools to provide real-time visibility into misconfigurations, access anomalies, and compliance drift against defined baselines.
5. Exit Strategy & Portability: SAMA CSF requires documented exit strategies to ensure operational continuity if a CSP relationship is terminated.
6. Audit Rights: Ensure contracts grant the institution and SAMA the right to audit CSP environments, or accept equivalent third-party audit certifications (e.g., ISO 27001, SOC 2 Type II).
Establishing a dedicated Cloud Security Working Group with representatives from IT, Risk, Compliance, and Legal is a practical starting point for operationalizing these requirements effectively.
Adopting cloud services in Saudi financial institutions requires careful alignment with both SAMA CSF and NCA ECC frameworks, as both impose specific obligations around data residency, access control, and risk governance.
SAMA CSF Cloud Requirements:
- Control 3.3.5: Cloud service providers (CSPs) must be subject to formal risk assessments before onboarding, covering security certifications (ISO 27001, CSA STAR), financial stability, and exit strategy.
- Control 2.1.2: All sensitive financial data processed or stored in the cloud must remain within Saudi Arabia's geographic boundaries unless explicitly approved by SAMA.
- Control 4.1: Cloud environments must be included in BCP/DRP scope with tested failover capabilities.
NCA ECC Requirements:
- ECC Article 2-15: Mandates a cloud security policy, data classification before cloud migration, and clear definition of shared responsibility boundaries with the CSP.
- ECC Article 2-7: Requires encryption of data in transit and at rest across all cloud workloads using approved cryptographic standards.
Practical Implementation Guidance:
- Shared Responsibility Mapping: Document precisely what security controls the CSP owns versus your institution using a RACI matrix.
- Cloud Security Posture Management (CSPM): Deploy tools to continuously monitor misconfigurations in IaaS/PaaS environments (AWS, Azure, Oracle Cloud).
- Identity & Access Management: Enforce multi-factor authentication, privileged access workstations, and just-in-time access for cloud admin roles.
- Data Classification: Apply PDPL-aligned data classification labels before migrating any customer data to cloud environments.
- Audit Logging: Enable centralized cloud audit logs forwarded to your SIEM for a minimum 12-month retention per SAMA requirements.
Before migrating any workload to a public cloud, Saudi banks must complete a structured pre-migration assessment aligned with SAMA CSF Domain 4.3 (Technology Security) and NCA ECC-1:2018 Control 3-16 (Cloud Computing Security).
Key requirements include:
- Regulatory Pre-Approval: SAMA requires prior written approval for outsourcing core banking functions to cloud providers. Submit a detailed outsourcing request including risk assessment, data classification, and a business case.
- Data Residency: Customer data classified as sensitive or confidential must remain within Saudi Arabia unless SAMA grants explicit exemption. Validate that your chosen CSP (e.g., AWS Riyadh, Azure KSA) operates locally sovereign regions.
- Cloud Security Risk Assessment: Conduct a formal Cloud Security Risk Assessment per SAMA CSF Control 3.3.5, covering shared responsibility models, data encryption at rest and in transit (AES-256 minimum), and identity & access management controls.
- CSP Due Diligence: Verify the CSP holds recognized certifications — ISO 27001, SOC 2 Type II, and CSA STAR Level 2 — and can provide audit rights contractually.
- Exit Strategy: Document a cloud exit/transition plan ensuring business continuity if the CSP relationship is terminated, per SAMA outsourcing guidelines.
- Continuous Monitoring: Implement Cloud Security Posture Management (CSPM) tools to maintain real-time visibility into misconfigurations and compliance drift post-migration.
Failing to meet these controls exposes institutions to SAMA supervisory action and potential NCA escalation. Engage your vCISO or GRC team early in the cloud adoption lifecycle to ensure compliance gates are embedded in your migration playbook.
Before migrating critical workloads to the cloud, Saudi banks must satisfy a layered set of requirements across both SAMA CSF and NCA ECC frameworks.
SAMA CSF Requirements: Under SAMA CSF Domain 4 (Technology Risk Management), banks must conduct a formal Cloud Risk Assessment prior to any migration. This includes classifying data sensitivity, evaluating the cloud service provider's (CSP) security posture, and ensuring contractual obligations cover data residency, audit rights, and incident notification. SAMA also requires banks to maintain a Cloud Governance Policy and ensure the CSP undergoes third-party assurance assessments (e.g., SOC 2 Type II, ISO 27001 certification).
NCA ECC Requirements: NCA ECC Article 2-6 mandates that organizations classify information assets before cloud adoption and ensure that sensitive national data remains within Saudi Arabia unless explicitly approved otherwise. CSPs must be evaluated against NCA's Cloud Cybersecurity Controls (CCC), and a formal agreement must address security responsibilities using a shared responsibility model.
Practical Steps for CISOs:
- Conduct a Data Classification exercise aligned to SAMA and NCA taxonomies.
- Perform a Cloud Security Risk Assessment covering availability, confidentiality, and integrity risks.
- Validate CSP compliance certifications (ISO 27001, CSA STAR, PCI DSS where applicable).
- Define a Shared Responsibility Matrix documenting bank vs. CSP obligations.
- Establish continuous cloud security monitoring using a Cloud Security Posture Management (CSPM) tool.
- Ensure exit strategy and data portability clauses are included in contracts.
Failure to meet these requirements exposes banks to regulatory sanctions and audit findings during SAMA's annual cybersecurity maturity assessments.
Before migrating critical workloads to the cloud, Saudi banks must satisfy controls across both SAMA CSF and NCA ECC frameworks. Under SAMA CSF Domain 4 (Technology Security), banks are required to conduct a formal Cloud Risk Assessment that evaluates data classification, residency, sovereignty, and shared responsibility boundaries. Critically, customer and financial data classified as 'Sensitive' or 'Confidential' must remain within Saudi Arabia or approved jurisdictions unless explicit regulatory approval is obtained.
Key requirements include:
SAMA CSF Controls:
- Control 3.3.1: Establish a cloud governance policy covering provider selection, exit strategies, and contractual obligations.
- Control 4.2.7: Enforce encryption at rest and in transit using FIPS 140-2 approved algorithms.
- Control 3.2.5: Ensure third-party (CSP) risk assessments are conducted before onboarding and reviewed annually.
NCA ECC Article 2-7 (Cloud Computing Security): Organizations must apply NCA's Cloud Cybersecurity Controls (CCC) baseline, which mandates identity federation, privileged access management (PAM), logging and monitoring integration with the SOC, and vulnerability management for cloud-hosted assets.
Practical Steps for CISOs:
- Classify all workloads using your data classification policy before migration scoping.
- Demand SOC 2 Type II or ISO 27001 certifications from cloud service providers.
- Define a Cloud Exit Strategy to avoid vendor lock-in and ensure business continuity.
- Integrate cloud audit logs into your SIEM for real-time visibility.
- Conduct a pre-migration penetration test on the cloud environment.
Non-compliance with SAMA's cloud security guidance can trigger supervisory review and mandatory remediation orders, making proactive alignment essential for any cloud adoption roadmap.
Cloud adoption in Saudi financial institutions is governed by overlapping requirements from SAMA CSF, NCA ECC, and SAMA's dedicated Cloud Computing Framework. Non-compliance in this area carries significant operational and regulatory risk.
Data Residency & Sovereignty: SAMA requires that sensitive financial data and critical systems remain within the Kingdom unless explicit written approval is obtained. NCA ECC Article 2-15 reinforces this by mandating that national data not leave Saudi borders without proper authorization. CISOs must classify data before cloud migration and validate that their Cloud Service Provider (CSP) offers KSA-region data centers — currently available through AWS, Azure, Google Cloud, and STC Cloud.
Shared Responsibility Model: Per SAMA CSF Control 3.5.1, institutions remain fully accountable for cybersecurity outcomes regardless of outsourcing. Document the shared responsibility matrix with your CSP and ensure security controls not covered by the provider are compensated for internally.
Due Diligence & Contracts: Conduct formal cloud vendor risk assessments aligned to SAMA's outsourcing requirements. Contracts must include right-to-audit clauses, data breach notification obligations, SLA commitments, and data deletion procedures upon contract termination.
Technical Controls: Implement Cloud Security Posture Management (CSPM) tools to continuously monitor misconfigurations. Enforce encryption at rest and in transit, multi-factor authentication, privileged access management (PAM), and network segmentation within your cloud environment.
Ongoing Monitoring: NCA ECC requires logging and monitoring of cloud environments. Integrate cloud logs into your SIEM and establish alert thresholds for anomalous activity. Conduct cloud-specific penetration tests at least annually.
Engaging a vCISO experienced in Saudi regulatory cloud requirements can significantly accelerate compliant cloud adoption.
Cloud adoption in the Saudi financial sector is accelerating, but it introduces significant compliance obligations under both SAMA CSF and NCA ECC. Financial institutions must navigate these frameworks carefully before and during any cloud deployment.
SAMA CSF Requirements: SAMA CSF Section 3.7 (Technology Risk Management) requires that any cloud deployment undergo a formal risk assessment, receive senior management approval, and be governed by a cloud security policy. Critically, SAMA mandates that core banking data must reside within the Kingdom unless explicit regulatory approval is granted for offshore storage.
NCA ECC Requirements: NCA ECC Article 2.7 (Cloud Computing Security) requires organizations to classify data before cloud migration, enforce encryption in transit and at rest, and maintain full visibility over cloud-hosted assets. The NCA Cloud Cybersecurity Controls (CCC-1) provide additional mandatory guidance for government-adjacent entities.
Practical Implementation Steps:
- Cloud Risk Assessment: Conduct a pre-deployment risk assessment evaluating data classification, residency, access controls, and shared responsibility boundaries.
- CSP Due Diligence: Evaluate cloud service providers (CSPs) against SAMA's third-party risk requirements. Preferred CSPs include those with local Saudi regions (e.g., AWS, Azure, Google Cloud in KSA) to satisfy data residency.
- Shared Responsibility Model: Clearly document what the CSP secures versus what your institution owns — particularly for IaaS, PaaS, and SaaS models.
- Continuous Monitoring: Deploy Cloud Security Posture Management (CSPM) tools to detect misconfigurations, enforce policies, and generate audit-ready reports.
- Exit Strategy: SAMA expects documented cloud exit plans to ensure operational resilience if a CSP is terminated.
Align your cloud security program with ISO 27017 (cloud security controls) and ISO 27018 (PII in cloud) to demonstrate international best-practice alignment alongside local regulatory compliance.
Cloud migration in the Saudi financial sector is heavily regulated, and CISOs must navigate overlapping requirements from SAMA, NCA, and the Communications, Space & Technology Commission (CST) before moving critical workloads to the cloud.
SAMA CSF Cloud Requirements: SAMA CSF Control 3.1.4 and the SAMA Cloud Computing Framework (CCF) require financial institutions to conduct a formal cloud risk assessment before onboarding any cloud service. Key obligations include:
- Data Residency: Core banking data and customer personal data must remain within Saudi Arabia borders unless SAMA grants explicit written approval for cross-border transfers.
- CSP Due Diligence: Cloud Service Providers (CSPs) must be assessed against SAMA's CSP evaluation criteria covering security controls, SLAs, audit rights, and incident notification timelines (typically 72 hours for breaches).
- Exit Strategy: A documented exit and portability plan must exist to avoid vendor lock-in and ensure business continuity.
NCA ECC Requirements: NCA ECC Article 3-4 requires organizations to apply the same security baseline to cloud environments as on-premises systems, including access control, encryption, vulnerability management, and logging. Cloud-hosted systems must be included in annual compliance assessments.
Pre-Migration Checklist for CISOs:
- Classify workloads by criticality — Tier 1 (Core Banking, Payment Systems) requires the highest scrutiny.
- Verify CSP holds relevant certifications: ISO 27001, CSA STAR, and ideally local NCA certification.
- Conduct shared responsibility mapping to identify security gaps between bank and CSP obligations.
- Implement Cloud Security Posture Management (CSPM) tools to maintain continuous compliance visibility.
- Establish a Cloud Security Policy reviewed annually and approved by the board.
Both SAMA and NCA can request audit reports and penetration testing results for cloud-hosted systems at any time.
Migrating to public cloud in Saudi Arabia's financial sector requires satisfying overlapping requirements from both SAMA CSF and NCA ECC. Here is a structured compliance approach:
1. Pre-Migration Risk Assessment (SAMA CSF Control 3.3.2) Conduct a formal cloud risk assessment covering data classification, residency requirements, and shared-responsibility model gaps. Sensitive customer and financial data must be classified per SAMA's data classification policy before any workload moves to cloud.
2. Data Residency (NCA ECC Art. 2-7 & PDPL Art. 29) NCA ECC explicitly requires that critical national infrastructure data remain within Saudi Arabia. Banks must ensure their cloud provider offers Saudi-region data centers and contractually commits to data residency. PDPL further restricts cross-border transfer of personal data unless adequate safeguards exist.
3. Cloud Service Provider (CSP) Due Diligence Under SAMA CSF Control 3.3.14 (Third-Party Risk), CSPs must be assessed as vendors. Require SOC 2 Type II, ISO 27001 certification, and a completed SAMA-aligned vendor assessment questionnaire before contract execution.
4. Identity and Access Management Implement Zero Trust principles: enforce MFA, privileged identity management (PIM), and just-in-time access for cloud consoles. Map controls to NCA ECC Domain 2-4 (Access Management).
5. Continuous Monitoring and SIEM Integration Cloud-native logs (e.g., AWS CloudTrail, Azure Monitor) must feed into your SIEM. SAMA CSF requires continuous monitoring of cybersecurity events (Control 3.3.19).
6. SAMA Pre-Approval For core banking workloads, obtain SAMA's no-objection letter before migration. Engage SAMA early in your cloud roadmap to avoid project delays.
Document everything in a Cloud Security Policy aligned to ISO 27017 as a supplementary control framework.
The NCA Essential Cybersecurity Controls (ECC-1:2018) dedicates a specific domain — ECC Domain 4: Cloud Computing and Hosting — to cloud security, making it one of the most operationally complex areas for Saudi organizations. Key NCA ECC Cloud Requirements: ECC-1:2-4.1 requires a formal Cloud Security Policy defining approved cloud service models (IaaS, PaaS, SaaS) and deployment types (public, private, hybrid). ECC-1:2-4.2 mandates data sovereignty controls ensuring national data is not processed or stored outside the Kingdom without explicit authorization. ECC-1:2-4.3 requires contractual assurances from CSPs covering security responsibilities, audit rights, incident notification (within 24 hours), and data deletion upon contract termination. NCA Cloud Compliance Assessment Steps: First, verify the cloud provider holds NCA-recognized certifications such as ISO 27001, CSA STAR Level 2, or SOC 2 Type II. Second, review the provider's Shared Responsibility Model to map security obligations clearly. Third, conduct a Cloud Security Risk Assessment using the CSA Cloud Controls Matrix (CCM) mapped to NCA ECC controls. Fourth, for sensitive or critical workloads, prioritize providers operating NCA-approved local data centers such as AWS Riyadh, Azure KSA, or STC Cloud. For SAMA-regulated entities: SAMA CSF 3.7 adds additional cloud vendor due diligence requirements including onsite audits and SAMA notification for critical outsourcing arrangements. Practically, organizations should maintain a Cloud Asset Register and review CSP security posture annually, with results reported to the CISO and board-level risk committees.
Saudi fintechs operating on cloud infrastructure must comply with both the NCA Cloud Cybersecurity Controls (CCC-1:2020) and SAMA CSF Domain 4 (Technology Security), which together create a layered compliance obligation for cloud environments.
Core NCA CCC requirements:
- CCC-1.1 (Data Residency): Customer data classified as sensitive or critical must be stored within KSA borders unless explicit regulatory approval is obtained. Fintechs must confirm their cloud provider (AWS, Azure, Google, etc.) has a certified KSA-region data center.
- CCC-1.3 (Shared Responsibility): Clearly document the shared responsibility matrix with your cloud provider. Define who is responsible for patching, identity management, encryption, and logging.
- CCC-2 (Identity & Access Management): Enforce Multi-Factor Authentication (MFA) for all privileged cloud accounts, implement Role-Based Access Control (RBAC), and review permissions quarterly.
- CCC-3 (Encryption): Data at rest must use AES-256 and data in transit must use TLS 1.2 or higher. Manage encryption keys using dedicated Key Management Services (KMS) with HSM-backed key storage.
SAMA CSF alignment:
Under Control 4.3.6, SAMA requires financial institutions to assess cloud environments against their information security policies before deployment. Conduct Cloud Security Posture Management (CSPM) scans continuously and maintain a Cloud Security Risk Register.
Practical steps:
- Obtain a Cloud Security Assessment from a SAMA-recognized provider before launch.
- Enable cloud-native logging (e.g., AWS CloudTrail, Azure Monitor) and forward logs to your SIEM.
- Conduct annual third-party cloud penetration tests.
- Review cloud vendor compliance certifications (ISO 27001, SOC 2, CSA STAR).
Cloud adoption in Saudi financial services is governed primarily by SAMA CSF (Domain 3.3 and the Cloud Computing Guidelines issued in 2023) and NCA ECC (Controls 3-1 through 3-4, Cloud Computing). Additionally, NCA's Cloud Cybersecurity Controls (CCC-1:2020) applies directly. Here is a compliance-focused framework:
Pre-Migration Requirements:
- Conduct a formal Cloud Risk Assessment and obtain SAMA/board approval for outsourcing material functions.
- Ensure the Cloud Service Provider (CSP) is compliant with NCA's approved CSP list and meets ISO 27001, CSA STAR, and SOC 2 Type II standards.
- Data residency is a hard requirement: customer financial data must remain within the Kingdom per SAMA guidelines and NCA ECC Control 3-1-3.
Technical Controls (NCA CCC-1):
- Implement Identity and Access Management (IAM) with least-privilege and MFA enforcement.
- Enable encryption at rest (AES-256) and in transit (TLS 1.2+) for all data.
- Deploy Cloud Security Posture Management (CSPM) tools to continuously detect misconfigurations.
- Establish Virtual Private Cloud (VPC) segmentation and restrict public-facing endpoints.
Governance & Monitoring:
- Maintain a shared responsibility matrix clearly defining security obligations between your institution and the CSP.
- Log all cloud activity and integrate with your SIEM for real-time alerting.
- Conduct annual cloud security assessments per SAMA CSF Domain 3.3.5.
Exit Strategy: SAMA requires documented cloud exit plans ensuring operational continuity if the CSP relationship ends. This should be tested at least every two years.
Yes, but with conditions. SAMA allows financial institutions to use public cloud, provided they: conduct a cloud risk assessment; ensure data residency requirements for sensitive customer data; implement appropriate access controls and encryption; maintain regulatory reporting capabilities; have a clear exit strategy; and use SAMA-approved or internationally recognized cloud providers with local data centers in KSA.
Financial institutions in Saudi Arabia operating in the cloud must satisfy overlapping requirements from three primary authorities:
NCA ECC (Cloud Security Controls – Domain 4): Article 4-2 of the ECC mandates that critical infrastructure entities, including financial institutions, classify cloud deployments and implement controls across data sovereignty, access management, encryption, and incident response. Cloud service providers (CSPs) must themselves be NCA-compliant, and organizations must maintain the right to audit CSP security practices.
SAMA Cloud Computing Guidelines (2017, updated): SAMA requires prior written approval before migrating critical systems or sensitive customer data to the cloud. Key obligations include: storing customer financial data within Saudi Arabia or in jurisdictions with equivalent data protection standards, conducting cloud-specific risk assessments, and ensuring business continuity and disaster recovery capabilities are not compromised by cloud dependencies.
Practical Implementation Checklist:
- Classify data per PDPL sensitivity tiers before cloud migration
- Use FIPS 140-2 validated encryption for data at rest and in transit
- Implement Identity and Access Management (IAM) with privileged access controls
- Establish a Cloud Security Posture Management (CSPM) tool to continuously monitor misconfigurations
- Define clear exit strategies and data portability clauses with CSPs
- Map cloud controls to SAMA CSF maturity levels for self-assessment reporting
Cloud adoption in Saudi financial services is accelerating, particularly with hyperscalers like AWS, Microsoft Azure, and Google Cloud establishing local regions. However, regulatory pre-approval remains non-negotiable. Engaging a vCISO or GRC platform early in the cloud journey ensures compliance is embedded by design, not retrofitted.
Migrating banking workloads to public cloud requires a structured security approach aligned with SAMA CSF Domain 3.3 (Technology Security) and NCA ECC-1:2018 Cloud Computing controls. Before any migration, banks must conduct a formal Cloud Risk Assessment and classify data according to SAMA's data classification policy — critical and sensitive financial data requires heightened controls or may mandate on-premises or sovereign cloud hosting.
Key mandatory controls include:
1. Due Diligence on CSPs: Validate that cloud service providers (CSPs) hold recognized certifications such as ISO 27001, SOC 2 Type II, and CSA STAR. Per SAMA CSF Control 3.3.5, third-party hosting agreements must include enforceable security SLAs.
2. Data Residency: SAMA requires that core banking data and customer PII remain within the Kingdom of Saudi Arabia unless explicit regulatory approval is obtained. Confirm your CSP offers KSA-based data center regions.
3. Encryption & Key Management: Implement end-to-end encryption at rest and in transit. Maintain ownership of encryption keys — avoid CSP-managed key models for sensitive workloads; use dedicated HSMs where feasible.
4. Identity & Access Management: Enforce MFA, privileged access management (PAM), and zero-trust principles across cloud environments per SAMA CSF Control 3.3.3.
5. Continuous Monitoring: Deploy CSPM (Cloud Security Posture Management) tools and integrate cloud logs into your SIEM for real-time threat detection.
6. Exit Strategy: Document a cloud exit plan ensuring data portability and service continuity — a direct requirement under SAMA CSF's business continuity provisions.
Engaging a vCISO with SAMA and cloud security expertise before migration significantly reduces compliance gaps and audit findings.
Saudi banks adopting public cloud must align with SAMA CSF Domain 4.3 (Infrastructure Security) and the SAMA Cloud Computing Framework, which mandates a structured risk-based approach before any cloud migration. Key requirements include:
1. Pre-Adoption Due Diligence: Conduct a formal Cloud Risk Assessment covering data classification, residency requirements, and provider security posture. SAMA requires that critical banking data remain subject to its supervisory oversight, meaning cross-border data transfers must be explicitly approved.
2. Contractual Safeguards: Cloud Service Agreements must include right-to-audit clauses, SLA guarantees for availability (typically 99.9%+), data deletion assurances upon contract termination, and incident notification timelines aligned with SAMA CSF Control 3.3.5.
3. Technical Controls: Implement encryption at rest (AES-256) and in transit (TLS 1.2+), multi-factor authentication for all administrative access, and Cloud Access Security Broker (CASB) solutions for visibility. Network segmentation between cloud and on-premises environments is mandatory.
4. Continuous Monitoring: Deploy Security Information and Event Management (SIEM) integration with cloud-native logging (e.g., AWS CloudTrail, Azure Monitor) to maintain audit trails. SAMA expects real-time alerting for anomalous access patterns.
5. Exit Strategy: Maintain a documented cloud exit plan to ensure operational continuity if the provider relationship is terminated, addressing data portability and recovery timelines.
NCA ECC Article 7-4 further reinforces cloud security obligations for entities within its scope. Banks should conduct annual cloud security assessments and ensure any Shared Responsibility Model gaps are explicitly addressed in internal security policies.
Before migrating critical workloads to public cloud, Saudi banks must satisfy a layered set of requirements under both SAMA CSF and NCA ECC.
SAMA CSF Requirements: Per SAMA CSF Control 3.3, banks must conduct a formal Cloud Risk Assessment prior to any migration, classifying data and systems by criticality. Sensitive customer data and core banking systems typically require explicit SAMA approval or must remain on-premises or in approved private cloud environments. Contracts with Cloud Service Providers (CSPs) must include enforceable data residency clauses confirming data stays within the Kingdom of Saudi Arabia, as well as right-to-audit provisions.
NCA ECC Requirements: NCA ECC Article 3-5 mandates that entities classify information assets before cloud adoption and ensure CSPs meet NCA's Cloud Cybersecurity Controls (CCC). Specifically, banks must verify that CSPs hold valid certifications (e.g., ISO 27001, CSA STAR) and comply with NCA CCC requirements covering logical separation, encryption at rest and in transit, and incident notification SLAs.
Practical Steps:
- Conduct a data classification exercise aligned to SAMA CSF and NCA ECC sensitivity levels.
- Perform a Cloud Security Risk Assessment documented and approved by the CISO and Board Risk Committee.
- Negotiate CSP contracts to include data residency, audit rights, breach notification within 72 hours, and exit strategy clauses.
- Implement Cloud Access Security Broker (CASB) controls for visibility and policy enforcement.
- Establish continuous compliance monitoring mapped to both frameworks.
Failure to follow this process can result in regulatory findings during SAMA examinations and NCA cybersecurity audits.
Before migrating critical workloads to the cloud, Saudi banks must satisfy a layered set of requirements under both SAMA CSF and NCA ECC.
SAMA CSF Requirements: Per SAMA CSF Control 3.3.5 (Cloud Computing), banks must conduct a formal Cloud Risk Assessment prior to any migration. This includes classifying data sensitivity, evaluating the Cloud Service Provider (CSP) against SAMA's approved vendor criteria, and ensuring contractual controls cover data sovereignty, audit rights, and exit strategies. SAMA also requires that critical customer data remain within the Kingdom unless explicit regulatory approval is granted.
NCA ECC Requirements: Under NCA ECC-1: 2-1 (Cloud Computing Security), organizations must ensure CSPs comply with NCA's Cloud Cybersecurity Controls. Banks should verify that their chosen CSP holds a valid NCA cloud compliance certificate and that shared responsibility models are clearly documented.
Practical Steps:
- Classify workloads using a data classification policy aligned to ISO 27001 Annex A.8.
- Conduct a Cloud Security Risk Assessment mapped to NIST CSF Identify (ID.AM) and Protect (PR.DS) functions.
- Review CSP contracts for data residency, incident notification SLAs (within 72 hours per PDPL Article 21), and forensic access rights.
- Implement Cloud Access Security Broker (CASB) controls and encryption at rest and in transit.
- Establish a Cloud Exit Strategy document as required by SAMA CSF Control 3.3.5.4.
Cloud migration without this governance foundation exposes banks to regulatory penalties and heightened breach risk.
Cloud adoption in Saudi financial services is governed by a layered regulatory framework. SAMA CSF Control 3.4 (Technology Security) and NCA ECC Article 2-14 collectively require financial institutions to establish a formal Cloud Security Governance framework before migrating any workloads. Key obligations include: (1) Cloud Risk Classification: Classify data and workloads by sensitivity — SAMA prohibits hosting core banking data on public cloud without explicit approval and robust controls; (2) Shared Responsibility Matrix: Formally document the security responsibilities split between your institution and the cloud service provider (CSP) for each service model (IaaS, PaaS, SaaS); (3) Cloud Service Provider Due Diligence: CSPs must undergo vendor risk assessments aligned with SAMA CSF third-party requirements, including evidence of ISO 27001 certification and SOC 2 Type II reports; (4) Data Residency: Customer financial data must remain within the Kingdom unless SAMA grants an exception — NCA ECC Article 2-14-1 reinforces this requirement; (5) Encryption and Key Management: Encryption at rest and in transit is mandatory, and encryption keys must be controlled by the financial institution, not the CSP; (6) Continuous Monitoring: Implement Cloud Security Posture Management (CSPM) tools and integrate alerts into your SOC. Additionally, SAMA's Cloud Computing Regulatory Framework (CCRF) provides supplementary guidance. Institutions should maintain a Cloud Asset Register and conduct annual cloud security reviews as part of their broader IS audit cycle.
Cloud adoption in Saudi financial institutions is tightly governed by both SAMA CSF and NCA ECC. Before migrating any data or workload, institutions must complete a formal data classification exercise as required under SAMA CSF Control 3.2.1, categorizing data into tiers such as Public, Internal, Confidential, and Restricted — with financial customer data and transaction records typically falling under Restricted.
For cloud deployments, NCA ECC Article 3-7 mandates that data classified as sensitive or critical must remain within Saudi Arabia's geographic boundaries unless explicit regulatory approval is obtained. This means institutions must verify that their cloud service providers (CSPs) operate sovereign data centers within the Kingdom, or leverage approved models such as Hyperscaler Sovereign Cloud offerings.
Key technical controls required include: (1) encryption of data at rest using AES-256 and in transit using TLS 1.2 or higher; (2) customer-managed encryption keys (CMEK) so the institution retains cryptographic control; (3) strict Identity and Access Management (IAM) with least-privilege principles enforced across all cloud tenants; (4) continuous cloud security posture management (CSPM) to detect misconfigurations; and (5) data loss prevention (DLP) policies aligned with your classification tiers.
SAMA also requires that cloud contracts include specific security clauses, audit rights, and incident notification obligations. Your GRC platform should map cloud controls to both SAMA CSF and NCA ECC requirements, providing a unified compliance view rather than managing two separate frameworks in silos.
Migrating core banking workloads to public cloud in Saudi Arabia requires satisfying a layered set of regulatory and technical requirements. Under SAMA CSF Control Domain 3.6 (Cloud Computing) and NCA Cloud Cybersecurity Controls (CCC), institutions must complete the following before go-live: (1) Regulatory pre-approval: SAMA requires prior notification and, for critical systems, explicit approval before cloud migration. Engage SAMA early and document your risk assessment. (2) Data residency: All customer financial data classified as sensitive must reside within the Kingdom of Saudi Arabia. Validate that your cloud provider (AWS Riyadh, Azure UAE North with data sovereignty guarantees, or STC Cloud) offers certified KSA data residency. (3) Cloud Security Posture Management (CSPM): Deploy CSPM tooling to continuously monitor misconfiguration risks against benchmarks such as CIS Cloud Foundations. (4) Encryption: Data must be encrypted at rest and in transit using approved algorithms (AES-256, TLS 1.2+). Crucially, key management must remain under the institution's control — use Bring Your Own Key (BYOK) or Hold Your Own Key (HYOK) models, per NCA CCC Control 3.4. (5) Shared Responsibility Model documentation: Clearly define and document security responsibilities between the bank and the CSP, covering incident response, patch management, and access control. (6) Exit strategy: Per SAMA CSF, a documented and tested cloud exit strategy is mandatory to avoid vendor lock-in risk. (7) Third-party audit: Annual cloud security assessments by an approved third party are required, with findings reported to the board risk committee. Engage your cloud provider's financial services compliance team early — AWS, Microsoft Azure, and Google Cloud all maintain dedicated Saudi financial sector compliance programs.
Cloud migration in Saudi financial services is governed by a layered set of regulatory requirements. Before moving any workload to public cloud, institutions must satisfy obligations from SAMA, NCA, and in some cases the Communications, Space & Technology Commission (CST).
SAMA Cloud Requirements: SAMA's Regulatory Framework for Cloud Computing in the Financial Sector requires prior notification or approval depending on workload criticality. Critical systems (core banking, payment processing) require explicit SAMA approval before migration. Non-critical workloads require formal risk assessments and documented board approval.
NCA Cloud Cybersecurity Controls (CCC): The NCA's CCC framework mandates that cloud service providers used by financial institutions meet specific security standards, including data sovereignty (data must reside in Saudi Arabia for sensitive workloads), encryption at rest and in transit, and multi-tenancy isolation controls.
Pre-Migration Checklist:
- Classify workloads by sensitivity (using SAMA CSF data classification guidelines)
- Conduct a Cloud Security Risk Assessment covering shared responsibility models
- Validate CSP compliance with NCA CCC and ISO 27017/27018
- Define exit strategy and data portability provisions
- Ensure incident response and logging capabilities extend to cloud environments (per NCA ECC Control 2-14)
- Establish Identity and Access Management (IAM) controls aligned with least-privilege principles
Ongoing Compliance: Post-migration, conduct quarterly cloud configuration reviews, enable CSPM (Cloud Security Posture Management) tools, and include cloud environments in annual penetration testing scope per SAMA CSF Control 3.3.5.
Engaging a vCISO or cloud security specialist familiar with Saudi regulatory nuances is strongly recommended before initiating migration.
The NCA ECC (Essential Cybersecurity Controls) addresses cloud computing under Control 2-14 (Cloud Computing and Hosting Services), establishing clear requirements for organizations operating in Saudi Arabia, including financial institutions subject to both NCA ECC and SAMA CSF oversight.
Key NCA ECC Cloud Requirements:
- Cloud services must be assessed and approved through a formal risk management process before adoption
- Data classification must be performed prior to cloud migration; sensitive and critical data requires additional safeguards
- Contracts with Cloud Service Providers (CSPs) must include security requirements, data residency clauses, and incident response obligations
- Data sovereignty is paramount: personal and sensitive financial data should preferably reside within Saudi Arabia, aligned with PDPL Article 29 on cross-border data transfers
SAMA-Specific Considerations: SAMA's Cloud Computing Guidelines require banks to notify SAMA before migrating material systems to the cloud and to maintain a cloud risk register. Core banking and customer data systems face stricter scrutiny.
Practical Implementation Steps:
- Cloud Security Assessment: Evaluate CSPs against CSA STAR, ISO 27017/27018, and local compliance requirements
- Shared Responsibility Model: Clearly document what security controls the CSP owns versus your institution
- Access Controls: Implement Zero Trust architecture, MFA, and privileged access management for all cloud environments
- Continuous Monitoring: Deploy Cloud Security Posture Management (CSPM) tools to detect misconfigurations
- Data Encryption: Enforce encryption at rest and in transit with customer-managed keys (CMK)
Financial institutions using hyperscalers (AWS, Azure, Google Cloud) should leverage their Saudi Arabia local regions to satisfy data residency requirements while benefiting from cloud scalability.
Migrating critical workloads to the cloud in Saudi Arabia's financial sector requires careful alignment with both NCA ECC and SAMA CSF frameworks before and after migration. Here's a structured compliance roadmap:
1. Pre-Migration Risk Assessment (SAMA CSF Domain 3 & NCA ECC Art. 3-2): Conduct a formal Cloud Risk Assessment covering data classification, regulatory data residency requirements, and shared responsibility model gaps. SAMA requires that risk assessments for cloud services be documented and approved at the board/senior management level.
2. Data Residency & Sovereignty: SAMA mandates that customer financial data must reside within the Kingdom of Saudi Arabia. Ensure your cloud provider (e.g., AWS Riyadh, Azure Saudi North) can demonstrate in-Kingdom data storage with contractual guarantees. Non-compliance here is a critical finding during SAMA examinations.
3. NCA Cloud Cybersecurity Controls (NCA ECC-1:2018 Domain 2-9): NCA ECC requires implementing specific controls for cloud environments including: identity and access management, encryption of data at rest and in transit, logging and monitoring, and secure API management.
4. Cloud Security Architecture Review: Before go-live, conduct an architecture review validating: network segmentation, WAF deployment, DDoS protection, and privileged access management. ISO 27017 controls provide a useful supplementary baseline.
5. Vendor Due Diligence & Exit Strategy: Assess the CSP's financial stability, SLA terms, and incident response capabilities. Critically, document a cloud exit strategy per SAMA CSF to avoid vendor lock-in risks.
Key Reminder: SAMA requires formal approval for cloud adoption of critical systems — engage your SAMA relationship manager early in the process.
Cloud adoption in Saudi financial institutions is governed by a layered regulatory framework combining NCA ECC, SAMA CSF, and the NCA Cloud Cybersecurity Controls (CCC). Before migrating any workload, security and compliance teams must address the following key requirements:
1. Data Residency (NCA ECC Art. 2-7 & CCC Control 1-3): Critical and sensitive data — especially customer financial and personal data — must reside within the Kingdom of Saudi Arabia. Confirm that your chosen CSP (e.g., AWS Riyadh, Azure KSA) operates sovereign, locally compliant data centers.
2. Cloud Risk Assessment (SAMA CSF 3.3.4): Conduct a formal cloud risk assessment prior to migration. This must evaluate data classification, shared responsibility boundaries, availability SLAs, and residual risks.
3. Shared Responsibility Model Documentation: Clearly delineate security responsibilities between your institution and the CSP. Many audit failures stem from assuming the CSP handles controls that remain the customer's responsibility (e.g., IAM configurations, encryption key management).
4. Encryption Requirements (NCA CCC Control 3-1): All data at rest and in transit must be encrypted. Institutions must retain ownership and management of encryption keys — avoid CSP-managed keys for sensitive workloads.
5. Identity and Access Management: Enforce least-privilege access, MFA for all cloud console access, and privileged access monitoring aligned with SAMA CSF Control 3.3.16.
6. Exit Strategy and Portability: Regulatory guidance requires documented cloud exit strategies to prevent vendor lock-in and ensure operational resilience.
Engage your CISO Consulting team early in cloud migration planning to map technical controls to regulatory requirements and avoid costly remediation post-deployment.
Migrating core banking systems to the public cloud in Saudi Arabia requires rigorous compliance with multiple regulatory frameworks before go-live. The primary references are NCA Cloud Cybersecurity Controls (CCC-1:2020), SAMA CSF Domain 3.3, and SAMA's Cloud Computing Guidelines.
Pre-Migration Requirements:
- Regulatory Approval: SAMA requires prior written notification and, for critical systems, explicit approval before migrating to any cloud environment. Institutions must submit a Cloud Risk Assessment report as part of this process.
- Data Residency: All customer financial data and transaction records must be stored within the Kingdom of Saudi Arabia, per SAMA directives and NCA CCC Control 3-1. Contracts with CSPs must explicitly enforce this.
- Cloud Security Architecture Review: Per NCA CCC Control 2-4, a formal security architecture review must be conducted, covering network segmentation, identity and access management (IAM), encryption (at rest and in transit), and API security.
- Shared Responsibility Model Documentation: Institutions must formally document which security controls are managed by the CSP and which remain the institution's responsibility, aligned to ISO 27017 guidelines.
- Continuous Monitoring and SIEM Integration: NCA CCC Control 3-3 mandates real-time log collection and security event monitoring. Cloud workloads must be integrated into the institution's Security Operations Center (SOC).
- Exit Strategy: SAMA expects a documented cloud exit strategy to prevent vendor lock-in and ensure operational continuity.
Institutions should also validate that their CSP holds NCA certification or equivalent recognized accreditation before selection.
Cloud adoption in Saudi financial institutions is governed by a layered regulatory framework. Institutions must align with NCA ECC Article 2-2 (Cloud Computing), NCA's dedicated Cloud Computing Controls (CCC), and SAMA's Cloud Computing Guidelines before deploying any cloud-based systems.
Core Requirements:
Data Residency: Sensitive customer financial data and core banking workloads must reside within Saudi Arabia. Cloud providers must demonstrate compliance with NCA CCC data localization mandates. This applies to both infrastructure-as-a-service (IaaS) and software-as-a-service (SaaS) deployments.
Cloud Risk Assessment: Prior to any cloud migration, a formal Cloud Security Risk Assessment must be conducted per SAMA guidelines. This should evaluate data classification, shared responsibility models, and regulatory implications of the deployment.
Access Control & Identity Management: NCA ECC Control 2-2-3 requires strict identity and access management (IAM) for cloud environments, including multi-factor authentication (MFA), privileged access management (PAM), and least-privilege principles.
Encryption Standards: Data at rest and in transit must be encrypted using approved cryptographic standards. Key management must remain under the institution's control, not the cloud provider's.
Continuous Monitoring & SIEM Integration: Cloud workloads must feed into centralized Security Information and Event Management (SIEM) systems to maintain visibility per SAMA CSF Domain 3 (Cybersecurity Operations).
Exit Strategy: SAMA requires documented cloud exit strategies to ensure portability and prevent vendor lock-in, protecting operational resilience.
Our platform maps your cloud architecture against NCA CCC and SAMA cloud requirements, providing gap analysis, control implementation tracking, and audit-ready compliance documentation.
Cloud adoption in Saudi financial services is governed by multiple overlapping frameworks. Before any migration, institutions must navigate SAMA CSF Domain 5 (Cloud Computing), NCA ECC Article 2-14 (Cloud Security), and NCA Cloud Cybersecurity Controls (CCC).
Pre-Migration Requirements:
- Risk Assessment: Classify data sensitivity and determine which workloads are permissible for cloud hosting. SAMA restricts certain core banking data from residing outside Saudi Arabia without explicit approval.
- Cloud Service Provider (CSP) Due Diligence: CSPs must demonstrate compliance with NCA ECC and ideally hold CST (Communications, Space & Technology Commission) certification or equivalent.
- Data Residency: Per NCA ECC Art. 2-14-4 and SAMA guidance, customer financial data must remain within KSA borders unless formally approved otherwise.
Key Technical Controls:
- Implement Cloud Security Posture Management (CSPM) tools for continuous misconfiguration detection.
- Enforce encryption at rest (AES-256) and in transit (TLS 1.2+) per SAMA CSF Control 3.3.
- Apply Zero Trust Architecture principles — no implicit trust for any cloud resource.
- Deploy Identity and Access Management (IAM) with MFA enforced for all privileged accounts.
- Maintain full audit logs exported to a SIEM outside the CSP environment to prevent tampering.
Governance Requirements:
- Establish a Cloud Security Policy reviewed annually.
- Define clear shared responsibility matrices with each CSP.
- Include cloud environments in annual penetration testing scope.
Institutions using hyperscalers (AWS, Azure, GCP) must ensure their KSA-region deployments satisfy all local regulatory obligations before go-live.
Before migrating critical workloads to the cloud, Saudi banks must satisfy a layered set of regulatory requirements under SAMA CSF Domain 4 (Technology Risk Management) and NCA ECC-1:2018 Article 3-5 (Cloud Computing Controls).
Key requirements include:
- Risk Classification: Conduct a formal data and workload classification exercise. SAMA CSF Control 3.3.2 requires that data sensitivity levels guide hosting decisions — critical and confidential data may require on-premises or sovereign cloud deployments.
- SAMA Pre-Approval: Banks must obtain SAMA's explicit no-objection before moving core banking systems or customer data to cloud environments, particularly public cloud. Submit a Cloud Risk Assessment report as part of this process.
- Data Residency: NCA ECC mandates that data classified as 'Restricted' or above must remain within the Kingdom of Saudi Arabia. Verify your cloud provider maintains KSA-based data centers (e.g., AWS Riyadh, Azure Saudi North).
- Third-Party Due Diligence: Per SAMA CSF Control 3.4.1, cloud providers must undergo formal vendor risk assessments covering security certifications (ISO 27001, CSA STAR), SLA terms, audit rights, and incident notification obligations.
- Exit Strategy: Document a cloud exit and portability plan to avoid vendor lock-in, as required under SAMA outsourcing guidelines.
- Encryption & Access Control: Enforce encryption at rest and in transit, implement privileged access management (PAM), and maintain full audit logs accessible to SAMA examiners.
Practically, banks should establish a Cloud Security Governance Committee and integrate cloud risk reviews into the existing IT Risk Management framework before any migration begins.
Before migrating critical workloads to the cloud, Saudi banks must satisfy a layered set of requirements across both SAMA CSF and NCA ECC. Under SAMA CSF Control 3.3, institutions must conduct a formal cloud risk assessment that evaluates data classification, residency obligations, and vendor security posture. Data classified as sensitive or critical must — per SAMA CSF Appendix C — either remain on-premises or be hosted within the Kingdom unless explicit regulatory approval is obtained.
From an NCA ECC perspective, Article 3-8 mandates that cloud service providers used by financial entities meet ECC baseline controls and, where applicable, hold NCA certification. Banks must perform due diligence on CSP compliance documentation, shared responsibility matrices, and audit rights before signing contracts.
Key pre-migration steps include:
- Data Classification Review – Identify which workloads contain personal, financial, or regulated data under PDPL and SAMA guidelines.
- CSP Risk Assessment – Evaluate SOC 2 Type II, ISO 27001, and NCA ECC alignment of the chosen provider.
- Contractual Controls – Enforce clauses covering data sovereignty, incident notification (within 72 hours per SAMA CSF 3.7.3), audit rights, and exit strategies.
- Encryption & Key Management – Ensure customer-managed encryption keys (CMEK) are used for data at rest and in transit.
- Continuous Monitoring – Implement Cloud Security Posture Management (CSPM) tools and integrate alerts into your SOC.
Engaging a vCISO or GRC consultant with SAMA and NCA expertise during the pre-migration phase significantly reduces regulatory exposure and accelerates approval timelines.
Before migrating critical workloads to the cloud, Saudi banks must satisfy several layered requirements across both SAMA CSF and NCA ECC frameworks.
SAMA CSF Requirements: Under SAMA CSF Domain 4 (Technology Security), banks must conduct a formal Cloud Security Risk Assessment prior to any migration. Control 4.3 requires that all cloud deployments maintain data residency within the Kingdom of Saudi Arabia for sensitive financial data. Banks must also ensure contractual clauses with Cloud Service Providers (CSPs) address right-to-audit, incident notification timelines (within 72 hours), and data deletion guarantees upon contract termination.
NCA ECC Requirements: Per NCA ECC Article 3-5 (Cloud Computing Security), organizations must classify data before migration using the NCA Data Classification Policy and ensure that Tier 1 (confidential) data is hosted on government-approved or Saudi-localized infrastructure. ECC also mandates that CSPs undergo third-party security assessments aligned with ISO 27001 and CSA STAR certifications.
Practical Steps:
- Conduct a Cloud Readiness Assessment mapped to SAMA CSF and NCA ECC controls.
- Evaluate CSPs against SAMA's approved vendor criteria and NCA's Cloud Cybersecurity Controls.
- Implement CASB (Cloud Access Security Broker) solutions for continuous visibility.
- Establish a shared responsibility matrix clearly defining bank vs. CSP security obligations.
- Ensure Business Continuity and Disaster Recovery plans cover cloud-hosted systems.
Engaging a qualified vCISO or GRC consultant early in the migration planning phase significantly reduces compliance gaps and regulatory exposure.
Cloud adoption in Saudi fintech is accelerating, but it introduces significant compliance obligations under both NCA's Cloud Computing Controls (CCC) and SAMA CSF. Getting cloud security right requires addressing governance, architecture, and operational controls simultaneously.
NCA CCC Key Requirements: NCA CCC mandates that critical national infrastructure data — including financial customer data — must reside within Saudi Arabia or designated regions. Fintechs must verify that their cloud service provider (CSP) has a Saudi-region data center (AWS, Azure, and Google Cloud all operate local zones).
SAMA CSF Cloud Obligations (Controls 3.6 & 4.x):
- Conduct a cloud risk assessment before migration
- Maintain a cloud asset inventory covering all workloads, APIs, and storage
- Ensure CSP contracts include explicit security responsibilities per the Shared Responsibility Model
- Implement data encryption at rest (AES-256) and in transit (TLS 1.2+)
Technical Security Controls:
- Identity & Access: Enforce MFA for all cloud console access; implement least-privilege IAM policies; use Privileged Access Management (PAM) for admin accounts
- Network Segmentation: Deploy Virtual Private Clouds (VPCs) with strict security group rules; segregate production, development, and test environments
- Logging & Monitoring: Enable cloud-native logging (e.g., AWS CloudTrail, Azure Monitor) and integrate with your SIEM for real-time threat detection — required under SAMA CSF Control 3.5
- Vulnerability Management: Conduct quarterly cloud configuration reviews and use CSPM (Cloud Security Posture Management) tools to detect misconfigurations continuously
PDPL Considerations: When processing customer personal data in the cloud, ensure data processing agreements with CSPs address PDPL Article 29 requirements for cross-border transfers if applicable.
A vCISO with cloud expertise can accelerate your NCA CCC gap assessment and build a cloud security roadmap aligned to both frameworks.
Cloud adoption in Saudi financial institutions is subject to strict regulatory scrutiny under both SAMA CSF (Domain 4: Cloud Computing) and NCA ECC (Article 3-7: Cloud Computing Controls). Before migrating any workload, CISOs must conduct a formal cloud risk assessment and classify data per PDPL and internal sensitivity tiers. SAMA requires that institutions retain full ownership of data and that cloud service providers (CSPs) are contractually obligated to support regulatory audits. Key compliance steps include: (1) Ensure the CSP is approved or assessed under NCA's Cloud Cybersecurity Controls (CCC-1:2020). (2) Implement data residency controls — sensitive financial and customer data must remain within the Kingdom unless explicitly approved. (3) Establish a Cloud Security Governance Framework covering access control, encryption at rest and in transit (AES-256 minimum), and continuous monitoring. (4) Per SAMA CSF Control 4.3, conduct annual cloud-specific risk assessments and include cloud environments in your penetration testing scope. (5) Define clear exit strategies and data portability clauses in CSP contracts to avoid vendor lock-in risks. CISOs should also map cloud controls to ISO 27017 and CSA CCM for a layered compliance posture. Failure to comply can trigger SAMA supervisory action and NCA audit findings, both of which carry reputational and operational consequences for licensed financial entities.
SAMA CSF Domains 3.3 and 4.2 impose stringent requirements on cloud adoption within Saudi financial institutions. Before onboarding any cloud service provider (CSP), CISOs must conduct a formal Cloud Risk Assessment covering data residency, sovereignty, encryption standards, and exit strategy feasibility.
Key requirements include:
1. Data Residency: Per SAMA CSF Control 3.3.2, sensitive financial and customer data must be stored within the Kingdom of Saudi Arabia or in jurisdictions approved by SAMA. Confirm this contractually with your CSP.
2. Due Diligence: Evaluate CSPs against ISO 27001, CSA STAR, and SOC 2 Type II certifications. SAMA expects documented evidence of third-party audits and penetration testing results from providers.
3. Access Controls: SAMA CSF Control 4.2.3 requires privileged access management (PAM) controls for cloud environments, including MFA enforcement and just-in-time access provisioning.
4. Shared Responsibility Model: CISOs must formally document and communicate the shared responsibility boundary, ensuring configuration management, logging, and incident response responsibilities are explicitly assigned.
5. NCA ECC Alignment: NCA ECC Article 3-4 further mandates that government-regulated entities (including licensed banks) seek NCA approval before migrating critical national infrastructure workloads to cloud environments.
6. Continuous Monitoring: Implement Cloud Security Posture Management (CSPM) tools to detect misconfigurations and compliance drift in real time.
Practically, CISOs should build a Cloud Security Policy that references both SAMA CSF and NCA ECC controls, conduct annual cloud security reviews, and ensure Business Continuity Plans (BCPs) explicitly address cloud provider outage scenarios.
Cloud adoption is accelerating across Saudi financial institutions, but NCA ECC and SAMA CSF impose strict requirements that must be met before any migration to cloud environments — particularly for critical and sensitive workloads.
NCA ECC Cloud Security Requirements (Domain 2-13: Cloud Computing and Hosting):
- Cloud services hosting sensitive or critical data must be provided by CSPs holding a valid NCA Cloud Computing Cybersecurity Controls (CCC) certification or equivalent recognized approval.
- Data sovereignty requirements mandate that data classified as sensitive or national-critical must reside within the Kingdom of Saudi Arabia unless an explicit regulatory exemption is granted.
- Organizations must maintain full visibility and control over data stored in cloud environments, including encryption key ownership — per NCA ECC Control 2-13-1.
- Exit strategies and portability must be documented to avoid CSP lock-in risks.
SAMA CSF Alignment (Control 3.7 — Outsourcing and Cloud):
- Financial institutions must conduct a formal cloud risk assessment before onboarding any CSP.
- Contractual agreements with CSPs must include right-to-audit clauses, SLA guarantees, and incident notification obligations.
- Shared responsibility models must be clearly documented, with the institution retaining accountability for data protection regardless of CSP involvement.
CSP Evaluation Checklist:
- Regulatory certifications: Verify NCA CCC certification, ISO 27001, SOC 2 Type II, and CSA STAR.
- Data residency: Confirm all primary and backup data remains within KSA data centers.
- Encryption controls: Ensure customer-managed encryption keys (CMEK) are supported.
- Access management: Validate support for MFA, privileged access workstations, and zero-trust architecture.
- Incident response SLAs: Confirm breach notification timelines meet SAMA's 72-hour reporting obligation.
- Audit rights: Ensure contracts permit independent third-party audits of the CSP environment.
For financial institutions, hyperscalers such as AWS, Microsoft Azure, and Google Cloud now operate KSA-based regions — but contractual and technical controls must still be validated before onboarding.
Cloud adoption in Saudi financial services is tightly regulated. Both SAMA CSF and NCA ECC impose specific controls that CISOs must address before and during cloud deployments.
SAMA CSF Cloud Requirements (Domain 3.7):
- Formal cloud risk assessment before onboarding any cloud service provider (CSP)
- Data classification must determine what data can reside in the cloud — critical/sensitive financial data requires heightened controls
- Contractual obligations: CSPs must agree to SAMA's security requirements, audit rights, and data residency clauses
- Exit strategy and data portability provisions must be documented
NCA ECC Controls (Article 2-14 and Cloud Controls Annex):
- NCA's Cloud Cybersecurity Controls (CCC) framework applies to all government-connected entities and regulated financial institutions
- Data sovereignty: NCA mandates that certain data categories must reside within Saudi Arabia — verify CSP availability zones in KSA
- Shared responsibility model must be formally documented and reviewed annually
Practical Implementation Steps:
- Classify all data assets before migration using your data classification policy
- Conduct a formal Cloud Security Risk Assessment aligned with ISO 27017/27018
- Evaluate CSPs against NCA's approved cloud service provider list where applicable
- Implement Cloud Access Security Broker (CASB) controls for visibility and policy enforcement
- Establish continuous cloud security posture management (CSPM) monitoring
- Ensure encryption at rest and in transit meets SAMA's cryptographic control requirements
Key Risk: Misunderstanding the shared responsibility model remains the top cloud compliance gap in Saudi financial institutions. Document exactly what the CSP secures versus your internal obligations.
Cloud adoption in Saudi financial institutions must align with both SAMA CSF Control Domain 3.3 and NCA ECC-2 Article 3-12 (Cloud Computing Security). Compliance requires a layered approach across governance, architecture, and operations.
Regulatory Baseline: SAMA requires prior approval before migrating critical systems to the cloud. Submit a formal Cloud Risk Assessment and obtain written SAMA acknowledgment. NCA ECC mandates that all cloud service providers (CSPs) used by regulated entities must hold a valid NCA Cloud Compliance certificate or equivalent recognized certification.
Data Residency: Both frameworks require that sensitive financial and personal data remain within Saudi Arabia unless explicit regulatory approval is granted. This aligns with PDPL Article 29 on cross-border data transfers. Confirm your CSP offers KSA-based regions (e.g., AWS Riyadh, Microsoft Azure Saudi North) and that data sovereignty is contractually guaranteed.
Shared Responsibility Model: Define and document the security responsibilities split between your institution and the CSP. Map each NCA ECC control to either the CSP or internal teams — this is critical for audit evidence.
Key Technical Controls: Enforce encryption at rest and in transit (minimum AES-256 / TLS 1.2+), implement privileged access management (PAM) for cloud admin accounts, enable continuous cloud security posture management (CSPM) tooling, and conduct cloud-specific penetration testing annually.
Incident Response: Ensure your CSP contractually commits to incident notification within SAMA's required timeframe. Integrate cloud logs (CloudTrail, Azure Monitor) into your SIEM for real-time threat detection aligned with NCA SOC requirements.
Cloud adoption in Saudi banking is accelerating, but it introduces complex compliance obligations that span both SAMA CSF and NCA ECC simultaneously. Financial institutions must navigate these requirements carefully to avoid regulatory exposure.
SAMA CSF Cloud Requirements: SAMA's Technology Risk Management (TRM) guidelines and CSF Control Domain 4.5 require that cloud deployments undergo a formal risk assessment, with critical banking systems restricted to approved cloud service models. Key controls include:
- Data classification and enforcement of residency requirements (sensitive customer data must remain within the Kingdom per PDPL Article 29).
- Shared Responsibility Model documentation clarifying security obligations between the institution and the Cloud Service Provider (CSP).
- Exit strategy and data portability planning.
NCA ECC Cloud Controls: NCA ECC Articles 2-11 and 2-14 establish baseline cloud security controls including:
- Mandatory use of NCA-approved or locally regulated cloud providers for government-adjacent data.
- Encryption at rest and in transit using approved cryptographic standards.
- Continuous monitoring and logging with retention aligned to NCA requirements (minimum 12 months).
Practical Implementation Roadmap:
- Cloud Security Policy: Draft a dedicated policy referencing both SAMA TRM and NCA ECC obligations.
- CSP Due Diligence: Validate that your CSP holds ISO 27001, CSA STAR, and ideally Saudi CITC certifications.
- Security Baseline: Implement Cloud Security Posture Management (CSPM) tools to continuously enforce NCA ECC controls.
- Identity & Access: Enforce Zero Trust principles with MFA and Privileged Access Management (PAM) across all cloud workloads.
- Incident Response Integration: Extend your IR playbooks to cover cloud-specific breach scenarios with SAMA notification timelines in mind.
Regular cloud security assessments — at minimum annually per SAMA CSF — are essential to maintain compliance posture.
The NCA Essential Cybersecurity Controls (ECC) dedicates an entire domain — Domain 4: Cloud Computing and Hosting Cybersecurity — to regulating how Saudi organizations must secure cloud environments. Compliance is mandatory for all government entities and strongly recommended for regulated private sector organizations including financial institutions.
Key ECC Cloud Controls Include:
ECC 4-1 (Cloud Security Governance): Organizations must define a cloud security policy, classify workloads by sensitivity, and obtain formal approval from leadership before migrating any critical systems to cloud environments.
ECC 4-2 (Cloud Provider Assessment): Before selecting a Cloud Service Provider (CSP), a formal security assessment must be conducted covering data residency (Saudi data must reside within the Kingdom unless explicitly approved), certifications (ISO 27001, CSA STAR), and SLA commitments for security incident response.
ECC 4-3 (Shared Responsibility Model): Organizations must formally document what security responsibilities are retained internally versus delegated to the CSP, particularly around identity management, encryption, and logging.
ECC 4-4 (Data Protection in Cloud): All sensitive and personal data stored or processed in cloud environments must be encrypted at rest and in transit. Access must follow least-privilege principles with MFA enforced for administrative accounts.
SAMA Alignment: For banks and fintechs, SAMA CSF additionally requires that outsourcing to cloud providers be notified to SAMA in advance for material outsourcing arrangements, with a risk assessment documented.
PDPL Consideration: Personal data transferred to cloud environments must comply with PDPL cross-border transfer restrictions unless the destination jurisdiction provides adequate protection.
Practical guidance: Implement a Cloud Security Posture Management (CSPM) tool to continuously validate your cloud configurations against NCA ECC benchmarks and detect drift in real time.
Cloud adoption in Saudi Arabia's financial sector is subject to layered regulatory oversight. The NCA's Cloud Cybersecurity Controls (CCC-1:2020) and SAMA's Cloud Computing Framework establish the primary compliance baseline, while NCA ECC Domain 2-13 addresses cloud-specific cybersecurity requirements.
Critical controls organizations must implement:
- Data Residency & Sovereignty: Government and critical national infrastructure entities are generally required to store sensitive and confidential data within Saudi Arabia. Financial institutions must conduct data classification before migration to determine what can reside offshore versus what must stay local.
- Shared Responsibility Model (CCC-1 Control 3.1): Clearly document and contractually define the division of security responsibilities between the organization and the cloud service provider (CSP). Assume nothing is covered by default.
- Identity & Access Management: Enforce least-privilege access, multi-factor authentication (MFA) for all administrative accounts, and privileged access workstations (PAW) for cloud console access.
- Encryption Standards: Data must be encrypted at rest (AES-256) and in transit (TLS 1.2 minimum). Organizations must retain control of encryption keys — avoid CSP-managed keys for sensitive financial data.
- Security Monitoring & Logging (NCA ECC 2-13-3): Enable cloud-native logging (e.g., AWS CloudTrail, Azure Monitor) and integrate with the organization's SIEM. Log retention must meet SAMA's minimum 12-month online requirement.
- Exit Strategy: Maintain documented cloud exit plans to avoid vendor lock-in and ensure business continuity.
- CSP Assessment: Verify that your cloud provider holds recognized certifications (ISO 27001, CSA STAR, SOC 2) and has completed NCA's CSP assessment process where applicable.
For SAMA-regulated entities, any outsourcing to cloud providers also triggers the Outsourcing Risk Management Guidelines, requiring board-level approval for critical functions.
The NCA ECC (Essential Cybersecurity Controls) sets clear obligations for Saudi organizations planning to adopt cloud services, particularly under Control Domain 3-18 (Cloud Computing and Hosting). These requirements apply to government entities, critical infrastructure operators, and financial institutions supervised by SAMA.
Mandatory pre-migration controls include:
- Cloud Risk Assessment: Conduct a formal risk assessment specific to the target cloud environment. Evaluate the cloud service provider (CSP) against NCA-approved criteria, including data residency (Saudi Arabia or compliant jurisdiction), certifications (ISO 27001, ISO 27017/27018, CSA STAR), and breach notification capabilities.
- Data Classification: Per NCA ECC Control 3-7, classify all data before migration. Highly sensitive or "secret" data may be prohibited from public cloud environments without explicit authorization and compensating controls such as customer-managed encryption keys (CMEK).
- Shared Responsibility Model Documentation: Define and document the security responsibilities between your organization and the CSP. Gaps in coverage — particularly around identity, logging, and incident response — must be addressed before go-live.
- Access Control & Privileged Access: Implement MFA for all cloud management console access, enforce least-privilege IAM policies, and log all privileged actions per NCA ECC Control 3-5.
- Security Monitoring & SIEM Integration: Cloud audit logs (e.g., AWS CloudTrail, Azure Monitor) must feed into your central SIEM to support real-time threat detection and compliance reporting.
- Exit Strategy: NCA ECC requires organizations to maintain the ability to migrate away from a CSP without data loss or prolonged unavailability — document your portability and data retrieval procedures.
For SAMA-regulated entities, the SAMA Cloud Computing Framework supplements these NCA controls with additional financial-sector-specific requirements around outsourcing approval and regulatory notification.
Saudi financial institutions adopting cloud services face dual compliance obligations: SAMA CSF's technology risk management requirements and NCA ECC's cloud security controls (specifically ECC-1:2018 Section 3-14: Cloud Computing Controls). Here is how to build a compliant cloud security framework:
1. Pre-Adoption Risk Assessment: Before migrating any workload, conduct a formal Cloud Risk Assessment per SAMA CSF Control 3.2 (Technology Risk Management). Classify data sensitivity — PDPL 'sensitive personal data,' financial records, and transaction data require elevated protection measures and may restrict which cloud regions are permissible.
2. Data Residency & Sovereignty: NCA ECC mandates that critical national infrastructure data — which includes core banking data — must reside within the Kingdom of Saudi Arabia. Verify your cloud provider offers KSA-region data centers (e.g., AWS Riyadh, Azure KSA) and contractually enforce data residency.
3. Shared Responsibility Model Documentation: Clearly define security responsibilities between your institution and the Cloud Service Provider (CSP). SAMA examiners expect documented evidence of this delineation covering identity management, encryption, logging, and incident response.
4. Encryption Standards: Implement encryption at rest (AES-256) and in transit (TLS 1.2 minimum) for all financial data, consistent with SAMA CSF 3.3.5 and NCA ECC encryption controls. Maintain your own key management using HSM or BYOK models.
5. Continuous Monitoring & SIEM Integration: Cloud workloads must feed security events into your SIEM for real-time anomaly detection. NCA ECC Section 3-10 requires comprehensive logging and monitoring of all access to sensitive systems.
6. Cloud Security Posture Management (CSPM): Deploy automated CSPM tools to continuously audit cloud configurations against CIS Benchmarks, detecting misconfigurations before they become breaches.
7. Exit Strategy: SAMA CSF requires documented exit/migration plans from cloud providers to prevent vendor lock-in risk to operational continuity.
Our vCISO team can perform a cloud readiness gap assessment, map your architecture to SAMA CSF and NCA ECC controls, and deliver a remediation roadmap within weeks.
Other Questions 78
We deliver comprehensive security awareness training tailored to Saudi Arabia's regulatory landscape, covering SAMA CSF requirements, NCA ECC controls, and PDPL data protection obligations. Our programs include phishing simulation campaigns, role-based training for executives and technical staff, incident response procedures, and secure remote work practices. All content is delivered in both Arabic and English, aligned with Vision 2030 digital transformation goals, and designed to build a lasting security culture that reduces human-related risks across your organization.
Security training is a mandatory control under both SAMA CSF and NCA ECC frameworks, specifically addressing workforce competency and awareness requirements. Our training programs directly map to control domains including security awareness (SAMA CSF Domain 1), human resource security, and third-party management, providing documented evidence of compliance for audits and assessments. We ensure your staff understands their responsibilities under Saudi regulations, including PDPL data handling obligations, incident reporting procedures, and secure operational practices that reduce regulatory risk and demonstrate due diligence to supervisory authorities.
Absolutely. We develop fully customized training programs tailored to your specific industry requirements, whether you operate in financial services, healthcare, government, energy, or other sectors regulated under Saudi frameworks. Our approach includes conducting a training needs assessment, incorporating your organization's policies and real-world scenarios, addressing sector-specific threats and compliance obligations, and delivering content through your preferred methods—classroom sessions, e-learning platforms, or hybrid models. We also provide ongoing measurement through testing, phishing simulations, and behavioral metrics to continuously improve your security posture and demonstrate training effectiveness to stakeholders and regulators.
Cloud migration security in Saudi Arabia requires compliance with SAMA CSF for financial institutions and NCA ECC for critical infrastructure, alongside PDPL requirements for data protection. Essential measures include data classification and encryption both in transit and at rest, implementation of identity and access management controls aligned with ISO/IEC 27001:2022, and ensuring your cloud service provider meets local data residency requirements. You should conduct thorough security assessments before, during, and after migration, implement continuous monitoring, and establish incident response procedures that address both on-premises and cloud environments.
PDPL compliance during cloud migration requires careful attention to data transfer, processing, and storage practices. You must conduct a data protection impact assessment to identify personal data being migrated, ensure your cloud provider has appropriate technical and organizational measures in place, and verify that cross-border data transfers comply with PDPL requirements including obtaining necessary consents or implementing standard contractual clauses. Maintain detailed records of processing activities, implement privacy-by-design principles in your cloud architecture, and ensure individuals' rights can be exercised effectively in the new environment. Your cloud service agreements must clearly define data controller and processor responsibilities in accordance with PDPL provisions.
Secure cloud migration costs vary significantly based on your infrastructure complexity, data volume, compliance requirements, and chosen cloud model. Typical projects range from SAR 150,000 for small-scale migrations to several million riyals for enterprise-wide transformations with stringent regulatory requirements. Timeline generally spans 3-12 months depending on scope, including assessment and planning (4-8 weeks), pilot migration and testing (6-12 weeks), full migration execution, and post-migration optimization. Factors affecting both cost and duration include legacy system complexity, required security controls for SAMA CSF or NCA ECC compliance, staff training needs, and the level of automation implemented in your migration strategy.
Organizations in Saudi Arabia must comply with multiple incident reporting frameworks depending on their sector. The NCA ECC requires reporting cybersecurity incidents to the National Cybersecurity Authority within specified timeframes based on incident severity, with critical incidents reported immediately. Financial institutions must additionally report to SAMA within timelines defined in the SAMA Cybersecurity Framework, typically within 72 hours for significant incidents. Under the PDPL, personal data breaches must be reported to the SDAIA within 72 hours if they pose risks to individuals' rights and freedoms, with affected individuals notified without undue delay when high risk exists.
Regulatory incident reports should include comprehensive details to enable proper assessment and response. Essential elements include incident classification and severity level, date and time of detection and occurrence, affected systems and data categories, number of individuals impacted (for data breaches), preliminary root cause analysis, and immediate containment actions taken. Reports must describe the potential impact on operations, customers, and data subjects, outline your remediation plan with timelines, and identify any third parties involved. Follow-up reports should provide investigation findings, lessons learned, and implemented preventive measures. Maintaining consistent reporting formats and documentation standards ensures compliance with NCA, SAMA, and SDAIA expectations while supporting your internal improvement processes.
Vulnerability scanning is an automated process that identifies security weaknesses in your IT infrastructure, applications, and network devices before attackers can exploit them. Under the NCA Essential Cybersecurity Controls (ECC) and SAMA Cybersecurity Framework, organizations must conduct regular vulnerability assessments to maintain compliance and protect critical assets. This proactive approach helps Saudi organizations meet their regulatory obligations while reducing cyber risk exposure. Regular scanning is particularly critical for entities handling personal data under PDPL or operating critical infrastructure.
SAMA CSF and NCA ECC require organizations to conduct vulnerability scans at least quarterly for general systems, with more frequent scanning for critical assets and internet-facing systems. Best practice recommends monthly or continuous scanning for high-risk environments, particularly for financial institutions and critical infrastructure operators. Scans must also be performed after any significant system changes, new deployments, or when new vulnerabilities are publicly disclosed. Our managed vulnerability scanning service ensures continuous compliance with automated scheduling, prioritized remediation guidance, and regulatory reporting aligned with Saudi requirements.
Vulnerability scanning is an automated process that identifies known security weaknesses across your systems, while penetration testing is a manual, simulated attack that attempts to exploit those vulnerabilities to assess real-world risk. Scanning provides broad, frequent coverage and is ideal for continuous monitoring and compliance requirements under SAMA CSF and NCA ECC. Penetration testing offers deeper validation of your security controls and is typically conducted annually or after major changes. Both are complementary: vulnerability scans help you maintain ongoing security hygiene, while penetration tests validate your defenses against sophisticated attack scenarios relevant to the Saudi threat landscape.
We provide comprehensive Security Operations Center (SOC) services tailored to Saudi organizations, including 24/7 security monitoring, threat detection and response, incident management, and security event correlation. Our SOC services are designed to meet SAMA CSF requirements for financial institutions and NCA ECC controls for critical infrastructure, utilizing advanced SIEM platforms and threat intelligence. We offer both fully managed SOC solutions and co-managed models where our team augments your internal security operations, ensuring continuous protection against evolving cyber threats while maintaining compliance with Saudi regulatory frameworks.
Our SOC services directly support compliance with SAMA Cybersecurity Framework and NCA Essential Cybersecurity Controls through continuous monitoring, logging, and incident response capabilities that align with regulatory requirements. We implement security monitoring controls covering SAMA CSF domains such as Cybersecurity Operations and Cybersecurity Defense, and NCA ECC controls including logging and monitoring (3-1-1 through 3-1-5) and incident management (3-2-1 through 3-2-7). Our SOC generates compliance-ready reports, maintains audit trails, and ensures proper incident documentation and notification procedures as required by Saudi regulators. This integrated approach helps organizations demonstrate regulatory compliance while maintaining robust security posture aligned with Vision 2030's digital transformation objectives.
A managed SOC provides immediate access to experienced security analysts, advanced threat detection technologies, and 24/7 monitoring capabilities without the significant capital investment and operational overhead of building an in-house team. Building an internal SOC requires substantial investment in specialized personnel, SIEM and security tools, threat intelligence feeds, and continuous training to keep pace with evolving threats—costs that can be prohibitive for many organizations. Managed SOC services offer faster time-to-value, access to broader threat intelligence, and the ability to scale security operations as your organization grows, while allowing your internal IT team to focus on strategic initiatives. For Saudi organizations, partnering with a local managed SOC provider also ensures familiarity with regional compliance requirements, Arabic language support, and alignment with local business hours and cultural context.
While SAMA CSF and NCA ECC do not explicitly mandate specific certifications, they require organizations to employ qualified cybersecurity personnel with demonstrated competence. Industry-recognized certifications like CISSP, CISM, or ISO/IEC 27001 Lead Implementer provide strong evidence of the technical knowledge and professional standards expected by regulators. For critical roles such as Chief Information Security Officer (CISO) or security operations team leads, having certified professionals significantly strengthens your compliance posture and demonstrates due diligence to SAMA, NCA, and other regulatory bodies.
Under the Saudi Personal Data Protection Law (PDPL), you have comprehensive rights including the right to access your personal data, request corrections or deletions, object to processing, withdraw consent, and request data portability. You also have the right to be informed about how your data is collected and used, and to lodge complaints with the Saudi Data and Artificial Intelligence Authority (SDAIA) if your rights are violated. Organizations must respond to your requests within specified timeframes and provide clear mechanisms for exercising these rights, ensuring transparency and accountability in all data processing activities.
The right to data portability under PDPL allows you to receive your personal data in a structured, commonly used, and machine-readable format, and to transmit that data to another controller without hindrance. This right empowers you to switch service providers more easily, promotes competition, and gives you greater control over your digital footprint in alignment with Saudi Vision 2030's digital transformation objectives. Organizations must facilitate portability requests for data processed based on consent or contract, typically providing the data in formats like CSV, JSON, or XML. This right is particularly valuable in sectors like banking, telecommunications, and digital services where customer data mobility enhances market dynamics and consumer choice.
SAMA CSF encompasses five core domains: Cybersecurity Governance, Cybersecurity Defense, Cybersecurity Resilience, Third-Party Cybersecurity, and Cybersecurity Compliance. Each domain contains specific controls and requirements that organizations must implement based on their risk profile and criticality. The framework includes 114 cybersecurity controls across these domains, covering areas such as risk management, asset management, access control, incident response, business continuity, vendor management, and regulatory reporting. Organizations must conduct regular assessments to ensure ongoing compliance with all applicable controls.
Our comprehensive SAMA CSF compliance services include gap assessment, control implementation, policy development, and ongoing compliance monitoring tailored to the Saudi financial sector. We conduct thorough assessments of your current cybersecurity posture against all 114 SAMA CSF controls, develop remediation roadmaps, and assist in implementing required technical and organizational measures. Our team of certified experts with deep knowledge of SAMA requirements, NCA ECC, and PDPL provides end-to-end support including documentation, staff training, incident response planning, and preparation for SAMA audits to ensure your organization meets all regulatory obligations.
Our security awareness training directly addresses mandatory requirements under SAMA CSF controls (particularly in the Cybersecurity Culture domain) and NCA ECC framework provisions for employee awareness and training. The program covers essential topics including phishing prevention, password security, data classification under PDPL, incident reporting procedures, and secure remote work practices. We provide measurable training outcomes with completion certificates, assessment scores, and periodic refresher courses that satisfy regulatory audit requirements. Our training methodology includes simulated phishing campaigns and practical exercises that demonstrate compliance effectiveness to regulators.
Our training programs range from half-day security awareness sessions to comprehensive multi-week technical certification courses, depending on your organization's needs and compliance requirements. Pricing is structured based on training type, number of participants, delivery method (on-site, virtual, or hybrid), and customization level. We offer flexible packages including per-participant pricing for awareness training, project-based pricing for organization-wide programs, and annual subscription models for ongoing training needs. Contact us for a detailed quote tailored to your specific requirements, team size, and regulatory compliance objectives under SAMA, NCA, or PDPL frameworks.
Our third-party risk management framework is specifically designed to meet SAMA CSF domain requirements for vendor management and NCA ECC controls related to supply chain security. We conduct comprehensive due diligence assessments covering cybersecurity posture, data protection capabilities, and regulatory compliance of all third parties. Our approach includes continuous monitoring, contractual security requirements, and periodic reassessments to ensure ongoing compliance with Saudi regulatory standards. This ensures your organization maintains accountability for third-party risks as mandated by both frameworks.
We provide end-to-end third-party risk management services including vendor security assessments, contract review for cybersecurity clauses, and ongoing monitoring programs. Our services include security questionnaire development, on-site vendor audits, penetration testing coordination, and risk scoring based on criticality and data access levels. We also assist with establishing vendor management policies, creating risk registers, and implementing remediation plans for identified vulnerabilities. All services are tailored to meet PDPL data processor requirements and support your Vision 2030 digital transformation initiatives securely.
We implement a comprehensive PDPL compliance verification process for all third-party data processors handling personal data. This includes reviewing data processing agreements to ensure they contain mandatory PDPL clauses, verifying technical and organizational security measures, and confirming cross-border data transfer safeguards are in place. We conduct regular compliance audits and require vendors to demonstrate their data protection capabilities through certifications, security assessments, and incident response procedures. Our approach ensures your organization meets its controller obligations under PDPL while maintaining full visibility into how vendors handle Saudi residents' personal data.
We implement end-to-end encryption during all data transfer phases and ensure data residency requirements align with PDPL Article 25 for cross-border transfers. Our migration process includes data classification, secure transfer protocols (TLS 1.3), and continuous monitoring to prevent unauthorized access. We conduct pre-migration security assessments and maintain detailed audit logs throughout the migration process to demonstrate compliance with PDPL and SAMA CSF requirements. All personal data handling follows the principle of data minimization and purpose limitation as mandated by Saudi regulations.
Our cloud migration methodology aligns with NCA ECC domains including Asset Management (1-1), Data Security (5-1 to 5-4), and Third-Party Cybersecurity (4-1). We implement multi-factor authentication, privileged access management, and network segmentation during migration phases. All cloud service providers we work with are evaluated against NCA Cloud Cybersecurity Controls (CCC), and we ensure proper configuration of security groups, identity and access management policies, and encryption at rest and in transit. Post-migration, we conduct vulnerability assessments and penetration testing to validate security posture.
Yes, we conduct a comprehensive pre-migration security assessment that includes current infrastructure analysis, data classification, risk assessment, and gap analysis against SAMA CSF and NCA ECC frameworks. This assessment identifies sensitive data, evaluates existing security controls, and determines the appropriate cloud deployment model (public, private, or hybrid) based on your regulatory requirements and risk appetite. We deliver a detailed migration security roadmap with specific recommendations for Saudi Arabia's regulatory landscape, including considerations for Vision 2030 digital transformation objectives and sector-specific requirements for financial institutions, healthcare, or government entities.
SAMA CSF and NCA ECC frameworks recommend conducting vulnerability scans at least quarterly for standard systems, with monthly scans for critical infrastructure and payment systems. Additional scans should be performed after any significant system changes, new deployments, or security incidents. Financial institutions under SAMA supervision typically require continuous or weekly scanning for internet-facing assets. We offer flexible scanning schedules including continuous monitoring solutions that automatically detect and report new vulnerabilities, ensuring ongoing compliance with Saudi regulatory standards.
Building an in-house SOC requires significant capital investment in technology infrastructure, hiring specialized cybersecurity analysts (which are scarce in the Saudi market), and ongoing training to keep pace with evolving threats. A managed SOC service provides immediate access to experienced security professionals, advanced threat detection technologies, and 24/7/365 monitoring at a predictable operational cost. Our managed SOC eliminates the challenges of recruitment, reduces time-to-value, and provides enterprise-grade security capabilities that would otherwise require millions in investment. For most Saudi organizations, especially those in regulated sectors like banking and healthcare, a managed SOC offers faster compliance achievement, better threat coverage, and allows internal IT teams to focus on strategic initiatives supporting Vision 2030 objectives.
For Saudi Arabian organizations, certifications aligned with SAMA CSF, NCA ECC, and PDPL requirements are essential. ISO 27001 is highly recognized and demonstrates comprehensive information security management systems. Additionally, certifications like CISSP, CISM, and CEH are valuable for technical staff, while ISO 27701 specifically addresses privacy management in line with PDPL requirements. These certifications help organizations meet regulatory obligations and support Vision 2030's digital transformation goals.
The timeline for ISO 27001 certification typically ranges from 6 to 12 months, depending on your organization's size, current security maturity, and complexity. The process includes gap analysis, implementing required controls, documentation, internal audits, and the final certification audit by an accredited body. Organizations with existing security frameworks aligned with SAMA CSF or NCA ECC requirements may achieve certification faster. Our team provides structured implementation support to streamline the process and ensure successful certification within optimal timeframes.
While not always legally mandated, having certified cybersecurity professionals significantly strengthens your compliance posture with SAMA, NCA, and PDPL requirements. Key certifications include CISSP for security architecture, CISA for audit and compliance, and CISM for security management. For technical roles, CEH and CompTIA Security+ are valuable. NCA also recognizes specific training programs aligned with the Essential Cybersecurity Controls. Certified staff demonstrate competency and help organizations maintain robust security programs that meet regulatory expectations and support digital transformation initiatives.
You can submit a formal data deletion request directly to the data controller (the organization holding your data) through their designated privacy channels. The organization must respond within 30 days and delete your data unless they have a legitimate legal basis to retain it, such as regulatory compliance requirements under SAMA CSF or NCA ECC. If your request is denied, the organization must provide clear justification, and you have the right to escalate the matter to SDAIA. We help organizations establish compliant data deletion processes that balance individual rights with regulatory obligations.
Yes, PDPL grants you the explicit right to withdraw consent at any time, and the withdrawal process must be as easy as giving consent initially. Once you withdraw consent, the organization must stop processing your personal data unless they have another legal basis for processing, such as contractual necessity or legal obligations. Organizations are required to inform you about your right to withdraw consent before collecting your data and must implement mechanisms to facilitate easy withdrawal. This right is fundamental to ensuring individual control over personal information in Saudi Arabia's digital economy.
Non-compliance with NCA ECC can result in severe penalties under Saudi cybersecurity laws, including fines up to 5 million SAR for organizations and potential imprisonment for responsible individuals. Beyond financial penalties, non-compliant organizations may face operational disruptions, suspension of digital services, reputational damage, and loss of government contracts or licenses. The NCA conducts regular audits and assessments, and organizations must submit compliance reports demonstrating adherence to all applicable controls. Proactive compliance not only avoids penalties but also protects your organization from cyber threats, ensures business continuity, and builds trust with customers and partners in alignment with Vision 2030's digital economy objectives.
Yes, security awareness training is a mandatory requirement under both SAMA CSF and NCA ECC frameworks for organizations operating in Saudi Arabia. The NCA Essential Cybersecurity Controls specifically require organizations to implement ongoing security awareness programs for all employees. SAMA regulations mandate that financial institutions conduct regular training on information security policies, procedures, and best practices. Organizations must document training completion, maintain records, and conduct periodic assessments to ensure compliance with these regulatory requirements.
We provide comprehensive third-party risk assessment services aligned with SAMA CSF Domain 9 (Third Party Service Provider Management) and NCA ECC requirements. Our methodology includes vendor security assessments, contract review for cybersecurity clauses, continuous monitoring frameworks, and due diligence processes. We help you establish a robust third-party risk management program that ensures your vendors meet regulatory requirements and protect your organization's data and systems. Our services include vendor questionnaires, on-site assessments, and ongoing compliance monitoring tailored to Saudi Arabian regulations.
Under PDPL, organizations must ensure third parties processing personal data implement appropriate security measures and comply with data protection obligations. We conduct thorough vendor assessments focusing on data processing agreements, security controls, data localization requirements, and breach notification procedures. Our services include drafting PDPL-compliant data processing agreements, conducting security audits of third-party systems, and establishing monitoring mechanisms to ensure ongoing compliance. We also help you maintain proper documentation and evidence of vendor compliance for regulatory inspections.
SAMA CSF and NCA ECC require annual reassessments at minimum, with more frequent reviews for high-risk vendors or those handling critical systems and sensitive data. Our reassessment process includes updated security questionnaires, vulnerability scan reviews, compliance certificate verification, and incident history analysis. We implement a risk-based approach where critical vendors undergo quarterly reviews, while lower-risk vendors are assessed annually. The process also includes continuous monitoring through automated tools, regular security updates from vendors, and immediate reassessment following any security incidents or significant changes in the vendor's environment.
We implement a comprehensive compliance framework that maps cloud security controls to SAMA CSF and NCA ECC requirements before, during, and after migration. Our approach includes conducting gap assessments, implementing required security controls such as data encryption, access management, and continuous monitoring aligned with Saudi regulatory standards. We ensure data residency requirements are met by utilizing cloud regions within Saudi Arabia or approved jurisdictions, and maintain detailed documentation for audit purposes. Our team works closely with your compliance officers to ensure all regulatory obligations under PDPL and sector-specific requirements are maintained throughout the migration process.
We implement multi-layered security controls including end-to-end encryption for data in transit and at rest, secure VPN tunnels for data transfer, and role-based access controls with multi-factor authentication. Our migration process includes data classification, vulnerability assessments, and continuous security monitoring to detect and respond to threats in real-time. We conduct pre-migration security audits and post-migration validation testing to ensure data integrity and confidentiality throughout the process. All security measures are designed to meet or exceed SAMA CSF and NCA ECC requirements while supporting your organization's Vision 2030 digital transformation goals.
Yes, we specialize in secure cloud migration services for highly regulated sectors including banking, financial services, healthcare, and government entities in Saudi Arabia. Our team has extensive experience with sector-specific requirements such as SAMA's cybersecurity framework for financial institutions and healthcare data protection regulations. We provide tailored migration strategies that address unique compliance challenges, implement industry-specific security controls, and ensure business continuity throughout the transition. Our proven methodology has successfully supported numerous Saudi organizations in their secure cloud adoption journey while maintaining full regulatory compliance and operational resilience.
Incident reports must include incident classification and severity level, date and time of detection and occurrence, affected systems and data types, number of impacted users or customers, and immediate actions taken. Additional required information includes root cause analysis, potential business impact, containment measures implemented, evidence preservation methods, and estimated recovery timeline. For PDPL compliance, reports must also detail any personal data breaches, affected individuals, and notification plans, ensuring comprehensive documentation that meets both NCA ECC and SAMA CSF requirements.
Vulnerability scanning is an automated process that identifies security weaknesses in your IT infrastructure, applications, and networks before attackers can exploit them. For Saudi organizations, it is essential for meeting SAMA CSF requirements (particularly domains 1 and 8) and NCA ECC controls that mandate regular security assessments. Regular vulnerability scanning helps protect sensitive data under PDPL regulations and supports Vision 2030's digital transformation objectives by ensuring robust cybersecurity posture. Our scanning services provide comprehensive coverage with prioritized remediation guidance tailored to Saudi regulatory requirements.
SAMA CSF and NCA ECC frameworks require organizations to conduct vulnerability scans at least quarterly for standard systems and monthly for critical infrastructure and internet-facing assets. Additionally, scans must be performed after any significant system changes, new deployments, or security incidents. Financial institutions under SAMA supervision often require more frequent scanning, sometimes weekly or continuous monitoring for high-risk environments. We offer flexible scanning schedules including continuous vulnerability management solutions that automatically detect and alert you to new vulnerabilities in real-time, ensuring ongoing compliance with Saudi regulatory requirements.
Our vulnerability scanning service includes comprehensive network and application scanning, authenticated and unauthenticated scans, detailed vulnerability reports with CVSS scoring, prioritized remediation recommendations, and compliance mapping to SAMA CSF, NCA ECC, and PDPL requirements. We provide executive summaries in both English and Arabic, technical remediation guides, and ongoing support from certified security analysts. Pricing varies based on the number of IP addresses, applications, scan frequency, and whether you need continuous monitoring or periodic assessments. Contact us for a customized quote tailored to your organization's specific needs and regulatory obligations.
Our SOC services are specifically designed to address SAMA CSF and NCA ECC compliance requirements for Saudi organizations. We provide continuous monitoring (ECC-1, SAMA Domain 1), threat detection and incident response capabilities (ECC-3, SAMA Domain 4), and comprehensive logging and analysis (ECC-2). Our SOC generates detailed compliance reports, maintains audit trails, and implements security controls aligned with both frameworks. We also ensure that all security events are documented and responded to within the timeframes mandated by Saudi regulators, helping you avoid penalties and maintain regulatory standing.
Our managed SOC services include 24/7/365 security monitoring, threat intelligence integration, incident detection and response, vulnerability management, and regular security reporting. We provide dedicated security analysts, SIEM platform management, threat hunting, and escalation procedures aligned with your business requirements. Response times vary by severity: Critical incidents receive immediate response within 15 minutes, high-priority incidents within 1 hour, and medium-priority within 4 hours, all compliant with NCA and SAMA requirements. All services are delivered by bilingual teams familiar with Saudi regulatory landscape and include monthly executive reports in both Arabic and English.
For SAMA CSF compliance, organizations benefit from having ISO 27001, CISSP, and CISM certified professionals on their teams. NCA ECC compliance typically requires expertise demonstrated through certifications like ISO 27001, CEH, and specialized training in the Essential Cybersecurity Controls framework. While specific certifications aren't mandated, having certified professionals significantly strengthens your compliance posture and demonstrates commitment to cybersecurity excellence in line with Vision 2030 objectives.
Yes, we offer comprehensive training and certification preparation programs tailored to Saudi Arabian organizations. Our services include customized training for ISO 27001, CISSP, CISM, and other industry-recognized certifications, with specific focus on SAMA CSF and NCA ECC requirements. We provide both classroom and virtual training options, exam preparation materials, and ongoing mentorship to ensure your team successfully obtains and maintains relevant certifications that support your compliance and security objectives.
Organizations must establish clear processes and mechanisms to respond to data subject requests within the timeframes specified by PDPL, typically within 30 days. This includes implementing secure identity verification procedures, maintaining accurate data inventories, and training staff on handling rights requests. Our cybersecurity solutions help organizations automate these processes while ensuring compliance with both PDPL and complementary frameworks like SAMA CSF and NCA ECC. We provide technical controls, documentation templates, and workflow systems that enable timely and compliant responses to all data subject rights requests.
The right to data portability under PDPL allows individuals to receive their personal data in a structured, commonly used, and machine-readable format, and to transmit that data to another data controller without hindrance. This right applies when processing is based on consent or contract and is carried out by automated means. Organizations must provide data in formats such as CSV, JSON, or XML within reasonable timeframes. Our technical solutions help businesses implement secure data export mechanisms that comply with PDPL requirements while maintaining data integrity and security throughout the transfer process.
Achieving NCA ECC compliance typically takes 6-18 months depending on your organization's current security maturity level and size. The main steps include conducting a comprehensive gap assessment against all 114 controls, developing a remediation roadmap, implementing required technical and organizational controls, and preparing documentation for NCA submission. Organizations must prioritize controls based on their classification level (1-5) and ensure continuous monitoring and improvement. We recommend engaging cybersecurity experts familiar with NCA requirements to streamline the process and ensure successful compliance.
Non-compliance with NCA ECC can result in severe consequences including financial penalties of up to 5 million SAR, operational shutdowns, and reputational damage. The National Cybersecurity Authority has enforcement powers to conduct audits, issue compliance orders, and restrict operations of non-compliant entities. Beyond regulatory penalties, non-compliance increases vulnerability to cyberattacks, potentially leading to data breaches, service disruptions, and loss of customer trust. Organizations may also face difficulties in securing government contracts or partnerships, as NCA ECC compliance is increasingly becoming a prerequisite for doing business in Saudi Arabia's digital economy.
SAMA Cyber Security Framework (CSF) is a comprehensive regulatory framework issued by the Saudi Central Bank (SAMA) to protect the financial sector from cyber threats. All financial institutions operating in Saudi Arabia, including banks, insurance companies, finance companies, and payment service providers, must comply with SAMA CSF. The framework establishes mandatory cybersecurity controls across five domains: Cybersecurity Governance, Cybersecurity Defense, Cybersecurity Resilience, Third-Party Cybersecurity, and Cybersecurity Compliance. Non-compliance can result in significant penalties and regulatory sanctions.
SAMA CSF is structured around five core domains with 114 cybersecurity controls. The Cybersecurity Governance domain covers risk management, policies, and organizational structure. Cybersecurity Defense includes asset management, access control, threat detection, and incident response. Cybersecurity Resilience focuses on business continuity, disaster recovery, and backup strategies. Third-Party Cybersecurity addresses vendor risk management and supply chain security. Finally, Cybersecurity Compliance ensures ongoing monitoring, auditing, and regulatory reporting to demonstrate adherence to the framework.
Achieving SAMA CSF compliance typically takes 6-18 months depending on the organization's current cybersecurity maturity level and size. The implementation process begins with a comprehensive gap assessment against all 114 controls to identify deficiencies. This is followed by developing a remediation roadmap, implementing required technical and organizational controls, establishing governance structures, and conducting staff training. Organizations must then perform internal audits, prepare compliance documentation, and submit reports to SAMA demonstrating adherence to the framework requirements.
We offer comprehensive cybersecurity training programs tailored to Saudi organizations, including SAMA CSF compliance training, NCA ECC framework implementation, security awareness for employees, incident response training, and PDPL data protection workshops. Our programs are designed to meet local regulatory requirements and support Vision 2030 digital transformation goals. Training is available in both Arabic and English, with customizable modules for different organizational roles from executives to technical staff. We also provide specialized training for security operations centers (SOC) and penetration testing teams.
Yes, our security awareness training programs are fully aligned with both NCA ECC and SAMA CSF requirements for Saudi organizations. The training covers all essential controls including password management, phishing awareness, data classification, incident reporting, and secure remote work practices as mandated by Saudi regulations. We regularly update our content to reflect the latest NCA guidelines and SAMA circulars, ensuring your organization maintains compliance. Upon completion, participants receive certificates that can be used as evidence of compliance during regulatory audits.
Our cybersecurity training programs are highly flexible and range from half-day security awareness sessions to comprehensive multi-week technical courses depending on your needs. Basic employee awareness training typically takes 2-4 hours, while specialized technical training for IT staff can span 3-5 days. We fully customize all programs to address your organization's specific industry sector, risk profile, and compliance requirements under SAMA, NCA, or PDPL. Training can be delivered on-site at your location, online, or in a hybrid format to accommodate your team's schedule and preferences.
SAMA CSF requires financial institutions to implement comprehensive third-party risk management programs, including vendor due diligence, continuous monitoring, and contractual security requirements. NCA ECC mandates that organizations maintain an inventory of third parties with access to critical systems and ensure they meet minimum cybersecurity standards. Our services help you establish compliant third-party risk frameworks that satisfy both regulatory bodies, including vendor assessments, security questionnaires, and ongoing risk monitoring aligned with Saudi regulations.
We provide comprehensive third-party risk assessments that ensure vendors processing personal data comply with PDPL requirements, including data processing agreements, cross-border transfer controls, and breach notification procedures. Our services include vendor security assessments, privacy impact analysis, contractual review to ensure PDPL compliance clauses, and ongoing monitoring of third-party data handling practices. We help you establish a risk-based approach to vendor management that protects personal data throughout the supply chain while meeting Saudi data protection obligations.
As Saudi organizations embrace digital transformation under Vision 2030, they increasingly rely on cloud services, fintech partners, and technology vendors, making third-party risk management critical for secure innovation. A robust third-party risk program enables you to confidently adopt new technologies and partnerships while maintaining security and compliance standards. We help you build scalable vendor risk frameworks that accelerate digital initiatives, ensure supply chain resilience, and protect your organization's reputation as you contribute to Saudi Arabia's digital economy growth.
Under NCA ECC and SAMA CSF, organizations must report cybersecurity incidents within specific timeframes. Critical incidents affecting critical infrastructure or financial services must be reported to NCA within 1 hour of detection, with detailed reports following within 72 hours. SAMA-regulated entities must also notify SAMA of any incidents affecting financial systems, customer data, or business continuity, with initial notification required immediately upon discovery.
We provide comprehensive incident reporting solutions tailored to Saudi regulatory requirements including NCA and SAMA frameworks. Our services include developing incident classification matrices, establishing automated reporting workflows, creating communication templates for regulatory notifications, and implementing 24/7 incident response coordination. We also provide training for your security teams on proper escalation procedures and conduct regular drills to ensure compliance with the mandatory reporting timelines under Saudi regulations.
Incident reports to NCA and SAMA must include specific details such as incident classification and severity level, date and time of detection, affected systems and data categories, number of impacted users or customers, and immediate containment actions taken. Additional requirements include root cause analysis, potential regulatory violations (such as PDPL breaches), estimated recovery timeline, and preventive measures being implemented. Our incident management platform ensures all mandatory fields are captured and reports are formatted according to regulatory templates for seamless submission.
A Security Operations Center (SOC) is a centralized facility that monitors, detects, analyzes, and responds to cybersecurity threats in real-time across your organization's IT infrastructure. In Saudi Arabia, having a SOC is essential for compliance with SAMA CSF and NCA ECC requirements, which mandate continuous monitoring and incident response capabilities. A SOC provides 24/7 protection against evolving cyber threats, reduces response time to security incidents, and helps protect sensitive data in accordance with PDPL regulations. By implementing a SOC, organizations align with Vision 2030's digital transformation goals while maintaining robust cybersecurity posture.
We offer comprehensive SOC services including 24/7 security monitoring, threat detection and analysis, incident response, vulnerability management, and security event correlation using advanced SIEM platforms. Our services are specifically designed to meet SAMA CSF requirements for financial institutions, NCA ECC controls for critical infrastructure, and PDPL data protection mandates. We provide Arabic and English reporting, local incident response teams familiar with Saudi regulatory requirements, and regular compliance assessments. Our SOC analysts are trained on Saudi-specific threat landscapes and regulatory frameworks, ensuring your organization maintains continuous compliance while defending against both local and global cyber threats.
Our SOC operates 24/7/365 with advanced threat detection capabilities that identify security incidents within minutes of occurrence. We maintain response time SLAs aligned with NCA ECC requirements, typically achieving initial incident triage within 15 minutes for critical alerts and full incident response initiation within 1 hour. Our team uses automated threat intelligence, machine learning-based anomaly detection, and continuous monitoring to minimize dwell time of threats in your environment. For organizations under SAMA supervision, we ensure incident reporting timelines meet regulatory requirements, with immediate escalation protocols for critical incidents affecting financial systems or personal data protected under PDPL.
Our team holds internationally recognized certifications including CISSP, CISM, CEH, and ISO 27001 Lead Auditor/Implementer. We also maintain specialized certifications relevant to the Saudi market such as SAMA CSF assessors and NCA ECC compliance specialists. Our consultants continuously update their credentials to stay current with evolving cybersecurity standards and regulations. This ensures we deliver expert guidance aligned with both global best practices and local regulatory requirements.
Yes, we offer comprehensive training programs to prepare your team for leading cybersecurity certifications including CISSP, CISA, CEH, and ISO 27001. Our training is customized to address Saudi Arabia's regulatory landscape, incorporating SAMA CSF, NCA ECC, and PDPL requirements into the curriculum. We provide both classroom and virtual training options with Arabic and English instruction. Our programs include exam preparation materials, hands-on labs, and post-training support to maximize certification success rates.
For Saudi regulatory compliance, we recommend ISO 27001 Lead Implementer/Auditor as it aligns closely with SAMA CSF and NCA ECC frameworks. CISM and CISSP certifications are highly valued for governance and risk management roles required by financial institutions under SAMA supervision. For technical implementation, CEH and specialized cloud security certifications support NCA ECC controls. Additionally, obtaining PDPL-specific training ensures your team understands data protection requirements under Saudi Arabia's Personal Data Protection Law, supporting Vision 2030's digital transformation objectives.
Under PDPL, individuals have comprehensive rights including the right to access their personal data, request corrections or deletions, object to processing, and withdraw consent at any time. You also have the right to data portability, allowing you to receive your data in a structured format and transfer it to another controller. Additionally, you can lodge complaints with the Saudi Data and Artificial Intelligence Authority (SDAIA) if you believe your rights have been violated. These rights align with Saudi Arabia's Vision 2030 commitment to protecting digital privacy and building trust in the digital economy.
To request data deletion under PDPL, you should submit a written request to the organization's designated Data Protection Officer or through their official privacy contact channels. The organization must respond to your request within 30 days and either comply with the deletion or provide valid legal grounds for retention, such as regulatory obligations under SAMA CSF or NCA ECC requirements. If your request is denied without proper justification, you have the right to escalate the matter to SDAIA. Organizations must maintain audit trails of such requests to demonstrate PDPL compliance during regulatory assessments.
The NCA Essential Cybersecurity Controls (ECC) is a mandatory framework issued by the National Cybersecurity Authority for all government entities and critical infrastructure operators in Saudi Arabia. It establishes baseline security requirements across 114 controls organized into 5 domains to protect national cyber assets. Compliance is legally required and helps organizations align with Vision 2030's digital transformation goals while protecting against evolving cyber threats. Non-compliance can result in significant penalties and operational restrictions.
The timeline for NCA ECC compliance typically ranges from 6 to 18 months depending on your organization's current security maturity level, size, and complexity. The process includes gap assessment, remediation planning, implementation of controls, documentation, and validation phases. Organizations with existing cybersecurity programs may achieve compliance faster, while those starting from baseline may require extended timelines. We provide phased implementation approaches that prioritize critical controls to demonstrate progress while working toward full compliance.
While both frameworks aim to strengthen cybersecurity in Saudi Arabia, NCA ECC applies to government entities and critical infrastructure across all sectors, whereas SAMA CSF is specific to financial institutions regulated by the Saudi Central Bank. NCA ECC contains 114 controls across 5 domains with a broader national security focus, while SAMA CSF has a more detailed risk-based approach tailored to financial sector threats. Organizations in the financial sector must comply with both frameworks, and we help identify overlapping controls to optimize compliance efforts and avoid duplication.
No matching questions found.
Didn't find what you're looking for?
✉️ Contact Us