Entire Section | SAMA Rulebook

Cyber Risk Control

Glossary

Item	Description
Access Control	Means to ensure that access to assets is authorized and restricted based on business and security requirements.
Access management	The process of granting authorized users the right to use a service, while preventing access to non-authorized users.
Anomalous Session	Log-in sessions to mobile or online services that have different log-in parameters to those previously used by the customer, e.g., Device ID or location; or when the IP address is flagged as a risk.
Anomaly Detection	Finding patterns in data that depart significantly from the expected behaviour. Fraud anomaly detection can be implemented as an intelligence tool using unsupervised Machine Learning algorithms.
Anti-skimming solution	A solution that monitors an ATM or POS environment for illegally mounted intrusion mechanisms (both hard- and software).
Application	A software program hosted by an information system. Source: NISTIR 7298 3Glossary of Key Information Security Terms
Application Architects	Application Architects identify needed changes to the portfolio of applications across the ecosystem. They develop and administer application-specific standards such as user interface design, globalization, Web services, portal application programming interfaces, XML, and content. They provide design recommendations based on long-term development organization strategy and develop enterprise level application and custom integration solutions including major enhancements and interfaces, functions and features.
Application whitelisting	A list of applications and application components (libraries, configuration files, etc.) that are authorized to be present or active on a host according to a well- defined baseline. Application whitelisting technologies are intended to stop the execution of malware and other unauthorized software. Unlike security technologies such as antivirus software, which use blacklists to block known bad activity and permit all other, application whitelisting technologies are designed to permit known activity and block all other. (NIST SP 800–167 Guide to Application Whitelisting)
APT	An advanced persistent threat (APT) is an adversary that possesses sophisticated levels of expertise and significant resources which allow it to create opportunities to achieve its objectives by using multiple attack vectors (e.g., cyber, physical, and deception). These objectives typically include establishing and extending footholds within the information technology infrastructure of the targeted organizations for purposes of exfiltrating information, undermining or impeding critical aspects of a mission, program, or organization; or positioning itself to carry out these objectives in the future. The advanced persistent threat: (i) pursues its objectives repeatedly over an extended period of time; (ii) adapts to defenders’ efforts to resist it; and (iii) is determined to maintain the level of interaction needed to execute its objectives. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Artificial Intelligence	The use of computer systems to perform tasks typically requiring human knowledge and logical capabilities, often in problem solving scenarios.
Asset	The data, personnel, devices, systems, and facilities that enable the organization to achieve business purposes. Source: NISTIR 7298 3Glossary of Key Information Security Terms
Asset management	The systematic process of deploying, operating, maintaining, upgrading, and disposing of assets in a safe, secure and cost effective manner.
Asset Owner	The term Asset owner identifies an individual or entity that has approved management responsibility for controlling the production, development, maintenance, use of the information assets.
Assurance	Grounds for confidence that the other four security goals (integrity, availability, confidentiality, and accountability) have been adequately met by a specific implementation. “Adequately met” includes (1) functionality that performs correctly, (2) sufficient protection against unintentional errors (by users or software), and (3) sufficient resistance to intentional penetration or by-pass. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Attack Vector	General approach for achieving an impact, taking advantage of the exposure of a type of, or a region in, an attack surface.
Attacker	Refer to "Threat actor".
Audit	Independent review and examination of records and activities to assess the adequacy of system controls to ensure compliance with established policies, operational procedures, and relevant standard, legal and regulatory requirements.
Audit trail	A record showing who has accessed an Information Technology (IT) system and what operations the user has performed during a given period. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Authentication	Verifying the identity of a user, process, or device, often as a prerequisite in order to allow access to resources in a system.
Authorization matrix	A matrix that defines the rights and permissions for a specific role needs for information. The matrix lists each user, the business process tasks he or she performs, and the affected systems.
Availability	Ensuring timely and reliable access to and use of information. Source: NISTIR 7298r3 Glossary of Key Information Security Terms
Backup	Files, devices, data and procedures available for use in case of a failure or loss, or in case of deletion or suspension of their original copies.
Batch Processing	Batch processing is the processing of the transactions in a group or batch with no or minimal human interaction.
BCIS	The Banking Committee for Information Security
Black Box System	A complex system where the internal rules and mechanisms are not visible to or understood by the system owner.
Blacklist	A list of untrustworthy or high risk individuals or entities that should be excluded and avoided. Also known as block-list.
Blue Team	A group of individuals that conduct operational network vulnerability evaluations and provide mitigation techniques to customers who have a need for an independent technical review of their network security posture. The Blue Team identifies security threats and risks in the operating environment, and in cooperation with the customer, analyzes the network environment and its current state of security readiness. Based on the Blue Team findings and expertise, they provide recommendations that integrate into an overall community security solution to increase the customer's cybersecurity readiness posture. Often times a Blue Team is employed by itself or prior to a Red Team employment to ensure that the customer's networks are as secure as possible before having the Red Team test the systems. Ref: (CNSSI 4009–2015 )
Business Application	Any software or set of computer programs that are used by business users to perform various business functions.
Business Continuity (BC)	The capability of an organization to continue delivery of IT and business services at acceptable predefined levels following a disruptive incident. Source: ISO 22301:2012 Societal security -- Business continuity management systems
Business Continuity Management (BCM)	Holistic management process that identifies potential threats to an organization and the impacts to business operations those threats, if realized, might cause, and which provides a Fundamental Requirements for building organizational resilience with the capability of an effective response that safeguards the interests of its key stakeholders, reputation, brand and value creating activities. Source: ISO 22301:2012 - Business continuity management systems — Requirements
BYOD	Bring your own device (BYOD) refers to personally owned devices (laptops, tablets, and smart phones) that employees and contractors are permitted to use to carry out business functions.
Case Management System	A system used to manage alerts and fraud incidents from an initial report, through investigation, resolution and remediation where required.
CCTV	Closed-circuit television (CCTV) is the use of video cameras to transmit a signal to a specific place, on a limited set of monitors.
CEO	The Chief Executive Officer (CEO) is the executive with the chief decision-making authority in an organization.
CERT	A computer emergency response team (CERT) is a group of experts that handle computer security incidents.
Change management	The controlled identification and implementation of required changes within a business or information systems.
Chief Information Officer (CIO)	A senior-level executive referred as Chief Information Officer (CIO), Chief Technology Officer (10) / Head of IT or relevant stakeholder who is accountable for IT advocacy, aligning IT and business strategies, and planning, resourcing and managing the delivery of IT services, information and the deployment of associated human resources.
Chief Operating Officer (COO)	A senior-level executive responsible for the daily operation of the organization.
CISO	Chief information security officer (CISO). A senior-level executive responsible for establishing and maintaining the enterprise cyber security vision, strategy, and program to ensure information assets and technologies are adequately protected.
Classification	Setting the sensitivity level2 of data and information that results in security controls for each level of classification. Data and information sensitivity levels are set according to predefined categories where data and information is created, modified, improved, stored or transmitted. The classification level is an indication of the value or importance of the data and information of the organization.
Classification scheme	Refer to 'Data classification'.
Cloud computing	A model for enabling on-demand network access to a shared pool of configurable IT capabilities/ resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. It allows users to access technology-based services from the network cloud without knowledge of, expertise with, or control over the technology infrastructure that supports them. This cloud model is composed of five essential characteristics (on-demand self-service, ubiquitous network access, location independent resource pooling, rapid elasticity, and measured service); three service delivery models: (Cloud Software as a Service [SaaS], Cloud Platform as a Service [PaaS], and Cloud Infrastructure as a Service [IaaS]); and four models for enterprise access (Private cloud, Community cloud, Public cloud, and Hybrid cloud). (NISTIR 7298r2 Glossary of Key Information Security Terms)
Code of Conduct	A defined set of expectations which outline principles, values, and behaviours that an organisation considers important to its operations and success.
Compensating Control	A management, operational, and/or technical control (i.e., safeguard or countermeasure) employed by an organization in place of a recommended control in the low, moderate, or high baselines that provides equivalent or comparable protection for an information system.
Compensating Security Control	A management, operational, and/or technical control (i.e., safeguard or countermeasure) employed by an organization in place of a recommended security control in the low, moderate, or high baselines that provides equivalent or comparable protection for an information system. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Confidentiality	Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Configuration Item (CI)	Component of an infrastructure-or an item, such as a request for change, associated with an infrastructure-which is (or is to be) under the control of configuration management
Containerization	1. A virtualization method for deploying and running distributed applications without launching a virtual machine for each application. Instead, multiple isolated systems run on a single control host and access a single kernel. 2. Unit of software that packages up code and all its dependencies.
Contractor	An individual or organisation under contract for the provision of services to an organisation.
Control effectiveness	The measure of correctness of implementation (i.e., how consistently the control implementation complies with the security plan) and how well the security plan meets organizational needs in accordance with current risk tolerance. (NISTIR 7298r2 Glossary of Key Information Security Terms)
COO	Chief Operating Officer. A senior-level executive responsible for the daily operation of the organization.
Counter-Fraud Culture	The shared values, beliefs, knowledge, attitudes and understanding about fraud risk within an organisation. In a strong Counter-Fraud culture people proactively identify, discuss, and take responsibility for fraud risks.
Counter-Fraud Maturity	The extent to which an organisation’s resources are effectively implemented for the purpose of countering fraud in comparison to global accepted standards and best practice.
Counter-Fraud Policy	A set of criteria for the provision of Counter-Fraud activities. It sets the commitment and objectives for Counter-Fraud and documents responsibilities.
Counter-Fraud Strategy	A high-level plan, consisting of projects and initiatives, to mitigate fraud risks while complying with legal, statutory, contractual, and internally prescribed requirements.
Counter-Fraud Department	A dedicated department or team established for the purpose of managing the implementation of the organisation’s Counter-Fraud objectives.
Counter-Fraud Governance	A set of responsibilities and practices exercised by the Board, Executive and Senior Management with the goal of providing strategic direction for countering fraud, ensuring that Counter-Fraud objectives are achieved, ascertaining that fraud risks are managed appropriately and verifying that the enterprise's resources are used responsibly.
Counter-Fraud Governance Committee (CFGC)	An established group of individuals tasked with providing oversight and direction, and ensuring that the organisation’s combined Counter-Fraud capabilities are functioning appropriately and efficiently.
Counter-Fraud Programme	A collection of policies, processes, guidelines, risk management approaches, actions, training, best practices, assurance, and technologies that are used to protect the Member Organisation and its customers against internal and external fraud threats.
Critical IT infrastructures	These are the information assets (i.e., facilities, systems, networks, processes, and key operators who operate and process them), whose loss or vulnerability to security breaches may result in significant negative impact on the availability, integration or delivery of basic services, including services that could result in serious loss of property, alongside observance of significant economic and/or social impacts.
Critical services	Services provided by a third party where a failure or disruption in the provision of services could leave the Member Organisation unable to serve its customers or meet its regulatory obligations.
Cryptographic solutions	Solutions pertaining to cryptography. Refer to 'Cryptography'.
Cryptography	The discipline that embodies the principles, means, and methods for the transformation of data in order to hide their semantic content, prevent their unauthorized use, or prevent their undetected modification. Source: NISTIR 7298r3 Glossary of Key Information Security Terms
Custodianship	Responsibility for controlling the access to and the accounting, safeguarding, and destruction of information according to an organization's security policy .
Cyber kill chain	Contractual concept used to structure a cyber-attack.
Cyber risk	Risk of financial loss, operational disruption, or damage, from the failure of the digital technologies employed for informational and/or operational functions introduced to a manufacturing system via electronic means from the unauthorized access, use, disclosure, disruption, modification, or destruction of the manufacturing system Source: NISTIR 7298r3 Glossary of Key Information Security Terms
Cyber security	Cyber security is defined as the collection of tools, policies, security concepts, security safeguards, guidelines, risk management approaches, actions, training, best practices, assurance, and technologies that can be used to protect the member organization's information assets against internal and external threats.
Cyber security architecture	An embedded, integral part of the enterprise architecture that describes the structure and behavior for the enterprise's security processes, cyber security systems, personnel and organizational sub-units, showing their alignment with the enterprise's mission and strategic plans. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Cyber security audit	Independent review and examination of security-related records and activities to provide reasonable assurance that system controls are adequate and that established policies and operational procedures are compliant. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Cyber security awareness	Activities which seek to focus an individual's attention on a cyber security issues. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Cyber security awareness program	A program that explains proper rules of behavior for the safe and secure use of IT systems and information. The program communicates cyber security policies and procedures that need to be followed.
Cyber security control	The management, operational, and technical controls (i.e., safeguards or countermeasures) prescribed for an information system to protect the confidentiality, integrity, and availability of the system and its information. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Cyber Security event	Any observable occurrence in an information system or network that has, or may potentially result in, unauthorized access, processing, corruption, modification, transfer or disclosure of data and / or Information or (b) a violation of an explicit or implemented Organization security policy.
Cyber security examination	A review of security-related records and activities of records and activities to assess the adequacy of system controls and to ensure compliance with established policies and operational procedures. An examination does not provide assurance.
Cyber security function	A function, independent from the information technology function, that is headed by a CISO and that reports directly to the CEO/managing director of the Member Organization or general manager of a control function. The information security function is responsible for: – supporting information security policies, defining information security roles and responsibilities, and setting information security goals for implementation; – providing information security and information risk management frameworks; – identifying known and emerging information security issues; – identifying shifts in the organization's implicit information risk appetite; – assisting management in developing information security processes and controls to manage information security risks and information security issues; – providing guidance and training on information security and information risk management processes; – facilitating and monitoring implementation of effective information security and information risk management practices by operational management; – alerting operational management to emerging information security issues and changing regulatory and information risk scenarios; – monitoring the adequacy and effectiveness of internal control, accuracy and completeness of reporting, compliance with laws and regulations in connection with information security , and timely remediation of deficiencies.
Cyber security governance	A set of responsibilities and practices exercised by the board and executive management with the goal of providing strategic direction for cyber security, ensuring that cyber security objectives are achieved, ascertaining that cyber risks are managed appropriately and verifying that the enterprise's resources are used responsibly.
Cyber security policy	A set of rules that governs all aspects of security-relevant system and system element behaviour. Note 1: System elements include technology, machine, and human, elements. Note 2: Rules can be stated at very high levels (e.g., an organizational policy defines acceptable behaviour of employees in performing their mission/business functions) or at very low levels (e.g., an operating system policy that defines acceptable behaviour of executing processes and use of resources by those processes) Source: NISTIR 7298r3 Glossary of Key Information Security Terms
Cyber security program	Top-down management structure and mechanism for coordinating security activities throughout the organization.
Cyber security review	Independent review and examination of security-related records and activities to provide limited assurance that system controls are adequate and that established policies and operational procedures are compliant. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Cyber security risk assessment	The process of identifying risks to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other organizations, and the Nation, resulting from the operation of an information system. Part of risk management, incorporates threat and vulnerability analyses, and considers mitigations provided by security controls planned or in place Source: NISTIR 7298r3 Glossary of Key Information Security Terms
Cyber security risk management	The process of managing risks to organizational operations, organizational assets, individuals, other organizations, and the Nation, resulting from the operation of an information system, and consists of (i) a risk assessment; (ii) the implementation of a risk mitigation strategy; and (iii) employment of techniques and procedures for the continuous monitoring of the security state of the information system. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Cyber security strategy	A high-level plan, consisting of projects and initiatives, to mitigate cyber security risks while complying with legal, statutory, contractual, and internally prescribed requirements.
Cyber security threat	Any circumstance or event with the potential to adversely impact organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, or the Nation through an information system via unauthorized access, destruction, disclosure, modification of information, and/or denial of service. Source: NISTIR 7298r3 Glossary of Key Information Security Terms
Cyber threat intelligence (CTI)	Threat information that has been aggregated, transformed, analyzed, interpreted, or enriched to provide the necessary context for decision-making processes. Source: NISTIR 7298 3Glossary of Key Information Security Terms
Cyber-attacks	An attack, via cyberspace, targeting an enterprise’s use of cyberspace for the purpose of disrupting, disabling, destroying, or maliciously controlling a computing environment/infrastructure; or destroying the integrity of the data or stealing controlled information. Ref (NIST SP 800–39 (CNSSI 4009) )
Data classification	The conscious decision to assign a level of sensitivity to data as it is being created, amended, enhanced, stored, or transmitted. The classification of the data should then determine the extent to which the data needs to be controlled / secured and is also indicative of its value in terms of business assets.
Data Masking	A. computerized technique of blocking out the display of sensitive information or PII.
Database Administrator	Database administrator, frequently known just by the acronym DBA, is a role usually within the Information Technology department, charged with the creation, maintenance, backups, querying, tuning, user rights assignment and security of an organization's database.
Disaster Recovery	Programs, activities and plans designed to restore the organizations critical business functions and services to an acceptable situation, following exposure to cyber and IT incidents or disruption of such services.
Disaster Recovery (DR)	Programs, activities and plans designed to restore the organizations critical business functions and services to an acceptable situation, following exposure to cyber and IT incidents or disruption of such services.
Disaster Recovery Plan	Disaster Recovery is part of BCM which includes policies, standards, procedures and processes pertaining to resilience, recovery or continuation of technology infrastructure supporting critical business processes.
Double crosscut	A technique using saws or blades to cut media into confetti-sized bits.
Due Diligence	The investigation of an employee, customer or third party to confirm facts and that it is as presented.
Emergency Stop	A self-service capability for customers to immediately freeze their account and block further transactions if they suspect their account has been compromised
Employee	Employees encompass members of the Board of Directors and its committees, Executives, permanent and contract employees, consultants, and employees working through a third party
Enterprise Architect	Description of the fundamental underlying design of the components of the business system, or of one element of the business system (e.g., technology), the relationships among them, and the manner in which they support the enterprise's objectives.
Enterprise architecture	The description of an enterprise's entire set of information systems: how they are configured, how they are integrated, how they interface to the external environment at the enterprise's boundary, how they are operated to support the enterprise mission, and how they contribute to the enterprise's overall security posture. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Enterprise risk management	The methods and processes used by an enterprise to manage risks to its mission and to establish the trust necessary for the enterprise to support shared missions. It involves the identification of mission dependencies on enterprise capabilities, the identification and prioritization of risks due to defined threats, the implementation of countermeasures to provide both a static risk posture and an effective dynamic response to active threats; and it assesses enterprise performance against threats and adjusts countermeasures as necessary. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Entity Resolution	A process to identify data records in a single data source or across multiple data sources that refer to the same real-world entity and to link the records together.
Ethical hackers	An expert, performing a penetration test. Refer to ‘Penetration test’.
Exploit	A piece of code or a command, which purposes to perform malicious activities on a system, by taking advantage of a vulnerability.
External Fraud	A fraudulent event conducted by any persons on the ‘outside’ of the organisation i.e., not employed by the organisation.
F.E.E.R.	The Financial Entities Ethical Red Teaming Framework
Fall-back	Business procedures and measures, undertaken when events have triggered the execution of either a business continuity plan or a contingency plan.
Feasibility study	A phase of a system development life cycle (SDLC) methodology that researches the feasibility and adequacy of resources for the development or acquisition of a system solution to a user need.
Financial Crime	Criminal activities to provide economic benefit including money laundering; terrorist financing; bribery and corruption; and market abuse and insider dealing.
Forensics	The practice of gathering, retaining, and analyzing computer-related data for investigative purposes in a manner that maintains the integrity of the data. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Formally documented	Documentation that is written, approved by the senior leadership and disseminated to relevant parties.
Fraud	Any act that aims to obtain an unlawful benefit or cause loss to another party. This can be caused by exploiting technical or documentary means, relationships or social means, using functional powers, or deliberately neglecting or exploiting weaknesses in systems or standards, directly or indirectly.
Fraud case	An individual occurrence of fraud recognised by an organisation.
Fraud Incident	A fraud case or series of associated cases.
Fraud Landscape/Threat Landscape	Fraud threats, trends, and developments in the political, economic, social, technological, or legal environment.
Fraud Response Plan	A plan which details the actions to be undertaken when a fraud is suspected or has been detected. This will include reporting protocols, team responsibilities and information logging.
Fraud Risk Appetite	The level of fraud risk that an organisation is willing to accept or tolerate in pursuit of its objectives.
Fraud Risk Assessment	A process aimed at addressing the organisation’s vulnerability to fraud. This will include identification of fraud risks, assessment of the likelihood that fraud risks will occur and the resulting impact, determination of the appropriate response, and review of the control framework.
Fraud Risk Management	The ongoing process of identifying, analysing, monitoring, and responding to fraud risks to which the organisation and its customers are exposed.
Fraud Scenario Analysis	The testing of devised fraud scenarios for the purpose of assessing the current capability of fraud systems within the organisation.
Fraud Threat	Any circumstance or event with the potential to result in a fraud event occurring.
Fraud Typology	A categorisation of a fraud event based on its methodology and common themes with other fraud events.
Freezing period	e.g. Salaries deposit days, public or national holidays.
Gateway server	Interface providing compatibility between networks by converting transmission speeds, protocols, codes, or security measures. It directs, but does not filter, connections between networks. See also ‘Proxy server’.
GCC countries	Members of the Gulf Cooperation Council (GCC), a political and economic alliance of the Kingdom of Bahrain, the State of Kuwait, the Sultanate of Oman, the State of Qatar, the Kingdom of Saudi Arabia and the United Arab Emirates.
Geo-blocking	A form of internet censorship where access to content is restricted based upon the user's geographical location.
Geofencing	Restricting access to online or mobile services based upon the user's geographical location.
Green Team	The Green Team is provided by SAMA Financial Sector Cyber Team. The Green Team appoints the Test Manager for each red teaming test. The Green Team also maintains a short list of potential Red Teaming Providers and provides the threat intelligence for the Financial Sector.
Hard token	A hard token (a.k.a. an 'authentication token') is a hardware security device that is used to authorize a user to a system. Some hard tokens are used in combination with other security measures to further enhance security (known as multi-factor authentication). See also 'Soft token'.
Head of Cyber Security	The Head of Cyber Security may refer to the Head of Information Security, the Chief Information Security Officer (CISO) or any other title given to the senior manager accountable for the cyber security function and processes.
Hybrid cloud services	A cloud computing service that is composed of some combination of private, public and community cloud services, from different service providers. (Gartner)
Hypervisor	A hypervisor allows one host computer to support multiple guest Virtual Machines (VMs) by virtually sharing its resources, like memory and processing.
Identity management	The process of controlling information about users on computers, including how they authenticate and what systems they are authorized to access and/or what actions they are authorized to perform. It also includes the management of descriptive information about the user and how and by whom that information can be accessed and modified. Managed entities typically include users, hardware and network resources and even applications
IDS	An intrusion detection system (IDS) is a hardware or software product that gathers and analyzes information from various areas within a computer or a network to identify possible security breaches, which include both intrusions (attacks from outside the organizations) and misuse (attacks from within the organizations). (NISTIR 7298r2 Glossary of Key Information Security Terms)
Incident	An occurrence that (1) actually or imminently jeopardizes, without lawful authority, the integrity, confidentiality, or availability of information or an information system; or (2) constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies. Source: NISTIR 7298r3 Glossary of Key Information Security Terms
Incident management	The monitoring and detection of security events on an information system and the execution of proper responses to those events.
Incident management plan	The documentation of a predetermined set of instructions or procedures to detect, respond to, and limit consequences of a malicious cyber-attack against an organization's information system(s). Also Refer to 'Cyber security incident management. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Incineration	A method of media and device destruction using high heat.
Indicator of compromise	A forensic artifact or remnant of an intrusion that can be identified on a host or network. (RSA)
indicator of Compromise (loC)	Indicators of compromise serve as forensic evidence of potential intrusions on a host system or network.
Information Asset	A piece of information, stored in any manner, which is recognized as 'valuable' to the organization.
Inherent Risk	The fraud risks posed to the organisation’s business operations or its customers if there were no controls present.
Integrity	Guarding against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Intelligence Monitoring	The process of continually reviewing and gathering intelligence on new and emerging fraud threats and typologies from a comprehensive range of sources.
Interdependencies	Set of interaction with dependence of information assets on each another in order to deliver set of works or tasks.
Internal Fraud	Fraud committed by or with the assistance of people employed by the organisation.
IPS	An intrusion prevention system (IPS) can detect an intrusive activity and can also attempt to stop the activity, ideally before it reaches its targets. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Irreversibly delete	See 'Secure erase'
IT Change and Release Management	A holistic and proactive approach to managing the transition from a current to a desired organizational state, focusing specifically on the critical human or "soft" elements of change
IT facilities	The physical environment where the IT infrastructure is located.
IT risk	The business risk associated with the use, ownership, operation, involvement, influence and adoption of IT within an enterprise.
IT Steering committee	An executive-management-level committee that assists in the delivery of the IT strategy oversees day-to-day management of IT service delivery and IT projects, and focuses on implementation aspects.
Jailbreaking	A form of privilege escalation that removes software restrictions imposed by the software manufacturer and often results in unlimited privileges on the device.
Key performance indicator	A type of performance measurement that evaluate the success of an organization or of a particular activity in which it engages. Numerical threshold(s) are typically used to categorize performance.
Key Performance Indicator (KPI)	KPI is a type of performance measurement that evaluates the success of an organization or of a particular activity in which it engages to achieve particular objectives and goals.
Key risk indicator	A measure used to indicate the probability an activity or organization will exceed its defined risk appetite. KRIs are used by organizations to provide an early signal of increasing risk exposures in various areas of the enterprise.
Key Risk Indicator (KRI)	KRI is a measure used to indicate the probability an activity or organization will exceed its defined risk appetite. KRIs are used by organizations to provide an early signal of increasing risk exposures in various areas of the enterprise.
Key Risk Indicators (KRIs)	A measure used to indicate the probability an activity or organisation will exceed its defined risk appetite. KRIs are used by organisations to provide an early signal of increasing risk exposures in various areas of the enterprise.
Keyword Analysis	Codifying rules to match key words on a look-up table to those within key fields of a fraud case record. Complexity can be added to rules such as requiring the words to be in a particular order or high-risk terms that have often indicated fraud.
Kill Chain	Adopted from the military, the kill chain was developer by Lockheed Martin to identify and taxonomize the various phases of a cyber attack (Reconnaissance, Weaponization, Delivery, Exploitation, Installation, Command and Control, Actions upon Objectives).
KSA	Kingdom of Saudi Arabia
Likelihood	A weighted factor based on an analysis of the probability that a given threat is capable of exploiting a given vulnerability.
LoA	Letter of Authorization
Machine Learning	The use of computer systems that have the capability to learn and adapt without explicit instruction through the use of algorithms or models to analyse and build on patterns and trends in data.
Major change	Any change to a system's configuration, environment, information content, functionality, or users which has the potential to change the risk imposed upon its continued operations. Source: NISTIR 7298r2 Glossary of Key Information Security Terms Critical changes are also included in the concept of major changes.
Malware	Software or firmware intended to perform an unauthorized process that will have adverse impact on the confidentiality, integrity, or availability of an information system. A virus, worm, Trojan horse, or other code-based entity that infects a host. Spyware and some forms of adware are also examples of malicious code. Source: NISTIR 7298r3 Glossary of Key Information Security Terms
Management Information	Information collated and then presented, often in the form of a report or statement, to management or decision makers for the purpose of identifying trends, solving issues and/or forecasting the future.
MDM	Mobile device management (MDM) is an industry term for the administration of mobile devices.
Member Organisation	All financial institutions or financial services providers regulated by SAMA.
Member Organization	Any regulated entity supervised and regulated by SAMA.
MITRE ATT&CK	An open source framework developed by MITRE taxonomizing tactics, techniques, and procedures used by threat actors when conducting cyber attacks.
MO	Member Organization - Organizations affiliated with SAMA.
Mobile device	Portable cartridge/disk-based, removable storage media (e.g., floppy disks, compact disks, USB flash drives, external hard drives, and other flash memory cards or drives that contain nonvolatile memory). Portable computing and communications device with information storage capability (e.g., notebook/laptop computers, personal digital assistants, cellular telephones, digital cameras, and audio recording devices). (NISTIR 7298r2 Glossary of Key Information Security Terms)
Model Validation	Analysis to assess whether the outputs of a system are performing as expected.
Modus Operandi	A method of procedure, especially referred to a distinct pattern or method of operation that indicates or suggests the work of a single criminal in more than one crime.
Motivation	The type of benefit or harm a threat actor ultimately wants to achieve with its actions.
Mule accounts	Accounts set-up (often via remote or online channels) to receive fraudulently obtained funds and launder the proceeds of crime.
Multi-factor authentication	Authentication using two or more factors to achieve authentication. Factors include: (i) something you know (e.g. password/PIN); (ii) something you have (e.g., cryptographic identification device, token); or (iii) something you are (e.g., biometric). (NISTIR 7298r2 Glossary of Key Information Security Terms)
Multi-Factor Authentication	Authentication using two or more factors to achieve authentication. Factors include something you know (e.g., password/PIN), something you have (e.g., cryptographic identification device, token), or something you are (e.g., biometric).
NDA	Non-disclosure agreement
Near Misses	Potential fraud incidents that are detected and remediated prior to the fraud incident resulting in a monetary loss.
Need-to-know	The restriction of data, which is considered sensitive unless one has a specific need to know; for official business duties.
Network	Information system(s) implemented with a collection of interconnected components. Such components may include routers, hubs, cabling, telecommunications controllers, key distribution centers, and technical control devices. Source: NISTIR 7298 3Glossary of Key Information Security Terms
NIST	The (U.S.) National Institute of Standards and Technology (www.nist.gov)
Non-repudiation	Protection against an individual falsely denying having performed a particular action. Provides the capability to determine whether a given individual took a particular action such as creating information, sending a message, approving information, and receiving a message. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Off-the-shelf system	Software that already exists and is available from commercial sources.
Open Source Intelligence (OSINT)	Relevant information derived from the systematic collection, processing, and analysis of publicly available information in response to known or anticipated intelligence requirements.
Organization	Company, entity, or group of people that works together for a particular purpose.
Outsourcing	Obtaining goods or services by contracting with a supplier or service provider.
Owner	Individual or group that holds or possesses the rights of and the responsibilities for an enterprise, entity or asset.
Patch	An update to an operating system, application, or other software issued specifically to correct particular problems with the software. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Patch management	The systematic notification, identification, deployment, installation, and verification of operating system and application software code revisions. (NISTIR 7298r2 Glossary of Key Information Security Terms)
PBX	A private branch exchange (PBX) is a telephone exchange or switching system that serves a private organization and performs concentration of central office lines and provides intercommunication between a large number of telephone stations within the organization.
PCI DSS	The Payment Card Industry Data Security Standard (PCI DSS) is a proprietary cyber security standard for organizations that handle branded credit cards from the major card schemes including Visa, MasterCard, American Express, Discover, and JCB.
Penetration test	Security testing in which evaluators mimic real-world attacks in an attempt to identify ways to circumvent the security features of an application, system, or network. Penetration testing often involves issuing real attacks on real systems and data, using the same tools and techniques used by actual attackers. Most penetration tests involve looking for combinations of vulnerabilities on a single system or multiple systems that can be used to gain more access than could be achieved through a single vulnerability. Ref (NIST SP 800–115)
Penetration testing	A test methodology in which assessors, using all available documentation (e.g., system design, source code, manuals) and working under specific constraints, attempt to circumvent the security features of an information system. Source: NISTIR 7298r3 Glossary of Key Information Security Terms
Periodically	With this term, SAMA does not intend to define a default time interval. Each Entities has the responsibility to determine this interval based on its own risk- based approach. The same term adopted in different control requirements could be translated into different time intervals by the MO.
Personal devices	Devices, like a smart phone, that are not owned or issued by the organization.
Physical security	The physical protection of facilities that host information assets against intentional and unintentional security events.
PIN	A password consisting only of decimal digits. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Policy Breach	The failure to comply with or disregard of policy requirements.
Precision and Recall Testing	Metrics to evaluate the effectiveness of models. Precision: The ability of a classification model to identify only the relevant data points. Recall: The ability of a model to find all the relevant cases within a data set.
Predictive Analytics	The use of statistics and modelling techniques to determine future outcomes or performance.
Privileged account / access	An information system account with approved authorizations to perform security- relevant functions that ordinary users are not authorized to perform. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Procedure	Procedures are the specific implementation the threat actor uses for techniques. Source: MITRE ATT&CK
Process	A set of interrelated or interacting activities which transforms inputs into outputs.
Proxy server	A server that services the requests of its clients by forwarding those requests to other servers. It directs and filters connections between networks. See also ‘Gateway server’.
Public cloud service	Services that are rendered over a network that is open to the public. Public cloud providers own and operate the infrastructure at their data center and access is generally via the Internet.
RACI Chart	Illustrates who is Responsible, Accountable, Consulted and Informed within an organizational framework.
RACI Matrix	Illustrates who is Responsible, Accountable, Consulted and Informed within an organisational framework.
Ransomware	A form of malware designed to deny access to a computer system or data until ransom is paid. A user of a system infected with ransomware is usually confronted with an extortion message (in many cases a windows popup) asking the victim to pay a ransom fee to the threat actor (usually in cryptocurrency) in order to regain access to their system and data.
Recovery	A procedure or process to restore or control something that is suspended, damaged, stolen or lost.
Recovery Point Objective (RPO)	The point in time to which data must be recovered after an outage. RPO is determined based on the acceptable data loss in case of a disruption of operations. It indicates the earliest point in time that is acceptable to recover the data. The RPO effectively quantifies the permissible amount of data loss in case of interruption.
Recovery Time Objective (RTO)	The amount of time allowed for the recovery of a business function or resource after a disaster occurs
Red teaming	An exercise, reflecting real-world conditions, that is conducted as a simulated adversarial attempt to compromise organizational missions and/or business processes to provide a comprehensive assessment of the security capability of the information system and organization. Source: NIST SP 1800 21B Glossary of Key Information Security Terms
Regression Testing	Testing of a previously tested program following modification to ensure that defects have not been introduced or uncovered in unchanged areas of the software, as a result of the changes made.
Residual Risk	The remaining risk after management has implemented a risk response.
Resilience	The ability to continue to: (i) operate under adverse conditions or stress, even if in a degraded or debilitated state, while maintaining essential operational capabilities; and (ii) recover to an effective operational posture in a time frame consistent with mission needs.
Retention	The length of time that information, data, event logs or backups must be retained, regardless of the form (i.e., paper and electronic).
Risk	A measure of the extent to which an organization is threatened by a potential circumstance or event, and typically a function of: (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence. Source: NISTIR 7298r3 Glossary of Key Information Security Terms
Risk appetite	The amount and type of risk that an organization is willing to take in order to meet their strategic objectives. Also refer to 'Risk tolerance'. (ISO/Guide 73:2009 Risk management — Vocabulary)
Risk Factors	Different categories of risk that organisations must consider considered when performing a Fraud Risk Assessment
Risk profile	A description of any set of risks that relate to the whole organization, part of the organization, or as otherwise defined. The risk profile will outline the number of risks, type of risk and potential effects of risks. (ISO/Guide 73:2009 Risk management — Vocabulary)
Risk register	Risk register is a table used as a repository for all risks identified and includes additional information about each risk, e.g. risk category, risk owner, and mitigation actions taken.
Risk tolerance	The acceptable variation relative to performance to the achievement of objectives. Also refer to 'Risk appetite'. (COSO Internal Control — Integrated Framework)
Risk treatment	A process to modify risk that can involve avoiding the risk by deciding not to start or continue with the activity that gives rise to the risk; taking or increasing risk in order to pursue an opportunity; removing the risk source; changing the likelihood; changing the consequences; sharing the risk with another party or parties; and retaining the risk by informed decision. Risk treatments that deal with negative consequences are sometimes referred to as “risk mitigation”, “risk elimination”, “risk prevention” and “risk reduction”. Risk treatments can create new risks or modify existing risks. (ISO/Guide 73:2009 Risk management — Vocabulary)
Risk-aware culture	The shared values, beliefs, knowledge, attitudes and understanding about risk within an organization. In a strong risk culture people proactively identify, discuss and take responsibility for risks. (Institute of Risk Management)
Root-cause analysis	A principle-based, systems approach for the identification of underlying causes associated with a particular set of risks. (NISTIR 7298r2 Glossary of Key Information Security Terms)
RTP	Red Teaming Provider
SAMA	The Saudi Central Bank*
Sandboxing	A restricted, controlled execution environment that prevents potentially malicious software, such as mobile code, from accessing any system resources except those for which the software is authorized. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Scams	Where an individual is tricked into making or authorising a payment to a criminal’s account. Scammers typically use social engineering and can impersonate banks, investment opportunities, utility companies and government bodies using emails, phone calls and SMS that appear genuine.
Scrubbing services	A service that analyzes an organization's network traffic and removes malicious traffic (DDoS, known vulnerabilities and exploits).
SDLC	A system development lifecycle (SDLC) describes the scope of activities associated with a system, encompassing the system's initiation, development and acquisition, implementation, operation and maintenance, and ultimately its disposal that instigates another system initiation. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Sector	One of the areas in which the economic activity of a country is divided.
Sectorial Anti-Fraud Committee	A committee governed by SAMA to combat fraud involving Member Organisations operating in the Kingdom (e.g., Banking Anti-Fraud Committee).
Secure coding standard	A document that describes a uniform set of rules and guidelines for developing computer software that protects against the accidental introduction of security vulnerabilities. Examples includes OWASP's Secure Coding Practices and the Software Engineering Institute's Secure Coding Standards.
Secure disposal	The disposing of equipment and media that minimizes the risk of unwanted disclosure. See also 'Secure erase', 'Secure wiping', 'Incineration', and 'Double crosscuť.
Secure erase	An overwrite technology using a firmware-based process to overwrite a hard drive. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Secure wiping	Refer to 'Secure erase'.
Security architecture	Refer to 'Cyber security architecture'.
Security control	Refer to 'Cyber security control'
Security testing	A process intended to ensure that modified or new systems and applications include appropriate security controls and protection and do not introduce any security holes or vulnerabilities that might compromise other systems or applications or misuses of the system, application or its information, and to maintain functionality as intended.
Security-by Design	A methodology to systems and software development and networks design that seeks to make systems, software and networks free from cybersecurity vulnerabilities/weaknesses and impervious to cyber-attack as much as possible through measures such as: continuous testing, authentication safeguards and adherence to best programming and design practices.
Segregation of Duties	Key principle that aims at minimizing errors and fraud when processing specific tasks. It is accomplished through having several people with different privileges, required to complete a task.
Senior Management	The highest level of management in an organisation (the level below the Board) and their direct reports.
Sensitive information	Information, the loss, misuse, or unauthorized access to or modification of, that could adversely affect the organizational affairs, or the privacy to which individuals are entitled. Additionally, sensitive information is the information deemed sensitive according to the organizational data classification policy (see 'Data classification'). (NISTIR 7298r2 Glossary of Key Information Security Terms)
Service	A capability or function provided by an entity. Source: NISTIR 7298 3Glossary of Key Information Security Terms
Service level agreement (SLA)	Defines the specific responsibilities of the service provider and sets the customer expectations.
Service Level Agreement (SLA)	The specific responsibilities for delivery, typically an agreement on timeliness or quality, for example relating to management of fraud alerts.
Shielding technique	Shielding," a process that obfuscates an application's binary code, ostensibly making it harder for hackers to reverse-engineer
SIEM	A security information and event management (SIEM) tool is Application that provides the ability to gather security data from information system components and present that data as actionable information via a single interface. Source: NISTIR 7298r3 Glossary of Key Information Security Terms
SLA	A service level agreement (SLA) defines the specific responsibilities of the service provider and sets the customer expectations. (NISTIR 7298r2 Glossary of Key Information Security Terms)
SOC	A security operations center (SOC) is a specialized location (and team) where security-related data from enterprise information systems (e.g., web sites, applications, databases, servers, networks, desktops and other devices) is monitored, assessed and actioned. The SOC is often dedicated to the detection, investigation and potential response to indicators of compromise. The SOC works closely with, and disseminates, collated security-related information to other areas of the organization (e.g., the cyber security function, incident management team and IT service owners).
Social Engineering	A general term for attackers trying to trick people into revealing sensitive information or performing certain actions, such as downloading and executing files that appear to be benign but are actually malicious. Ref: (NIST SP 800–114 )
Soft token	A soft token (a.k.a. a virtual token) is a software version of a hard token. Soft tokens are typically generated by a central server that runs security software and sent to users' devices. Some hard tokens are used in combination with other security measures to further enhance security (known as multi-factor authentication). See also 'Hard token'.
Stakeholder	One who is involved in or affected by a course of action.
Static Data	Data with low change frequency (e.g., name, email address, mobile phone number, signatory rights, specimen signatures, power-of-attorney).
Strategic threat intelligence	The level of threat intelligence focused on objectives, motivations and intents of cyber threat actors. It aims at examining attributions to cyber threat actors, investigating real motivations and links between cyber events, and understanding complex systems dynamics and trends. Geopolitical, sectorial and context analysis is a fundamental tool.
Strategy	Refer to “Cyber security strategy”.
Stress Testing	A type of performance testing conducted to evaluate a system or component at or beyond the limits of its anticipated or specified workloads, or with reduced availability of resources such as access to memory or servers.
System Acquisition	Procedures established to purchase application software, or an upgrade, including evaluation of the supplier's financial stability, track record, resources and references from existing customers
System Configuration Management	The control of changes to a set of configuration items over a system life cycle.
System Development Lifecycle (SDLC)	A system development lifecycle (SDLC) describes the scope of activities associated with a system, encompassing the system's initiation, development and acquisition, implementation, operation and maintenance, and ultimately its disposal that instigates another system initiation. Source: NISTIR 7298r3 Glossary of Key Information Security Terms
Tactic	The threat actor's tactical goal: the reason for performing an action. Source: MITRE ATT&CK
Taxonomy	A classification of interrelated elements.
Technique	Techniques represent "how" a threat actor achieves a tactical goal by performing an action. Source: MITRE ATT&CK
Term	Description
Test Manager	The Test Manager is responsible for a guiding the White Team through the red teaming exercise.
The Cyber Security Framework	The Saudi Arabian Monetary Authority Cyber Security Framework.
Third Party	A separate unrelated entity that provides an organisation with a service. This may include suppliers, technology providers (e.g., Absher, Nafath), outsourcers, intermediaries, brokers, introducers, and agents.
Threat	Refer to “Cyber security threat”.
Threat actor	Individuals, groups, organizations, or states that seek to exploit the organization's dependence on cyber resources (i.e., information in electronic form, information and communications technologies, and the communications and information-handling capabilities provided by those technologies)" (NIST 2012) or, more in general, "An individual or a group posing a threat" (NIST 2016).
Threat actor Capability	Resources and skills of a threat actor.
Threat actor Intent	The desire of a threat actor to target a particular entity. Threat actors are usually rational actors operating with a clear purpose (e.g. espionage, data theft/exfiltration, extortion, destruction, disruption, supply chain compromise).
Threat actor Origin	Country from which the threat actor launches its attacks. The origin of a threat actor cannot always be determined with sufficient precision because they tend to cover their tracks.
Threat actor Resources	Resources measure the scope, intensity, sustainability, and diversity of the total set of actions that a threat actor can take.
Threat actor Skill	The extent to which a threat actor is able to leverage technical means (e.g. create custom malware) and operates with awareness, intelligence, learning potential, problem solving, decision-making coherence, and operational experience.
Threat actor Target	The choices that actors make in terms of the target(s) of their attacks. A threat actor selects a target based on location, sector, and the types of information processed and attack surface available. The geopolitical landscape plays a key role in the targeting pattern of nation state actors.
Threat actor Type	Grouping of threat actors who share similar characteristics, such as similar intents and motivations, and operate in similar ways.
Threat intelligence	Threat intelligence is evidence-based knowledge, including context, mechanisms, indicators, implications and actionable advice, about an existing or emerging menace or hazard to assets that can be used to inform decisions regarding the subjecťs response to that menace or hazard. (Gartner)
Threat intelligence requirement	Threat intelligence requirements guide the intelligence production effort efficiently and establish what intelligence should be produced to meet the security objectives of an Organization.
Threat landscape	1. An overview of threats, together with current and emerging trends. 2. A collection of threats in a particular domain or context, with information on identified vulnerable assets, threats, risks, threat actors and observed trends. (ENISA)
Token	Something that the user possesses and controls (typically a key or password) that is used to authenticate the user's identity. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Trend Analysis	The process of collecting and reviewing information to identify patterns and predict future trends.
Trusted Device	A trusted device is a device that the customer owns, controls access to, and uses often.
TTPs	Tactics, Techniques and Procedures
Unified Kill Chain	An evolution of the kill chain framework detailing the phases of an attack.
Unit Testing	A testing technique that is used to test program logic within a particular program or module.
User Acceptance Testing (UAT)	Taking use cases or procedures for how the system was designed to perform and ensuring that someone who follows the procedure gets the intended result.
Vendor management	The practice of ensuring that third-party service providers adhere to the same information security standards that an organization must comply with and includes periodic security assessments.
Violation	Any act, or concealment of acts, of fraud, corruption, collusion, coercion, unlawful conduct, misconduct, financial mismanagement, accounting irregularities, conflict of interest, wrongful conduct, illegal or unethical practices or other violations of any applicable laws and instructions.
Vulnerability	Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source. Source: NISTIR 7298r3 Glossary of Key Information Security Terms
Vulnerability management	Vulnerability management is the cyclical practice of identifying, classifying, remediating, and mitigating vulnerabilities. Also refer to “Vulnerability”.
Whistle Blowing Policy	SAMA Whistle Blowing Policy for Financial Institutions.
White Team	The group responsible for referring an engagement between a Red Team of mock attackers and a Blue Team of actual defenders of their enterprise’s use of information systems. In an exercise, the White Team acts as the judges, enforces the rules of the exercise, observes the exercise, scores teams, resolves any problems that may arise, handles all requests for information or questions, and ensures that the competition runs fairly and does not cause operational problems for the defender's mission. The White Team helps to establish the rules of engagement, the metrics for assessing results and the procedures for providing operational security for the engagement. The White Team normally has responsibility for deriving lessons-learned, conducting the post engagement assessment, and promulgating results. Ref: (CNSSI 4009–2015 )
Wholesale Payment Endpoint Security	Measures taken with respect to endpoint hardware, software, physical access, logical access, organisation and processes at a point in place and time at which payment instruction information is exchanged between two parties in the ecosystem.

* The Saudi Arabian Monetary Agency was replaced by the name of Saudi Central Bank in accordance with The Saudi Central Bank Law No. (M/36), dated 11/04/1442H, corresponding 26/11/2020G.

Cyber Resilience

Cyber Resilience Fundamental Requirements (CRFR)
No: NA Date(g): 1/1/2022 | Date(h): 28/5/1443 Status: In-Force

1 Introduction
Modern society has high expectations of flawless customer experience, continuous availability of services and effective protection of sensitive data. Information assets and online financial services are now critically important to all public and private organizations and broader society. These services are fundamental to the global and national economy, vital to digital innovation and important to broader national security. This importance emphasizes the need to safeguard sensitive data, transactions and the availability of services, and thereby ensure confidence in the Saudi Financial Sector.
Not many industries have seen such a vivid increase in innovation like FinTech. Throughout the past decade, there has been an increase in the number of products and services that have reached the market which is already delivering significant benefits to consumers and financial institutions. However, the increasing use of emerging technologies also brings cyber resilience risks that may impact the financial stability of the financial sector ecosystem.
In November 2019, Saudi Arabian Monetary Authority (herein “SAMA”) developed a regulatory sandbox framework in order to understand and assess the impact of new technologies in the KSA’s FS market, as well as to help transforming the Saudi market into a smart financial centre. SAMA has designed a Regulatory Sandbox which welcomes local as well as international firms wishing to test new digital solutions in a ‘live’ environment with a view to deploy them in the KSA in the future.
SAMA developed the Cyber Resilience Fundamental Requirements (herein “Fundamental Requirements”), specifically intended for entities that are recently established and are in the early stages of their operations in the financial sector of the Kingdom of Saudi Arabia (herein “KSA”).

1.1 Objective

Given the resource constraints these types of entities often face, the objective of the Fundamental Requirements is to help Entities in:
	Managing and mitigating a widened range of cyber security and resilience risks relevant to the KSA financial sector;
	Focusing resources on a fundamental set of controls aimed at an effective protection of information assets.
To achieve this objective, the fundamental requirements provides:
	a prioritized set of cyber security and resilience control requirements;
	a structure and a content that are aligned with other SAMA regulatory frameworks, such as the Cyber Security Framework (herein “CSF”) and the Business Continuity Management Framework (herein “BCMF”), which will be applicable to organizations in the future.

1.2 Applicability
The framework “Fundamental Requirements” applies to entities intending to qualify for SAMA Regulatory Sandbox environment and/or entities seeking license to operate in the kingdom of Saudi Arabia. The “Fundamental Requirements” serves as a catalyst to enable entities to comply with minimum SAMA’s cyber resilience licensing requirements. The “Fundamental Requirements” should not be treated as a replacement of SAMA’s Cyber Security and Business Continuity Management regulatory frameworks where the entities are required to comply with other relevant SAMA regulatory requirements post licensing decision. Additionally, this framework should also be read in conjunction with the requirements mandated in SAMA’s Regulatory Sandbox Framework.

1.3 Responsibilities
The framework is mandated by SAMA. SAMA is the owner and is responsible for periodically updating the Framework.

1.4 Compliance
In the event that an entity is not able to demonstrate compliance with the Fundamental Requirements, SAMA reserves the right to prohibit the sandboxing graduation/license request of the entity.

1.5 Interpretation
SAMA, as the owner of the Fundamental Requirements, is solely responsible for providing interpretations of the principles and control requirements, if required.

1.6 Target Audience
The Fundamental Requirements is intended for senior and executive management, business owners, owners of information assets, Heads of Cyber Security and those who are accountable for and involved in defining, implementing and reviewing cyber security and resilience controls within the Entities.

1.7 Review, Updates and Maintenance
SAMA will review the Fundamental Requirements periodically to evaluate its applicability to the context of the KSA financial sector and its intended Entities. If deemed necessary, SAMA will update the fundamental Requirements based on the outcome of the review.
SAMA will implement version control for maintaining the Fundamental Requirements. Whenever making any changes, SAMA will retire the preceding version, as well as release and communicate the new version to all Entities. For the convenience of the Entities, SAMA will clearly indicate any changes to the revised Fundamental Requirements.

1.8 Reading Guide

The Fundamental Requirements is structured as follows:
	chapter 2 elaborates on the structure of the Fundamental Requirements and provides guidance on how to apply the Fundamental Requirements; and
	chapter 3 presents the cyber security and resilience domains including control requirements.

2 Fundamental Requirements Structure and Features

2.1 Structure

The Fundamental Requirements is structured around four domains, including:

Cyber Security Leadership and Governance;

Cyber Security Operations and Technology; and

Resilience.

Control requirements have been uniquely numbered throughout the Fundamental Requirements. The control requirements are numbered according to the following numbering system:

Figure 1. Control requirement numbering system

The figure below illustrates the overall structure of the Fundamental Requirements and indicates the cyber security and resilience domains:

Cyber Resilience Fundamental Requirements
Cyber Security Leadership and Governance	Cyber Security Operations and Technology
	Resilience

Figure 3. Fundamental Requirements domains

2.2 Risk-Based Approach
The domains and control requirements included in the fundamental requirements are risk-based and intended to provide participants with essential direction on how to mitigate the most common risks they face, without placing undue burden on them that could stifle innovation and business growth.
From this perspective, the fundamental requirements sets the essential cyber security and resilience mandatory requirements for entities that are within the scope of applicability. In addition, SAMA expects entities to conduct their own internal risk assessments to monitor the development of the cyber security and resilience threat landscape, to identify new and evolving risks, to evaluate the potential impact of these risks, and where deemed necessary to implement additional or enhanced security and resilience control requirements beyond the fundamental requirements to mitigate these risks in line with the entities risk appetite.

2.3 Entities Self-Assessment and Saudi Central Bank Audit
The implementation of the fundamental requirements at the participants will be subject to periodic self-assessment. The self-assessment will be performed by the entities based on a questionnaire. The entities will send a copy of its self-assessment to SAMA, and SAMA reserves the right to review the self-assessment for demonstration of compliance with the fundamental requirements at its discretion. SAMA also reserves the right to audit the compliance with the fundamental requirements of the entities at any time.

3 Control Requirements

3.1 Cyber Security Leadership and Governance

Control ID	Control requirement description
3.1.1.	Entities should develop a robust Cyber Security Governance structure that is supported with appropriate resources to oversee and control overall approach to cyber security.
3.1.2.	Entities should define, approve, implement and communicate cyber security policies and procedures that is supported by detailed security standards (e.g. password standard, firewall standard).
3.1.3.	Entities should periodically review and update cyber security policies, procedures and standards taking into consideration the evolving cyber threat landscape.
3.1.4.	Entities should incorporate cyber security requirements in their new and/or existing business operating model, including at least:
		a.	evaluation of cyber security and fraud risks that could target business operating model; and
		b.	adoption and evaluation of cyber security measures for the protection against adversarial attacks (e.g. model stealing, malicious inputs, and poisoning attack).
3.1.5.	Entities should establish and implement strong password policy for users’ access to its information assets, such as:
		a.	change of password upon first logon, minimum password length and history and password complexity;
		b.	revoking the access after the three successive incorrect passwords; and
		c.	use non-caching techniques.
3.1.6.	Entities should execute comprehensive IT and cyber security risk assessments covering (infrastructure, network, applications, and systems) and the controls implemented to address the identified risks. The identified risks should be documented in a central register, and periodically monitored and reviewed.
Ref. to other SAMA Framework(s)
Cyber Security Framework
- 3.1.1 Cyber Security Governance
- 3.1.3 Cyber Security Policy
- 3.2.1 Cyber Security Risk Management

3.2 Cyber Security Operations and Technology

Control ID	Control requirement description
3.2.1.	Entities should establish identity and access management process to govern the logical accesses to the information assets according to need-to-have and need-to-know principles.
3.2.2.	Entities should establish change management process to ensure that changes to the entities information assets are classified, tested and approved before their deployment into production environments. The change management process should also include cyber security requirements for controlling changes to information assets.
3.2.3.	Entities should establish and maintain a secure network architecture that address taking into consideration the following:
		a.	segmentation of networks, according to the functionality of services and the adoption of network security systems (e.g. firewalls) to control the network traffic between segments; and
		b.	availability.
3.2.4.	Entities should adopt secure and robust cryptography algorithms and ensure that the application and server communications are encrypted using secure protocols.
3.2.5.	Entities should periodically conduct comprehensive vulnerability assessment (VA) covering both the application and infrastructure layers of the Entities technology landscape.
3.2.6.	Entities should conduct penetration testing (PT) twice a year as a minimum or after major/ critical change to comprehensively evaluate its cyber security defense capability.
3.2.7.	Entities should ensure up-to-date and relevant patches are tested, applied and installed in a timely manner to avoid security breaches due to existing vulnerabilities in the applications and infrastructure.
3.2.8.	In addition to secure System Development Life Cycle (herein “Secure SDLC”) process entities should implement shielding techniques (such as but not limited to code obfuscation, white box cryptography and anti-tampering) in the application design.
3.2.9.	Entities should implement effective brand protection controls to detect and defend against targeted attacks by continuously monitoring the online services such as apps, social media accounts and websites and proactively takedown malicious activities.
3.2.10.	Entities should ensure that endpoints (both personal, if allowed, and corporate) are secured through implementation of a minimum set of cyber security requirements such as the following, but not limited to:
		a.	the real time protection for the endpoints (e.g. antivirus and antimalware);
		b.	implementation of behavioural-based and/or signature-based solutions;
		c.	ensuring anti-malware signatures are up-to-date and the systems are regularly scanned for malicious files or anomalous activities; and
		d.	in case of mobile devices:
			i.	separation and encryption of entities data; and
			ii.	secure wiping of stored entities data in cases of device loss, theft or decommissioning in alignment with the Secure Information Asset Disposal process.
3.2.11.	Entities should establish and implement a process to collect, process, review and retain security logs to facilitate continuous security monitoring. These logs should provide sufficient details and should be retained securely for a period of one year as a minimum.
3.2.12.	Entities should ensure applications and infrastructure components are integrated with a security information and event management (SIEM) solution.
3.2.13.	Entities should ensure continuous security monitoring and analysis of cyber security events to promptly detect and respond to cyber security incidents.
3.2.14.	Entities should develop Cyber Security Incident Management process to timely identify, respond and contain cyber security incidents impacting the Entities information assets.
3.2.15.	Entities should implement session timeout configurations with reasonable timeframe; in-active sessions should not exceed 5 minutes for applications and underlying infrastructure.
3.2.16.	Entities should immediately inform SAMA (F.S.Cybersecurity@SAMA.GOV.SA) in case any of the following incidents classified as medium or above has occurred and identified for:
		a.	Cyber security;
		b.	Fraud;
		c.	All disruptive incidents.
Ref. to other SAMA Framework(s)
Cyber Security Framework
- 3.3.5 Identity and Access Management - 3.3.6 Application Security - 3.3.7 Change Management			- 3.3.8 Infrastructure Security - 3.3.9 Cryptography - 3.3.13 Electronic Banking Services		- 3.3.14 Cyber Security Event Management - 3.315 Cyber Security Incident Management - 3.3.17 Vulnerability Management

3.3 Resilience

Control ID	Control requirement description
3.3.1.	The Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP) should be defined, approved, communicated, implemented and periodically reviewed to enable the entities to continue delivering its critical services, at an acceptable pre-defined level.
3.3.2.	Entities should define and implement its backup and restoration requirements considering the following, but not limited to:
		a.	legal and regulatory requirements;
		b.	Critical and customer data;
		c.	business requirements;
		d.	schedule of the backup (daily, weekly, monthly, etc.);
		e.	protection of confidential data stored in back up media through applying encryption techniques;
		f.	storage of backup media offline or at an offsite location; and
		g.	secure destruction of backup data.
		h.	restoration tests.
Ref. to other SAMA Framework(s)
Business Continuity Management Framework
- 2.5 Business Continuity Plan
- 2.6 Disaster Recovery Plan
- 2.7 Cyber Resilience

4 Appendices

Appendix A: Glossary

Term	Description
Access management	Access management is the process of granting authorized users the right to use a service, while preventing access to non-authorized users.
Audit	Independent review and examination of records and activities to assess the adequacy of system controls, to ensure compliance with established policies and operational procedures. Source: NISTIR 7298r3 Glossary of Key Information Security Terms
Availability	Ensuring timely and reliable access to and use of information. Source: NISTIR 7298r3 Glossary of Key Information Security Terms
Back-up	Files, devices, data and procedures available for use in case of a failure or loss, or in case of deletion or suspension of their original copies.
Business Continuity (BC)	The capability of an organization to continue delivery of IT and business services at acceptable predefined levels following a disruptive incident. Source: ISO 22301:2012 Societal security -- Business continuity management systems
Business Continuity Management (BCM)	Holistic management process that identifies potential threats to an organization and the impacts to business operations those threats, if realized, might cause, and which provides a Fundamental Requirements for building organizational resilience with the capability of an effective response that safeguards the interests of its key stakeholders, reputation, brand and value creating activities. Source: ISO 22301:2012 - Business continuity management systems — Requirements
Change management	The controlled identification and implementation of required changes within a business or information systems.
Cryptography	The discipline that embodies the principles, means, and methods for the transformation of data in order to hide their semantic content, prevent their unauthorized use, or prevent their undetected modification. Source: NISTIR 7298r3 Glossary of Key Information Security Terms
Cyber risk	Risk of financial loss, operational disruption, or damage, from the failure of the digital technologies employed for informational and/or operational functions introduced to a manufacturing system via electronic means from the unauthorized access, use, disclosure, disruption, modification, or destruction of the manufacturing system Source: NISTIR 7298r3 Glossary of Key Information Security Terms
Cyber security	Cyber security is defined as the collection of tools, policies, security concepts, security safeguards, guidelines, risk management approaches, actions, training, best practices, assurance, and technologies that can be used to protect the Entities information assets against internal and external threats.
Cyber Security event	Any observable occurrence in an information system or network that has, or may potentially result in, unauthorized access, processing, corruption, modification, transfer or disclosure of data and / or Information or (b) a violation of an explicit or implemented Organization security policy.
Cyber security governance	A set of responsibilities and practices exercised by the Board of Directors with the goal of providing strategic direction for cyber security, ensuring that cyber security objectives are achieved, ascertaining that cyber risks are managed appropriately and verifying that the enterprise's resources are used responsibly.
Cyber security incident	An occurrence that (1) actually or imminently jeopardizes, without lawful authority, the integrity, confidentiality, or availability of information or an information system; or (2) constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies. Source: NISTIR 7298r3 Glossary of Key Information Security Terms
Cyber security incident management	The monitoring and detection of security events on an information system and the execution of proper responses to those events.
Cyber security policy	A set of rules that governs all aspects of security-relevant system and system element behaviour. Note 1: System elements include technology, machine, and human, elements. Note 2: Rules can be stated at very high levels (e.g., an organizational policy defines acceptable behaviour of employees in performing their mission/business functions) or at very low levels (e.g., an operating system policy that defines acceptable behaviour of executing processes and use of resources by those processes) Source: NISTIR 7298r3 Glossary of Key Information Security Terms
Cyber security risk assessment	The process of identifying risks to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other organizations, and the Nation, resulting from the operation of an information system. Part of risk management, incorporates threat and vulnerability analyses, and considers mitigations provided by security controls planned or in place Source: NISTIR 7298r3 Glossary of Key Information Security Terms
Cyber security risk management	The process of managing risks to organizational operations (including mission, functions, image, or reputation), organizational assets, or individuals resulting from the operation of an information system, and includes: (i) the conduct of a risk assessment; (ii) the implementation of a risk mitigation strategy; and (iii) employment of techniques and procedures for the continuous monitoring of the security state of the information system Source: NISTIR 7298r3 Glossary of Key Information Security Terms
Cyber security strategy	A high-level plan, consisting of projects and initiatives, to mitigate cyber security risks while complying with legal, statutory, contractual, and internally prescribed requirements.
Cyber security threat	Any circumstance or event with the potential to adversely impact organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, or the Nation through an information system via unauthorized access, destruction, disclosure, modification of information, and/or denial of service. Source: NISTIR 7298r3 Glossary of Key Information Security Terms
Disaster Recovery (DR)	Programs, activities and plans designed to restore the organizations critical business functions and services to an acceptable situation, following exposure to cyber and IT incidents or disruption of such services.
Head of Cyber Security	The Head of Cyber Security may refer to the Head of Information Security, the Chief Information Security Officer (CISO) or any other title given to the senior manager accountable for the cyber security function and processes.
Fall-back	Business procedures and measures, undertaken when events have triggered the execution of either a business continuity plan or a contingency plan.
Formally documented	Documentation that is written, approved by the senior leadership and disseminated to relevant parties.
Identity management	The process of controlling information about users on computers, including how they authenticate and what systems they are authorized to access and/or what actions they are authorized to perform. It also includes the management of descriptive information about the user and how and by whom that information can be accessed and modified. Managed entities typically include users, hardware and network resources and even applications
Disaster Recovery Plan	Disaster Recovery is part of BCM which includes policies, standards, procedures and processes pertaining to resilience, recovery or continuation of technology infrastructure supporting critical business processes.
Major change	Any change to a system's configuration, environment, information content, functionality, or users which has the potential to change the risk imposed upon its continued operations. Source: NISTIR 7298r2 Glossary of Key Information Security Terms Critical changes are also included in the concept of major changes.
Malware	Software or firmware intended to perform an unauthorized process that will have adverse impact on the confidentiality, integrity, or availability of an information system. A virus, worm, Trojan horse, or other code-based entity that infects a host. Spyware and some forms of adware are also examples of malicious code. Source: NISTIR 7298r3 Glossary of Key Information Security Terms
Penetration testing	A test methodology in which assessors, using all available documentation (e.g., system design, source code, manuals) and working under specific constraints, attempt to circumvent the security features of an information system. Source: NISTIR 7298r3 Glossary of Key Information Security Terms
Periodically	With this term, SAMA does not intend to define a default time interval. Each Entities has the responsibility to determine this interval based on its own risk- based approach. The same term adopted in different control requirements could be translated into different time intervals by the MO.
Recovery	A procedure or process to restore or control something that is suspended, damaged, stolen or lost.
Resilience	The ability to continue to: (i) operate under adverse conditions or stress, even if in a degraded or debilitated state, while maintaining essential operational capabilities; and (ii) recover to an effective operational posture in a time frame consistent with mission needs.
Risk	A measure of the extent to which an organization is threatened by a potential circumstance or event, and typically a function of: (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence. Source: NISTIR 7298r3 Glossary of Key Information Security Terms
Risk register	Risk register is a table used as a repository for all risks identified and includes additional information about each risk, e.g. risk category, risk owner, and mitigation actions taken.
Shielding technique	Shielding," a process that obfuscates an application's binary code, ostensibly making it harder for hackers to reverse-engineer
Strategy	Refer to “Cyber security strategy”.
SIEM	A security information and event management (SIEM) tool is Application that provides the ability to gather security data from information system components and present that data as actionable information via a single interface. Source: NISTIR 7298r3 Glossary of Key Information Security Terms
System Development Lifecycle (SDLC)	A system development lifecycle (SDLC) describes the scope of activities associated with a system, encompassing the system's initiation, development and acquisition, implementation, operation and maintenance, and ultimately its disposal that instigates another system initiation. Source: NISTIR 7298r3 Glossary of Key Information Security Terms
Threat	Refer to “Cyber security threat”.
Threat landscape	A collection of threats in a particular domain or context, with information on identified vulnerable assets, threats, risks, threat actors and observed trends. Source: ENISA
Vulnerability	Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source Source: NISTIR 7298r3 Glossary of Key Information Security Terms
Vulnerability management	Vulnerability management is the cyclical practice of identifying, classifying, remediating, and mitigating vulnerabilities. Also refer to “Vulnerability”.

Cyber Security Framework
No: 381000091275 Date(g): 24/5/2017 | Date(h): 28/8/1438 Status: In-Force
Foreword
In view of the ever-growing seriousness of cyber-attacks, we are conscious of the need to stay one-step ahead. The issuance of a Cyber Security Framework (“Framework”) seeks to support our regulated entities in their efforts to have an appropriate cyber security governance and to build a robust infrastructure along with the necessary detective and preventive controls. The Framework articulates appropriate controls and provide guidance on how to assess maturity level.
The adoption and implementation of the Framework is a vital step for ensuring that Saudi Arabian Banking, Insurance and Financing Companies sectors can manage and withstand cyber security threats. In designing the Framework, we have considered the ways that our regulated entities are leveraging technology and felt that each entity will be able to adopt a common approach for addressing cyber security. This will ensure cyber security risks are properly managed throughout the sectors
To achieve the above, the full support and oversight from the Board of Directors and Senior Management are required for its implementation.
The Information Technology Risk team within the Deputyship of Supervision is at your disposal for any clarifications and we remain committed to guiding our regulated entities in creating a safer cyber environment.

1 Introduction

1.1 Introduction to the Framework
The current digital society has high expectations of flawless customer experience, continuous availability of services and effective protection of sensitive data. Information assets and online services are now strategically important to all public and private organizations, as well as to broader society. These services are vital to the creation of a vibrant digital economy. They are also becoming systemically important to the economy and to broader national security. All of which underlines the need to safeguard sensitive data and transactions, and thereby ensure confidence in the overall Saudi Financial Sector.
The stakes are high when it comes to the confidentiality, integrity and availability of information assets, and applying new online services and new developments (e.g. Fintech, block chain); while improving resilience against cyber threats. Not only is the dependency on these services growing, but the threat landscape is rapidly changing. The Financial Sector recognizes the rate at which the cyber threats and risks are evolving, as well as the changing technology and business landscape.
SAMA established a Cyber Security Framework (“the Framework”) to enable Financial Institutions regulated by SAMA (“the Member Organizations”) to effectively identify and address risks related to cyber security. To maintain the protection of information assets and online services, the Member Organizations must adopt the Framework.
The objective of the Framework is as follows:
1. To create a common approach for addressing cyber security within the Member Organizations.
2. To achieve an appropriate maturity level of cyber security controls within the Member Organizations.
3. To ensure cyber security risks are properly managed throughout the Member Organizations.
The Framework will be used to periodically assess the maturity level and evaluate the effectiveness of the cyber security controls at Member Organizations, and to compare these with other Member Organizations.
The Framework is based on the SAMA requirements and industry cyber security standards, such as NIST, ISF, ISO, BASEL and PCI.
The Framework supersedes all previous issued by SAMA circulars with regard to cyber security. Please refer to ‘Appendix A - Overview previous issued by SAMA circulars' for more details.

1.2 Definition of Cyber Security
Cyber security is defined as the collection of tools, policies, security concepts, security safeguards, guidelines, risk management approaches, actions, training, best practices, assurance, and technologies that can be used to protect the member organization's information assets against internal and external threats.
The general security objectives comprise the following:
- Confidentiality - Information assets are accessible only to those authorized to have access (i.e., protected from unauthorized disclosure or (un)intended leakage of sensitive data).
- Integrity - Information assets are accurate, complete and processed correctly (i.e., protected from unauthorized modification, which may include authenticity and non-repudiation).
- Availability - Information assets are resilient and accessible when required (i.e., protected from unauthorized disruption).

1.3 Scope
The Framework defines principles and objectives for initiating, implementing, maintaining, monitoring and improving cyber security controls in Member Organizations.
The Framework provides cyber security controls which are applicable to the information assets of the Member Organization, including:
- Electronic information.
- Physical information (hardcopy).
- Applications, software, electronic services and databases.
- Computers and electronic machines (e.g., ATM).
- Information storage devices (e.g., hard disk, USB stick).
- Premises, equipment and communication networks (technical infrastructure).
The Framework provides direction for cyber security requirements for Member Organizations and its subsidiaries, staff, third parties and customers.
For business continuity related requirements please refer to the SAMA Business Continuity Minimum Requirements.
The Framework has an interrelationship with other corporate policies for related areas, such as physical security and fraud management. This framework does not address the non-cyber security requirements for those areas.

1.4 Applicability
The Framework is applicable to all Member Organizations regulated by SAMA, which include the following:
- All Banks operating in Saudi Arabia;
- All Insurance and/or Reinsurance Companies operating in Saudi Arabia;
- All Financing Companies operating in Saudi Arabia;
- All Credit Bureaus operating In Saudi Arabia;
- The Financial Market Infrastructure
All domains are applicable for the banking sector. However, for other financial institutions the following exceptions apply:
- Sub-domain (3.1.2) the alignment with cyber security strategy of banking sector is mandatory when applicable.
- Exclude sub-domain (3.2.3). However, if the organization store, process or transmit cardholder data or deal with SWIFT services, then PCI standard and/or SWIFT Customer Security Controls Framework should be implemented.
- Exclude sub-domain (3.3.12).
- Exclude sub-domain (3.3.13). However, if the organization provides online services for customers, a Multi Factor Authentication capability should be implemented.

1.5 Responsibilities
The framework is mandated by SAMA. SAMA is the owner and is responsible for periodically updating the Framework.
The Member Organizations are responsible for adopting and implementing the Framework.

1.6 Interpretation
Saudi Central Bank, as the owner of the Framework, is solely responsible for providing interpretations of the principles, objectives and control considerations, if required.

1.7 Target Audience
The Framework is intended for senior and executive management, business owners, owners of information assets, CISOs and those who are responsible for and involved in defining, implementing and reviewing cyber security controls within the Member Organizations.

1.8 Review, Updates and Maintenance
The Framework will be reviewed and maintained by SAMA.
SAMA will review the Framework periodically to determine the Framework's effectiveness, including the effectiveness of the Framework to address emerging cyber security threats and risks. If applicable, SAMA will update the Framework based on the outcome of the review.
If a Member Organization considers that an update to the Framework is required, the Member Organization should formally submit the requested update to SAMA. SAMA will review the requested update, and when approved, the Framework will be adjusted.
The Member Organization will remain responsible to be compliant with the Framework pending the requested update.
Please refer to ‘Appendix B - How to request an Update to the Framework’ for the process of requesting an update to the Framework.
Version control will be implemented for maintaining the Framework. Whenever any changes are made, the preceding version shall be retired and the new version shall be published and communicated to all Member Organizations. For the convenience of the Member Organizations, changes to the Framework shall be clearly indicated.

1.9 Reading Guide
The Framework is structured as follows. Chapter 2 elaborates on the structure of the Framework, and provides instructions on how to apply the Framework. Chapter 3 presents the actual Framework, including the cyber security domains and subdomains, principles, objectives and control considerations.

2 Framework Structure and Features

2.1 Structure

The Framework is structured around four main domains, namely:

For each domain, several subdomains are defined. A subdomain focusses on a specific cyber security topic. Per subdomain, the Framework states a principle, objective and control considerations.

A principle summarizes the main set of required cyber security controls related to the subdomain.
The objective describes the purpose of the principle and what the set of required cyber security controls are expected to achieve.
The control considerations reflects the mandated cyber security controls that should be considered.

Control considerations have been uniquely numbered throughout the Framework. Where applicable, a control consideration can consist of up to 4 levels.

The control considerations are numbered according to the following numbering system:

Figure 1 - Control consideration numbering system

The figure below illustrates the overall structure of the Framework and indicates the cyber security domains and subdomains, including a reference to the applicable section of the Framework.

Figure 2 - Cyber Security Framework

2.2 Principle-Based
The Framework is principle based, also referred to as risk based. This means that it prescribes key cyber security principles and objectives to be embedded and achieved by the Member Organization. The list of mandated control considerations provides additional direction and should be considered by the Member Organization in achieving the objectives. When a certain control consideration cannot be tailored or implemented, the Member Organization should consider applying compensating controls, pursuing an internal risk acceptance and requesting a formal waiver from SAMA.
Please refer to Appendix D for details for the - How to request a Waiver from the Framework - process.

2.3 Self-Assessment, Review and Audit
The implementation of the Framework at the Member Organization will be subject to a periodic self-assessment. The self-assessment will be performed by the Member Organization based on a questionnaire. The self-assessments will be reviewed and audited by SAMA to determine the level of compliance with the Framework and the cyber security maturity level of the Member Organization.
Please refer to ’2.4 Cyber Security Maturity Model’ for more details about the cyber security maturity model.

2.4 Cyber Security Maturity Model

The cyber security maturity level will be measured with the help of a predefined cyber security maturity model. The cyber security maturity model distinguishes 6 maturity levels (0, 1, 2, 3, 4 and 5), which are summarized in the table below. In order to achieve levels 3, 4 or 5, a Member Organization must first meet all criteria of the preceding maturity levels.

Maturity Level	Definition and Criteria	Explanation
0 Non-existent	No documentation. There is no awareness or attention for certain cyber security control.	Cyber security controls are not in place. There may be no awareness of the particular risk area or no current plans to implement such cyber security controls.
1 Ad-hoc	Cyber security controls is not or partially defined. Cyber security controls are performed in an inconsistent way. Cyber security controls are not fully defined.	Cyber security control design and execution varies by department or owner. Cyber security control design may only partially mitigate the identified risk and execution may be inconsistent.
2 Repeatable but informal	The execution of the cyber security control is based on an informal and unwritten, though standardized, practice.	Repeatable cyber security controls are in place. However, the control objectives and design are not formally defined or approved. There is limited consideration for a structured review or testing of a control.
3 Structured and formalized	Cyber security controls are defined, approved and implemented in a structured and formalized way. The implementation of cyber security controls can be demonstrated.	Cyber security policies, standards and procedures are established. Compliance with cyber security documentation i.e., policies, standards and procedures is monitored, preferably using a governance, risk and compliance tool (GRC). key performance indicators are defined, monitored and reported to evaluate the implementation.
4 Managed and measurable	The effectiveness of the cyber security controls are periodically assessed and improved when necessary. This periodic measurement, evaluations and opportunities for improvement are documented.	Effectiveness of cyber security controls are measured and periodically evaluated. key risk indicators and trend reporting are used to determine the effectiveness of the cyber security controls. Results of measurement and evaluation are used to identify opportunities for improvement of the cyber security controls.
5 Adaptive	Cyber security controls are subject to a continuous improvement plan.	The enterprise-wide cyber security program focuses on continuous compliance, effectiveness and improvement of the cyber security controls. Cyber security controls are integrated with enterprise risk management framework and practices. Performance of cyber security controls are evaluated using peer and sector data.

Table 1 - Cyber Security Maturity Model

The objective of the Framework is to create an effective approach for addressing cyber security and managing cyber security risks within the Financial Sector. To achieve an appropriate cyber security maturity level, the Member Organizations should at least operate at maturity level 3 or higher as explained below.

2.4.1 Maturity Level 3
To achieve level 3 maturity, a Member Organization should define, approve and implement cyber security controls. In addition, it should monitor compliance with the cyber security documentation .
The cyber security documentation should clearly indicate “why”, “what” and “how” cyber security controls should be implemented. The cyber security documentation consists of cyber security policies, cyber security standards and cyber security procedures.

Figure 3 - Cyber Security Documentation Pyramid
The cyber security policy should be endorsed and mandated by the board of the Member Organization and stating “why” cyber security is important to the Member Organization. The policy should highlight which information assets must be protected and “what” cyber security principles and objectives should be established.
Based on the cyber security policy, cyber security standards must be developed. These standards define “what“ cyber security controls must be implemented, such as security and system parameters, segregation of duties, password rules, monitoring events and back-up and recovery rules. The standards support and reinforce the cyber security policy and are to be considered as cyber security baselines.
The step-by-step tasks and activities that should be performed by staff, third parties or customers of the Member Organization are detailed in the cyber security procedures. These procedures prescribe “how” the cyber security controls, tasks and activities have to be executed in the operating environment and support the safeguarding of the information assets of the Member Organization according to the cyber security policy and standards.
The process in the context of this framework is defined as a structured set of activities designed to accomplish the specified objective. A process may include policies, standards, guidelines, procedures, activities and work instructions, as well as any of the roles, responsibilities, tools and management controls required to reliably deliver the output.
The actual progress of the implementation, performance and compliance of the cyber security controls should be periodically monitored and evaluated using key performance indicators (KPIs).

2.4.2 Maturity Level 4
Additional requirements for Banks pursuant to circular No (29814/67) dated 15/05/1440H (corresponding to 11/06/2020).
To achieve maturity level 4, the Member Organization should periodically measure and evaluate the effectiveness of implemented cyber security controls. In order to measure and evaluate whether the cyber security controls are effective, key risk indicators (KRIs) should be defined. A KRI indicates the norm for effectiveness measurement and should define thresholds to determine whether the actual result of measurement is below, on, or above the targeted norm. KRIs are used for trend reporting and identification of potential improvements.

2.4.3 Maturity Level 5
Maturity level 5 focuses on the continuous improvement of cyber security controls. Continuous improvement is achieved through continuously analyzing the goals and achievements of cyber security and identifying structural improvements. Cyber security controls should be integrated with enterprise risk management practices and supported with automated real-time monitoring. Business process owners should be accountable for monitoring the compliance of the cyber security controls, measuring the effectiveness of the cyber security controls and incorporating the cyber security controls within the enterprise risk management framework . Additionally, the performance of cyber security controls should be evaluated using peer and sector data.

3 Control Domains

3.1 Cyber Security Leadership and Governance
The ultimate responsibility for cyber security rests with the board of the Member Organization. The board of the Member Organization can delegate its cyber security responsibilities to a cyber security committee (or a senior manager from a control function). The cyber security committee could be responsible for defining the cyber security governance and setting the Member Organization's cyber security strategy. The cyber security committee can also be responsible for defining a cyber security policy and ensuring the operational effectiveness of this cyber security policy.
To develop and maintain the cyber security policy and to execute the cyber security activities across the Member Organization, an independent cyber security function should be established.

3.1.1 Cyber Security Governance

Principle

A cyber security governance structure should be defined and implemented, and should be endorsed by the board.

Objective

To direct and control the overall approach to cyber security within the Member Organization.

Control considerations

1.	A cyber security committee should be established and be mandated by the board.
2.	The cyber security committee should be headed by an independent senior manager from a control function.
3.	The following positions should be represented in the cyber security committee:
	a.	senior managers from all relevant departments (e.g., COO, CIO, compliance officer, heads of relevant business departments);
	b.	Chief information security officer (CISO);
	c.	Internal audit may attend as an “observer.
4.	A cyber security committee charter should be developed, approved and reflect:
	a.	committee objectives;
	b.	roles and responsibilities;
	c.	minimum number of meeting participants;
	d.	meeting frequency (minimum on quarterly basis).
5.	A cyber security function should be established.
6.	The cyber security function should be independent from the information technology function. To avoid any conflict of interest, the cyber security function and information technology function should have separate reporting lines, budgets and staff evaluations.
7.	The cyber security function should report directly to the CEO/managing director of the Member Organization or general manager of a control function.
8.	A full-time senior manager for the cyber security function, referred to as CISO, should be appointed at senior management level.
9.	The Member Organization should :
	a.	ensure the CISO has a Saudi nationality;
	b.	ensure the CISO is sufficiently qualified;
	c.	obtain no objection from SAMA to assign the CISO.
10.	The board of the Member Organization should allocate sufficient budget to execute the required cyber security activities.

3.1.2 Cyber Security Strategy

Principle

A cyber security strategy should be defined and aligned with the Member Organization's strategic objectives, as well as with the Banking Sector's cyber security strategy.

Objective

To ensure that cyber security initiatives and projects within the Member Organization contribute to the Member Organization's strategic objectives and are aligned with the Banking Sector's cyber security strategy.

Control considerations

1.	The cyber security strategy should be defined, approved, maintained and executed.
2.	The cyber security strategy should be aligned with:
	a.	the Member Organization's overall objectives;
	b.	the legal and regulatory compliance requirements of the Member Organization;
	c.	the Banking Sector's cyber security strategy.
3.	The cyber security strategy should address:
	a.	the importance and benefits of cyber security for the Member Organization;
	b.	the anticipated future state of cyber security for the Member Organization to become and remain resilient to (emerging) cyber security threats;
	c.	which and when cyber security initiatives and projects should be executed to achieve the anticipated future state.

3.1.3 Cyber Security Policy

Principle

A cyber security policy should be defined, approved and communicated.

Objective

To document the Member Organization's commitment and objectives of cyber security, and to communicate this to the relevant stakeholders.

Control considerations

1.	The cyber security policy should be defined, approved and communicated.
2.	The cyber security policy should be reviewed periodically according to a predefined and structured review process.
3.	The cyber security policy should be:
	a.	considered as input for other corporate policies of the Member Organization (e.g., HR policy, finance policy and IT policy);
	b.	supported by detailed security standards (e.g., password standard, firewall standard) and procedures;
	c.	based on best practices and (inter)national standards;
	d.	communicated to relevant stakeholders.
4.	The cyber security policy should include:
	a.	a definition of cyber security;
	b.	the Member Organization's overall cyber security objectives and scope;
	c.	a statement of the board's intent, supporting the cyber security objectives;
	d.	a definition of general and specific responsibilities for cyber security;
	e.	the reference to supporting cyber security standards and procedures;
	f.	cyber security requirements that ensure:
		1.	information is classified in a way that indicates its importance to the Member Organization;
		2.	information is protected in terms of cyber security requirements, in line with the risk appetite;
		3.	owners are appointed for all information assets;
		4.	cyber security risk assessments are conducted for information assets;
		5.	relevant stakeholders are made aware of cyber security and their expected behavior (cyber security awareness program);
		6.	compliance with regulatory and contractual obligations are being met;
		7.	cyber security breaches and suspected cyber security weaknesses are reported;
		8.	cyber security is reflected in business continuity management.

3.1.4 Cyber Security Roles and Responsibilities

Principle

Responsibilities to implement, maintain, support and promote cyber security should be defined throughout the Member Organization. Additionally, all parties involved in cyber security should understand and take their role and responsibilities.

Objective

To ensure that relevant stakeholders are aware of the responsibilities with regard to cyber security and apply cyber security controls throughout the Member Organization.

Control considerations

1.	The Board of Directors has the ultimate responsibility for cyber security, including:
	a.	ensuring that sufficient budget for cyber security is allocated;
	b.	approving the cyber security committee charter;
	c.	endorsing (after being approved by the cyber security committee):
		1.	the cyber security governance;
		2.	the cyber security strategy;
		3.	the cyber security policy.
2.	The cyber security committee should be responsible for:
	a.	monitoring, reviewing and communicating the Member Organization's cyber security risk appetite periodically or upon a material change in the risk appetite;
	b.	reviewing the cyber security strategy to ensure that it supports the Member Organization objectives;
	c.	approving, communicating, supporting and monitoring:
		1.	the cyber security governance;
		2.	the cyber security strategy;
		3.	the cyber security policy;
		4.	cyber security programs (e.g., awareness program, data classification program, data privacy, data leakage prevention, key cyber security improvements);
		5.	cyber security risk management process;
		6.	the key risk indicators (KRIs) and key performance indicators (KPIs) for cyber security.
3.	The senior management should be responsible for:
	a.	ensuring that standards, processes and procedures reflect security requirements (if applicable);
	b.	ensuring that individuals accept and comply with the cyber security policy, supporting standards and procedures when they are issued and updated;
	c.	ensuring that cyber security responsibilities are incorporated in the job descriptions of key positions and cyber security staff.
4.	The CISO should be responsible for:
	a.	developing and maintaining:
		1.	cyber security strategy;
		2.	cyber security policy;
		3.	cyber security architecture;
		4.	cyber security risk management process;
	b.	ensuring that detailed security standards and procedures are established, approved and implemented;
	c.	delivering risk-based cyber security solutions that address people, process and technology;
	d.	developing the cyber security staff to deliver cyber security solutions in a business context;
	e.	the cyber security activities across the Member Organization, including:
		1.	monitoring of the cyber security activities (SOC monitoring);
		2.	monitoring of compliance with cyber security regulations, policies, standards and procedures;
		3.	overseeing the investigation of cyber security incidents;
		4.	gathering and analyzing threat intelligence from internal and external sources;
		5.	performing cyber security reviews;
	f.	conducting cyber security risk assessments on the Members Organization's information assets;
	g.	proactively supporting other functions on cyber security, including:
		1.	performing information and system classifications;
		2.	determining cyber security requirements for important projects;
		3.	performing cyber security reviews.
	h.	defining and conducting the cyber security awareness programs;
	i.	measuring and reporting the KRIs and KPIs on:
		1.	cyber security strategy;
		2.	cyber security policy compliance;
		3.	cyber security standards and procedures;
		4.	cyber security programs (e.g., awareness program, data classification program, key cyber security improvements).
5.	The internal audit function should be responsible for:
	a.	performing cyber security audits.
6.	All Member Organization's staff should be responsible for:
	a.	complying with cyber security policy, standards and procedures.

3.1.5 Cyber Security in Project Management

Principle

Cyber security should be addressed in project management and project governance.

Objective

To ensure that the all the Member Organization's projects meet cyber security requirements.

Control considerations

1.	Cyber security should be integrated into the Member Organization's project management methodology to ensure that cyber security risks are identified and addressed as part of a project.
2.	The Member Organization's project management methodology should ensure that:
	a.	cyber security objectives are included in project objectives;
	b.	the cyber security function is part of all phases of the project;
	c.	a risk assessment is performed at the start of the project to determine the cyber security risks and to ensure that cyber security requirements are addressed either by the existing cyber security controls (based on cyber security standards) or to be developed;
	d.	cyber security risks are registered in the project-risk register and tracked;
	e.	responsibilities for cyber security are defined and allocated;
	f.	a cyber security review is performed by an independent internal or external party.

3.1.6 Cyber Security Awareness

Principle

A cyber security awareness program should be defined and conducted for staff, third parties and customers of the Member Organization.

Objective

To create a cyber security risk-aware culture where the Member Organization's staff, third parties and customers make effective risk-based decisions which protect the Member Organization's information.

Control considerations

1.	The cyber security awareness programs should be defined, approved and conducted to promote cyber security awareness and to create a positive cyber security culture.
2.	A cyber security awareness program should be defined and conducted for:
	a.	staff of the Member Organization;
	b.	third parties of the Member Organization;
	c.	customers of the Member Organization.
3.	The cyber security awareness program should target cyber security behaviors by tailoring the program to address the different target groups through multiple channels.
4.	The activities of the cyber security awareness program should be conducted periodically and throughout the year.
5.	The cyber security awareness program should at a minimum include:
	a.	an explanation of cyber security measures provided;
	b.	the roles and responsibilities regarding cyber security;
	c.	information on relevant emerging cyber security events and cyber threats (e.g., spear-phishing, whaling).
6.	The cyber security awareness program should be evaluated to:
	a.	measure the effectiveness of the awareness activities;
	b.	formulate recommendations to improve the cyber security awareness program.
7.	Customer awareness should address for both retail and commercial customers and, at a minimum, include a listing of suggested cyber security mechanisms which customers may consider implementing to mitigate their own risk(s).

3.1.7 Cyber Security Training

Principle

Staff of the Member Organization should be provided with training regarding how to operate the Member Organization's systems securely and to address and apply cyber security controls.

Objective

To ensure that staff of the Member Organization are equipped with the skills and required knowledge to protect the Member Organization's information assets and to fulfil their cyber security responsibilities.

Control considerations

1.	Specialist or security-related skills training should be provided to staff in the Member Organization's relevant functional area categories in line with their job descriptions, including:
	a.	key roles within the organization;
	b.	staff of the cyber security function;
	c.	staff involved in developing and (technically) maintaining information assets;
	d.	staff involved in risk assessments.
2.	Education should be provided in order to equip staff with the skills and required knowledge to securely operate the Member Organization's information assets.

3.2 Cyber Security Risk Management and Compliance
Risk management is the ongoing process of identifying, analyzing, responding and monitoring and reviewing risks. The cyber security risk management process focusses specifically on managing risks related to cyber security. In order to manage cyber security risks, Member Organizations should:
- identify their cyber security risks - cyber security risk identification;
- determine the likelihood that cyber security risks will occur and the resulting impact - cyber security risk analysis;
- determine the appropriate response to cyber security risks and select relevant controls - cyber security risk response;
- monitor the cyber security risk treatment and review control effectiveness - cyber security risk monitoring and review.
The compliance with the cyber security controls should be subject to periodic review and audit.

3.2.1 Cyber Security Risk Management

Principle

A cyber security risk management process should be defined, approved and implemented, and should be aligned with the Member Organization's enterprise risk management process.

Objective

To ensure cyber security risks are properly managed to protect the confidentiality, integrity and availability of the Member Organization's information assets, and to ensure the cyber security risk management process is aligned with the Member Organization's enterprise risk management process.

Control considerations

1.	The cyber security risk management process should be defined, approved and implemented.
2.	The cyber security risk management process should focus on safeguarding the confidentiality, integrity and availability of information assets.
3.	The cyber security risk management process should be aligned with the existing enterprise risk management process.
4.	The cyber security risk management process should be documented and address:
	a.	risk identification;
	b.	risk analysis;
	c.	risk response;
	d.	risk monitoring and review.
5.	The cyber security risk management process should address the Member Organization's information assets, including (but not limited to):
	a.	business processes;
	b.	business applications;
	c.	infrastructure components.
6.	The cyber security risk management process should be initiated:
	a.	at an early stage of the project;
	b.	prior to critical change;
	c.	when outsourcing is being considered;
	d.	when launching new products and technologies.
7.	Existing information assets should be periodically subject to cyber security risk assessment based on their classification or risk profile.
8.	The cyber security risk management activities should involve:
	a.	business owners;
	b.	IT specialists;
	c.	cyber security specialists;
	d.	key user representatives.
9.	The result of the risk assessment should be reported to the relevant business owner (i.e., risk owner) within the Member Organization;
10.	The relevant business owner (i.e., risk owner) within the Member Organization should accept and endorse the risk assessment results.
11.	The Member Organization's cyber security risk appetite and risk tolerance should be clearly defined and formally approved.

3.2.1.1 Cyber Security Risk Identification
Principle
Cyber security risk identification should be performed and should include the Member Organization's relevant assets, threats, existing controls and vulnerabilities.
Objective
To find, recognize and describe the Member Organization's cyber security risks.
Control considerations
1. Cyber security risk identification should be performed.
2. Identified cyber security risks should be documented (in a central register).
3. Cyber security risk identification should address relevant information assets, threats, vulnerabilities and the key existing cyber security controls.

3.2.1.2 Cyber Security Risk Analysis
Principle
A cyber security risk analysis should be conducted based on the likelihood that the identified cyber security risks will occur and their resulting impact.
Objective
To analyze and determine the nature and the level of the identified cyber security risks.
Control considerations
1. A cyber security risk analysis should be performed.
2. The cyber security risk analysis should address the level of potential business impact and likelihood of cyber security threat events materializing.

3.2.1.3 Cyber Security Risk Response

Principle

The cyber security risks of a Member Organization should be treated.

Objective

To ensure cyber security risks are treated (i.e., accepted, avoided, transferred or mitigated).

Control considerations

1.	The relevant determined cyber security risks should be treated according to the Member Organization’s risk appetite and cyber security requirements.
2.	Cyber security risk response should ensure that the list of risk treatment options are documented (i.e., accepting, avoiding, transferring or mitigating risks by applying cyber security controls).
3.	Accepting cyber security risks should include:
	a.	the consideration of predefined limits for levels of cyber security risk;
	b.	the approval and sign-off by the business owner, ensuring that:
		1.	the accepted cyber security risk is within the risk appetite and is reported to the cyber security committee;
		2.	the accepted cyber security risk does not contradict SAMA regulations.
4.	Avoiding cyber security risks should involve a decision by a business owner to cancel or postpone a particular activity or project that introduces an unacceptable cyber security risk.
5.	Transferring or sharing the cyber security risks should:
	a.	involve sharing the cyber security risks with relevant (internal or external) providers;
	b.	be accepted by the receiving (internal or external) provider(s);
	c.	eventually lead to the actual transferring or sharing of the cyber security risk.
6.	Applying cyber security controls to mitigate cyber security risks should include:
	a.	identifying appropriate cyber security controls;
	b.	evaluating the strengths and weaknesses of the cyber security controls;
		1.	assessing the cost of implementing the cyber security controls;
		2.	assessing the feasibility of implementing the cyber security controls;
		3.	reviewing relevant compliance requirements for the cyber security controls;
	c.	selecting cyber security controls;
	d.	identifying, documenting and obtaining sign-off for any residual risk by the business owner.
7.	Cyber security risk treatment actions should be documented in a risk treatment plan.

3.2.1.4 Cyber Risk Monitoring and Review

Principle

The progress cyber security risk treatment should be monitored and the effectiveness of revised or newly implemented cyber security controls should be reviewed.

Objective

To ensure that the cyber security risk treatment is performed according to the treatment plans. To ensure that the revised or newly implemented cyber security controls are effective.

Control considerations

1.	The cyber security treatment should be monitored, including:
	a.	tracking progress in accordance to treatment plan;
	b.	the selected and agreed cyber security controls are being implemented.
2.	The design and effectiveness of the revised or newly implemented cyber security controls should be reviewed.

3.2.2 Regulatory Compliance

Principle

A process should be established by the Member Organization to identify, communicate and comply with the cyber security implications of relevant regulations.

Objective

To comply with regulations affecting cyber security of the Member Organization.

Control considerations

1.	A process should be established for ensuring compliance with relevant regulatory requirements affecting cyber security across the Member Organization. The process of ensuring compliance should:
	a.	be performed periodically or when new regulatory requirements become effective;
	b.	involve representatives from key areas of the Member Organization;
	c.	result in the update of cyber security policy, standards and procedures to accommodate any necessary changes (if applicable).

3.2.3 Compliance with (Inter)national Industry Standards

Principle

The Member Organization should comply with mandatory (inter)national industry standards.

Objective

To comply with mandatory (inter)national industry standards.

Control considerations

1.	The Member Organization should comply with:
	a.	Payment Card Industry Data Security Standard (PCI-DSS);
	b.	EMV (Europay, MasterCard and Visa) technical standard;
	c.	SWIFT Customer Security Controls Framework - March 2017.

3.2.4 Cyber Security Review

Principle

The cyber security status of the Member Organization’s information assets should be subject to periodic cyber security review.

Objective

To ascertain whether the cyber security controls are securely designed and implemented, and the effectiveness of these controls is being monitored.

Control considerations

1.	Cyber security reviews should be periodically performed for critical information assets.
2.	Customer and internet facing services should be subject to annual review and penetration tests.
3.	Details of cyber security review performed should be recorded, including the results of review, issues identified and recommended actions.
4.	The results of cyber security review should be reported to business owner.
5.	Cyber security review should be subject to follow-up reviews to check that:
	a.	all identified issues have been addressed;
	b.	critical risks have been treated effectively;
	c.	all agreed actions are being managed on an ongoing basis.

3.2.5 Cyber Security Audits
Principle
The cyber security status of the Member Organization’s information assets should be subject to thorough, independent and regular cyber security audits performed in accordance with generally accepted auditing standards and SAMA cyber security framework.
Objective
To ascertain with reasonable assurance whether the cyber security controls are securely designed and implemented, and whether the effectiveness of these controls is being monitored.
Control considerations
1. Cyber security audits should be performed independently and according to generally accepted auditing standards and SAMA cyber security framework.
2. Cyber security audits should be performed according to the Member Organization’s audit manual and audit plan.

3.3 Cyber Security Operations and Technology
In order to safeguard the protection of the operations and technology of the Member Organization’s information assets and its staff, third parties and customers, the Member Organizations have to ensure that security requirements for their information assets and the supporting processes are defined, approved and implemented.
The compliance with these cyber security requirements should be monitored and the effectiveness of the cyber security controls should be periodically measured and evaluated in order to identify potential revisions of the controls or measurements.

3.3.1 Human Resources

Principle

The Member Organization should incorporate cyber security requirements into human resources processes.

Objective

To ensure that Member Organization staff’s cyber security responsibilities are embedded in staff agreements and staff are being screened before and during their employment lifecycle.

Control considerations

1.	The human resources process should define, approve and implement cyber security requirements.
2.	The effectiveness of the human resources process should be monitored, measured and periodically evaluated.
3.	The human resource process should include:
	a.	cyber security responsibilities and non-disclosure clauses within staff agreements (during and after the employment);
	b.	staff should receive cyber security awareness at the start and during their employment;
	c.	when disciplinary actions will be applicable;
	d.	screening and background check;
	e.	post-employment cyber security activities, such as:
		1.	revoking access rights;
		2.	returning information assets assigned (e.g., access badge, tokens, mobile devices, all electronic and physical information).

3.3.2 Physical Security

Principle

The Member Organization should ensure all facilities which host information assets are physically protected against intentional and unintentional security events.

Objective

To prevent unauthorized physical access to the Member Organization information assets and to ensure its protection.

Control considerations

1.	The physical security process should be defined, approved and implemented.
2.	The effectiveness of the physical security process should be monitored, measured and periodically evaluated.
3.	The physical security process should include (but not limited to):
	a.	physical entry controls (including visitor security);
	b.	monitoring and surveillance (e.g., CCTV, ATMs GPS tracking, sensitivity sensors);
	c.	protection of data centers and data rooms;
	d.	environmental protection;
	e.	protection of information assets during lifecycle (including transport and secure disposal, avoiding unauthorized access and (un)intended data leakage.

3.3.3 Asset Management

Principle

The Member Organization should define, approve, implement, communicate and monitor an asset management process, which supports an accurate, up-to-date and unified asset register.

Objective

To support the Member Organization in having an accurate and up-to-date inventory and central insight in the physical / logical location and relevant details of all available information assets, in order to support its processes, such as financial, procurement, IT and cyber security processes.

Control considerations

1.	The asset management process should be defined, approved and implemented.
2.	The effectiveness of the asset management process should be monitored, measured and periodically evaluated.
3.	The asset management process should include:
	a.	a unified register;
	b.	ownership and custodianship of information assets;
	c.	the reference to relevant other processes, depending on asset management;
	d.	information asset classification, labeling and handling;
	e.	the discovery of new information assets.

3.3.4 Cyber Security Architecture

Principle

The Member Organization should define, follow and review the cyber security architecture, which Outlines the cyber security requirements in the enterprise architecture and addresses the design principles for developing cyber security capabilities.

Objective

To support the Member Organization in achieving a strategic, consistent, cost effective and end-to-end cyber security architecture.

Control considerations

1.	The cyber security architecture should be defined, approved and implemented.
2.	The compliance with the cyber security architecture should be monitored.
3.	The cyber security architecture should include:
	a.	a strategic outline of cyber security capabilities and controls based on the business requirements;
	b.	approval of the defined cyber security architecture;
	c.	the requirement of having qualified cyber security architects;
	d.	design principles for developing cyber security controls and applying cyber security requirements (i.e., the security-by-design principle);
	e.	periodic review of the cyber security architecture.

3.3.5 Identity and Access Management

Principle

The Member Organization should restrict access to its information assets in line with their business requirements based on the need-to-have or need-to-know principles.

Objective

To ensure that the Member Organization only provides authorized and sufficient access privileges to approved users.

Control considerations

1.	The identity and access management policy, including the responsibilities and accountabilities, should be defined, approved and implemented.
2.	The compliance with the identity and access policy should be monitored.
3.	The effectiveness of the cyber security controls within the identity and access management policy should be measured and periodically evaluated.
4.	The identity and access management policy should include:
	a.	business requirements for access control (i.e., need-to-have and need-to-know);
	b.	user access management (e.g., joiners, movers, leavers):
		1.	all identified user types should be covered (i.e., internal staff, third parties);
		2.	changes of job status or job positions for internal staff (e.g. joiner, mover and leaver) should be instigated by the human resources department;
		3.	changes for external staff or third parties should be instigated by the appointed accountable party;
		4.	user access requests are formally approved in accordance with business and compliance requirements (i.e., need-to-have and need-to-know to avoid unauthorized access and (un)intended data leakage));
		5.	changes in access rights should be processed in a timely manner;
		6.	periodically user access rights and profiles should be reviewed;
		7.	an audit trail of submitted, approved and processed user access requests and revocation requests should be established;
	c.	user access management should be supported by automation;
	d.	centralization of the identity and access management function;
	e.	multi-factor authentication for sensitive and critical systems and profiles;
	f.	privileged and remote access management, which should address:
		1.	the allocation and restricted use of privileged and remote access, specifying:
			a.	multi-factor authentication should be used for all remote access;
			b.	multi-factor authentication should be used for privilege access on critical systems based on a risk assessment;
		2.	the periodic review of users with privileged and remote accounts;
		3.	individual accountability;
		4.	the use of non-personal privileged accounts, including:
			a.	limitation and monitoring;
			b.	confidentiality of passwords;
			c.	changing passwords frequently and at the end of each session.

3.3.6 Application Security

Principle

The Member Organization should define, approve and implement cyber security standards for application systems. The compliance with these standards should be monitored and the effectiveness of these controls should be measured and periodically evaluated.

Objective

To ensure that sufficient cyber security controls are formally documented and implemented for all applications, and that the compliance is monitored and its effectiveness is evaluated periodically within the Member Organization.

Control considerations

1.	The application cyber security standards should be defined, approved and implemented.
2.	The compliance with the application security standards should be monitored.
3.	The effectiveness of the application cyber security controls should be measured and periodically evaluated.
4.	Application development should follow the approved secure system development life cycle methodology (SDLC).
5.	The application security standard should include:
	a.	secure coding standards;
	b.	the cyber security controls implemented (e.g., configuration parameters, events to monitor and retain [including system access and data], identity and access management);
	c.	the segregation of duties within the application (supported with a documented authorization matrix);
	d.	the protection of data aligned with the (agreed) classification scheme (including privacy of customer data and, avoiding unauthorized access and (un)intended data leakage);
	e.	vulnerability and patch management;
	f.	back-up and recovery procedures;
	g.	periodic cyber security compliance review.

3.3.7 Change Management

Principle

The Member Organization should define, approve and implement a change management process that controls all changes to information assets. The compliance with the process should be monitored and the effectiveness should be measured and periodically evaluated.

Objective

To ensure that all change in the information assets within the Member Organization follow a strict change control process.

Control considerations

1.	The change management process should be defined, approved and implemented.
2.	The compliance with the change management process should be monitored.
3.	The effectiveness of the cyber security controls within the change management process should be measured and periodically evaluated.
4.	The change management process should include:
	a.	cyber security requirements for controlling changes to information assets, such as assessing the impact of requested changes, classification of changes and the review of changes;
	b.	security testing, which should (if applicable) include:
		1.	penetration testing;
		2.	code review if applications are developed internally;
		3.	code review of externally developed applications and if the source code is available
		4.	a code review report (or equivalent, such as an independent assurance statement) in case the source code cannot be provided;
	c.	approval of changes by the business owner;
	d.	approval from the cyber security function before submitting to Change Advisory Board (CAB);
	e.	approval by CAB;
	f.	post-implementation review of the related cyber security controls;
	g.	development, testing and implementation are segregated for both the (technical) environment and involved individuals;
	h.	the procedure for emergency changes and fixes;
	i.	fall-back and roll-back procedures.

3.3.8 Infrastructure Security

Principle

The Member Organization should define, approve and implement cyber security standards for their infrastructure components. The compliance with these standards should be monitored and the effectiveness should be measured and periodically evaluated.

Objective

To support that all cyber security controls within the infrastructure are formally documented and the compliance is monitored and its effectiveness is evaluated periodically within the Member Organization.

Control considerations

1.	The infrastructure security standards should be defined, approved and implemented.
2.	The compliance with the infrastructure security standards should be monitored.
3.	The effectiveness of the infrastructure cyber security controls should be measured and periodically evaluated.
4.	The infrastructure security standards should cover all instances of infrastructure available in the main datacenter(s), the disaster recovery data site(s) and office spaces.
5.	The infrastructure security standards should cover all instances of infrastructure (e.g., operating systems, servers, virtual machines, firewalls, network devices, IDS, IPS, wireless network, gateway servers, proxy servers, email gateways, external connections, databases, file-shares, workstations, laptops, tablets, mobile devices, PBX).
6.	The infrastructure security standard should include:
	a.	the cyber security controls implemented (e.g., configuration parameters, events to monitor and retain [including system access and data], data-leakage prevention [DLP], identity and access management, remote maintenance);
	b.	the segregation of duties within the infrastructure component (supported with a documented authorization matrix);
	c.	the protection of data aligned with the (agreed) classification scheme (including privacy of customer data and, avoiding unauthorized access and (un)intended data leakage);
	d.	the use of approved software and secure protocols;
	e.	segmentation of networks;
	f.	malicious code/software and virus protection (and applying application whitelisting and APT protection);
	g.	vulnerability and patch management;
	h.	DDOS protection (where applicable); this should include:
		1.	the use of scrubbing services;
		2.	specification of the bandwidth agreed;
		3.	24x7 monitoring by Security Operating Center (SOC), Service Provider (SP) and scrubbing provider;
		4.	testing of DDOS scrubbing (minimum twice a year);
		5.	DDOS services should be implemented for the main datacenter(s) as well as the disaster recovery site(s);
	i.	back-up and recovery procedures;
	j.	periodic cyber security compliance review.

3.3.9 Cryptography

Principle

The use of cryptographic solutions within the Member Organizations should be defined, approved and implemented.

Objective

To ensure that access to and integrity of sensitive information is protected and the originator of communication or transactions can be confirmed.

Control considerations

1.	A cryptographic security standard should be defined, approved and implemented.
2.	The compliance with the cryptographic security standard should be monitored.
3.	The effectiveness of the cryptographic security controls should be measured and periodically evaluated.
4.	The cryptographic security standard should include:
	a.	an overview of the approved cryptographic solutions and relevant restrictions (e.g., technically,legally);
	b.	the circumstances when the approved cryptographic solutions should be applied;
	c.	the management of encryption keys, including lifecycle management, archiving and recovery.

3.3.10 Bring Your Own Device (BYOD)

Principle

When the Member Organization allows the use of personal devices (e.g., smartphones, tablets, laptops) for business purposes, the use should be supported by a defined, approved and implemented cyber security standard, additional staff agreements and a cyber security awareness training.

Objective

To ensure that business and sensitive information of the Member Organization is securely handled by staff and protected during transmission and storage, when using personal devices.

Control considerations

1.	The BYOD cyber security standard should be defined, approved and implemented.
2.	The compliance with the BYOD cyber security standard should be monitored.
3.	The effectiveness of the BYOD cyber security controls should be measured and periodically evaluated.
4.	The BYOD standard should include:
	a.	responsibilities of the user (including awareness training);
	b.	information regarding the restrictions and consequences for staff when the Member Organization implements cyber security controls on their personal devices; for example when using modified devices (jailbreaking), terminating the employment or in case of loss or theft of the personal device;
	c.	the isolation of business information from personal information (e.g., containerization);
	d.	the regulation of corporate mobile applications or approved “public” mobile applications;
	e.	the use of mobile device management (MDM); applying access controls to the device and business container and encryption mechanisms on the personal device (to ensure secure transmission and storage).

3.3.11 Secure Disposal of Information Assets
Principle
The information assets of the Member Organization should be securely disposed when the information assets are no longer required.
Objective
To ensure that the Member Organization’s business, customer and other sensitive information are protected from leakage or unauthorized disclosure when disposed.
Control considerations
1. The secure disposal standard and procedure should be defined, approved and implemented.
2. The compliance with the secure disposal standard and procedure should be monitored.
3. The effectiveness of the secure disposal cyber security controls should be measured and periodically evaluated.
4. Information assets should be disposed in accordance with legal and regulatory requirements, when no longer required (i.e. meeting data privacy regulations to avoid unauthorized access and avoid (un)intended data leakage).
5. Sensitive information should be destroyed using techniques to make the information non-retrievable (e.g., secure erase, secure wiping, incineration, double crosscut, shredding)
6. The Member Organization should ensure that third party service providers used for secure disposal, transport and storage comply with the secure disposal standard and procedure and the effectiveness is periodically measured and evaluated.

3.3.12 Payment Systems

Principle

The Member Organization should define, approve, implement and monitor a cyber security standard for payment systems. The effectiveness of this process should be measured and periodically evaluated.

Objective

To ensure the Member Organization safeguards the confidentiality and integrity of shared banking systems.

Control considerations

	For Saudi Arabian Riyal Interbank Express (SARIE) information, please refer to the SARIE Information Security Policy, Version Issue 1.0 - June 2016.
	For MADA information, please refer to the following sections in the MADA Rules and Standards Technical Book (see appendix A):
		Part IIIa - Security Framework, Version Issue 6.0.0 - May 2016
		Part IIIb - HSM Requirements, Version Issue 6.0.0 - May 2016
		SAMA CA IPK Certificate Procedures, Version Issue 6.0.1 - October 2016

3.3.13 Electronic Banking Services

Principle

The Member Organization should define, approve, implement and monitor a cyber security standard for electronic banking services. The effectiveness of this standard should be measured and periodically evaluated.

Objective

To ensure the Member Organization safeguards the confidentiality and integrity of the customer information and transactions.

Control Considerations

1.	The cyber security standards for electronic banking services should be defined, approved and implemented.
2.	The compliance with cyber security standards for electronic banking services should be monitored.
3.	The effectiveness of the cyber security standard for electronic banking services should be measured and periodically evaluated.
4.	Electronic banking services security standard should cover:
	a.	use of brand protection measures to protect online services including social media.
	b.	online, mobile and phone banking:
		1.	use of official application stores and websites (applicable for online and mobile banking);
		2.	use of detection measures and take-down of malicious apps and websites (applicable for online and mobile banking);
		3.	use of sandboxing (applicable for online and mobile banking);
		4.	use of non-caching techniques (applicable for online and mobile banking);
		5.	use of communication techniques to avoid ‘man-in-the-middle'-attacks (applicable for online and mobile banking);
		6.	use of multi-factor authentication mechanisms:
			a.	multi-factor authentication should be used during the registration process for the customer in order to use of electronic banking services;
			b.	multi-factor authentication should be implemented for all electronic banking services available to customers;
			c.	the use of hard and soft tokens should be password protected;
			d.	revoking the access of customers after 3 successive incorrect passwords or invalid PINs;
			e.	the process for changing the customer mobile number should only be done from either a branch or ATM;
			f.	the processes for requesting and activating of the multi-factor authentication should be done through different delivery channels;
			g.	multi-factor authentication should be implemented for the following processes:
				1.	sign-on;
				2.	adding or modifying beneficiaries;
				3.	adding utility and government payment services;
				4.	high-risk transactions (when it exceeds predefined limits);
				5.	password reset;
		7.	the processes for adding and activating beneficiaries should be done through different delivery channels (applicable for mobile and online banking);
		8.	high availability of the electronic banking services should be ensured;
		9.	scheduled downtime of the electronic banking services should be timely communicated to SAMA and customers;
		10.	contractual agreements between the Member Organization and the customer addressing the roles, responsibilities and liabilities for both the Member Organization and the customers;
		11.	obtaining approval of SAMA before launching a new electronic banking service.
	c.	ATMs and POSs:
		1.	prevention and detection of exploiting the ATM/POS application and infrastructure vulnerabilities (e.g., cables, (USB)-ports, rebooting);
		2.	cyber security measures, such as hardening of operating systems, malware protection, privacy screens, masking of passwords or account numbers (e.g., screen and receipt), geo-blocking (e.g., disable cards per default for outside GCC countries, disable magnetic strip transactions), video monitoring (CCTV), revoking cards after 3 successive invalid PINs, anti-skimming solutions (hardware/software), and PIN-pad protection;
		3.	remote stopping of ATMs in case of malicious activities.
	d.	SMS instant notification services:
		1.	SMS messages should not contain sensitive data (e.g., account balance - except for credit cards);
		2.	SMS alert should be sent to both mobile numbers (old and new) when the customer’s mobile number has been changed;
		3.	SMS notification should be sent to the customer’s mobile number when requesting a new multi-factor authentication mechanism.
		4.	SMS notification should be sent to the customer’s mobile number for all retail and personal financial transactions.
		5.	SMS notification should be sent to the customer’s mobile number when beneficiaries are added, modified and activated.

3.3.14 Cyber Security Event Management

Principle

The Member Organization should define, approve and implement a security event management process to analyze operational and security loggings and respond to security events. The effectiveness of this process should be measured and periodically evaluated.

Objective

To ensure timely identification and response to anomalies or suspicious events within regard to information assets.

Control considerations

1.	The security event management process should be defined, approved and implemented.
2.	The effectiveness of the cyber security controls within the security event management process should be measured and periodically evaluated.
3.	To support this process a security event monitoring standard should be defined, approved and implemented.
	a.	the standard should address for all information assets the mandatory events which should be monitored, based on the classification or risk profile of the information asset.
4.	The security event management process should include requirements for:
	a.	the establishment of a designated team responsible for security monitoring (i.e., Security Operations Center (SOC));
	b.	skilled and (continuously) trained staff;
	c.	a restricted area to facilitate SOC activities and workspaces;
	d.	resources required continuous security event monitoring activities (24x7);
	e.	detection and handling of malicious code and software;
	f.	detection and handling of security or suspicious events and anomalies;
	g.	deployment of security network packet analysis solution;
	h.	adequately protected logs;
	i.	periodic compliance monitoring of applications and infrastructure cyber security standards
	j.	automated and centralized analysis of security loggings and correlation of event or patterns (i.e., Security Information and Event Management (SIEM));
	k.	reporting of cyber security incidents;
	l.	independent periodic testing of the effectiveness of the security operations center (e.g., red- teaming).

3.3.15 Cyber Security Incident Management

Principle

The Member Organization should define, approve and implement a cyber security incident management that is aligned with the enterprise incident management process, to identify, respond to and recover from cyber security incidents. The effectiveness of this process should be measured and periodically evaluated.

Objective

To ensure timely identification and handling of cyber security incidents in order to reduce the (potential) business impact for the Member Organization.

Control considerations

1.	The cyber security incident management process should be defined, approved, implemented and aligned with the enterprise incident management process.
2.	The effectiveness of the cyber security controls within the cyber security incident management process should be measured and periodically evaluated.
3.	The standard should address the mandatory and suspicious security events which should be responded to.
4.	The security incident management process should include requirements for:
	a.	the establishment of a designated team responsible for security incident management;
	b.	skilled and (continuously) trained staff;
	c.	sufficient capacity available of certified forensic staff for handling major incidents (e.g., internal staff or contracting an external forensic team);
	d.	a restricted area to facilitate the computer emergency response team (CERT) workspaces;
	e.	the classification of cyber security incidents;
	f.	the timely handling of cyber security incidents, recording and monitoring progress;
	g.	the protection of relevant evidence and loggings;
	h.	post-incident activities, such as forensics, root-cause analysis of the incidents;
	i.	reporting of suggested improvements to the CISO and the Committee;
	j.	establish a cyber security incident repository.
5.	The Member Organization should inform ‘SAMA IT Risk Supervision' immediately when a medium or high classified security incident has occurred and identified.
6.	The Member Organization should obtain ‘no objection' from ‘SAMA IT Risk Supervision' before any media interaction related to the incident.
7.	The Member Organization should submit a formal incident report ‘SAMA IT Risk Supervision' after resuming operations, including the following incident details:
	a.	title of incident;
	b.	classification of the incident (medium or high);
	c.	date and time of incident occurred;
	d.	date and time of incident detected;
	e.	information assets involved;
	f.	(technical) details of the incident;
	g.	root-cause analysis;
	h.	corrective activities performed and planned;
	i.	description of impact (e.g., loss of data, disruption of services, unauthorized modification of data, (un)intended data leakage, number of customers impacted);
	j.	total estimated cost of incident;
	k.	estimated cost of corrective actions.

3.3.16 Threat Management

Principle

The Member Organization should define, approve and implement a threat intelligence management process to identify, assess and understand threats to the Member Organization information assets, using multiple reliable sources. The effectiveness of this process should be measured and periodically evaluated.

Objective

To obtain an adequate understanding of the Member Organization’s emerging threat posture.

Control considerations

1.	The threat intelligence management process should be defined, approved and implemented.
2.	The effectiveness of the threat intelligence management process should be measured and periodically evaluated.
3.	The threat intelligence management process should include:
	a.	the use of internal sources, such as access control, application and infrastructure logs, IDS, IPS, security tooling, Security Information and Event Monitoring (SIEM), support functions (e.g., Legal, Audit, IT Helpdesk, Forensics, Fraud Management, Risk Management, Compliance);
	b.	the use of reliable and relevant external sources, such as SAMA, government agencies, security forums, (security) vendors, security organizations and specialist notification services;
	c.	a defined methodology to analyze the threat information periodically;
	d.	the relevant details on identified or collected threats, such as modus operandi, actors, motivation and type of threats;
	e.	the relevance of the derived intelligence and the action-ability for follow-up (for e.g., SOC, Risk Management);
	f.	sharing the relevant intelligence with the relevant stakeholders (e.g., SAMA, BCIS members).

3.3.17 Vulnerability Management

Principle

The Member Organization should define, approve and implement a vulnerability management process for the identification and mitigation of application and infrastructural vulnerabilities. The effectiveness of this process should be measured and the effectiveness should be periodically evaluated.

Objective

To ensure timely identification and effective mitigation of application and infrastructure vulnerabilities in order to reduce the likelihood and business impact for the Member Organization.

Control considerations

1.	The vulnerability management process should be defined, approved and implemented.
2.	The effectiveness of the vulnerability management process should be measured and periodically evaluated.
3.	The vulnerability management process should include:
	a.	all information assets;
	b.	frequency of performing the vulnerability scan (risk-based);
	c.	classification of vulnerabilities;
	d.	defined timelines to mitigate (per classification);
	e.	prioritization for classified information assets;
	f.	patch management and method of deployment.

3.4 Third Party Cyber Security
When Member Organizations do rely on, or have to deal with third party services, it is key to ensure the same level of cyber security protection is implemented at the third party, as within the Member Organization.
This paragraph describes how the cyber security requirements between the Member Organization and Third Parties should be organized, implemented and monitored. Third Parties in this Framework are defined as, information services providers, outsourcing providers, cloud computing providers, vendors, suppliers, governmental agencies, etc.

3.4.1 Contract and Vendor Management

Principle

The Member Organization should define, approve, implement and monitor the required cyber security controls within the contract and vendor management processes.

Objective

To ensure that the Member Organization's approved cyber security requirements are appropriately addressed before signing the contract, and the compliance with the cyber security requirements is being monitored and evaluated during the contract life-cycle.

Control Considerations

1.	The cyber security requirements should be defined, approved, implemented and communicated within the contract and vendor management processes.
2.	The compliance with contract and vendor management process should be monitored.
3.	The effectiveness of the cyber security controls within the contract and vendor management process should be measured and periodically evaluated.
4.	These contract and vendor management processes should cover:
	a.	whether the involvement of the cyber security function is actively required (e.g., in case of due diligence);
	b.	the baseline cyber security requirements which should be applied in all cases;
	c.	the right to periodically perform cyber security reviews and audits.
5.	The contract management process should cover requirements for:
	a.	executing a cyber security risk assessment as part of the procurement process;
	b.	defining the specific cyber security requirements as part of the tender process;
	c.	evaluating the replies of potential vendors on the defined cyber security requirements;
	d.	testing of the agreed cyber security requirements (risk-based);
	e.	defining the communication or escalation process in case of cyber security incidents;
	f.	ensuring cyber security requirements are defined for exiting, terminating or renewing the contract (including escrow agreements if applicable);
	g.	defining a mutual confidentiality agreement.
6.	The vendor management process (i.e., service level management) should cover requirements for:
	a.	periodic reporting, reviewing and evaluating the contractually agreed cyber security requirements (in SLAs).

3.4.2 Outsourcing

Principle

The Member Organization should define, implement and monitor the required cyber security controls within outsourcing policy and outsourcing process. The effectiveness of the defined cyber security controls should periodically be measured and evaluated.

Objective

To ensure that the Member Organization's cyber security requirements are appropriately addressed before, during and while exiting outsourcing contracts.

Control Considerations

1.	The cyber security requirements within the outsourcing policy and process should be defined, approved, implemented and communicated within Member Organization.
2.	The cyber security requirements regarding the outsourcing policy and process should be measured and periodically evaluated.
3.	The outsourcing process should include:
	a.	the approval from SAMA prior to material outsourcing;
	b.	the involvement of the cyber security function;
	c.	compliance with the SAMA circular on outsourcing.

3.4.3 Cloud Computing

Principle

The Member Organization should define, implement and monitor the required cyber security controls within the cloud computing policy and process for hybrid and public cloud services. The effectiveness of the defined cyber security controls should periodically be measured and evaluated.

Please note that this requirement is not applicable to private cloud services (= internal cloud).

Objective

To ensure that all functions and staff within the Member Organization are aware of the agreed direction and position on hybrid and public cloud services, the required process to apply for hybrid and public cloud services, the risk appetite on hybrid and public cloud services and the specific cyber security requirements for hybrid and public cloud services.

Control Considerations

1.	The cyber security controls within the cloud computing policy for hybrid and public cloud services should be defined, approved and implemented and communicated within Member Organization.
2.	The compliance with the cloud computing policy should be monitored.
3.	The cyber security controls regarding the cloud computing policy and process for hybrid and public cloud services should be periodically measured and evaluated.
4.	The cloud computing policy for hybrid and public cloud services should address requirements for:
	a.	the process for adopting cloud services, including that:
		1.	a cyber security risk assessment and due diligence on the cloud service provider and its cloud services should be performed;
		2.	the Member Organization should obtain SAMA approval prior to using cloud services or signing the contract with the cloud provider;
		3.	a contract should be in place, including the cyber security requirements, before using cloud services;
	b.	data location, including that:
		1.	in principle only cloud services should be used that are located in Saudi Arabia, or when cloud services are to be used outside Saudi Arabia that the Member Organization should obtain explicit approval from SAMA;
	c.	data use limitations, including that:
		1.	the cloud service provider should not use the Member Organization’s data for secondary purposes;
	d.	security, including that:
		1.	the cloud service provider should implement and monitor the cyber security controls as determined in the risk assessment for protecting the confidentiality, integrity and availability of the Member Organization’s data;
	e.	data segregation, including that:
		1.	the Member Organization’s data is logically segregated from other data held by the cloud service provider, including that the cloud service provider should be able to identify the Member Organization’s data and at all times should be able to distinguish it from other data.
	f.	business continuity, including that:
		1.	business continuity requirements are met in accordance with the Member Organization’s business continuity policy;
	g.	audit, review and monitoring, including that:
		1.	the Member Organization has the right to perform a cyber security review at the cloud service provider;
		2.	the Member Organization has the right to perform a cyber security audit at the cloud service provider;
		3.	the Member Organization has the right to perform a cyber security examination at the cloud service provider;
	h.	exit, including that:
		1.	the Member Organization has termination rights;
		2.	the cloud service provider has to return the Member Organization’s data on termination;
		3.	the cloud service provider has to irreversibly delete the Member Organization’s data on termination.

Appendices

Appendix A - Overview Previous Issued SAMA Circulars

The Framework Supersedes the following previously issued SAMA circulars:
	Assessment of protection and information security systems for all banks, 25514-MAT-53331, 25/10/2012;
	Enhance monitoring controls over ATMs, 49616-MAT-24388, 8/9/2012;
	Requirements to reduce DoS/DDoS attacks, 361000033746, 24/12/2014;
	Cards Cloning, 361000078157, 19/3/2015;
	Independency of Information Security, 361000036797, 30/12/2014;
	Caution from electronic fraud, 17722-MAT, 29/6/2011;
	Confidentiality of banking information, 341000065707, 6/4/2013;
	SAMA regulation about mobile banking, 341000096665, 16/6/2013;
	Using forged ATM cards to withdrawals from client accounts, 644/MAT/33043, 24/6/2009;
	Token service, 341000071570, 18/4/2013;
	E-Banking Rules, 11231-MAG-23612, 9/4/2010;
	Multi-factor authentication, 789/MAT/40690, 6/8/2009.
The framework refers to the following SAMA circulars or documents with regard to Payment Systems:
		For Saudi Arabian Riyal Interbank Express (SARIE) information, please refer to the SARIE Information Security Policy, Version Issue 1.0 - June 2016.
		For mada information, please refer to the following sections in the mada Rules and Standards Technical Book (see appendix A):
			Part IIIa - Security Framework, Version Issue 6.0.0 - May 2016
			Part IIIb - HSM Requirements, Version Issue 6.0.0 - May 2016
			SAMA CA IPK Certificate Procedures, Version Issue 6.0.1 - October 2016
The framework refers to the following SAMA circulars or documents with regard to outsourcing and business continuity management:
	Rules on outsourcing, 424-BCS-34720, 20/7/2008;
	Business Continuity Framework, 381000058504, 01/06/1438H

Appendix B - How to Request an Update to the Framework

Below the illustration of the process for requesting an update to the Framework.
	Detail information supported by pros and cons about the suggested update.
	The request should first be approved by CISO before submitting to cyber security committee.
	The request should be approved by Member Organization's cyber steering committee.
	The request should be sent formally in writing to SAMA via the Member Organization's CEO or managing director to the deputy governor of Supervision.
	‘SAMA IT Risk Supervision' will evaluate the request and informs the Member Organization.
	The current Framework remains applicable while the requested update is being considered, processed and if applicable is approved and processed.

Appendix C – Framework Update Request Form
Request to Update SAMA Cyber Security Framework
A submission to the deputy governor of SAMA IT Risk Supervision
The Saudi Arabian Monetary Authority (SAMA) will consider requests from a member organization (MO) to update its Cyber Security Framework based on the information submitted using the form below. A separate form must be completed for each requested update. Please note that all required fields must be properly filled in before SAMA will begin the review process
Requestor Information
REQUESTOR'S SIGNATURE*

x REQUESTOR'S POSITION* DATE*
REQUESTOR'S NAME*
MEMBER ORGANIZATION OF REQUESTOR*

FRAMEWORK SECTION*:

PURPOSE OF REQUESTED UPDATE (including detailed information on its pros and cons)*:

PROPOSAL*:

Approvals
1. MO’s CISO APPROVAL*
DATE*

2. MO’S CYBER SECURITY COMMITTEE APPROVAL*
APPROVER’S POSITION*
DATE*

* Denotes required fields

Appendix D - How to Request a Waiver from the Framework

Below the illustration of the process for requesting a waiver from the Framework.
	Detail description about the reasons that the bank could not meet the required control.
	Details description about the available or suggested compensating controls.
	The waiver request should first be approved by CISO before submitting to cyber security committee.
	The waiver request should approved by the members of Member Organization's cyber security committee.
	The waiver request should be signed by the CISO and relevant (business) owner.
	The waiver request should be formally issued in writing to SAMA via the Member Organization's CEO or managing director to the deputy governor of Supervision.
	‘SAMA IT Risk Supervision' will evaluate the waiver request and informs the Member Organization.
	The current Framework remains applicable while the requested waiver is being evaluated and processed, until the moment of granting the waiver.

Appendix E – Framework Waiver Request Form
Request for Waiver from the SAMA Cyber Security Framework
A submission to the deputy governor of SAMA IT Risk Supervision
The Saudi Arabian Monetary Authority (SAMA) will consider requests for waiver from a member organization (MO) from its Cyber Security Framework based on the information submitted using the form below. A separate form must be completed for each requested waiver. Please note that all required fields must be properly filled in before SAMA will begin the review process.
Requestor Information
REQUESTOR'S SIGNATURE*

x REQUESTOR'S POSITION* DATE*
REQUESTOR'S NAME*
MEMBER ORGANIZATION OF REQUESTOR*

FRAMEWORK CONTROL*:

DETAILED DESCRIPTION OF WHY CONTROL CANNOT BE IMPLEMENTED*:

DETAILED DESCRIPTION OF AVAILABLE OR SUGGESTED COMPENSATING CONTROLS*:

Approvals
1. MO’s CISO APPROVAL*
DATE*

2. MO’S CYBER SECURITY COMMITTEE APPROVAL*
APPROVER’S POSITION*
DATE*

* Denotes required fields

Appendix F - Glossary

Term	Description
Access management	Access management is the process of granting authorized users the right to use a service, while preventing access to non-authorized users.
Anti-skimming solution	A solution that monitors an ATM or POS environment for illegally mounted intrusion mechanisms (both hard- and software).
Application whitelisting	A list of applications and application components (libraries, configuration files, etc.) that are authorized to be present or active on a host according to a well- defined baseline. Application whitelisting technologies are intended to stop the execution of malware and other unauthorized software. Unlike security technologies such as antivirus software, which use blacklists to block known bad activity and permit all other, application whitelisting technologies are designed to permit known activity and block all other. (NIST SP 800-167 Guide to Application Whitelisting)
APT	An advanced persistent threat (APT) is an adversary that possesses sophisticated levels of expertise and significant resources which allow it to create opportunities to achieve its objectives by using multiple attack vectors (e.g., cyber, physical, and deception). These objectives typically include establishing and extending footholds within the information technology infrastructure of the targeted organizations for purposes of exfiltrating information, undermining or impeding critical aspects of a mission, program, or organization; or positioning itself to carry out these objectives in the future. The advanced persistent threat: (i) pursues its objectives repeatedly over an extended period of time; (ii) adapts to defenders’ efforts to resist it; and (iii) is determined to maintain the level of interaction needed to execute its objectives. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Asset management	The systematic process of deploying, operating, maintaining, upgrading, and disposing of assets in a safe, secure and cost effective manner.
Assurance	Grounds for confidence that the other four security goals (integrity, availability, confidentiality, and accountability) have been adequately met by a specific implementation. “Adequately met” includes (1) functionality that performs correctly, (2) sufficient protection against unintentional errors (by users or software), and (3) sufficient resistance to intentional penetration or by-pass. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Audit trail	A record showing who has accessed an Information Technology (IT) system and what operations the user has performed during a given period. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Authorization matrix	A matrix that defines the rights and permissions a specific role needs for information. The matrix lists each user, the business process tasks he or she performs, and the affected systems.
Availability	Ensuring timely and reliable access to and use of information. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Business applications	Any software or set of computer programs that are used by business users to perform various business functions.
Business continuity	The capability of an organization to continue delivery of IT and business services at acceptable predefined levels following a disruptive incident. (ISO 22301:2012 Societal security -- Business continuity management systems)
BYOD	Bring your own device (BYOD) refers to personally owned devices (laptops, tablets, and smart phones) that employees and contractors are permitted to use to carry out business functions.
CCTV	Closed-circuit television (CCTV) is the use of video cameras to transmit a signal to a specific place, on a limited set of monitors.
CEO	The Chief Executive Officer (CEO) is the executive with the chief decision-making authority in an organization.
CERT	A computer emergency response team (CERT) is a group of experts that handle computer security incidents.
Change management	The controlled identification and implementation of required changes within a business or information systems.
CIO	Chief information officer (CIO). A senior-level executive responsible for the information technology and computer systems that support enterprise goals.
CISO	Chief information security officer (CISO). A senior-level executive responsible for establishing and maintaining the enterprise cyber security vision, strategy, and program to ensure information assets and technologies are adequately protected.
Classification scheme	Refer to 'Data classification'.
Cloud computing	A model for enabling on-demand network access to a shared pool of configurable IT capabilities/ resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. It allows users to access technology-based services from the network cloud without knowledge of, expertise with, or control over the technology infrastructure that supports them. This cloud model is composed of five essential characteristics (on-demand self-service, ubiquitous network access, location independent resource pooling, rapid elasticity, and measured service); three service delivery models: (Cloud Software as a Service [SaaS], Cloud Platform as a Service [PaaS], and Cloud Infrastructure as a Service [IaaS]); and four models for enterprise access (Private cloud, Community cloud, Public cloud, and Hybrid cloud). (NISTIR 7298r2 Glossary of Key Information Security Terms)
Compensating Security Control	A management, operational, and/or technical control (i.e., safeguard or countermeasure) employed by an organization in place of a recommended security control in the low, moderate, or high baselines that provides equivalent or comparable protection for an information system. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Confidentiality	Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Containerization	A virtualization method for deploying and running distributed applications without launching a virtual machine for each application. Instead, multiple isolated systems run on a single control host and access a single kernel.
Control effectiveness	The measure of correctness of implementation (i.e., how consistently the control implementation complies with the security plan) and how well the security plan meets organizational needs in accordance with current risk tolerance. (NISTIR 7298r2 Glossary of Key Information Security Terms)
COO	Chief Operating Officer. A senior-level executive responsible for the daily operation of the organization.
Cryptographic solutions	Solutions pertaining to cryptography. Refer to 'Cryptography'.
Cryptography	The discipline that embodies the principles, means, and methods for the transformation of data in order to hide their semantic content, prevent their unauthorized use, or prevent their undetected modification. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Custodianship	Responsibility for controlling the access to and the accounting, safeguarding, and destruction of information according to an organization's security policy .
Cyber risk	The risk to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other organizations, and the Nation due to the potential for unauthorized access, use, disclosure, disruption, modification, or destruction of information and/or information systems. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Cyber security	Cyber security is defined as the collection of tools, policies, security concepts, security safeguards, guidelines, risk management approaches, actions, training, best practices, assurance, and technologies that can be used to protect the member organization's information assets against internal and external threats.
Cyber security architecture	An embedded, integral part of the enterprise architecture that describes the structure and behavior for the enterprise's security processes, cyber security systems, personnel and organizational sub-units, showing their alignment with the enterprise's mission and strategic plans. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Cyber security audit	Independent review and examination of security-related records and activities to provide reasonable assurance that system controls are adequate and that established policies and operational procedures are compliant. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Cyber security awareness	Activities which seek to focus an individual's attention on a cyber security issues. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Cyber security awareness program	A program that explains proper rules of behavior for the safe and secure use of IT systems and information. The program communicates cyber security policies and procedures that need to be followed.
Cyber security control	The management, operational, and technical controls (i.e., safeguards or countermeasures) prescribed for an information system to protect the confidentiality, integrity, and availability of the system and its information. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Cyber security examination	A review of security-related records and activities of records and activities to assess the adequacy of system controls and to ensure compliance with established policies and operational procedures. An examination does not provide assurance.
Cyber security function	A function, independent from the information technology function, that is headed by a CISO and that reports directly to the CEO/managing director of the Member Organization or general manager of a control function. The information security function is responsible for:
	–	supporting information security policies, defining information security roles and responsibilities, and setting information security goals for implementation;
	–	providing information security and information risk management frameworks;
	–	identifying known and emerging information security issues;
	–	identifying shifts in the organization's implicit information risk appetite;
	–	assisting management in developing information security processes and controls to manage information security risks and information security issues;
	–	providing guidance and training on information security and information risk management processes;
	–	facilitating and monitoring implementation of effective information security and information risk management practices by operational management;
	–	alerting operational management to emerging information security issues and changing regulatory and information risk scenarios;
	–	monitoring the adequacy and effectiveness of internal control, accuracy and completeness of reporting, compliance with laws and regulations in connection with information security , and timely remediation of deficiencies.
Cyber security governance	A set of responsibilities and practices exercised by the board and executive management with the goal of providing strategic direction for cyber security, ensuring that cyber security objectives are achieved, ascertaining that cyber risks are managed appropriately and verifying that the enterprise's resources are used responsibly.
Cyber security incident	An occurrence that actually or potentially jeopardizes the confidentiality, integrity, or availability of an information system or the information the system processes, stores, or transmits or that constitutes a violation or imminent threat of violation of security policies, security procedures, or acceptable use policies. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Cyber security incident management	The monitoring and detection of security events on an information systems and the execution of proper responses to those events.
Cyber security policy	A set of criteria for the provision of security services. It defines and constrains the activities of a data processing facility in order to maintain a condition of security for systems and data. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Cyber security program	Top-down management structure and mechanism for coordinating security activities throughout the organization.
Cyber security review	Independent review and examination of security-related records and activities to provide limited assurance that system controls are adequate and that established policies and operational procedures are compliant. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Cyber security risk assessment	The process of identifying risks to organizational operations, organizational assets, individuals, other organizations, and the nation, arising through the operation of an information system. A part of risk management, it incorporates threat and vulnerability analyses and considers mitigations provided by security controls planned or in place. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Cyber security risk management	The process of managing risks to organizational operations, organizational assets, individuals, other organizations, and the Nation, resulting from the operation of an information system, and consists of (i) a risk assessment; (ii) the implementation of a risk mitigation strategy; and (iii) employment of techniques and procedures for the continuous monitoring of the security state of the information system. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Cyber security strategy	A high-level plan, consisting of projects and initiatives, to mitigate cyber security risks while complying with legal, statutory, contractual, and internally prescribed requirements.
Cyber security threat	Any circumstance or event with the potential to adversely impact organizational operations, organizational assets, individuals, other organizations, or the nation through an information system via unauthorized access, destruction, disclosure, modification of information, and/or denial of service. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Data classification	The conscious decision to assign a level of sensitivity to data as it is being created, amended, enhanced, stored, or transmitted. The classification of the data should then determine the extent to which the data needs to be controlled / secured and is also indicative of its value in terms of business assets.
Double crosscut	A technique using saws or blades to cut media into confetti-sized bits.
Enterprise architecture	The description of an enterprise's entire set of information systems: how they are configured, how they are integrated, how they interface to the external environment at the enterprise's boundary, how they are operated to support the enterprise mission, and how they contribute to the enterprise's overall security posture. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Enterprise risk management	The methods and processes used by an enterprise to manage risks to its mission and to establish the trust necessary for the enterprise to support shared missions. It involves the identification of mission dependencies on enterprise capabilities, the identification and prioritization of risks due to defined threats, the implementation of countermeasures to provide both a static risk posture and an effective dynamic response to active threats; and it assesses enterprise performance against threats and adjusts countermeasures as necessary. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Fall-back	Business procedures and measures, undertaken when events have triggered the execution of either a business continuity plan or a contingency plan.
Forensics	The practice of gathering, retaining, and analyzing computer-related data for investigative purposes in a manner that maintains the integrity of the data. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Formally documented	Documentation that is written, approved by the senior leadership and disseminated to relevant parties.
Gateway server	Interface providing compatibility between networks by converting transmission speeds, protocols, codes, or security measures. It directs, but does not filter, connections between networks. See also ‘Proxy server’.
GCC countries	Members of the Gulf Cooperation Council (GCC), a political and economic alliance of the Kingdom of Bahrain, the State of Kuwait, the Sultanate of Oman, the State of Qatar, the Kingdom of Saudi Arabia and the United Arab Emirates.
Geo-blocking	A form of internet censorship where access to content is restricted based upon the user's geographical location.
Hard token	A hard token (a.k.a. an 'authentication token') is a hardware security device that is used to authorize a user to a system. Some hard tokens are used in combination with other security measures to further enhance security (known as multi-factor authentication). See also 'Soft token'.
Hybrid cloud services	A cloud computing service that is composed of some combination of private, public and community cloud services, from different service providers. (Gartner)
Identity management	The process of controlling information about users on computers, including how they authenticate and what systems they are authorized to access and/or what actions they are authorized to perform. It also includes the management of descriptive information about the user and how and by whom that information can be accessed and modified. Managed entities typically include users, hardware and network resources and even applications.
IDS	An intrusion detection system (IDS) is a hardware or software product that gathers and analyzes information from various areas within a computer or a network to identify possible security breaches, which include both intrusions (attacks from outside the organizations) and misuse (attacks from within the organizations). (NISTIR 7298r2 Glossary of Key Information Security Terms)
Incident management	Refer to 'Cyber security incident management'.
Incident management plan	The documentation of a predetermined set of instructions or procedures to detect, respond to, and limit consequences of a malicious cyber-attack against an organization's information system(s). Also Refer to 'Cyber security incident management'. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Incineration	A method of media and device destruction using high heat.
Indicator of compromise	A forensic artifact or remnant of an intrusion that can be identified on a host or network. (RSA)
Integrity	Guarding against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity. (NISTIR 7298r2 Glossary of Key Information Security Terms)
IPS	An intrusion prevention system (IPS) can detect an intrusive activity and can also attempt to stop the activity, ideally before it reaches its targets. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Irreversibly delete	See 'Secure erase'
Jailbreaking	A form of privilege escalation that removes software restrictions imposed by the software manufacturer and often results in unlimited privileges on the device.
Key performance indicator	A type of performance measurement that evaluate the success of an organization or of a particular activity in which it engages. Numerical threshold(s) are typically used to categorize performance.
Key risk indicator	A measure used to indicate the probability an activity or organization will exceed its defined risk appetite. KRIs are used by organizations to provide an early signal of increasing risk exposures in various areas of the enterprise.
Likelihood	A weighted factor based on an analysis of the probability that a given threat is capable of exploiting a given vulnerability.
Malware	A program that is inserted into a system, usually covertly, with the intent of compromising the confidentiality, integrity, or availability of the victim's data, applications, or operating system or of otherwise annoying or disrupting the victim. (NISTIR 7298r2 Glossary of Key Information Security Terms)
MDM	Mobile device management (MDM) is an industry term for the administration of mobile devices.
Member organization	Organizations affiliated with SAMA.
Mobile device	Portable cartridge/disk-based, removable storage media (e.g., floppy disks, compact disks, USB flash drives, external hard drives, and other flash memory cards or drives that contain non-volatile memory). Portable computing and communications device with information storage capability (e.g., notebook/laptop computers, personal digital assistants, cellular telephones, digital cameras, and audio recording devices). (NISTIR 7298r2 Glossary of Key Information Security Terms)
Multi-factor authentication	Authentication using two or more factors to achieve authentication. Factors include: (i) something you know (e.g. password/PIN); (ii) something you have (e.g., cryptographic identification device, token); or (iii) something you are (e.g., biometric). (NISTIR 7298r2 Glossary of Key Information Security Terms)
NIST	The (U.S.) National Institute of Standards and Technology (nist.gov)
Non-repudiation	Protection against an individual falsely denying having performed a particular action. Provides the capability to determine whether a given individual took a particular action such as creating information, sending a message, approving information, and receiving a message. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Patch	An update to an operating system, application, or other software issued specifically to correct particular problems with the software. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Patch management	The systematic notification, identification, deployment, installation, and verification of operating system and application software code revisions. (NISTIR 7298r2 Glossary of Key Information Security Terms)
PBX	A private branch exchange (PBX) is a telephone exchange or switching system that serves a private organization and performs concentration of central office lines and provides intercommunication between a large number of telephone stations within the organization.
PCI DSS	The Payment Card Industry Data Security Standard (PCI DSS) is a proprietary cyber security standard for organizations that handle branded credit cards from the major card schemes including Visa, MasterCard, American Express, Discover, and JCB.
Penetration testing	A test methodology in which assessors, working under specific constraints and optionally using all available documentation (e.g., system design, source code, manuals), attempt to circumvent the security features of an information system. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Personal devices	Devices, like a smart phone, that are not owned or issued by the organization.
Physical security	The physical protection of facilities that host information assets against intentional and unintentional security events.
PIN	A password consisting only of decimal digits. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Privileged account / access	An information system account with approved authorizations to perform security- relevant functions that ordinary users are not authorized to perform. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Proxy server	A server that services the requests of its clients by forwarding those requests to other servers. It directs and filters connections between networks. See also ‘Gateway server’.
Public cloud service	Services that are rendered over a network that is open to the public. Public cloud providers own and operate the infrastructure at their data center and access is generally via the Internet.
Red-teaming	An exercise, reflecting real-world conditions, that is conducted as a simulated adversarial attempt to compromise organizational missions and/or business processes to provide a comprehensive assessment of the security capability of the information system and organization.
Resilience	The ability to continue to: (i) operate under adverse conditions or stress, even if in a degraded or debilitated state, while maintaining essential operational capabilities; and (ii) recover to an effective operational posture in a time frame consistent with mission needs.
Risk	A measure of the extent to which an organization is threatened by a potential circumstance or event, and typically a function of: (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Risk appetite	The amount and type of risk that an organization is willing to take in order to meet their strategic objectives. Also refer to 'Risk tolerance'. (ISO/Guide 73:2009 Risk management — Vocabulary)
Risk profile	A description of any set of risks that relate to the whole organization, part of the organization, or as otherwise defined. The risk profile will outline the number of risks, type of risk and potential effects of risks. (ISO/Guide 73:2009 Risk management — Vocabulary)
Risk register	Risk register is a table used as a repository for all risks identified and includes additional information about each risk, e.g. risk category, risk owner, and mitigation actions taken.
Risk tolerance	The acceptable variation relative to performance to the achievement of objectives. Also refer to 'Risk appetite'. (COSO Internal Control — Integrated Framework)
Risk treatment	A process to modify risk that can involve avoiding the risk by deciding not to start or continue with the activity that gives rise to the risk; taking or increasing risk in order to pursue an opportunity; removing the risk source; changing the likelihood; changing the consequences; sharing the risk with another party or parties; and retaining the risk by informed decision. Risk treatments that deal with negative consequences are sometimes referred to as “risk mitigation”, “risk elimination”, “risk prevention” and “risk reduction”. Risk treatments can create new risks or modify existing risks. (ISO/Guide 73:2009 Risk management — Vocabulary)
Risk-aware culture	The shared values, beliefs, knowledge, attitudes and understanding about risk within an organization. In a strong risk culture people proactively identify, discuss and take responsibility for risks. (Institute of Risk Management)
Root-cause analysis	A principle-based, systems approach for the identification of underlying causes associated with a particular set of risks. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Sandboxing	A restricted, controlled execution environment that prevents potentially malicious software, such as mobile code, from accessing any system resources except those for which the software is authorized. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Scrubbing services	A service that analyzes an organization's network traffic and removes malicious traffic (DDoS, known vulnerabilities and exploits).
SDLC	A system development lifecycle (SDLC) describes the scope of activities associated with a system, encompassing the system's initiation, development and acquisition, implementation, operation and maintenance, and ultimately its disposal that instigates another system initiation. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Secure coding standard	A document that describes a uniform set of rules and guidelines for developing computer software that protects against the accidental introduction of security vulnerabilities. Examples includes OWASP's Secure Coding Practices and the Software Engineering Institute's Secure Coding Standards.
Secure disposal	The disposing of equipment and media that minimizes the risk of unwanted disclosure. See also 'Secure erase', 'Secure wiping', 'Incineration', and 'Double crosscut'.
Secure erase	An overwrite technology using a firmware-based process to overwrite a hard drive. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Secure wiping	Refer to 'Secure erase'.
Security architecture	Refer to 'Cyber security architecture'.
Security control	Refer to 'Cyber security control'
Security testing	Examination and analysis of the safeguards required to protect an information system, as they have been applied in an operational environment, to determine the security posture of that system. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Sensitive information	Information, the loss, misuse, or unauthorized access to or modification of, that could adversely affect the organizational affairs, or the privacy to which individuals are entitled. Additionally, sensitive information is the information deemed sensitive according to the organizational data classification policy (see 'Data classification'). (NISTIR 7298r2 Glossary of Key Information Security Terms)
SIEM	A security information and event management (SIEM) tool is a system that provides the ability to gather security data from information system components and presents that data as actionable information via a single interface. (NISTIR 7298r2 Glossary of Key Information Security Terms)
SLA	A service level agreement (SLA) defines the specific responsibilities of the service provider and sets the customer expectations. (NISTIR 7298r2 Glossary of Key Information Security Terms)
SOC	A security operations center (SOC) is a specialized location (and team) where security-related data from enterprise information systems (e.g., web sites, applications, databases, servers, networks, desktops and other devices) is monitored, assessed and actioned. The SOC is often dedicated to the detection, investigation and potential response to indicators of compromise. The SOC works closely with, and disseminates, collated security-related information to other areas of the organization (e.g., the cyber security function, incident management team and IT service owners).
Soft token	A soft token (a.k.a. a virtual token) is a software version of a hard token. Soft tokens are typically generated by a central server that runs security software and sent to users' devices. Some hard tokens are used in combination with other security measures to further enhance security (known as multi-factor authentication). See also 'Hard token'.
Strategy	Refer to 'Cyber security strategy'.
Threat	Refer to 'Cyber security threat'
Threat intelligence	Threat intelligence is evidence-based knowledge, including context, mechanisms, indicators, implications and actionable advice, about an existing or emerging menace or hazard to assets that can be used to inform decisions regarding the subject's response to that menace or hazard. (Gartner)
Threat landscape	1. An overview of threats, together with current and emerging trends. 2. A collection of threats in a particular domain or context, with information on identified vulnerable assets, threats, risks, threat actors and observed trends. (ENISA)
Token	Something that the user possesses and controls (typically a key or password) that is used to authenticate the user's identity. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Vendor management	The practice of ensuring that third-party service providers adhere to the same information security standards that an organization must comply with and includes periodic security assessments.
Vulnerability	Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Vulnerability management	Vulnerability management is the cyclical practice of identifying, classifying, remediating, and mitigating vulnerabilities. Also refer to 'Vulnerability'.

Financial Sector Cyber Threat Intelligence Principles
No: 43065348 Date(g): 27/2/2022 | Date(h): 26/7/1443 Status: In-Force
Referring to the Cybersecurity Strategy for the financial sector aimed at creating a secure and reliable financial sector that enables growth and prosperity. Through monitoring changes in business models of financial institutions, reliance on technology in financial transactions, and the adoption of emerging and modern technologies,
it has been observed that there is a change in the cyber threat landscape for the financial sector. This has resulted in a rapid and noticeable evolution by Advanced Persistent Threats (APT) groups targeting the financial sector for various purposes, using different levels, methods, tools, and procedures. This necessitates the development of monitoring and investigation capabilities for financial institutions to proactively keep pace with the advancement of these hacking groups.
Accordingly, and based on SAMA's regulatory and supervisory role over the financial sector, we inform you of the adoption of the Financial Sector Cyber Threat Intelligence Principles, which aim to establish scientific and practical foundations for monitoring and investigating cyber threats, and to enhance the practices of financial institutions in analyzing the cyber threat landscape to take precautionary measures. These principles also aim to provide various technical, operational, and business departments with proactive threat intelligence tailored to their functions. The principles have been divided into several levels as follows:
- Core Principles - These are foundational principles required as a basis for all monitoring and investigation operations related to cyber threats.
- Strategic Principles - Focus on the strategic aspects of the investigated information, such as the objectives and motives of hacking groups, identifying expected breach and attack scenarios based on the organization's cyber threat landscape, and conducting necessary assessments.
- Operational Principles - Target the analysis of operational patterns and methods used by hacking groups, such as malware, procedures followed, and classification of different stages of attacks (Taxonomization).
- Technical Principles - These are the recognized principles in cyber threat analysis to derive indicators of compromise (IOCs) and establish controls for detecting and responding to cyberattacks.
Accordingly, to enhance the cyber resilience of the financial sector and elevate the maturity level for proactive monitoring and response to cyber threats, it has been decided as follows:
1. Conduct an accurate assessment of the current state of Threat Intelligence management in the financial institution compared to the principles outlined (Gap Assessment) across its various classifications to identify gaps.
2. Develop a Roadmap to ensure full compliance with the principles effective immediately, according to the following timelines:
a. Six months for the basic, operational, and technical principles.
b. Twelve months for the strategic principles.
1. The financial institution must present the prepared Roadmap to the Board of Directors, inform them of its contents, secure approval, and obtain the necessary support for its implementation.
2. The Cybersecurity Committee within the financial institution shall oversee the implementation of the principles, ensure adherence to the approved roadmap, and provide full support to address obstacles and challenges faced by the specialized teams in the institution. Any matters that could affect or hinder the application of the principles should be escalated internally to the appropriate authority.
3. The financial institution must provide the necessary support to the Cybersecurity Department to implement the provisions of the framework, enhance the role of cyber threat analysis, and ensure they are equipped with trained national competencies, technical tools, and adequate training to perform their tasks efficiently.
We would also like to inform you that SAMA will conduct supervisory visits to verify full compliance with these principles. For any inquiries in this regard, you may contact the General Administration for Cyber Risk Supervision, represented by the Cyber Forecasting Center, via email at: (CFC@SAMA.GOV.SA).

Introduction
With the progressive digitalization of financial services, safeguarding sensitive data, transactions, and the availability of services have become a priority to the financial sector in the Kingdom of Saudi Arabia (KSA). These services are not only fundamental to the global and national economy, but also vital to digital innovation and national security.
Cyber-attacks have increasingly posed a significant challenge to organizations, with threat actors becoming more sophisticated and continuously evolving their modus operandi and attack vectors. Cyber Threat Intelligence (CTI) enables organizations to collect, analyze, and share data concerning cyber threats. A better understanding of these cyber threats, both existing and emerging, enables organizations to proactively anticipate cyber attacks and protect critical information assets.
The document is an extension of the Cyber Security Framework (CSF) mandated by the Saudi Central Bank* (SAMA), specifically of its associated "Threat Management" subdomain. SAMA created the Cyber Threat Intelligence Principles with the aim of scaling up the CTI practices within the financial sector regulated by SAMA.
* The "Saudi Arabian Monetary Agency" was replaced By the "Saudi Central Bank" in accordance with The Saudi Central Bank Law No. (M/36), dated 11/04/1442H, corresponding to 26/11/2020G.

Scope of Applicability
This document is mandatory for all Member Organizations regulated by SAMA.
This document is intended for senior and executive management, business owners, owners of information assets, Chief Information Security Officers (CISO), and individuals accountable for and involved in defining, implementing, and reviewing Cyber Threat Intelligence within Member Organizations.

Responsibilities
This document is mandated by SAMA, who is the owner of the document and is responsible for its periodic updates. Member Organizations are responsible for adopting and implementing the principles contained in this document.

Review, Updates and Maintenance
SAMA will review the document periodically to evaluate its applicability to the context of the KSA financial sector and its Member Organizations. If deemed necessary, SAMA will update the document based on the outcome of the review. Once changes are applied, SAMA will retire the previous version, and release and communicate the new version to all Member Organizations.

Cyber Threat Intelligence Principles
The Cyber Threat Intelligence (CTI) Principles describes best practices focused on producing, processing, and disseminating threat intelligence to enhance the identification and mitigation of cyber threats relevant to the financial sector in the KSA through actionable threat intelligence.
The structure of the document has been developed based on different types of CTI. The principles contained in each section (Core, strategic, Operational, and Technical and Tactical) have different purposes aiming at a holistic practice of CTI. In particular:
Core CTI Principles are a prerequisite to the practice of CTI and inform the other types of CTI. They include the activities needed to be performed for the planning, production, and dissemination of CTI.
Strategic CTI Principles involve a specialized CTI practice which include the activities needed to be performed for the identification of the objective, motivations, and intent of threat actors.
Operational CTI Principles involve a specialized CTI practice which include the activities needed to be performed for the identification of the modus operandi, behavior, and techniques used by threat actors.
Technical & Tactical CTI Principles involve a specialized CTI practice which include the activities needed to be performed for the identification of technical components and indicators of cyber attacks.
All principles should be applied by Member Organizations. The adoption of a phased approach for the complete implementation of the principles is at the discretion of the Member Organizations. The principles contained in this document apply also to the Member Organizations who outsource their CTI capability.
This document is organized in four domains including Core CTI, Strategic CTI, Operational CTI, and Technical and Tactical CTI as detailed in the graph below:

Figure 1. CTI Principles

Domain 1: Core Cyber Threat Intelligence Principles
Core Cyber Threat Intelligence Principles establish a baseline for the planning, collection, processing, analysis, and dissemination of threat intelligence based around the intelligence lifecycle framework.
The Core Threat Intelligence Principles section is based on the main phases of the intelligence lifecycle, including the dissemination of threat intelligence and continuously improving the CTI capability and performance of Member Organizations.
The intelligence lifecycle allows security teams to analyze and understand the information, prevent, and defend their networks from cyber attacks. It is the process by which raw data and information is identified, collected, and analyzed. Subsequently, raw data and information is transformed into intelligence to be used and actioned by Member Organizations. The intelligence lifecycle is fully represented by the following Core Principles.

Principle 1: Define Roles and Responsibilities
Member Organizations should define roles and responsibilities within the organization to produce threat intelligence with the expectation of creating their own CTI capability. This should include a dedicated team in charge of the production and dissemination of threat intelligence. In addition, the cyber threat intelligence team should be supported by skilled resources with purpose-specific advanced tools and a defined budget. Member Organizations should define communication channels inside the organization between the cyber threat intelligence team and other teams, including with stakeholders (e.g. Cyber security teams, business leaders, risk team, etc.) and with external organizations.

Principle 2: Define Threat Intelligence Planning and Collection Requirements
Member Organizations should develop a set of threat intelligence requirements to guide their intelligence production efforts efficiently and to establish what intelligence should be produced to meet their security and business objectives. To define such requirements, Member Organizations should define the scope of the analysis (e.g. organizational, sectorial, national, etc.) and consider different areas of analysis relevant to their business priorities (e.g. technology, threat actors, etc.). In addition, Member Organizations should ensure periodical review of the defined requirements. Further explanation of the areas of analysis is provided in "Annex B. Areas of Analysis“.

Principle 3: Select and Validate Relevant Sources
Member Organizations should select sources in line with the defined threat intelligence requirements. Moreover, Member Organizations should define what type of sources to use, understand which sources are likely to produce the desired information, and consider a wide range of different sources to enable them to build a holistic understanding of threats relevant to the financial sector. Additionally, Member Organizations should assess the reliability and reputation of every source considering specific parameters. These parameters include the quality and accuracy of information, timeliness in relation to reporting, technical information included, comprehensiveness of threat feed, and type of information aligned with the defined threat intelligence requirements.
Member Organizations should select sources that provide information that is relevant to their business and in line with the threat Intelligence requirements defined. These sources can be external or internal to the organization. Examples of internal and external sources are provided In "Annex C. Types of Sources”.

Principle 4: Collect Data Through Intelligence Sources
Member Organizations should collect data via various intelligence sources (e.g. OSINT, TECHINT, SOCMINT, HUMINT and deep web and dark web intelligence). Gathering information from a diverse range of sources will produce holistic assessments of threats faced by the organization. Examples of types of Intelligence are provided in "Annex D. Types of Intelligence". Specific Standard Operating Procedures (SOPs) to conduct intelligence should be followed as specified in "Annex F. Intelligence Standard Operating Procedures".

Principle 5: Define Specific Standard Operating Procedures (SOPs)
Member Organizations should define specific standard operating procedures (SOPs) when conducting specific types of intelligence as detailed in "Principle 4: Collect Data Through Intelligence Sources". Member Organizations should establish a set of instructions for individuals within the organizations to perform CTI to ensure functional procedures, while simultaneously reducing miscommunication and ambiguity. The SOPs should be detail-oriented and provide step-by-step instructions as to how analysts within Member Organizations must go about completing tasks and processes related to CTI. Examples of SOPs are provided in "Annex F. Intelligence Standard Operating Procedures".

Principle 6: Process and Classify Information
Member Organizations should process and classify collected intelligence - either manually, automatically, or a combination of the two - from the selected sources and store it securely. Furthermore, Member Organizations should refer to the "SAMA Cybersecurity Communication Protocols" when employing the Traffic Light Protocol (TLP) classification scheme for the collection and processing of information.

Principle 7: Analyze Information
Member Organizations should apply a variety of quantitative and qualitative analytical techniques to analyze the importance and implications of the processed information, and, in turn, produce actionable intelligence. Moreover, Member Organizations will combine and analyze various pieces of information, collected from diverse sources, to identify patterns, trends, and new developments relevant to the Member Organization.
Member Organizations should adopt adequate analytical approaches (e.g. Hypothesis-driven, Analyst-driven, and/or Contrarian) to be sure that the intelligence produced meets the intelligence requirements as defined in "Principle 2: Define Threat Intelligence Requirements". Examples of different types of analytical approaches are provided in "Annex G. Analytical Approach".

Principle 8: Share Intelligence
Member Organizations should establish specific sharing standards for the dissemination of threat intelligence. Examples of delivery methods for threat intelligence are provided in "Annex E,-Threat intelligence Delivery Methods".
Member Organizations should establish a consistent and precise language practice throughout the organization to ensure wide applicability of threat intelligence. To clearly communicate threat intelligence, the Member Organizations should rely for example on a writing guide (e.g. the Economist style Guide). They should also use a scale of 'estimative probability' system while engaging in analysis as defined in "SAMA's Threat Advisory Template".
Member Organizations should disseminate threat intelligence in an effective, timely, and accurate manner. It should be presented in a clear, concise, and coherent way when shared with the relevant internal stakeholders. When sharing intelligence with SAMA, Member Organizations should define procedures that help control the publication and distribution of threat information.
All the information produced by the Member Organizations should be classified in accordance with the Traffic Light Protocol (TLP) classification scheme as per the "SAMA Cybersecurity Communication Protocols".

Principle 9: Deliver Actionable Threat Intelligence
Member Organizations should implement relevant decisions and actions based on the intelligence produced to help build the resilience of the financial sector in the KSA. Member Organizations should take into consideration what actions are necessary, who is going to take these actions, and the response timeframe for anticipating or responding to an attack. Based on threat Intelligence produced, Member Organizations should take relevant mitigation actions or measures to improve defense infrastructure and resilience based on their knowledge of relevant threats (e.g. knowing techniques adopted by threat actors on a network could help Member Organizations to prioritize mitigation controls).
The Member Organization's threat intelligence team should share relevant intelligence with other relevant departments such as the Security Operations Center (SOC), IT, etc. sharing of such information should be done as per "Principle 8: Share Intelligence". These departments should also share information deemed relevant to the CTI capability as to feed and complement threat intelligence assessments.

Principle 10: Continuously Improve Methods of Intelligence
Member Organizations should continuously maintain, update, and improve the production, processing, analysis, and dissemination of threat intelligence with the aim of continuously increasing the maturity of the financial sector in the KSA. Additionally, Member Organizations should also regularly update existing threat intelligence requirements based on feedback from internal and external stakeholders, threat intelligence users, changes in the industry, and evolutions within the global threat landscape.
Member Organizations should perform periodic analysis of the threat information collected and verify its relevance (e.g. in terms of motivation, target, modus operandi, capability, etc.) according to assets and data processed by them. Member Organizations should also consider the services of a dedicated threat intelligence provider, who can offer relevant insights to complement the organization's existing understanding of threats.
Member Organizations should consider using Key Performance Indicators (KPIs), Key Risk Indicators (KRIs), and Objectives and Key Results (OKRs) to quantify progress and update intelligence practices and protocols as aligned to their internal procedures.

Principle 11: Integrate CTI
Member Organizations should consider integrating CTI in situational awareness and red teaming assessments in line with the "SAMA FEER Framework".
The Integration within situational awareness activities will help to build strategic understanding of cyber incidents, for example, identifying threat actors, trends in their activities, and objectives. Additionally, it will offer tactical understanding of events or situations in cyberspace and will facilitate effective and efficient decision-making in times of crisis.
Member Organizations should also take into consideration that the integration of CTI in red team assessments activities will help to get a better understanding of how cyber attackers gain access to networks and sensitive data. This can help to validate the organisation's security posture and help contextualise business process improvements by delivering more intelligence on cyber risks, their potential impact, and remediation options.

Domain 2: Strategic Cyber Threat Intelligence
Considering the changing nature of the threat landscape, Strategic CTI allows to continuously monitor the cyber ecosystem and to prevent threats.
Strategic CTI specifically helps at identifying and understanding the threats to the financial sector. It provides the level of threat intelligence focused on objectives, motivations, and intent of cyber threat actors, strategic CTI aims at examining attribution, investigating real motivations and links between cyber events, and understanding the financial sector's ecosystem.
The threat landscape includes information on the threat actors that are most relevant to the Member Organizations, their main characteristics, and the main cyber trends within the financial sector worldwide.
This information is addressed to relevant executive management (e.g. chief Information Security officer) who will relay the information to other relevant parties (e.g. IT management, business leaders, etc.). Strategic CTI aids in the organization's understanding of current cyber threats, unknown future threats, threat actors, and attribution of attacks. Such understanding is key to having a pro-active approach to cybersecurity in order to build the resilience of the financial sector in the KSA.

Principle 12: Identify a Cyber Threat Landscape
Member Organizations should identify the cyber threat landscape relevant to their organization and operations, with information on identified vulnerable assets, threats, risks, threat actors, and observed trends. This includes identifying events that can influence the financial sector's threat landscape.
Moreover, Member Organizations should identify the threat actors that may intend to target them, and their main characteristics including their origin, intent, motivation, and capabilities. After identifying their threat landscape, Member Organizations should perform an assessment of the identified threats to prioritize which are the most relevant. Additionally, Member Organizations should also identify the main cyber trends that are likely to influence the future evolutions of the cyber threat landscape.

Principle 13: Identify Strategic Cyber Attack Scenarios
Member Organizations should identify the strategic cyber attack scenarios that provide a realistic representation of likely cyber attacks against them. These scenarios should involve one or more threat actors, address one or more targets, and the potential impacts of the scenarios.
To elaborate strategic cyber attack scenarios, Member Organizations should identify similarities of features of threat actors or campaigns within the threat landscape outlined as per "Principle 12: Identify a Cyber Threat Landscape" (e.g. similar technique, similar attack type, etc.). In addition, Member Organizations should perform an assessment on the identified scenarios to prioritize the most likely and impactful scenarios and should take relevant corrective actions based on the threats and scenarios identified. The periodicity of the assessment of the identified scenarios should be defined by Member Organizations based on their own internal processes.

Principle 14: Elaborate Requests for Information (RFIs) and Tailored Threat Assessments
Member Organizations should be able to provide, upon request, detailed information (e.g. cyber threats, trends, events, and malware or tools) related to possible cyber attacks that could target them. These can be structured, for example, as threat actor profiles, country profiles, malware or tools analyses, or cyber trend studies.
Member Organizations, based on the intelligence produced, should be able to perform tailored threat assessments to define the relevancy and level of potential threats, as well as the probability of attacks.
The CISO is responsible for validating the quality and relevance of the information. This information can be of particular interest to senior and executive management, business owners, owners of information assets, etc. This information is particularly valuable for instance when defining business strategies, planning security interventions, or following significant cyber incidents in the sector or in the country.

Domain 3: Operational Cyber Threat Intelligence
Operational CTI helps the Member Organizations to understand the nature, intent, and timing of a specific attack, and provides insight into the behavior of a threat actor on a network.
Operational CTI provides detailed information on the behavior and modus operandi of threat actors used to carry out cyber attacks. Generally, this information is commonly taxonomized in Tactics, Techniques, and Procedures (TTPs).

Principle 15: Define the Attack Chain
Member Organizations should define and taxonomize the various phases of an attack performed by the threat actors based on industrial standards or frameworks (e.g. kill chain, unified kill chain, etc.). Moreover, Member Organizations should analyze information and modus operandi of the threat actors based on a structured approach to attacks (e.g. MITRE framework adopts a modified version of the unified kill-chain).

Principle 16: Identify TTPs
Member Organizations should analyze the information collected from sources related to relevant threat actors, tools, or malware to identify relevant Techniques, Tactics, and Procedures (TTPs). In addition, Member Organizations should adopt a taxonomy of attacks and classification of such TTPs (e.g. MITRE ATT&CK). Based on the defined taxonomy, they should build threat actor behavior profiles and identify techniques used by threat actors. Member Organizations should rely also on Indicators of Compromise (loCs) for the identification of these TTPs.

Principle 17: Identify Malware and Tools
Member Organizations should identify malware and tools during an attack, as well as conduct a general classification of these to use at an organizational level (e.g. Banking Trojan, Ransomware, etc.). Member Organizations can obtain information regarding the different types of malware and tools used by the threat actors using different sources, such as Indicators of Compromises (loCs), dark web, deep web, OSINT, code repositories, information sharing platforms, etc.

Domain 4: Technical and Tactical Cyber Threat Intelligence
Technical and tactical threat intelligence provide technical information regarding specific attacks performed by threat actors such as loCs, Yara Rules, etc.
The indicators of technical threat intelligence are collected from active and past campaigns obtained from public sources, technical indicators collected within the organization, and/or data feeds provided by external third-parties.

Principle 18: Collect IoCs
Member Organizations should identify, collect, and aggregate loCs and implement them in their defence infrastructure. Member Organizations should be able to collect details on specific implementation of malware and tools in order to understand how the organization is likely to be attacked and determine whether appropriate detection and mitigation mechanisms exist or whether they need to be implemented. In addition, Member Organizations should take into consideration different threat intelligence platforms and sources to obtain such technical information.

Principle 19: Monitor and Report Vulnerabilities
Member Organizations should constantly monitor announcements of new vulnerabilities discovered, as well as zero-day vulnerabilities exploited by threat actors. They should report these vulnerabilities to relevant parties within the organization (e.g. those in charge of patching management). These communications should be done in accordance to Member Organizations' internal procedures (e.g. SLA and KPI).
Member Organization should adapt a risk-based approach that correlates asset value, the severity of vulnerabilities, and threat actor activity via the use of threat intelligence and analytics to calculate realistic risk rating. This rating should be used to prioritize remediation activities. In addition, Member Organization should use a risk-based approach to employ mitigating controls, such as intrusion prevention system (IPS), when unable to patch vulnerabilities to reduce the attack surface and prevent vulnerabilities from being exploited.

Annexes

Annex A. Glossary

The following list contains a definition of the main terms used in this document.

Glossary
Term	Description
Application	A software program hosted by an information system. Source: NISTIR 7298 3Glossary of Key Information Security Terms
Asset	The data, personnel, devices, systems, and facilities that enable the organization to achieve business purposes. Source: NISTIR 7298 3Glossary of Key Information Security Terms
Attacker	Refer to "Threat actor".
(Threat actor) Capability	Resources and skills of a threat actor.
Cyber risk	The risk to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other organizations, and the nation due to the potential for unauthorized access, use, disclosure, disruption, modification, or destruction of information and/or information systems. Source: NISTIR 7298 3Glossary of Key information Security Terms
Cybersecurity	Cybersecurity is defined as the collection of tools, policies, security concepts, security safeguards, guidelines, risk management approaches, actions, training, best practices, assurance, and technologies that can be used to protect the Member Organization's information assets against internal and external threats.
Cyber threat intelligence (CTI)	Threat information that has been aggregated, transformed, analyzed, interpreted, or enriched to provide the necessary context for decision-making processes. Source: NISTIR 7298 3Glossary of Key Information Security Terms
(Cybersecurity) Incident	An occurrence that actually or potentially jeopardizes the confidentiality, integrity, or availability of an information system or the information the system processes, stores, or transmits or that constitutes a violation or imminent threat of violation of security policies, security procedures, or acceptable use policies. Source: NISTIR 7298 3Glossary of Key Information Security Terms
indicator of Compromise (loC)	Indicators of compromise serve as forensic evidence of potential intrusions on a host system or network.
(Threat actor) Intent	The desire of a threat actor to target a particular entity. Threat actors are usually rational actors operating with a clear purpose (e.g. espionage, data theft/exfiltration, extortion, destruction, disruption, supply chain compromise).
Kill Chain	Adopted from the military, the kill chain was developer by Lockheed Martin to identify and taxonomize the various phases of a cyber attack (Reconnaissance, Weaponization, Delivery, Exploitation, Installation, Command and Control, Actions upon Objectives).
Malware	Hardware, firmware, or software that is intentionally included or inserted in a system for a harmful purpose. Source: NISTIR 7298 3Glossary of Key information Security Terms
MITRE ATT&CK	An open source framework developed by MITRE taxonomizing tactics, techniques, and procedures used by threat actors when conducting cyber attacks.
Member Organization	Any regulated entity supervised and regulated by SAMA.
Modus Operandi	A method of procedure, especially referred to a distinct pattern or method of operation that indicates or suggests the work of a single criminal in more than one crime.
Motivation	The type of benefit or harm a threat actor ultimately wants to achieve with its actions.
Network	Information system(s) implemented with a collection of interconnected components. Such components may include routers, hubs, cabling, telecommunications controllers, key distribution centers, and technical control devices. Source: NISTIR 7298 3Glossary of Key Information Security Terms
Open Source Intelligence (OSINT)	Relevant information derived from the systematic collection, processing, and analysis of publicly available information in response to known or anticipated intelligence requirements.
Organization	Company, entity, or group of people that works together for a particular purpose.
(Threat actor) Origin	Country from which the threat actor launches its attacks. The origin of a threat actor cannot always be determined with sufficient precision because they tend to cover their tracks.
Procedure	Procedures are the specific implementation the threat actor uses for techniques. Source: MITRE ATT&CK
Process	A set of interrelated or interacting activities which transforms inputs into outputs.
Ransomware	A form of malware designed to deny access to a computer system or data until ransom is paid. A user of a system infected with ransomware is usually confronted with an extortion message (in many cases a windows popup) asking the victim to pay a ransom fee to the threat actor (usually in cryptocurrency) in order to regain access to their system and data.
Red team (exercise)	An exercise, reflecting real-world conditions, that is conducted as a simulated adversarial attempt to compromise organizational missions and/or business processes to provide a comprehensive assessment of the security capability of the information system and organization. Source: NIST SP 1800 21B Glossary of Key Information Security Terms
(Threat actor) Resources	Resources measure the scope, intensity, sustainability, and diversity of the total set of actions that a threat actor can take.
Sector	One of the areas in which the economic activity of a country is divided.
Service	A capability or function provided by an entity. Source: NISTIR 7298 3Glossary of Key Information Security Terms
(Threat actor) Skill	The extent to which a threat actor is able to leverage technical means (e.g. create custom malware) and operates with awareness, intelligence, learning potential, problem solving, decision-making coherence, and operational experience.
Stakeholder	One who is involved in or affected by a course of action.
Strategic threat intelligence	The level of threat intelligence focused on objectives, motivations and intents of cyber threat actors. It aims at examining attributions to cyber threat actors, investigating real motivations and links between cyber events, and understanding complex systems dynamics and trends. Geopolitical, sectorial and context analysis is a fundamental tool.
Tactic	The threat actor's tactical goal: the reason for performing an action. Source: MITRE ATT&CK
(Threat actor) Target	The choices that actors make in terms of the target(s) of their attacks. A threat actor selects a target based on location, sector, and the types of information processed and attack surface available. The geopolitical landscape plays a key role in the targeting pattern of nation state actors.
Taxonomy	A classification of interrelated elements.
Technique	Techniques represent "how" a threat actor achieves a tactical goal by performing an action. Source: MITRE ATT&CK
(Cyber security) Threat	Any circumstance or event with the potential to adversely impact organizational operations, organizational assets, individuals, other organizations, or the nation through an information system via unauthorized access, destruction, disclosure, modification of information, and/or denial of service. Source: NISTIR 7298 3Glossary of Key Information Security Terms
Threat actor	Individuals, groups, organizations, or states that seek to exploit the organization's dependence on cyber resources (i.e., information in electronic form, information and communications technologies, and the communications and information-handling capabilities provided by those technologies)" (NIST 2012) or, more in general, "An individual or a group posing a threat" (NIST 2016).
Threat landscape	A collection of threats in a particular domain or context, with information on identified vulnerable assets, threats, risks, threat actors and observed trends. Source: ENISA
Threat intelligence requirement	Threat intelligence requirements guide the intelligence production effort efficiently and establish what intelligence should be produced to meet the security objectives of an Organization.
(Threat actor) Type	Grouping of threat actors who share similar characteristics, such as similar intents and motivations, and operate in similar ways.
Unified Kill Chain	An evolution of the kill chain framework detailing the phases of an attack.
(Attack) Vector	General approach for achieving an impact, taking advantage of the exposure of a type of, or a region in, an attack surface.

Annex B. Areas of Analysis

Member Organizations should develop threat intelligence requirements based on different areas of analysis which are relevant to their business priorities. These areas of analysis may vary depending on Member Organizations including but not limited to:
	Geopolitics: this includes requirements to identify geopolitical events that might determine a cybersecurity attack within the scope of analysis, such as large global campaigns carried out by threat actors, significant past relevant cybersecurity incidents, etc.
	Threat actor: this includes requirements to identify the main threat actors on which the organization should be particularly focused on.
	Threat vectors: this includes requirements to identify relevant attack techniques (e.g. initial access vectors, etc.).
	Technology: this includes requirements to evaluate possible attacks against technologies that the organisation rely upon.
	Industry: this includes requirements to identify possible attacks against industries relevant to the organization (e.g. third parties in the supply chain or national critical infrastructure).

Annex C. Types of Sources

The following tables contain examples of internal and external sources.

Sources
Type of sources
	Public sector	Threat intelligence provided by SAMA and the National Cybersecurity Authority (NCA)	National civil or government bodies (e.g. law enforcement)	Reports or information from other sectorial or national authorities (e.g. CMA, FS-ISAC, Saudi CERT)	Public frameworks (e g. ENISA, EUROPOL, MITRE)
External sources	Private sector	Threat intelligence from specialized suppliers and platforms available upon subscription or contract	Publicly available threat intelligence reports, news, briefs and analyses
	Academic sector	Whitepapers	Academic publications and conferences	Academic journals

Table 1. External sources

Sources

Type of sources

Internal
sources

Application and infrastructure logs

Intrusion Detection System (IDS)

Intrusion Prevention System (IPS)

Cyber security defence systems

Table 2 Internal sources

Annex D. Types of Intelligence

Currently, there is a wide range of different kinds of intelligence that could be used to obtain a holistic understanding of the threats that an organization faces.
These types of intelligence include:
		OSINT: open source intelligence obtained from publicly available sources (e.g. Threat report, blog, etc.)
		TECHINT: technical intelligence derived from signals generated routinely by hardware devices or software applications connected to an organization's network (e.g. loCs, malware analysis, code reports, etc.)
		SOCMINT: social media intelligence, a process of identifying, gathering, validating, and analyzing data from social media sites and accounts (e.g. Blogs, microblogs, social networks, etc.)
		HUMINT: human intelligence derived overtly or covertly from human sources based on a relationship between an intelligence analyst and the analyst's handler (e.g. active monitoring on forums)
		Deep and Dark Web Intelligence: intelligence gathered on the deep and dark web (e.g. marketplaces, forums, etc.)

Annex E. Threat Intelligence Delivery Methods

Member Organizations should establish the delivery mechanism of the threat intelligence produced which includes, but is not limited to:
		Cyber threat bulletins including cyber threat information that may be useful for the organizations
		Simple alerts sent out by phone, text, or email
		Detailed reports enriched with analysis, tables, numbers, graphics, and multimedia
		Machine-readable data feeds based on a proprietary or open standard structured threat intelligence notation, for Security Information and Event Management (SIEM), anti-virus software, firewalls, intrusion prevention systems (IPS), intrusion detection systems (IDS) and forensic tools
		Custom-designed output for in house systems
		Application Programming Interfaces (APIs) enabling direct system connection for the purposes of intelligence query or retrieval
		Secure online portals providing on-demand access to an up-to-date threat intelligence database and range of analytical functions that could be as basic as from simple queries to more complex data mining

Annex F. Intelligence Standard Operating Procedures

Below are listed some examples of how SOPs should help users when performing specific kind of threat intelligence.
When performing deep and dark web intelligence, the step-by-step instructions should help users in identifying all the elements needed to properly conduct it, including but not limited to:
		Using a controlled isolated and untraceable environment such as a Virtual Machine (VM)
		Update and collect a list of deep web and dark web forums and marketplaces
		Create various avatars for access
Similarly, when performing Social Media Intelligence (SOCMINT), the step-by-step instructions should help in identifying all the elements needed to properly conduct it, for example:
		Providing users with a list of different types of sources and continuously updating this list (e.g. Blogs, microblogs, social networks, images, video, and discussion forums)
		Conduct training on Social network and online video hosting and sharing platform (e.g. Twitter, Facebook, YouTube etc.)
		Using social media tools when possible (commercial and open-source)
In the same way, when performing human intelligence (HUMINT), the step-by-step instructions should help users in identifying all the elements needed to properly conduct it, including but not limited to:
		Conduct ethics training for analysts performing active engagements online
		Implement SOPs related to forum and marketplace accesses
		Build an avatar for each access to avoid traceback
		Understanding the difference between active and passive monitoring

Annex G. Analytical Approach

Member Organizations should adopt an analytical approach so the intelligence produced meets the intelligence requirements.
Based on what is most suitable for the Member Organizations, the analytical approach could be:
		Hypothesis-driven: this approach includes the definition of a hypothesis and its evaluation by analyzing available information
		Analyst-driven: this approach is based on the analyst's critical and analytical thinking
		Contrarian: this approach aims at challenging the main conclusions or points made by the source to put forward a counter-argumentative approach

Annex H. CTI Principles High Level Graph
Below is represented a high-level graph of the CTI principles. The graph is aimed at representing the high-level structure of the document.

Annex J. CTI Principles Mind Map
Below is represented a mind map of the structure of the CTI principles. The graph is aimed to clearly represent the different domains of the document and how the principles are related to each other.

Minimum Verification Controls
No: 202200000245 Date(g): 21/4/2022 | Date(h): 20/9/1443 Status: In-Force

1. Introduction
While digital innovation is creating major opportunities for the businesses and consumers, at the same time it is also presenting new dimension of emerging threats and changing the traditional view of the cyber risk. To enable member organizations regulated by SAMA to effectively identify and address cyber risks, in addition to the SAMA regulations, SAMA defined a set of controls that must be adopted and implemented by the member organization in order to maintain adequate protection of information assets and digital services.

2. Statement of Applicability
The controls mentioned in this document applies to any member organization that provide E-wallet, lending products, crowdfunding or other fintech business model under SAMA supervision taking into consideration the applicability of the requirements meeting the required objectives.

3. Registration/Onboarding Controls

3.1.	Member Organization should ensure registration for each phone number (or) National ID/Iqama, is linked to one application only.
3.2.	Member Organization should establish a secure process to validate users.
3.3.	The registration process should include the following:
	a.	For lending platforms: Strong form of authentication from an independent trusted party¹.
	b.	For E-wallet platforms: Strong form of authentication from an independent trusted party i.e. (National Single Sign-On (NSSO)) by using user name, password, and OTP.
	c.	For other business model, robust controls should be implemented in the registration/onboarding process taking into considerations the concept mentioned in points (3.3.a-b).
3.4.	Member Organization should verify that the ownership of the phone number is registered to the same user (i.e. match name & national ID) through trusted party only (i.e. Tahaqaq).
3.5.	Member Organization should ensure the registration process includes one-time-password mechanism (OTP) as a form of verification. The (OTP) must be send to a verified phone number as per point (3.4).
3.6.	Member organizations should implement session timeout controls for all issued (OTP)s.
3.7.	SMS notification should be sent to the users for registration, device re-registration or change in the status of account such as deactivation, reactivation and inactive.
3.8.	Member Organization application should be assigned to one- device only. Otherwise, an (OTP) should be implemented for each login, as well as disabling concurrent login.
3.9.	Member Organization should develop effective and secure process for account deactivation, reactivation and device re-registration to authenticate the user.

¹ Trusted party: Any party licensed to perform the activity in question

4. General Controls

4.1.	Member organization should implement regulatory SAMA cybersecurity requirements.
4.2.	Member Organization should use official application stores.
4.3.	Member Organization should develop installation restriction mechanism for privilege escalation devices such as “Jailbreak” for iOS and “Root” for Android or any open source operating system, taking into consideration that the application is installed through official stores..
4.4.	Member organization should have contingency measures in case of disaster and ensure effective back-up and recovery procedures.
4.5.	Terms & Conditions should cover data privacy taking into consideration customer consent to display name of account owner.
4.6.	Member Organization should conduct awareness program to all users on regular basis that should cover Terms & Conditions and general security awareness such as sharing confidential information (password or OTP).
4.7.	Member Organization should develop inactive accounts policy.
4.8.	Multi Factor Authentication (MFA) should be implemented to authenticate each log in.
4.9.	One-time-password mechanism (OTP) should be implemented for the following processes:
	a.	Transfer between wallet to wallet (for the first time as minimum for each beneficiary) below (Defined Value)²;
	b.	Making any application marketplace transaction;
	c.	Payment of bills, utility and government services (for the first time as minimum for each bills);
	d.	Password reset;
	e.	Wallets reactivations;
	f.	Risky transactions based on company assessment and use cases.
4.10.	One Time Password in one channel and using different delivery channel should be used for following transactions:
	a.	Any transaction between wallets exceeding (Defined Value) as a daily limit (for first time as minimum for each beneficiary)
	b.	transfer to IBAN (for first time as minimum for each beneficiary)
	c.	international transfer (for first time as minimum for each beneficiary)
	d.	high risk transactions based on company assessment and use cases
4.11.	SMS notification should be sent to users for all transactions and user account changes.
4.12.	Member Organization should consider the use of comprehensive use cases and scenarios tailored for their business model to combat fraud; including but not limited to:
	a.	Monitoring the behavior of all users to detect any anomalies based on best practices;
	b.	Managing device usage behavior;
4.13.	Member Organization should establish process to handle fraud cases taking into the consideration investigation and deactivation accounts steps.
4.14.	Member Organization should develop a process to safeguard “Data Privacy” and “Data Security” of these accounts. Such information includes “Displaying name of account owner”.
4.15.	Member Organization should ensure the content of the SMS messages is clear, direct, stating the purpose for the SMS and the name of the Member Organization
4.16.	Member Organizations should reflect all controls within this document within their board approved internal policies in their respective organizations, and should have a process in place for periodic review of the polices.

² Defined value will be circulated in the memo. The value will be reviewed periodically and officially communicated if changed.

5. Lending Application Special Controls

The controls below should be implemented by lending companies in addition to the above mention controls.
5.1.	Member Organization should have process implemented to assure the recipient IBAN belongs to the loan requester.
5.2.	Member Organization should use a trusted and authorized digital signature provider.(see appendix A for additional details)
5.3.	Ensure a process is implemented to securely create, save and manage promissory note by using national trusted party (e.g. Nafith)
5.4.	Member Organization should implement a process to call the customer to confirm the loan request.
5.5.	SMS notification should be sent with customer when:
	a.	User submitted the request.
	b.	When the loan request is approved or denied.

6. Appendix A - Overview Previous Issued SAMA Circulars

This document Supersedes the following previously issued SAMA circulars:
		E-Wallet Security Controls v1.0
This document refers to the following SAMA circulars or documents which is mandated as per issued memo:
		Regarding Digital signature for products of Finance companies, 42011675, 1442/02/27;

Business Continuity Management Framework
No: 381000058504 Date(g): 27/2/2017 | Date(h): 1/6/1438 Status: In-Force
Based on SAMA's keenness to improve the level of practices regarding the subject of business continuity in the event of accidents or disasters - God forbid - through the existence of an effective, applied and tested mechanism in the bank based on the best solutions and practices that provide a mature environment to ensure business continuity without interruption of important services and business disruption, we inform you that SAMA has developed and issued a regulatory guide for business continuity management for the banking sector (attached), which the bank / bank must fully comply with what is stated in this Guide by following the following procedures:
First: Assessing the current status of business continuity in the bank compared to the requirements contained in the regulatory manual (Gap Assessment) to identify weaknesses in the bank, provided that a roadmap is developed to comply with the requirements of SAMA after assessing the current situation and sending it to SAMA no later than the end of May 2017.
Second: Providing SAMA with quarterly reports starting from the end of the second quarter until the bank's compliance with the requirements of SAMA.
Third: Full commitment to the application of all the requirements contained in the manual by the end of January 2018.
In case of any inquiries in this regard, you can contact the Director of the Banking Information Technology Risk Division at SAMA.

1. Introduction

1.1 Introduction to the BCM Framework
Considering the need of 24 x 7 availability of the business operations by financial institutions in the Kingdom of Saudi Arabia, SAMA has developed a Business Continuity Management (BCM) framework for member organizations that would enhance the organizational resilience capability to ensure continuity and availability of their operations and services. The requirements are based on SAMA requirements, industry practices and international standards, such as ISO 22301, ISO 27001, Good practice guidelines from BCI, and Professional practice guidelines from DRII. All Member Organizations are required to comply with these requirements and integrate it formally in their BCM program.

1.2 Definitions
- BCM is a holistic management process that identifies potential threats to an organization and the impacts to business operations those threats, if realized, might cause. It provides a framework for building organizational resilience with the capability for an effective response that safeguards the interests of its key stakeholders, reputation, brand and value-creating activities.
- BCM is part of the overall management system, which includes organizational structure, policies, planning activities, responsibilities, procedures, processes and resources that establishes, implements, operates, monitors, reviews, maintains and improves business continuity.
- IT Disaster recovery (IT DR) is part of BCM which includes policies, standards, procedures and processes pertaining to resilience, recovery or continuation of technology infrastructure supporting critical business processes.
- Maximum Acceptable Outage (MAO) is defined as the time that would take for adverse impacts which might arise because of not providing a product/service or performing an activity, to become unacceptable.
- Recovery Time Objective (RTO) is defined as the period following an incident within which, products or services must be resumed, activity must be resumed, or resources must be recovered.
- Recovery Point Objective (RPO) is defined as the point to which, information used by an activity must be restored to enable the activity to operate on resumption. This can also be termed as "Maximum Data Loss".

1.3 Scope
The BCM framework document defines principles, objectives and control considerations for initiating, implementing, maintaining, monitoring and improving business continuity controls in member organizations.
The BCM framework document is applicable to the full scope of the Member Organization, including subsidiaries, employees, subcontractors, third-parties and customers.
The BCM framework document has an interrelationship with other corporate policies for related areas, such as enterprise risk management, health, safety and environment (HSE), physical security, cybersecurity (including cyber resilience and incident management).

1.4 Applicability
The BCM Framework document is applicable to following:
- All organizations affiliated with SAMA ("the Member Organizations")
- All banks operating in Saudi Arabia
- All banking subsidiaries of Saudi banks
- Subsidiaries of foreign banks situated in Saudi Arabia

1.5 Responsibilities
SAMA mandates the BCM framework requirements document to Member Organizations. This document outlines the BCM requirements to be implemented by the Member Organizations. SAMA is the owner and is responsible for periodically updating the BCM Framework document. The Member Organizations are responsible for adopting and implementing the requirements stated in this framework document.

1.6 Interpretation
SAMA, as the owner of the BCM framework requirements document, will provide interpretations of the principles, objectives and control considerations, if required.

1.7 Target Audience
This document is intended for board of directors, CEOs, chief risk officer, senior and executive management, business owners, owners of information assets, CIOs, CISOs, business continuity managers, internal auditors and for those, who are responsible for and involved in defining, implementing and reviewing business continuity controls.

1.8 Review, Changes and Maintenance
This document will be reviewed and maintained by SAMA. SAMA will review this document periodically to determine its effectiveness, including the effectiveness of the framework to address emerging business continuity threats and risks. If applicable, SAMA will update this document based on the outcome of the review.
If a Member Organization considers that an update to this document is required, the Member Organization should formally submit the requested update to SAMA after obtaining approval from the business continuity manager and business continuity steering committee within the Member Organization. SAMA will review the requested update, and when approved, this document will be updated.
Version control will be implemented for maintaining this document. Whenever any changes are made, the preceding version should be retired and the new version should be published and communicated to all Member Organizations.

1.9 Reading Guide
The BCM Framework represents the actual BCM domains and subdomains, principles, objectives, and control considerations.

2. Business Continuity Requirements

2.1 BCM Governance

Principle
The business continuity governance framework should be defined, approved, implemented and maintained, which should be monitored by senior management. The business continuity structure should be defined and communicated to all relevant employees and third parties.
Objective
To direct, control and evaluate the overall approach to business continuity within the Member Organization
Control Consideration:
1.	Board of directors or a delegated executive member should have the ultimate responsibility for the BCM program.
2.	The board of member organization, or a delegated member of senior management should allocate sufficient budget to execute the required BCM activities,
3.	A BCM Committee should be established and mandated by the board of directors.
4.	Senior management, such as CRO, COO, CIO, CISO, BCM manager and other relevant departments should be represented in the business continuity committee.
5.	A business continuity committee charter should be developed and should reflect:
	a.	Committee objectives
	b.	Roles and responsibilities
	c.	Minimum number of meeting participants
	d.	Meeting frequency (minimum on quarterly basis)
6.	A BCM function should be established.
7.	A BCM manager/head should:
	a.	Be appointed
	b.	Have appropriate authority to manage the BCM program
	c.	Be qualified and have appropriate experience, skills and competencies to implement and maintain the BCM program within the member organization
8.	The BCM function should be adequately staffed with qualified team members
9.	Cross-functional teams, consisting of strategic, tactical and operations team members should contribute in implementation and maintenance of the business continuity and disaster recovery plans.

2.2 BCM Strategy

Principle
A business continuity strategy should be defined and aligned with the Member Organization's overall strategic business objectives.
Objective
To ensure that business continuity Initiatives are in alignment with the strategic business objectives and embeds BCM as part of the good management practice within the Member Organization, in order to continual improvement In maturity.
Control Consideration
1.	The business continuity strategy should be defined, approved, implemented and maintained.
2.	The strategy should at minimum define:
	a.	Long-term strategic objectives for implementing and maturing the BCM program
	b.	Road map with timelines for achieving strategic objectives
	c.	Requirements for continual review and validation of alignment of the BCM program with strategic objectives

2.3 Business Continuity Policy

Principle
A business continuity policy should be defined, approved and communicated to relevant stakeholders.
Objective
To document the Member Organization’s commitment and objective of the business continuity program, and to communicate this to the relevant stakeholders.
Control considerations
1.	A business continuity policy should be defined, approved, implemented and communicated
2.	The business continuity policy should at the minimum identify:
	a.	Objectives
	b.	Scope
	c.	Responsibilities
3.	The compliance with the business continuity policy should be monitored .
4.	The effectiveness of policy implementation should be measured and periodically evaluated.
5.	Scope exclusions for the BCM should be documented and periodically evaluated. The justifications for scope exclusions should be documented and approved by BCM committee and senior management.

2.4 Business Impact Analysis (BIA) and Risk Assessment (RA)

Principle
The Member Organization should perform a business impact analysis and risk assessment for all relevant activities to determine the business continuity, and disaster recovery requirements and improvements.
Objective
To ensure that each Member Organization has Identified and prioritized their business processes along with key dependencies, and identified adequate controls in order to fulfill their business, regulatory, legal and compliance requirements with regards to business continuity
Control considerations
1.	Methodology for BIA and RA should be defined, approved, implemented and maintained.
2.	The Member Organization should periodically perform a Business Continuity risk assessment. It should include, but not limited to:
	a.	Identify potential internal and external threats, Including single point of failures that may cause disruption to critical activities as determined in the BIA considering people, process, technology and premises
	b.	Assess and prioritize potential risks by evaluating potential threats based on their operational impact and probability of occurrence
	c.	Select required controls to manage identified risks
	d.	Define treatment plan and implement BCM controls
3.	The Member Organization should identify and prioritize the activities (Le., products, services, business functions and processes) by performing BIA to determine the following but no limited to:
	a.	The potential impact of business disruptions for each prioritized business function and processes, including but not restricted to financial, operational, customer, legal and regulatory impacts
	b.	The recovery time objectives (RTOs), recover/ point objectives (RPOs) and maximum Acceptable Outage (MAO)
	c.	The internal and external interdependencies
	d.	Supporting recovery resources
4.	The BCM committee should endorse the prioritized list, BIA results, RA and the defined RTOs, RPOs and MAOs.
5.	Risk assessment results should be communicated to the BCM committee
6.	The BIA and RA should be updated annually and when major changes occur (such as change in structure and organization of people, process, technology, suppliers and locations).
7.	The risk assessment should include risks associated with overall organization as well as data centers (primary and alternative), which are not owned by the Member Organization (e.g., consider the timeframe needed to relocate to a new site and accordingly, It should Include a sufficient timeframe in the contractual agreement)
8.	Capability of vendors, suppliers and service providers to support and maintain service levels for prioritized activities during disruptive incidents should be assessed at least on a yearly basis.
9.	Member Organizations should ensure that RTOs are adequately defined for payment systems, customer related services, etc. considering the high availability of these operations and minimum disruption in the event of disaster.

2.5 Business Continuity Plan (BCP)

Principle
The Member Organization should define, approve and Implement BCP for their critical activities. The compliance with BCP should be monitored, and the effectiveness should be measured and periodically evaluated.
Objective
To ensure that the Member Organization has the capability to identify and clearly define the actions to be taken, and resources which are needed to enable the organization in managing a disruptive interruption and to come back to a position where normal business processes can resume
Control considerations
1.	A BCP should be defined, approved, implemented and maintained in readiness for use during disruptive incidents, to enable the Member organization to continue delivering its important and urgent activities, at an acceptable pre-defined level.
2.	The member organization should define, approve and implement procedures for responding to disruptive incidents. The procedures should collectively include:
	a.	Key resources (e.g., people, equipment, facilities, technologies)
	b.	Defined roles, responsibilities and authorities for stakeholders
	c.	A process to manage the immediate consequences of a disruptive incident and escalation procedures
	d.	A process to continue the critical activities within predetermined recovery objectives (RTO, RPO and MAO)
	e.	A process to resume the Member Organization's operations to business-as-usual once the incident is resolved
	f.	Guidelines for communicating with employees, relevant third-parties and emergency contacts
	g.	Process for including relevant cyber security requirements, if any, within the business continuity planning
3.	The compliance with the BCP should be monitored.
4.	The effectiveness of the BCPs should be measured and periodically evaluated.
5.	The BCM Manager and BCM coordinators are responsible to maintain and keep the BCPs and arrangements up-to-date.
6.	The Member Organization should have sufficient alternative business workspace(s) where it can relocate the required resources to deliver the critical processes required as per predefined recovery objectives in the BIA.
7.	The alternative business workspace(s) should have clear demarcation of the sitting arrangement for different business units.
8.	The Member Organization should implement sufficient logical, physical and environmental security controls in order to support the same level of access and security in case the alternative location needs to be activated.
10.	For all critical activities, as determined by the BIA, the Member Organization should ensure that the key service providers (if any) have a BCP in place and their plans tested at least on a yearly basis.

2.6 IT Disaster Recovery Plan (DRP)

Principle
The Member Organization should define, approve, implement and maintain a IT DRP for its critical activities and related technology infrastructure.
Objective
To ensure the Member Organization has IT DRP and up-to-date list of critical activities in place, in case of a disruptive incident
Control considerations
1.	An IT DRP to recover and restore technology services and infrastructure components (Data, systems, network, services and applications) should be defined, approved, implemented and maintained in alignment with business impact analysis.
2.	The Member Organization should establish an alternative data center at an appropriate location. The location should be identified based on:
	a.	A risk assessment to confirm that the location does not share the same risks of the main data center (e.g., geographical threat)
	b.	Upon approval from SAMA
3.	Data, system, network and application configurations, and capacities in the alternative data center should be commensurate to such configurations and capacities maintained in the main data center.
4.	Member Organization should implement the same logical, physical, environmental and cyber security controls for the alternative data center as for the primary data center.
5.	The Member Organization should define and implement a backup and recovery process.
6.	The Member Organization should have offsite location for storing backups.
7.	Formal contracts should be signed with third parties to ensure the continuity of outsourced services or delivery of replacing hardware or software within the agreed timelines in case of a disaster. Include guidelines to ensure that the contracts signed with external service providers are aligned with the BIA and RA outcomes.
8.	The IT manager should be responsible to maintain and keep the disaster recovery plans and arrangements up to date with an overall accountability of integration within the BCM Program on the BCM Manager.
9.	The compliance with the disaster recovery plan should be monitored.
10.	The effectiveness of the IT DRP should be measured and should be evaluated on a yearly basis as minimum.

2.7 Cyber Resilience

Principle
The Member Organization should ensure that critical services, business functions and processes run on reliable and robust infrastructure and software.
Objective
To ensure each that the Member Organization's critical services, business functions and processes are available when required and resistant to disruptions.
Control considerations
1.	All changes to the infrastructure and software, which directly support the identified critical services, business functions and processes, should:
	a.	Be subject to in-depth risk assessments to ensure the agreed business requirements regarding availability and recovery are met.
	b.	Follow strict development, testing and change management procedures to avoid single point of failures or malfunctioning.
2.	A periodic architectural review should be defined and approved to ensure the business requirements regarding availability and business continuity are being correctly addressed and implemented.
	Note. For more control considerations to improve the overall resilience, e.g., threat management, vulnerability management, please refer to the SAMA - Cyber Security Framework.

2.8 Crisis Management Plan

Principle
The Member Organization should define, approve and implement a crisis management plan that would facilitate a well-managed response for major incidents, including rapid communication to ensure overall safety to both internal and external stakeholders.
Objective
To ensure the Member Organization has effective crisis management plan in place and up-to-date for critical member organization products, services, business functions and processes, in case of a disruptive incident.
Control considerations
1.	A crisis management plan should be defined, approved and implemented.
2.	The compliance with the crisis management plan should be monitored.
3.	The effectiveness of the business continuity program within the crisis management plan should be measured and periodically evaluated.
4.	The Member Organization should document a crisis management plan(s) that define(s) how crisis resulting from a major incident(s) will be addressed and managed, and should include at least:
	a.	Criteria for declaring a crisis.
	b.	The member organization should establish a command center for centralized management and an emergency command center.
	c.	Crisis-management team members. Considering representatives of the critical products, services, functions and processes of the Member Organization (including Communications department)
	d.	Contact details of those who are part of the crisis management team (including third-parties)
	e.	Definition of the steps to be taken during and after a crisis or disaster (including the mandates required)
	f.	Communication plan including the media response plan, to address the communication with the internal and external stakeholders during crisis.
	g.	The frequency of crisis management tests

2.9 Testing

Principle
The Member Organization should define, approve, implement, execute and monitor regular BCP and DRP tests to train their employees and third-parties and test the effectiveness of the BC and DR plans.
Objective
To ensure that the Member Organization's existing BCP and DRP do work as defined and employees and third- parties are trained to execute these plans.

2.9.1 BCP Testing

Control considerations
1.	The Member Organization should periodically conduct BCP simulation test exercises ("at least once a year")
2.	The tests should consider appropriate scenarios that are well planned with clearly defined objectives (e.g., per function, per service, per process, per location, per worst cases scenarios). The Member Organization should take into consideration to Include cyber security scenarios.
3.	Defined test scenarios should cover the activation and involvement for crisis management team.
4.	After the completion of the above individual tests, each Member organization should consider conducting an integrated BCM test for all critical services, business processes and functions.

2.9.2 DRP Testing
Control considerations
1. The Member Organization should periodically execute a DR test combined with BCP ("at least once a year").
2. The Member Organization should conduct an evaluation of the executed DR test of IT DR infrastructure that supports the Member Organization's critical systems to ensure the readiness and capability of DR to resume critical business operations for a period of time in case of a major disaster.
3. The DR test results should provide an evaluation and suggestions for improvements to manage disruptive events impacting the Member Organization's business continuity.
4. It should cover the activation and involvement of the crisis management team.

2.9.3 Executed Tests

1.	Detailed results of all exercises and tests should be documented for future reference. The exercises/tests results should include, but not be limited to the following considerations:
	a.	Confirm meeting the objectives of the exercised plan
	b.	Confirm capabilities and readiness of recovery resources
	c.	Document lessons learnt and the required improvements
	d.	In case of failure, Capture the root-cause of the failure and remediation actions should be tracked to successful conclusion
2.	Re-testing of the plan within the defined timelines in case of a failure, the timelines should not exceed the limit of three (3) months.
3.	The Internal Audit of the Member Organization, or a qualified external auditor, should observe the business continuity and disaster recovery testing activities as an independent participant in order to provide a reasonable assurance on the executed activities, test results and to observe if the executed tests are meeting the Member Organization's overall Business Continuity program objectives.
4.	All BCP and DRP tests results should be reported to the BCM committee, senior management and the board of directors.

2.10 Awareness and Training

Principle
The Member Organization should establish, Implement and maintain a training and awareness program that effectively supports the BCM objectives by developing the required competency among staff.
Objective
The Member Organization should ensure BCM integration into its day-to-day activities, through an ongoing awareness plan, which should be documented.
Control considerations
1.	The Member Organization and relevant third-parties, such as providers and suppliers should be:
	a.	Familiar with relevant parts of business continuity policy and plans
	b.	Contractually bound to provide their services or products within the agreed time, in case of disruptive event
	c.	Familiar with their point of contact or their local BCM coordinator in the Member Organization
	d.	Familiar with their roles and responsibilities during disruptive incidents
2.	A training program should be provided once on an annual basis to employees involved in BCM to achieve the required level of experience, skills and competences.
3.	The Member Organization should periodically measure the effectiveness of the training and awareness program.

2.11 Communication

Principle

The Member Organization should define, establish and maintain a communication process for periodic communications with SAMA on matters related to its BCM program.

Objective

To ensure that continuous communication is maintained with SAMA by defining, agreeing and adhering to communication protocol, frequency, and roles and responsibilities for communications

Control considerations

The Member Organization should report all disruptive incidents classified as "Medium" or "High" to SAMA "Banking IT Risk Supervision" immediately. A post-incident report should be communicated to SAMA after the Member Organization resumes to normal operations.
The Member Organization should coordinate with SAMA Supervision when communicating with the media in case of incidents.
Member Organizations should seek SAMA's approval when selecting a new site for its main or alternative data center, or when relocating the current main or alternative data center.
The Member Organization should communicate the approved program for executing business continuity and disaster recovery tests, for the upcoming year, with SAMA "Banking IT Risk Supervision" by end of January of every year.
Test results of business continuity and disaster recovery should be shared with SAMA within four weeks after the test The Member Organization should identify the improvements based on the test performed and provide an action plan to SAMA within two months after the submission of the test results.

2.12 Periodic Documents Review

Principle

The business continuity and disaster recovery program, policies, plans and procedures should be reviewed and updated periodically, and in case of (major) change in the Member Organization's critical products, services, business functions and/or processes.

Objective

To ensure that all the business continuity documents are up to date and can be used during a disruptive incident to recover the business operations.

Control considerations

Member Organizations should establish a process for document review/update to ensure the BC documents are up-to-date, reviewed and approved.
All documents should clearly identify the last date in which the document was reviewed and approved.

2.13 Assurance

Principle

The BCM of the Member Organizations should be subjected to periodically reviews and audits by a qualified independent internal or external party to ensure its effectiveness, and to obtain assurance regarding the compliance with the SAMA BCM.

Objective

To ensure that an independent party is reviewing the BCM framework activities and reporting the identified issues to the senior management independently.

Control considerations

Member organization should conduct review / audit of BCM by qualified independent internal/ external party.
the Member Organization should identify the gaps and provide a road map to enhance the BCM within the organization.
The identified gaps along with road map should be reported to senior management and BCM committee.

Financial Entities Ethical Red-Teaming
No: 562240000067 Date(g): 13/5/2019 | Date(h): 9/9/1440 Status: In-Force
Referring to the Cybersecurity Strategy of the Central Bank*, which aims to enhance the readiness and security of the financial sector against cyberattacks, and in continuation of the Central Bank's commitment to governance through cybersecurity regulatory guidelines, we inform you of the Central Bank's adoption of the Financial Entities Ethical Red Teaming Framework. This framework has been developed based on best practices and international experiences. Its aim is to improve the ability of financial institutions to counter and respond to attacks by creating realistic scenarios to test the resilience of system infrastructures and enhance the cybersecurity resilience of the financial sectors in the Kingdom. The regulatory framework will be shared via email with the compliance departments of financial institutions.
Accordingly, and based on the Central Bank's regulatory and supervisory role over the financial sector, we inform you that the Central Bank will conduct periodic tests to apply the aforementioned framework to financial institutions to assess the readiness of their systems. The Central Bank also urges financial entities to independently and periodically conduct tests, evaluate the readiness of their systems, and work on their development in accordance with the requirements of the Cybersecurity Framework.
For any inquiries in this regard, you may contact the Financial Sector IT Risk Supervision Department or the Financial Sector Information Security Division at the Central Bank.
*The "Saudi Arabian Monetary Agency" was replaced by the "Saudi Central Bank" in accordance with The Saudi Central Bank Law No. (M/36), dated 11/04/1442H.

1 The Saudi Arabian Financial Entities Ethical Red Teaming Framework

1.1. Introduction
It is crucial that the Member Organizations within the Financial Sector are resilient against the newest and most advanced cyber-attacks.
The Financial Entities Ethical Red Teaming Framework (F.E.E.R.) is intended as a guide for Member Organizations within Saudi Arabia in preparing and executing controlled attacks (i.e. threat intelligence based red teaming tests) against their (live) production environment without exposing sensitive information with the help of certified and experienced Red Teaming Providers.
The Saudi Central Bank* (SAMA) has a leading role in the implementation of this Framework. This Framework and associated processes will be continuously improved using the feedback and lessons learned from each red teaming exercise. This framework aims for sharing of intelligence and information obtained during such testing in order to further improve the cyber resilience of the Saudi Arabian Financial Sector.
Red Teaming should not be regarded as an Audit. It is a simulation test, which seeks to provide insight into the level of resilience and effectiveness of the implemented cyber security controls and relevant processes (i.e. detection and response).
Red Teaming is not a penetration test. In contrast to a penetration test (in which one or more specific information assets are tested and assessed), it focuses on replicating a targeted and realistic attack against the entire Member Organization performed in a controlled manner.
The Red Teaming Provider will use the latest attack tactics, techniques and procedures (i.e. TTPs) in an attempt to compromise the Member Organization, aiming to reach the member organizations most important and valuable information assets and to test the detection and response capabilities of the Member Organization. The Red Team consists of certified and experienced ethical hackers with in-depth knowledge of all security domains.
* The "Saudi Arabian Monetary Agency" was replaced By the "Saudi Central Bank" in accordance with The Saudi Central Bank Law No. (M/36), dated 11/04/1442H, corresponding to 26/11/2020G.

1.2. Objective of the Framework
The principal objective of the framework is to provide guidance on how to conduct the red teaming activities and how to test the detection and response capabilities of the Member Organization against real sophisticated and advanced attacks and enhance the knowledge of the involved stakeholders. Likewise, the Framework aims to support the sharing of threat intelligence and lessons learned with the Member Organizations that will contribute to the cyber resilience of the Saudi Arabian Financial Sector.
The Framework will ensure that the red teaming exercise is executed in a controlled manner. This is important given the nature of the targets during the testing, namely business critical and (live) production systems (i.e. critical information assets).

1.3. Applicability
The Framework applies to all Member Organizations in the Financial Sector, which are regulated by SAMA. SAMA has the authority to select any Member Organization and request the organization to perform a red teaming test considering the emerging threat landscape or based on the latest threat intelligence. In addition, member organization can rightfully conduct red teaming tests in order to ensure security resilience.

1.4. Responsibilities
The framework is mandated by SAMA. SAMA is the owner and is responsible for periodically updating the Framework.

1.5. Interpretation
SAMA, as the owner of the Framework, is solely responsible for providing advice on the interpretation of the principles, objectives and considerations, if required.

1.6. Periodicity of the Red Teaming Tests
Each Member Organization within the Financial Sector of Saudi Arabia and are regulated by SAMA should be tested, as a minimum once every three (3) years, in line with this framework.

1.7. Target Audience
The Framework is intended for Senior and Executive Management, business owners, owners of information assets, CISOs and those who are responsible for (or involved in) defining, implementing and reviewing cyber security controls within the Financial Sector and tasked with the improvement of the cyber resilience of the Member Organization.

1.8. Review, Updates and Maintenance
The framework will be maintained by SAMA and reviewed periodically to determine the framework's effectiveness, including the extent to which it addresses emerging cybersecurity threats and risks. If applicable, SAMA will update the Framework based on the outcome of the review and lessons learned.

1.9. Additional Information
For any further information or enquiries about the Saudi Arabian Financial Entities Ethical Red Teaming Framework, please contact IT Risk of Financial Sector Supervision Department.

2 Background
More and more governments, national agencies and regulators consider the protection of their national or sector-wide critical infrastructure as a high priority on their national cyber security agenda. In order to test the cyber resilience of the critical infrastructure, governments, agencies and regulators are increasingly embracing red teaming approaches. These red teaming approaches are generally underpinned by a framework which outlines how red teaming tests should be conducted, how to identify the organizations which should be considered part of the key or core infrastructure and the periodicity or frequency of these tests.
In a red teaming test, an organization performs a ‘simulation' of a realistic cyber-attack. The Red Teaming Provider, consisting of certified and experienced ethical hackers, will execute / simulate cyber-attacks based on available threat intelligence and attack scenarios, which aims to test the cyber resilience of an organization.
The cyber security attacks are cautiously modelled and tested, and will simulate a malicious attacker - using their attack approach - from the reconnaissance activities up to the actual compromise of the critical information asset(s). The simulation of these (attack) steps are executed and tested during a red teaming test and will provide vital insights into the organization's resilience against cyber-attacks.

2.1 Stakeholders
The stakeholders within the red teaming exercises have different roles and corresponding responsibilities. Irrespective of role, it is important that everyone is aware that any form of testing is performed in a controlled manner, and that a communication protocol is agreed regarding the sharing of information among the stakeholders. The relevant stakeholders are:
1. SAMA IT Risk of Financial Sector Supervision department - The authority that has primary responsibility for overseeing the Red Teaming exercise.
2. The Member Organization - Each Financial Organization within the Financial Sector of Saudi Arabia and regulated by SAMA.
3. The Security Operations Centre - The SOC positioned within the Member Organization, which will be subject to the red teaming test.
4. The Red Teaming Provider - An external certified party, which has been selected to perform the red teaming exercise and provide required national or sector threat intelligence to define scenarios.
5. Available Member Organization committees (e.g. Banking Committee for Information Security - BCIS) - Relevant results of executed red teaming tests, lessons learned, and threat Intelligence might be shared within this committee, in an appropriately sanitized form using the agreed communication protocol, to support the increase of the overall cyber resilience of the (financial) sector.

2.2 Required Teams
For the execution of the red teaming exercise, the following teams should be established:
Green Team
SAMA IT Risk of Financial Sector Supervision department provides the Green Team. The Green Team appoints the Test Manager for each red teaming test. The Test Manager is responsible for guiding and supporting the White Team through the red teaming exercise. The Green Team approves the selection of Red Teaming Provider and provides - when applicable - additional or specific threat intelligence for the Financial Sector.
White Team
Within the Member Organization, the White Team should be appointed (including a White Team Leader), who will be responsible for the controlled execution of the red teaming exercise. The White Team consist of a limited number of security and business experts which are the only staff members that are aware of the red teaming test and who are the single-point-of-contacts (SPOCs), e.g. CISO. They will monitor the test and intervene when needed, e.g. when the test or results of the test are likely to, or have, caused a critical impact, compromise or service disruption.
The overall number of staff members that should be involved in the engagement, should be limited to maximum five (5) people, to avoid a too wide disclosure of the intended cyber-attack simulation and - as a result - that the effectiveness of the exercise is limited or flawed.
Blue Team
The cyber security monitoring team of the Member Organization (e.g. SOC) which monitors and analyses the generated security alerts and events to identify security breaches or flaws. It is the task of the Blue Team to detect the malicious activities (of the Red Team) and to follow the agreed incident response procedures the moment an incident is detected. The Blue Team should never be informed about the test and are expected to follow their standard operating procedures, in order to simulate a realistic attack.
Red Team
The Red Team, a selected third party that executes the attack scenarios and consists of certified and experienced specialists. The Red Team will work with the Green Team and White Team to develop the potential threats and attack scenarios. The Red Teaming Provider is also responsible for providing the latest threat intelligence related to the Financial Sector in order to achieve a certain level of assurance that the Member Organization is tested against the latest known (sophisticated) cyber-attacks.
Please refer to Appendix A-Requirements for Red Teaming provider, for more details on Red Teaming provider requirements.

2.3 Penetration Testing Versus Red Teaming

There is a significant difference between red teaming exercise and penetration testing. Red teaming focusses on testing the cyber resilience of an organization. In a penetration test, the scope is often limited to an application or system, with the intent to comprehensively test the security of that limited scope application or system.

The overall objective of a red teaming exercise is different from the objective of a penetration test. In a red teaming exercise, the objective is to (independently) test the overall cyber resilience of a Member Organization. This is achieved by testing the implemented cyber security controls, along with the detection and response capabilities.

A secondary objective is to share the lessons learned with the Member Organizations within the Financial Sector, to further improve the overall cyber resilience within the sector.

Penetration testing	versus	Red Teaming
Gain oversight of vulnerabilities	Goal	Test the resilience against realistic attacks
Predefined subset	Scope	Realistic access paths
Focus on preventive controls	Tested controls	Focus on detection and response
Focus on efficiency	Test method	Focus on realistic simulation
Mapping, scanning and exploiting	Test techniques	Tactics, Techniques and Procedures (TTPs)
Very limited	Post-exploitation	Extensive focus on critical assets or functions
Parts of development lifecycle	Recurrence	Periodical exercise

Figure 1 Difference between penetration testing and red teaming

2.4 The Cyber Kill Chain Methodology
The Cyber Kill Chain¹ provides a conceptual model to describe an attack. The term “chain” reflects the end-to-end process adopted by an attacker.

The Cyber Kill Chain provides a good insight into how an attack works and where the different tools and methods employed at each stage. To lower the risk of a successful attack, defensive measures (e.g. preventive, detective and responsive and corrective) should be considered and taken for each of the steps of the kill chain to reduce the probability of being compromised and improve the resilience of the Member Organization.

The following seven (7) stages characterize an advanced cyber-attack in the cyber kill chain:

Figure 2 Seven stages of a cyber-attack, with the red team and blue teams main tasks
1. Reconnaissance:
  The first stage is about selecting a target and gathering information about the target to determine attack methods. This happens before the attack is executed. Examples of useful information can be: names, phone numbers, email addresses, functions, private or professional areas of interest of employees on the internet and published information about the software that an organization is using.
2. Weaponize:
  The attacker creates the malicious payload/file for a specific target based upon information retrieved during the reconnaissance stage. The attack can come in many different formats and is based upon the creativity of the attacker, the available set of defenses and the possible vulnerabilities.
3. Delivery:
  The transmission of the crafted attack to the victims by the use of different means, such as: email (attachments), phishing, websites, physical devices or social engineering.
4. Exploitation:
  Triggering or activating the malicious payload/file (i.e. malware) will result in a successful penetration of the target's system and network. A staged malware attack limits the possibility of detection. The malware will communicate back to the malicious attacker over a secure channel, which limits the chance of detection. Attackers usually use popular methods and file formats to deliver the malware executables (e.g. Microsoft office files, pdf files, malicious websites, phishing emails and removable media).
5. Installation:
  The actual installation of malicious payload/file or software that supports the malicious attacker. In order to make the malware and backdoor(s) persistent, the attackers could install additional malware or malicious software tools to ensure that the attack can continue if the initial compromised system or active malware is disabled.
6. Command and Control:
  A compromised system will usually connect back to the attacker, to establish a so-called command-and- control channel, which allows remote control of the malware. Especially in advanced persistent threat (APT) malware, the attacker will control the malware and explore the network by using this type of remote access.
7. Actions on Objective:
  After the attacker completed his malicious actions or achieved his goals, the attacker will try to cover his digital tracks and traces by using different techniques, like data exfiltration, or will use the compromised system as starting point to ‘hop on' to other systems in the network (i.e. lateral movement), to search for other high value assets or targets.
¹ Computer scientists at Lockheed-Martin corporation developed and described the "intrusion kill chain" framework to defend computer networks in 2011.

2.5 Threat intelligence
The Red Teaming Provider(s) will maintain and deliver the threat intelligence landscape relevant for Saudi Arabian Financial Sector or specific Member Organization. This can be enriched using the provided input from SAMA (i.e. the IT Risk of Financial Sector Supervision department, or the Green Team), the White Team and, various governmental agencies. The Red Teaming Providers should provide the latest threat intelligence related to the Financial Sector in order to achieve a certain level of assurance that the Member Organization is tested against the latest known (sophisticated) cyber-attacks.

2.6 Overview of the Phases
The Saudi Arabian Financial Entities Ethical Red Teaming Framework consists of four phases. In the corresponding chapters of this framework, each phase is described in detail.

Please refer to Appendix C-Glossary for more details and definitions regarding this Framework.

3 Preparation Phase

3.1 Overview
The Green Team initiates the preparation phase of the red teaming exercise by appointing a Test Manager. A Backup Test Manager should also be nominated given the importance of this role.
The Test Manager is responsible for contacting the Member Organization to explain the red teaming concept and processes. The Test Manager will invite the Member Organization to appoint and formalize their White Team and start contracting the Red Teaming Provider.
The White Team Leader initiates a kick-off session, where all relevant stakeholders (i.e. Green, White and Red Team) are invited to align the ambition and objectives of the red teaming exercise.

3.2 Green Team: Determining Test Manager
The Test Manager is a crucial person during the Red Teaming exercise. This person should have extensive experience in project management and in-depth understanding of the banking and cyber security sector.
The Test Manager of the Green Team should invite the Member Organization to appoint a White Team. During the entire red teaming exercise, the White Team will keep close contact with the Test Manager.
The Test Manager will oversee the Red Teaming exercise and will provide support, guidance and reflections to ensure that the entire Red Teaming exercise performed by the White Team and Red Teaming Provider is in line with the Framework. As the Test Manager is not a formal part of the White Team, he cannot be held accountable for any actions or consequences.

3.3 Selecting a Red Teaming Provider
The Green Team will appoint the red team provider, who are pre-selected to execute the Red Teaming tests, based on their experiences and skilled staff. Given the fact, that these ethical hacking tests are carried out on the live production systems, it is crucial that the Red Teaming Provider has a proven track record and has the required skills, expertise, certifications and experienced staff to perform the red teaming test.
Please refer to Appendix A- Requirements for Red Teaming provider, for more details on Red Teaming provider requirements

3.4 Determining White Team
The Member Organization should carefully establish a White Team and nominate a White Team Leader in order to facilitate, oversee and lead the red teaming exercises during all phases. The White Team Leader's role is to make sure that the entire Red Teaming exercise is performed in a controlled manner, on behalf of the Member Organization. After establishing the White Team, the White Team Leader needs to coordinate with the appointed Red Teaming Provider for contract and invite the Red Teaming Provider to the kick-off meeting.

3.5 Procuring a Red Teaming Provider

Upon approval of the Red Teaming Provider by the Green Team, the Member Organization should initiate their procurement process. During the procurement of the Red Teaming Provider, the Member Organization should undertake the following activities:

Agreeing on contractual considerations, e.g. Non-Disclosure Agreement (NDA) clauses, the liability for any consequence flowing from the test, and a Letter of Authorization (LOA);
Introduce the Red Team members to the White and Green Team.

Please refer to Appendix A- Requirements for Red Teaming provider, for more details on Red Teaming provider requirements

After the procurement of the Red Teaming Provider, the White Team should start involving the Red Teaming Provider and its identified staff, to ensure their experience and input is fully utilized and that the staff of the Red Teaming Provider is introduced into the business model and services of the Member Organization.

3.6 Defining the Scope
During a kick-off session with all relevant stakeholders (Green, White and Red Team), the scope and the target critical information assets (i.e. ‘red flags') should be defined for the attack scenarios. Moreover, the planning of the project is discussed in detail along with the responsibilities for each team. Deliverables and contractual considerations should be discussed during the session. The White Team should determine the flags that should be targeted or attacked.
The Red Teaming Provider will share their advice and recommendations to the White and Green Team based on their (previous) experience in order to support the scoping discussion.
Boundaries, limitations and escalation procedure for the red teaming test should be discussed and defined by the White Team with mutual understanding with the Green Team. Another important step is to agree on the liability for the actions of the Red Teaming Provider (see also 3.5).
The White Team should create a Scoping document. This document should contain contact details of the White Team members and the identified flags (i.e. defined goals or target systems) during the red teaming exercise. This document also contains the overall plan for the exercise, predefined escalation procedures and communication protocols (including the code-name for the test).
Once the scope is defined by the White Team, the Scoping document should be submitted to the Green Team for approval.

4 Scenario Phase

4.1 Overview
At the beginning of this phase, the Green and White Team should independently provide their available Threat Intelligence (TI) to the Red Team. The Red Teaming provider will combine the received Threat Intelligence, with their own Threat Intelligence (which should be based on their own sources, their experience and earlier executed tests). Based on the combined threat intelligence the Red Team determines the attack scenarios and strategies. These attack scenarios and strategies are than discussed with the Green Team before defining the detailed attack Tactics, Techniques and Procedures (TTPs). If necessary, a discussion with Red and White Team should be initiated to further discuss and agree on the final attack scenarios in the light of Green Team comments.

The scenario phase usually takes several weeks (maximal five (5) weeks). An overview of the process is depicted below:

4.2 Threat Intelligence Gathering
Each of the teams provides their collated threat Intelligence independently. The Green Team will provide (when available) their sector-wide threat intelligence which is known and available via the Member Organizations or incidents. This may include threat intelligence from governmental agencies, which could be relevant to the Member Organization. The White Team should provide the Member Organization's input including specific threat intelligence considered relevant for their business and linked to the internal or external trends or incidents, they identified.
The Red Teaming Provider will combine the received threat intelligence with their external threat intelligence (including and using their own ‘open' sources), and the intelligence gathered during various red teaming engagements.

4.3 Defining and Approval of High-Level Attack Scenarios
Based on all received threat intelligence, the Red Team should analyze, outline and create realistic attack scenarios and prepare a test strategy document. Once the scenarios are determined, the attack scenarios and test strategy should be agreed upon before the Red Teaming Provider starts with the creation of the specific attack scenarios.

4.4 Preparing and Approval of Detailed Attack Scenarios
The detailed attack scenarios should be mapped to one or more critical information assets combining the external, internal (i.e. Member Organization specific) and sector-wide threat intelligence. Each attack scenario should include a written description of the kill chain from the attacker's point of view. The Red Teaming Provider should indicate various attack options, based on various tactics, techniques and procedures (TTPs) used by experienced testers and attackers. As with the high-level attack scenarios and test strategy, the detailed scenarios have to be agreed with the Green Team.

4.5 Finalizing the Red Teaming Plan
The final red teaming plan should not only consist of the different attack scenarios that the Red Teaming Provider will perform, but also define the agreed escalation procedures and communication protocols. Given the fact that critical production systems are in scope for the red teaming test, the Red Teaming Provider should be aware and consider how to react in case of any unexpected issues or disruptions. After finalizing the red teaming plan, final approval by the White and Green Team is required before Red Teaming Provider can proceed with executing the attack scenarios.

5 Execution Phase

5.1 Overview
The phase starts with the Red Teaming Provider executing the attack scenarios. During the process, the White and Green Team should be updated regularly. All actions should be logged for evidence and replay purposes, with the Blue Team.

An overview of the process is depicted below:

5.2 Execute Red Teaming Plan
The Red Teaming Provider should start the execution of the red teaming exercise following the agreed scenarios and against the identified critical (information) assets or functions. It should be noted that the agreed scenarios do not have to be followed precisely as these are outline and may not reflect the precise operational environment encountered during the execution phase. Nevertheless, the Red Teaming Provider should inform the White Team Leader and Green Team about the suggested adjustments in the scenarios. Deviation from the initial scenarios should be allowed and is desirable if obstacles are encountered.
Red Teaming Provider should apply their expertise and ‘creativity' to develop alternative ways or workarounds in order to reach the identified critical (information) assets or functions. It is crucial that the Red Teaming Provider remains in close contact with both the Green and the White Team and does provide periodic updates on the progress made during the red teaming test - in line with the frequency which was agreed during the kick-off, or in case of escalations or severe incidents or occurrences - immediately.

5.3 Executing the Defined and Agreed Scenarios
If the Blue Team detects any events triggered by the Red Team while performing their actions, the Red Teaming Provider should decide in conjunction with the White Team Leader if the red teaming test can be continued in line with the initial plan or whether the initial attack plan can be adjusted.
The White Team Leader should consider the following options when the actions of the Red Teaming Provider are detected:
1. Stop or postpone the test in case there is a significant risk of a business disruption;
2. Carefully monitor and direct the Blue Team or response activities, in case extreme actions are about to be taken (i.e. reporting the incident to law enforcement, shutting down critical services to avoid to avoid further impact from the incident, ..Etc.);
3. Inform the Red Teaming Provider to continue with the initial attack scenarios;
4. Inform the Red Teaming Provider to revise the (detected) attack or to create a workaround for the specific critical information asset and continue with the revised attack scenario after approval from the White Team Leader;
5. Inform Green Team on the detection of events and decision on the exercise.
6. Request the Red Teaming Provider to re-engineer an alternate attack scenario for an adjusted critical information assets (e.g. change in scope).

5.4 Reporting

After completing the red teaming test, or stopping upon request of the White Team Leader, the Red Teaming Provider should prepare their initial observations and findings, preferably in chronological order. These observations and results should be discussed with the Green and White Team. These observations and findings provide the basis of evaluating the detection and response capabilities of the Blue Team. After the preliminary evaluation, the White Team should share their observations, from their respective role and point of view.

Note. After completing the red teaming test the Red Teaming Provider is required to immediately inform the White Team Leader of the installed red teaming scripts, code or malware, etc., including an overview the user-ids which were created, compromised or (re)used during the test. The White Team Leader needs to evidence to the Green Team that these ‘indicators of compromise' were removed or reset.

The White Team should include insights of what has and has not been detected or observed by the Blue Team. The Red Teaming Provider should use this information to overall assess and evaluate the Blue Team's detection and response capabilities in the draft report. The Red Teaming Provider should include all relevant observations, findings, recommendations and evaluations, which were noted or experienced during preparation, scenario and execution phase, including those from the White and Green Team. The provided recommendation should consider SAMA Cyber Security Framework and other applicable industry good practice.

The final report should include the exploited cyber kill chains, summarized in the form of attack vector diagrams. These attack vector diagrams should provide insights into how the attack scenarios were executed and where to focus on when implementing mitigating controls. The final report should be agreed upon by all Teams involved and copy of the report should be submitted to SAMA by the provider.

Please refer to Appendix B - Requirements for Reporting, for more details on Red Teaming Provider requirements.

6 Lessons Learned Phase

6.1 Overview
In this phase, the Red Teaming Provider should deliver the final red teaming report, which should contain the overall assessment of the Member Organization's resilience against targeted cyber-attacks.

The Blue Team should deliver the blue team report with their observations, findings and recommendations and should focus on the alerts and actions taken as part of the detection and response capabilities of the Member Organization.

Once the final red and blue team reports are distributed to all Teams. The White Team should invite the Red, Blue and Green Teams to participate in a (360 degrees) feedback session in which they share their observations and experiences for learning purposes (of the staff and management involved), to understand what capabilities need to be improved (e.g. prevent, detect and respond) and (enhancing) future exercises.

After the feedback session, a Replay Exercise should be organized, led by the Blue and Red Team. The objective of the joint Replay Exercise is to step through the red team exercise, discussing all the relevant actions and observations, highlighted from both angles, i.e. the Blue and Red Team.

The next step is the overall evaluation of the red teaming exercise processes itself. The outcome of the evaluation may contribute to vital information to enhance the Financial Entities Ethical Red Teaming Framework for future exercises.

The White Team should create a remediation plan based on the detailed observations and recommendations.

To ensure that all Member Organizations within the Financial Sector benefit from these red teaming exercises, an anonymized summary report of the executed red teaming test should be provided, and if required presented. The sharing of this report should be limited to the agreed with the closed community (i.e. addresses) and within the boundaries of the agreed communication protocol.

The duration of this phase is approximately four (4) weeks.

Based on the evaluations, feedback and sharing sessions SAMA should review, discuss and initiate adjustments to improve the current Framework, if required.

An overview of the Lessons Learned process is depicted below:

6.2 Debriefing
The Red Teaming Provider finalizes the red teaming report and presents the output to all the White and Blue Team. Simultaneously, the Blue Team should create a blue team report. The blue team report should provide the observations from the perspective of the Blue Team and should include the alert and events detected; the actions initiated and the result of these actions. The blue team reports should also provide the Blue Team's recommendations for improvements.
It is important that all teams (i.e. Green, White and Red) that were directly involved in the red teaming test provide their (360 degrees) feedback on the executed red teaming test. The White Team should initiate and schedule a joint replay session with all the teams.

6.3 Red and Blue Team Replay Exercise

After delivering the red and blue team reports, the White Team should organize a Replay Exercise. During this Replay Exercise, the Blue and Red Team jointly perform a chronological walkthrough of the red teaming exercise and the relevant alerts, events and attack steps that were initiated.
The purpose of the Replay Exercise is to explain and discuss each step and action individually to assess whether the alert or detected event lead to the expected actions. It is important to determine whether the initiated actions led to the expected results and whether the actions were correctly initiated or should be subject for improvement.
Replaying the red teaming exercise should ensure the more comprehensive (in-depth) understanding of the performed attack patterns, the current maturity of the detection and response capabilities and the implemented layered defenses or controls within the tested Member Organization.
Additionally, the White Team may repeat the replay exercise for specific target audiences within the Member Organization. It is strongly suggested to re-perform the replay exercise for:
a.	The relevant staff members within the IT organization - the scope of this session can be a very in-depth and technical session in order to provide the relevant insights in the technical and procedural aspects.
	Note. When the level of detail is insufficient or the attack steps cannot be demonstrated, then there con be a tendency for members within the IT organization to downplay these attacks or argue that the exercise is just theoretical.
b.	The Senior Management - a high-level replay session with the Senior Management should also seek to raise awareness and educate Senior Management. The replay session should provide an overview and objective of the red teaming exercise, an overview of the performed attacks and responses, an overview of the current detection capabilities and an overview of the suggested improvements required to further improve the cyber resilience.

6.4 Defining the Remediation Plan

The White Team should create a remediation plan based on the recommendations provided by the Red Team and Blue Team. The White Team should:

analyze the observations and recommendations;
determine the improvements regarding the detection and response capabilities;
determine the associated risks and priorities.

The White Team shares the internally agreed and approved remediation plan with the Green Team and periodically track the remediation progress to ensure that the vulnerabilities identified are monitored and mitigated.

Note; The Green Team should not actively share nor distribute the red and blue team reports, nor the evaluation reports, nor the remediation plan unless the Member Organization provides written permission.

As stated earlier, the primary objective of this Framework is exercising, learning and sharing.

6.5 Remediate Identified Vulnerabilities
Shortly after finishing the red teaming exercise, the Member Organization, i.e. the White Team should start executing the agreed remediation activities and address the identified vulnerabilities.
The Member Organization should be tracking the actual remediation progress to ensure the timely execution and delivery of the improved capabilities. The Member Organization should ensure that the Cyber Security Committee (and if required the Senior Management) is periodically updated on the progress of the planned remediation actions, and should request support when remediation activities do not progress as expected.

6.6 Sharing of the Lesson Learned
An important activity within the lesson-learned phase is to provide an anonymized summary report of the executed red teaming test, which might be shared with Members Organizations Committees like e.g. BCIS.

Sharing the summarized report and the lessons learned helps other Member Organizations build the knowledge and experience they need to improve their own cyber resilience.

Note. The sharing of the report and lessons learned should be limited to the agreed with the closed community (i.e. addresses) and within the boundaries of the agreed communication protocol.

By applying the lessons learned within their own Member Organizations the cyber resilience of the overall Saudi Arabian Financial Sector will improve, regardless of whether the Member Organizations are considered systematic for the sector, or not.

6.7 Enhancing the Red Teaming Framework
Based on the evaluations, feedback and lessons learned sharing sessions SAMA should review, discuss and initiate adjustments to improve the current Framework for future red teaming exercises.

Appendix A – Requirements for Red Teaming Provider

The following requirements should be considered when selecting and procuring a Red Teaming Provider.

Proven Red Teaming Experience and References
1.	The Red Teaming Provider should be able to show evidence of a solid reputation, history and business / professional ethics (e.g. a good business history, good feedback from both clients and providers, a reliable financial record and a strong history of performance);
2.	The number of credentials and references (i.e. large organizations) of successfully executed red teaming tests;
3.	The Red Teaming Provider should be able to show independent feedback on the quality of work performed and conduct of staff involved (internal accreditation);
4.	The Red Teaming Provider should be able to provide (anonymized) reports of earlier tests, preferably in the same or similar field of work and similar tests;
5.	The Red Teaming Provider should be able to demonstrate exploits or vulnerabilities found in other similar environments;
6.	The Red Teaming Provider should demonstrate and proof the certification and experience of the staff involved in the red teaming test(s) - see table below for more details;
7.	The Red Teaming Provider should have taken part in specialized industry events (such as those run by BlackHat or RSA Conference etc.) - this is optional but should be considered as an additional reference and experience.

Clearly defined and proven Red Teaming approach and methodology, process, governance, quality assurance and risk management
1.	The Red Teaming Provider should have a clearly defined process in place for red teaming tests and the related operations; these should describe the activities regarding: the preparation, scenario development, execution and lessons learned phases activities and requirements;
2.	Key element in Red Teaming Provider's approach should be the learning experience for the Blue Team and feedback session to improve the knowledge of the involved staff and departments and to mature the cyber security detection, response and recover processes and control measures and where required the prevention measures (e.g. security hardening);
3.	The Red Teaming Provider should be able to assist in creating and maintaining a knowledge base so that known weaknesses and lessons learned can be shared and improved within the Financial Sector;
4.	The Red Teaming Provider should have a verifiable quality assurance and escalation structure in place for their red teaming operations;
5.	All activities from the Red Teaming Provider should be reproducible (e.g. logging all activities);
6.	The Red Teaming Provider should adhere to a formal code of conduct overseen by an internal/external party;
7.	The Red Teaming Provider should be able to proof that it provides high quality services, including the methodologies, tools, techniques and sources of information that will be used as part of the red teaming and testing process;
8.	The Red Teaming Provider should be able to proof that results of tests are generated, reported, stored, communicated and destroyed in a way that does not put a Member Organization at risk;
9.	The Red Teaming Provider should ensure that no data leakage occurs from the testers laptops and systems and that all data obtained is securely stored during and securely destroyed after the engagement;
10.	Any (agreed) data exfiltration by the Red Teaming provider should be restricted to the extent just required to prove the attack scenario. This data should only be stored in encrypted format and locally (not at cloud providers).
11.	The Red Teaming Provider should assure the privacy of the staff within the Member Organization;
12.	The Red Teaming Provider should be able to provide a written assurance that the activities and risks associated with the red teaming test and that confidential information will be adequately addressed and performed in line with the security and compliance requirements of the Member Organization;
13.	A Letter of Authorization including non-disclosure terms should be mutually agreed between the Red Teaming Provider and the White Team to ensure that potential liability or legal issues are covered.
The Red Teaming Provider should consider the one or more of the following suggested certifications for its managers and testers, which will participate in the red teaming exercise. Verification of the certification of the staff and level of practical experience is key when selecting or procuring the Red Teaming Provider.

Recommended Certification(s) for the Red Teaming Provider’s Staff
Role	Institute	Certification
Managers	ISACA	Certified Information Systems Auditor (CISA) Certified Information Security Manager (CISM) Cybersecurity Nexus (CSX)
	(ISC)2	Certified Information Systems Security Professional (CISSP) Systems Security Certified Practitioner (SSCP)
	CREST	CREST Certified Simulated Attack Manager (CCSAM) CREST Certified Threat Intelligence Manager (CC TIM) – Optional
Testers	SAN Institute – GIAC	GIAC Penetration Tester (GPEN) GIAC Web Application Penetration Tester (GWART) GIAC Exploit Researcher and Advanced Penetration Tester (GXPN)
	Offensive Security	Offensive Security Certified Professional (OSCP) Offensive Security Wireless Professional (OSWP) Offensive Security Certified Expert (OSCE) Offensive Security Exploitation Expert (OSEE) Offensive Security Web Expert (OSWE)
	CREST	CREST Certified Simulated Attack Specialist (CCSAS) CREST Registered Threat Intelligence Analyst (CRTIA) - Optional

Appendix B – Requirements for Reporting
The following content should be considered when drafting the reports and providing the deliverables.

Note. All reports should only be provided via secure communication channels and shared under on agreed communication protocol (i.e. need-to-have and for-you-eyes-only).

Red Team Evaluation Report (RTER)

At the end of the red teaming exercise, the Red Teaming Provider will draft an evaluation test report, which contains an assessment of the Member Organization's cyber security resilience against the executed cyber security attacks. The report should include a diagram of how the attack scenarios were executed. This report should be issued to the White Team, Blue Team and Green Team.

Below the outline of the report and the required elements (not limitative):

Red Team Evaluation Report (RTER)
1.	Introduction
2.	Executive summary
3.	Scope
		Scope of the agreed red teaming test
		Background on the agreed targeted critical (information) assets and functions
		Goal and objectives of the red teaming test
		Items which were explicitly out-of-scope
4.	Control Framework - references
		F.E.E.R. Framework
		OWASP (Top-10)
		Others
5.	Execution Methodology
		Listing all the attack stages and actions performed by the Red Team during the red teaming test
		How the each attack scenario was conducted, how, when and where (i.e. the exploited cyber kill chains, summarized in the form of attack vector diagrams)
		Explanation of the Cyber Kill Chain methodology and Tactics, Techniques and Procedures that were planned and eventually executed
		The timeline of activities performed (dates and time)
		What specific tools or software and methods were used during the attack scenarios
		Methodology for the risk rating for the observations
6.	Observations
		Listing of the identified vulnerabilities and the weaknesses of events that did occur
		Observations focused on people, process and technology
		Observations focused on detection, response and recover
		Suggested risk description and risk rating for each observations
		Recommendations on suggested improvements
7.	Conclusions
		An overall conclusion of the cyber resilience of the Member Organization
		Detailed conclusions for each attack scenario performed
		A conclusion per agreed critical information assets or function
Appendices
		The list of involved teams and team members
		Screenshots with evidence
		Any other supportive materials
The report should be classified as: Confidential

Blue Team Report (BTR)

After the distribution of the Red Team Evaluation Report, the Blue Team will generate their own report. This report should be based on the monitoring and detection alerts, response and recover activities and process-steps taken by the Blue Team during the exercise. The report should include the defense and monitoring techniques and capabilities that the Blue Team is currently using to detect cyber security attacks (e.g. events, alerts, incidents). The report should also include the Blue Team's observations regarding the identified limitations or weaknesses.

Below the outline of the report and the required elements (not limiative):

Blue Team Report (BTR)
1.	Introduction
2.	Executive summary
3.	Background of the report
		Goal and objectives of the red teaming test
4.	Introduction into the financial sector current threat landscape and cyber-attack trends
5.	Explanation of the current incident handling, incident response and crisis management processes regarding cyber incidents within the Member Organization
		Process flows
		People/teams involved
		Overview of the relevant tasks and responsibilities
6.	Time line of the detected activities or generated alerts (against the performed red teaming exercise and activities)
7.	Observations per performed attack scenario (chronological)
		First notification(s) or s)
		The monitoring and defense tools and techniques used
		Incident response plan and steps performed (e.g. was the crisis management organization activated and what where the observations)
		Involvement of other departments (e.g. Help desk, CISO, CIO, HR, Legal, Public Relations)
		What where the results reported by the Red Team
		What went well or what can or should be improved
		Results of the root-cause analysis performed
8.	Recommendations or areas of improvement
		Recommendations focused on people, process and technology,
		Recommendations focused on detection, response and recover
		Suggested priority rating for each recommendation
		Roadmap for the suggested improvements
		Suggested input for upcoming cyber security awareness campaigns
9.	Conclusions
		An overall conclusion of the current cyber resilience state of the Member Organization
		The conclusions regarding the required and suggested improvements (from both the Blue and Red Team)
		Detailed conclusions for each attack scenario performed and the state of the current capabilities of the Blue Team
Appendices
		The list of involved departments, teams and team members
		Screenshots with supporting evidence
		Any other supportive materials
The report should be classified as: Confidential

Remediation Plan (RP)

The White Team should draft a Remediation Plan, which should be based on the Red Teaming Evaluation Report and the Blue Team Report. The remediation plan should provide clear areas of improvements, priorities and a roadmap how and when to improve the prevention (e.g. hardening), detection, response and recover capabilities within the Member Organization. Important is that the status and progress of the remediation plan is monitored and periodically reported to the Cyber Security Committee of the Member Organization as well as the Green Team.

Below the outline of the report and the required elements (not limitative):

Remediation Plan (RP)
1.	Introduction
2.	Executive summary
3.	Background of the remediation plan
		Goal and objectives of the remediation plan
4.	Target audience and stakeholders
5.	Agreed recommendations and areas of improvement provided by the Red and Blue Team
		Agreed recommendations focused on people, process and technology,
		Agreed recommendations focused on (prevention) detection, response and recover
		Agreed priority rating for each recommendation
6.	Prioritized list of the agreed areas of improvement
7.	Agreed Remediation Plan
		What, when, where, and how
		Overview of the persons-to-act (e.g. where possible involvement business management)
		Agreed due dates
8.	Roadmap for the agreed and prioritized improvements
9.	Frequency of updating the Cyber Security Committee of the Member Organization and the Green Team
10.	Project Management Organization
		People/teams involved
		Overview of the relevant tasks and responsibilities
Appendices
		The list of involved departments, teams and team members
		Screenshots with supporting evidence
		Any other supportive materials
The remediation plan should be classified as: Confidential / Internal Use Only

Red Teaming Test Summary Report (RTTSR)

When the Remediation Plan is finalized, the White team will generate a summary test report (fully anonymized) in order to share via SAMA (i.e. the Green Team Test Manager) to all relevant Member Organization Committees (e.g. the BCIS). The summary test report should cover the current threat landscape for the financial sector, the red teaming test results and the observed weaknesses or vulnerabilities during the red teaming test and should include the lessons learned.

This report should only be provided via a secure communication channel and shared under an agreed communication protocol (i.e. need-to-have and for-you-eyes-only).

Below the outline of the report and the required elements (not limitative):

Red Teaming Test Summary Report (RTTSR)
1.	Introduction
2.	Personalized distribution list (to ensure the agreed communication protocol)
3.	Executive summary
4.	Background of the executed red teaming test
5.	The financial sector current threat landscape and recent cyber-attack trends
6.	The outline of each attack scenarios executed
		Listing of the most relevant identified vulnerabilities and weaknesses
		Most relevant observations focused on people, process and technology
		Most relevant observations focused on detection, response and recover
7.	Lessons learned
8.	Suggestions for the Financial Sector
9.	Recommendations for adjusting the Saudi Arabian Financial Entities Ethical Red Teaming Framework
The Red Teaming Test Summary plan should be classified: Highly Confidential (need-to-have and for- you-eyes-only)

Appendix C - Glossary

Term	Description
Resilience	The ability to continue to: (i) operate under adverse conditions or stress, even if in a degraded or debilitated state, while maintaining essential operational capabilities; and (ii) recover to an effective operational posture in a time frame consistent with mission needs.
Cyber-attacks	An attack, via cyberspace, targeting an enterprise’s use of cyberspace for the purpose of disrupting, disabling, destroying, or maliciously controlling a computing environment/infrastructure; or destroying the integrity of the data or stealing controlled information. Ref (NIST SP 800-39 (CNSSI 4009) )
MO	Member Organization - Organizations affiliated with SAMA.
F.E.E.R.	The Financial Entities Ethical Red Teaming Framework
KSA	Kingdom of Saudi Arabia
Red Teaming	An exercise, reflecting real-world conditions, that is conducted as a simulated adversarial attempt to compromise organizational missions and/or business processes to provide a comprehensive assessment of the security capability of the information system and organization.
SAMA	The Saudi Central Bank*
Penetration test	Security testing in which evaluators mimic real-world attacks in an attempt to identify ways to circumvent the security features of an application, system, or network. Penetration testing often involves issuing real attacks on real systems and data, using the same tools and techniques used by actual attackers. Most penetration tests involve looking for combinations of vulnerabilities on a single system or multiple systems that can be used to gain more access than could be achieved through a single vulnerability. Ref (NIST SP 800-115)
TTPs	Tactics, Techniques and Procedures
Ethical hackers	An expert, performing a penetration test. Refer to ‘Penetration test’.
LoA	Letter of Authorization
BCIS	The Banking Committee for Information Security
CISO	Chief information security officer (CISO). A senior-level executive responsible for establishing and maintaining the enterprise cyber security vision, strategy, and program to ensure information assets and technologies are adequately protected.
Social Engineering	A general term for attackers trying to trick people into revealing sensitive information or performing certain actions, such as downloading and executing files that appear to be benign but are actually malicious. Ref: (NIST SP 800-114 )
Blue Team	A group of individuals that conduct operational network vulnerability evaluations and provide mitigation techniques to customers who have a need for an independent technical review of their network security posture. The Blue Team identifies security threats and risks in the operating environment, and in cooperation with the customer, analyzes the network environment and its current state of security readiness. Based on the Blue Team findings and expertise, they provide recommendations that integrate into an overall community security solution to increase the customer's cybersecurity readiness posture. Often times a Blue Team is employed by itself or prior to a Red Team employment to ensure that the customer's networks are as secure as possible before having the Red Team test the systems. Ref: (CNSSI 4009-2015 )
SOC	A security operations center (SOC) is a specialized location (and team) where security-related data from enterprise information systems (e.g., web sites, applications, databases, servers, networks, desktops and other devices) is monitored, assessed and actioned. The SOC is often dedicated to the detection, investigation and potential response to indicators of compromise. The SOC works closely with, and disseminates, collated security-related information to other areas of the organization (e.g., the cyber security function, incident management team and IT service owners).
Cyber kill chain	Contractual concept used to structure a cyber-attack.
White Team	The group responsible for referring an engagement between a Red Team of mock attackers and a Blue Team of actual defenders of their enterprise’s use of information systems. In an exercise, the White Team acts as the judges, enforces the rules of the exercise, observes the exercise, scores teams, resolves any problems that may arise, handles all requests for information or questions, and ensures that the competition runs fairly and does not cause operational problems for the defender's mission. The White Team helps to establish the rules of engagement, the metrics for assessing results and the procedures for providing operational security for the engagement. The White Team normally has responsibility for deriving lessons-learned, conducting the post engagement assessment, and promulgating results. Ref: (CNSSI 4009-2015 )
Green Team	The Green Team is provided by the SAMA MA Financial Sector Cyber Team. The Green Team appoints the Test Manager for each red teaming test. The Green Team also maintains a short list of potential Red Teaming Providers and provides the threat intelligence for the Financial Sector.
Test Manager	The Test Manager is responsible for a guiding the White Team through the red teaming exercise.
Risk	A measure of the extent to which an organization is threatened by a potential circumstance or event, and typically a function of: (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence. (NISTIR 7298r2 Glossary of Key Information Security Terms)
Exploit	A piece of code or a command, which purposes to perform malicious activities on a system, by taking advantage of a vulnerability.
Vulnerability	Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source. (NISTIR 7298r2 Glossary of Key Information Security Terms)
NDA	Non-disclosure agreement
Threat Intelligence	Threat intelligence is evidence-based knowledge, including context, mechanisms, indicators, implications and actionable advice, about an existing or emerging menace or hazard to assets that can be used to inform decisions regarding the subject's response to that menace or hazard. (Gartner)
RTP	Red Teaming Provider
Availability	Ensuring timely and reliable access to and use of information. (NISTIR 7298r2 Glossary of Key Information Security Terms)
NIST	The (U.S.) National Institute of Standards and Technology (www.nist.gov)
Incident	An occurrence that actually or potentially jeopardizes the confidentiality, integrity, or availability of an information system or the information the system processes, stores, or transmits or that constitutes a violation or imminent threat of violation of security policies, security procedures, or acceptable use policies. (NISTIR 7298r2 Glossary of Key Information Security Terms)

* The Saudi Arabian Monetary Agency was replaced by the name of Saudi Central Bank in accordance with The Saudi Central Bank Law No. (M/36), dated 11/04/1442H, corresponding to 26/11/2020G.

Information Technology Governance

Information Technology Governance Framework
No: 43028139 Date(g): 4/11/2021 | Date(h): 29/3/1443 Status: In-Force

1. Introduction

1.1 Introduction to the Framework
The current digital society has high expectations of flawless customer experience and continuous availability of services. The advancement of information technology ("IT") has brought rapid changes to the way businesses and operations are being conducted in the financial sector. Although IT plays an essential role combined with today's environment, it also exposes financial institutions to dynamically evolving IT risks.
In this regard, Saudi Arabia Monetary Authority ("SAMA") has established an Information Technology Governance Framework ("the Framework") to enable organizations regulated by SAMA ("the Member Organizations") to effectively identify and address risks related to IT. The objective of the Framework is as follows:
1. To create a common approach for addressing IT risks within the Member Organizations.
2. To achieve an appropriate maturity level of IT controls within the Member Organizations.
3. To ensure IT risks are properly managed throughout the Member Organizations.

1.2 Definition of Information Technology Governance
An Information Technology (IT) governance ensures the effective and efficient use of IT to enable Member Organizations to achieve its goals and objectives. It enables Member Organizations formulating optimal value from IT by maintaining a balance between realizing benefits and optimizing risk levels and resource use.

1.3 Scope
The framework defines principles and objectives for initiating, implementing, maintaining, monitoring and improving IT governance controls within Member Organizations regulated by SAMA. The framework offers IT governance controls requirements which are applicable to the information assets of the Member Organizations. Additionally, the framework provides direction for IT Governance requirements for Member Organizations and its subsidiaries, staff, third parties and customers. The framework should be implemented in conjunction with SAMA's Cyber Security and Business Continuity framework respectively (figure 1). For specific Cyber Security and Business Continuity related requirements please refer to SAMA's Cyber Security Framework and Business Continuity Management Framework.

Figure 1 -Relationship between SAMA Frameworks

The Framework has an interrelationship with other corporate policies for related areas, such as change management and staff training. This framework does not address the non-IT requirements for those areas.

1.4 Applicability
The framework is applicable to Member Organizations regulated by SAMA.

1.5 Responsibilities
The framework is mandated by SAMA and will be circulated to Member Organizations for implementation. SAMA is the owner and is responsible for periodically updating the framework. The Member Organizations are responsible for implementing and complying with the framework.

1.6 Interpretation
SAMA, as the owner of the framework, is solely responsible for providing interpretations of the principles and Control Requirements, if required.

1.7 Target Audience
The Framework is intended for senior and executive management, business owners, owners of information assets, CIOs and those who are responsible for and involved in defining, implementing and reviewing IT controls within the Member Organizations.

1.8 Review, Updates and Maintenance
SAMA will review the Framework periodically to determine the Framework's effectiveness, including the effectiveness of the Framework to address emerging IT threats and risks. If applicable, SAMA will update the Framework based on the outcome of the review.
If a Member Organization considers that an update to the framework is required, the Member Organization should formally submit the requested update to SAMA. SAMA will review the requested update, and when applicable, the Framework will be adjusted on the next updated version.
The Member Organization will remain responsible to be compliant with the framework pending the next version update.
Please refer to 'Appendix A - How to request an Update to the Framework' for the process of requesting an update to the Framework.
Version control will be implemented for maintaining the framework. Whenever any changes are made, the preceding version shall be retired and the new version shall be published and communicated to all Member Organizations. For the convenience of the Member Organizations, changes to the framework shall be clearly indicated.

1.9 Reading Guide
The Framework is structured as follows. Chapter 2 elaborates on the structure of the Framework, and provides instructions on how to apply the Framework. Chapter 3 presents the actual framework, including the IT domains and subdomains, principles, objectives and Control Requirements.

2. Framework Structure and Features

2.1 Structure

The Framework is structured around four main domains, namely:

Information Technology Governance and Leadership.
Information Technology Risk Management.
Information Technology Operations Management.

System Change Management.

For each domain, several subdomains are defined. A subdomain focusses on a specific IT governance topic. Per subdomain, the Framework states a principle and Control Requirements.

A Principle summarizes the main set of required IT controls related to the subdomain.
The Control Requirements reflects the mandated IT controls that should be considered.

The framework should be implemented in view of principles mentioned in per subdomains along with its associated Control Requirements.

Control Requirements have been uniquely numbered according to the following numbering system throughout the Framework:

Figure 2 - Control requirements numbering system

The figure below illustrates the overall structure of the Framework and indicates the IT Governance Framework domains and subdomains, including a reference to the applicable section of the Framework.

Figure 3 - Information Technology Governance Framework

2.2 Principle-Based
The framework is principle based, also referred to as risk based. This means that it prescribes key IT governance principles and objectives to be embedded and achieved by the Member Organizations. The list of mandated Control Requirements provides additional direction and should be considered by the Member Organizations in achieving the objectives. When a certain control requirement cannot be tailored or implemented, the Member Organizations should consider applying compensating controls, pursuing an internal risk acceptance and requesting a formal waiver from SAMA. Please refer to Appendix D for details for the - How to request Waiver from the Framework - process.

2.3 Self-Assessment, Review and Audit
The implementation of the framework at the Member Organizations will be subject to a periodic self-assessment. The self-assessment will be performed by the Member Organizations based on a questionnaire. The self-assessments will be reviewed and audited by Saudi Central Bank to determine the level of compliance with the framework and the IT maturity level of the Member Organizations. Please refer to ‘2.4 Information Technology Governance Maturity Model' for more details about the information technology governance maturity model.

2.4 Information Technology Governance Maturity Model

The Information Technology Governance maturity level will be measured with the help of a predefined maturity model. The information technology governance maturity model distinguishes 6 maturity levels (0, 1, 2, 3, 4 and 5), which are summarized in the table below. In order to achieve levels 3, 4 or 5, Member Organizations should first meet all criteria of the preceding maturity levels.

Maturity Level	Definition and Criteria	Explanation
0 Non-existent	No documentation. There is no awareness or attention for certain information technology control.	IT controls are not in place. There may be no awareness of the particular risk area or no current plans to implement such IT controls.
1 Ad-hoc	IT controls is not or partially defined. IT controls are performed in an inconsistent way. IT controls are not fully defined.	IT control design and execution varies by department or owner. IT control design may only partially mitigate the identified risk and execution may be inconsistent.
2 Repeatable but informal	The execution of the IT control is based on an informal and unwritten, though standardized, practice.	Repeatable IT controls are in place. However, the control objectives and design are not formally defined or approved. There is limited consideration for a structured review or testing of a control.
3 Structured and formalized	IT controls are defined, approved and implemented in a structured and formalized way. The implementation of IT controls can be demonstrated.	IT policies, standards and procedures are established. Compliance with IT documentation i.e., policies, standards and procedures is monitored, preferably using a governance, risk and compliance tool (GRC). Key performance indicators are defined, monitored and reported to evaluate the implementation.
4 Managed and measurable	The effectiveness of the IT controls are periodically assessed and improved when necessary. This periodic measurement, evaluations and opportunities for improvement are documented.	Effectiveness of IT controls are measured and periodically evaluated. Key risk indicators and trend reporting are used to determine the effectiveness of the IT controls. Results of measurement and evaluation are used to identify opportunities for improvement of the IT controls.
5 Adaptive	IT controls are subject to a continuous improvement plan.	The enterprise-wide IT governance program focuses on continuous compliance, effectiveness and improvement of the IT controls. IT controls are integrated with enterprise risk management framework and practices. Performance of IT controls are evaluated using peer and sector data.

Table 1 - Information technology governance Maturity Model

2.4.1 Maturity Level 3
To achieve level 3 maturity, a Member Organization should define, approve and implement IT controls. In addition, it should monitor compliance with the IT documentation. The IT documentation should clearly indicate "why", "what" and "how" IT controls should be implemented. The IT documentation consists of IT policies, standards and procedures.

Figure 4 - Information Technology Documentation Pyramid
The IT policy should be endorsed and mandated by the board of the Member Organization and stating "why" IT is important to the Member Organization. The policy should highlight which information assets should be protected and "what" IT principles and objectives should be established.
Based on the IT policy, IT standards should be developed. These standards define "what" IT controls should be implemented, such as, segregation of duties, back-up and recovery rules, etc. The standards support and reinforce the IT policy and are to be considered as IT baselines.
The step-by-step tasks and activities that should be performed by staff of the Member Organization are detailed in the IT procedures. These procedures prescribe "how" the IT controls, tasks and activities have to be executed in the operating environment.
The process in the context of this framework is defined as a structured set of activities designed to accomplish the specified objective. A process may include policies, standards, guidelines, procedures, activities and work instructions, as well as any of the roles, responsibilities, tools and management controls required to reliably deliver the output.
The actual progress of the implementation, performance and compliance of the IT controls should be periodically monitored and evaluated using key performance indicators (KPIs).

2.4.2 Maturity Level 4
To achieve maturity level 4, Member Organizations should periodically measure and evaluate the effectiveness of implemented IT controls. In order to measure and evaluate whether the IT governance controls are effective, key risk indicators (KRIs) should be defined. A KRI indicates the norm for effectiveness measurement and should define thresholds to determine whether the actual result of measurement is below, on, or above the targeted norm. KRIs are used for trend reporting and identification of potential improvements.

2.4.3 Maturity Level 5
Maturity level 5 focuses on the continuous improvement of IT controls. Continuous improvement is achieved through continuously analyzing the goals and achievements of IT governance and identifying structural improvements. IT controls should be integrated with enterprise risk management practices and supported with automated real-time monitoring. Business process owners should be accountable for monitoring the compliance of the IT controls, measuring the effectiveness of the IT controls and incorporating the IT controls within the enterprise risk management framework. Additionally, the performance of IT controls should be evaluated using peer and sector data.

3. Control Domains

3.1 Information Technology Governance and Leadership
Member Organizations board is ultimately responsible for setting the Information Technology (IT) Governance and ensuring that IT risks are effectively managed within the Member organization. The board of the Member Organization can delegate its IT Governance responsibilities to senior management or IT steering committee (ITSC). The ITSC could be responsible for defining the IT governance and setting the Member Organization's IT strategy.

3.1.1 Information Technology Governance

Principle

An IT Governance structure should be defined, endorsed and supported with appropriate resources to oversee and control the Member Organization's overall approach to Information Technology.

Control Requirements

1.	Member organizations should establish ITSC and be mandated by the board.
2.	The ITSC should be headed by senior manager responsible for Member Organizations operations.
3.	The following positions should be represented in the ITSC:
	a.	senior managers from all relevant departments (e.g., CRO, CISO, compliance officer, heads of relevant business departments);
	b.	Chief Information Officer (CIO); and
	c.	Internal Audit may attend as an "observer".
4.	An ITSC charter should be developed, approved and reflect the following:
	a.	committee objectives;
	b.	roles and responsibilities;
	c.	minimum number of meeting participants;
	d.	meeting frequency (minimum on quarterly basis); and
	e.	documentation and retention of meeting minutes and decisions.
5.	A full-time senior manager for the IT function, referred to as CIO, should be appointed at senior management level.
6.	The Member Organizations should:
	a.	ensure the CIO is a Saudi national;
	b.	ensure the CIO is sufficiently qualified; and
	c.	obtain a written no objection letter from SAMA prior to assigning the CIO.
7.	The Member Organizations should establish formal practices for IT-related financial activities covering budget, cost, and prioritization of spending aligned with IT strategic objectives.
8.	The overall IT budget should be monitored, reviewed periodically and adjusted accordingly to meet the IT and business needs.
9.	Member Organizations should define roles and responsibilities of senior management and IT staff using a responsibility assignment matrix, also known as RACI. The RACI matrix should outline who are responsible and accountable for the functions, as well as who should be consulted or informed.
10.	Member organizations should define enterprise architecture reflecting fundamental components of the business processes and its supporting technology layers to ensure responsive and efficient delivery of strategic objectives.
11.	Member Organizations should define enterprise application architect role within the IT function to identify the required changes to the portfolio of applications across the member organizations ecosystem.
12.	Roles and responsibilities within IT function should be:
	a.	documented and approved by the management; and
	b.	segregated to avoid conflict of interest.
13.	Member Organizations should develop formal IT succession plan in coordination with Human Resource (HR) Department taking into consideration the reliance on a key IT staff having critical roles and responsibilities.

3.1.2 Information Technology Strategy

Principle

An IT strategy should be defined in alignment with the Member Organization's strategic objectives and in compliance with legal and regulatory requirements.

Control Requirements

1.	IT strategy should be defined, approved, maintained and executed.
2.	IT strategic initiatives should be translated into defined roadmap considering the following:
	a.	the initiatives should require closing the gaps between current and target environments;
	b.	the initiatives should be integrated into a coherent IT strategy that aligns with the business strategy;
	c.	the initiatives should address the external ecosystem (enterprise partners, suppliers, start-ups, etc.); and
	d.	should include determining dependencies, overlaps, synergies and impacts among projects, and prioritization.
3.	IT strategy should be aligned with:
	a.	the Member Organization's overall business objectives; and
	b.	legal and regulatory compliance requirements of the Member Organization.
4.	IT strategy at minimum should address:
	a.	the importance and benefits of IT for the Member Organization;
	b.	the current business and IT environment, the future direction, and the initiatives required to migrate to the future state environment; and
	c.	interdependencies of the critical information assets.
5.	Member organization should identify IT strategic and emerging technology risks that may have impact on the achievement of overall organization wide strategic objectives.
6.	Member organization should enhance skill sets and expertise (operational and technical) of the existing resources through providing periodic training on emerging technologies and if required to have the relevant resources on boarded in line with member organization direction towards digitalization.
7.	IT strategy should be reviewed and updated periodically or upon material change in the Member Organizations operational environment, change in business strategy, objectives or amendment in laws & regulations.

3.1.3 Manage Enterprise Architecture

Principle

Enterprise architecture should be defined which outlines fundamental components of the business processes, data and supporting technology layers to ensure responsive and efficient delivery of Member organizations IT strategic objectives.

Control Requirements

1.	The enterprise architecture should be defined, approved and implemented.
2.	The compliance with the enterprise architecture should be monitored.
3.	The enterprise architecture should address the following, but not limited to:
	a.	a strategic outline of organizations technology capabilities;
	b.	outline the gaps between baseline and target architectures, taking both business and technical perspectives; and
	c.	agility to meet changing business needs in an effective and efficient manner.

3.1.4 Information Technology Policy and Procedures

Principle

IT policy and procedures should be defined, approved, communicated and implemented to set member organizations commitment and objectives to IT and communicated to the relevant stakeholders.

Control Requirements

1.	IT policy and procedures should be defined, approved, communicated, and implemented.
2.	IT policy and procedures should be reviewed periodically taking into consideration the evolving technology landscape.
3.	IT Policy should be developed considering input from relevant member organizations policies (e.g. cyber security, finance, HR).
4.	IT Policy should include:
	a.	the Member Organization's overall IT objectives and scope;
	b.	a statement of the board's intent, supporting the IT objectives;
	c.	a definition of general and specific responsibilities for IT; and
	d.	the reference to supporting IT (inter)national standards and process (where applicable).

3.1.5 Roles and Responsibilities

Principle

IT roles and responsibilities should be defined and all parties involved in the Member Organization's IT processes should have an adequate level of understanding of the expectations related to their role.

Control Requirements

1.	The board should be accountable for:
	a.	the ultimate responsibility for the establishment of IT governance practice;
	b.	ensuring that robust IT risk management framework is established and maintained to manage IT risks;
	c.	ensuring that sufficient budget for IT is allocated;
	d.	approving the IT steering committee (ITSC) charter; and
	e.	endorsing (after being approved by the ITSC):
		1.	the governance and management practices roles and responsibilities;
		2.	the IT strategy; and
		3.	the IT policy.
2.	ITSC, at a minimum, should be responsible for:
	a.	monitoring, reviewing and communicating the Member Organization's IT risks periodically;
	b.	approving, communicating, supporting and monitoring:
		1.	IT strategy;
		2.	IT policies;
		3.	IT risk management processes; and
		4.	key performance indicators (KPIs) and key risk indicators (KRIs) for IT.
3.	The CIO, at minimum, should be accountable for:
	a.	developing, implementing and maintaining:
		1.	IT strategy;
		2.	IT policy; and
		3.	IT budget.
	b.	ensuring that detailed IT standards and procedures are established, approved and implemented;
	c.	delivering risk-based IT solutions that address people, process and technology;
	d.	defining and maintaining specific key performance indicators (KPIs) and key risk indicators (KRIs) for IT process;
	e.	periodically inform ITSC on the latest developments on IT strategic initiatives and its implementation status;
	f.	implementing adequate technology to streamline all internal operations and help optimize their strategic benefits;
	g.	the IT activities across the Member Organization, including:
		1.	monitoring of the IT operation;
		2.	monitoring of compliance with IT regulations, policies, standards and procedures; and
		3.	overseeing the investigation of IT related incidents.
	h.	analyzing IT costs, value and risks to advise COO/Managing director; and
	i.	defining IT training plan in coordination with HR.
4.	The internal audit function should be responsible for:
	a.	the identification of comprehensive set of auditable areas for IT risk and performance of effective IT risk assessment during audit planning; and
	b.	performing IT audits.
5.	The enterprise application architect, at minimum should be responsible for:
	a.	developing of IT ecosystem application architecture models, processes and documentation;
	b.	developing enterprise level application and custom integration solutions including major enhancements and interfaces, functions and features; and
	c.	ensuring continuous improvement to transition between current and future states of the application architectures.
6.	All Member Organization's staff should be responsible for complying with applicable IT policy, standards and procedures.

3.1.6 Regulatory Compliance

Principle

Relevant regulations including data privacy should be identified, communicated and complied which are affecting IT operations of the Member Organizations.

Control Requirements

1.	Member Organizations should establish a process ensuring compliance with IT related regulatory requirements. The process of ensuring compliance should:
	a.	be performed periodically or when new regulatory requirements become effective;
	b.	involve representatives from key areas of the Member Organization;
	c.	result in the update of IT policy, standards and procedures to accommodate any necessary changes (if applicable); and
	d.	maintain an up-to-date log of all relevant legal, regulatory and contractual requirements; their impact and required actions.

3.1.7 Internal IT Audit

Principle

IT Audit should be conducted in accordance with generally accepted auditing standards and relevant SAMA framework (s) to verify that the IT control design is adequately implemented and operating as intended.

Control Requirements

1.	IT audits should be performed independently and according to generally accepted auditing standards and relevant SAMA frameworks.
2.	The Member Organizations should establish an audit cycle that determines the frequency of IT audits.
3.	Member Organizations should develop formal IT audit plan addressing people, process and technology components.
4.	IT audit plan should be approved by the Member Organization's audit committee.
5.	The frequency of IT audit should be aligned with the criticality and risk of the IT system or process.
6.	A follow-up process for IT audit observations should be established to track and monitor IT audit observations.
7.	Member Organizations should ensure that the IT auditors have the requisite level of competencies and skills to effectively assess and evaluate the adequacy of IT policies, procedures, processes and controls implemented.
8.	IT audit report, at a minimum, should:
	a.	include the findings, recommendations, management's response with defined action plan, and responsible party and limitations in scope with respect to the IT audits;
	b.	signed, dated and distributed according to the format defined; and
	c.	submitted to the audit committee on periodical basis.

3.1.8 Staff Competence and Training

Principle

Staff of the Member Organizations should be equipped with the skills and required knowledge to operate the Member Organization's information assets in a controlled manner and provided with training regarding how to operate, address and apply IT relevant controls on Member Organization's information assets.

Control Requirements

1.	Member Organizations should identify and define critical roles within IT department (e.g. DBA, sysadmin, etc.)
2.	Member Organizations should ensure adequate staffing for critical IT roles, such that critical IT roles are not handled by only one staff.
3.	Member Organizations should identify the professional certifications required for staff responsible for critical IT roles.
4.	Member Organizations should evaluate staffing requirements on periodic basis or upon major changes to the business, operational or IT environments to ensure that the IT function has sufficient resources.
5.	Annual IT training plan should be developed by the Member Organizations.
6.	Formal training should be conducted, as a minimum for:
	a.	IT staff (existing and new); and
	b.	Contractors (where applicable).
7.	IT training plan should be reviewed periodically.
8.	Specialist training should be provided to staff in the Member Organization's relevant functional area categories in line with their job descriptions, including:
	a.	staff involved in performing critical IT roles;
	b.	staff involved in developing and (technically) maintaining information assets; and
	c.	staff involved in risk assessments.

3.1.9 Performance Management

Principle

Efficiency and effectiveness of IT processes and services of the Member Organizations should be continuously measured through key performance indicators (KPIs).

Control Requirements

1.	KPIs should be defined, approved and implemented to measure the execution of IT processes and system performance.
2.	KPIs should be defined considering for the following, but not limited to:
	a.	IT function and related processes;
	b.	workforce competency and development; and
	c.	compliance with regulatory regulations.
3.	KPIs should be:
	a.	communicated to the concerned IT Divisions/Units of the Member Organizations for implementation;
	b.	supported by target value and thresholds;
	c.	analyzed to identify the deviations against targets and initiate remedial actions;
	d.	analyzed to identify trends in performance and compliance and take appropriate action; and
	e.	monitored and periodically reported to the senior management and ITSC.

3.2 IT Risk Management
IT Risk Management is a continues process of identifying, analyzing, responding, monitoring, and reviewing risks related to IT from process, technology and people perspectives. In order to manage IT risks, Member Organizations should continually identify, assess and reduce IT risks within levels of tolerance set by the Member Organization's senior management.

3.2.1 Managing IT Risks

Principle

IT Risk Management process should be defined, approved, implemented, communicated and aligned to the Member Organization's Enterprise Risk Management process, including the identification, analysis, treatment, monitoring and review of IT risks at appropriate intervals.

Control Requirements

1.	IT risk management process should be defined, approved, implemented and communicated.
2.	The effectiveness of the IT risk management process should be measured and periodically evaluated.
3.	IT risk management process should be aligned with the Member Organization's enterprise risk management process.
4.	IT risk management process should clearly address the following sub processes, including but not limited to:
	a.	risk identification, analysis and classification;
	b.	risk treatment;
	c.	risk reporting; and
	d.	risk monitoring and profiling.
5.	IT risk management process should address Member Organization's information assets, including but not limited to:
	a.	business processes and related data;
	b.	business applications;
	c.	infrastructure components; and
	d.	Third party relationships and associated risks.
6.	IT risk management process should address Member Organization's people aspect (i.e. permanent staff, contractual employees, third party).
7.	IT risk management process should be initiated at, but not limited to:
	a.	an early stage of the program and project implementation;
	b.	prior to initiate critical and major changes to the information assets;
	c.	the time of outsourcing services; and
	d.	prior to procuring of new systems, tools and emerging technologies (i.e. Distributed Ledger Technology (DTL), Robotic Process Assurance (RPA)etc.)
8.	Existing information assets should be subject to periodic IT risk assessment based on their criticality such as:
	a.	all mission critical and critical information assets should be assessed at least once a year; and
	b.	non-critical information assets should be assessed based on their importance to the business.
9.	IT risk management activities should involve the following stakeholders, but not limited to:
	a.	business owners and users;
	b.	IT departmental/functional heads;
	c.	technical administrators; and
	d.	cyber security specialists.
10.	The Member Organization's should develop and implement IT risk response (i.e. avoid, mitigate, transfer and accept) and control strategies that are consistent with the value of the information assets and member organizations risk appetite.
11.	IT key risk indicators (KRIs) should be defined, implemented and monitored.

3.2.2 Risk Identification and Analysis

Principle

Information assets should be identified, recorded and maintained to gather information about related threats, existing controls and associated risks should be analyzed based on their likelihood of occurrences and resulting impact.

Control Requirements

1.	IT risk identification should be performed, documented and periodically updated in the formal centralized risk register.
2.	IT risk register should be regularly updated.
3.	IT risk analysis should address the following, but not limited to:
	a.	information asset description and classification;
	b.	potential threat(s) to the information asset;
	c.	impact and likelihood;
	d.	existing IT controls;
	e.	risk owner (business or process owner);
	f.	implementation owner (control owner); and
	g.	inherent as well as residual risks related to the information assets.

3.2.3 Risk Treatment

Principle

IT risks associated with the Member Organization's information assets should be adequately treated based on the applicable criteria (i.e. accepted, avoided, transferred or mitigated).

Control Requirements

1.	IT risk treatment plan should be defined, approved and communicated.
2.	IT risk treatment plan should be implemented and periodically evaluated.
3.	IT risks should be treated according to the Member Organization's risk appetite defined by the relevant governance function owner and approved by the ITSC.
4.	IT risk treatment plan should include detail design and implementation of required controls to mitigate the identified risks.
5.	IT risk treatment plan should ensure that the list of risk treatment options are formally documented (i.e. accepting, avoiding, transferring or mitigating risks by applying IT controls).
6.	Risk acceptance should be least preferred over risk mitigation through implementation of primary controls.
7.	Accepting IT risks should be formally documented, approved and signed-off by the business owner and reported to the risk committee, ensuring that:
	a.	risk acceptance should be provided with detail justification including but not limited to the following:
		1.	impact (i.e. operational, financial and reputational) of not implementing the primary control(s); and
		2.	compensating control(s) in place of primary control(s) for risk mitigation.
	b.	the accepted IT risk should be within the risk appetite of the Member Organization;
	c.	the accepted IT risk should not contradict with the SAMA regulations;
	d.	a separate exception should be documented for each unique risk;
	e.	risk acceptance should be renewed periodically; and
	f.	Risk acceptance should be presented and reported to the risk committee.
8.	Avoiding IT risks should involve a decision by a business owner and risk committee to cancel or postpone a particular activity or project that introduces an unacceptable IT risk to the business.
9.	Transferring or sharing the IT risks should:
	a.	involve sharing the IT risks with relevant (internal or external) providers; and
	b.	be accepted by the receiving (internal or external) provider(s).
10.	Applying IT controls to mitigate IT risks should include:
	a.	identifying appropriate IT controls;
	b.	evaluating the strengths and weaknesses of the IT controls;
	c.	selection of adequate IT controls; and
	d.	documenting and obtaining sign-off for any residual risk by the business owner and risk committee.
11.	IT risk treatment actions should be documented in a risk treatment plan.

3.2.4 Risk Reporting/ Monitoring, and Profiling

Principle

IT risks should be treated according to the defined treatment plans and should be effectively reviewed, monitored and reported.

Control Requirements

1.	IT risk assessment results should be formally documented and reported to the relevant business owners and senior management.
2.	IT risk assessment results should include risks, impact, likelihood, mitigations, and remediation status.
3.	IT risks should be monitored, including but not limited to:
	a.	tracking progress in accordance to the risk treatment plan; and
	b.	the selected and agreed IT controls are being implemented.
4.	The design and operating effectiveness of the revised or newly implemented IT controls should be monitored and reviewed periodically.
5.	The relevant business owners should accept the IT risk assessment results.
6.	IT risk assessment results should be endorsed by the risk committee.
7.	IT key risk indicators (KRIs) should be defined, implemented and monitored.
8.	IT risk profile and related data should be provided as an input to operational risk department to formulate an organization level risk profile.
9.	IT risk profile should be formulated and presented to the senior management, IT Steering Committee and board of directors on periodic basis.

3.3 Operations Management
IT Operations Management can be defined as the function responsible for continues management and maintenance of the Members Organization's IT applications and infrastructure to ensure delivery of the agreed level of IT services to the business. Thus, IT operations risk factors should be addressed by the Member Organizations through effective management and control.

3.3.1 Manage Assets

Principle

Asset Management process should be established to provide visibility of the Member Organization's information assets by maintaining an accurate and up-to-date inventory.

Control Requirements

1.	The asset management process should be defined, approved, implemented and communicated.
2.	The effectiveness of the asset management process should be monitored, measured and periodically evaluated.
3.	The asset management process should include but not limited to:
	a.	asset onboarding;
	b.	asset identification, classification, labeling and handling;
	c.	asset disposal; and
	d.	asset decommissioning.
4.	Asset register should provide with the level of details, including (but not limited):
	a.	asset name;
	b.	asset owner;
	c.	asset custodian; asset criticality;
	d.	asset physical location;
	e.	asset logical location (network zone);
	f.	asset identified as direct in-scope of PCI;
	g.	asset identified as indirect in-scope of PCI;
	h.	availability or backup information;
	i.	service contract or license information;
	j.	technical contacts (OS, Application, Database and Network);
	k.	primary and secondary processes supported by the asset;
	l.	acceptable downtime aligned with BCM - Business Impact Analysis where applicable;
	m.	financial impact per hour in the event of downtime;
	n.	vendor engagement contract number;
	o.	vendor point of contact details;
	p.	vendor SLA details; and
	q.	vendor classification details.
5.	Asset register should be maintained and updated on yearly basis, or whenever any asset introduced or removed from inventory.
6.	Member organizations should:
	a.	define criteria for the identification of critical assets;
	b.	identify, maintain and periodically update comprehensive list of critical assets;
	c.	proactively monitor performance of critical assets; and
	d.	ensure adequate resilience measures in place for critical assets to maintain availability of the required critical services.
7.	Asset owner should be responsible for, but not limited to:
	a.	classification and labeling of asset;
	b.	defining and reviewing access rights, restrictions, and taking into account applicable access control policies of the Member Organizations;
	c.	authorizing changes related to assets; and
	d.	ensure alignment with cyber security controls.
8.	Assets should be disposed of in a controlled and secure manner upon completion of its useful life and when other relevant obligations are met.

3.3.2 Interdependencies

Principle

Interdependencies for critical information assets should be identified and managed through governance model to ensure availability of business operations.

Control Requirements

1.	Member Organizations should define and implement robust governance model in light of their interdependencies with relevant stakeholders (e.g. service providers, government institutions, etc.)
2.	Member Organizations should identify its critical information assets interdependencies.
3.	As part of the 89 testing, the Member Organizations should take into consideration the interdependencies of critical information assets scenarios within its infrastructure.
	Note: For more Control Requirements to improve the overall resilience, please refer to the SAMA - BCM Framework.

3.3.3 Manage Service Level Agreements

Principle

Contractual terms and conditions governing the roles, relationships, obligations and responsibilities of internal stakeholder and third parties should be formally agreed, developed and adequately controlled.

Control Requirements

1.	Internal IT Service Level Agreement (SIA) should be formally defined, approved, and communicated to the relevant business department of the Member Organizations.
2.	The effectiveness of the internal IT SLA should be monitored, measured, and periodically evaluated.
3.	Internal IT SLA should include the following, but not limited to:
	a.	service level agreed between the business functions and the IT department;
	b.	specific and measurable targets for IT services against the defined KPI's; and
	c.	roles and responsibilities of the business and IT stakeholders.
4.	The third party relationship process should be defined, approved, implemented, and communicated.
5.	The effectiveness of the third party relationship process should be monitored, measured, and periodically evaluated.
6.	Formal SLA should be defined and signed with the third party.
7.	The third party relationship process should cover following requirements, but not limited to:
	a.	outsourcing service providers should have adequate process in place to ensure availability, protection of data and applications outsourced;
	b.	periodic reporting, reviewing and evaluating the contractually agreed requirements (in SLAs);
	c.	changes to the provision of provided services;
	d.	execution of a risk assessment as part of the procurement process;
	e.	escalation process in case of SLA breached;
	f.	administrative, physical, and technical safeguards that reasonably and appropriately protect the confidentiality, integrity, and availability of information;
	g.	legal assurance from the third party to provide onsite support that mandates onsite presence of certified and experienced relevant support engineer within a defined timeline to support the Member Organizations in adverse situations;
	h.	exiting, terminating, or renewing the contract (including escrow agreements if applicable);
	i.	compliance with applicable frameworks including but not limited to SAMA Cyber Security, Business Continuity Management and IT Governance Frameworks-and applicable Laws and Regulations;
	j.	right to audit (Member Organizations or independent party); and
	k.	Non-Disclosure Agreement ('NDA').

3.3.4 IT Availability and Capacity Management

Principle

Service availability should be maintained to support member organizations business functions and to avoid disruption and slowness of systems performance through monitoring current system thresholds and prediction of future performance and capacity requirements.

Control Requirements

1.	The IT availability and capacity management process should be defined, approved and implemented.
2.	The effectiveness of the IT availability and capacity management process should be monitored, measured and periodically evaluated.
3.	IT availability and capacity plan should be developed, approved and periodically evaluated.
4.	IT availability and capacity plan should be defined to address the following, but not limited to:
	a.	existing capacity of systems and resources;
	b.	alignment with the current and future business needs;
	c.	high availability requirements (including disruption and slowness for customer channels);
	d.	roles and responsibilities to maintain the plan; and
	e.	identification of dependencies over service providers as part of capacity planning to address BCM requirements.
5.	System performance thresholds should be defined and implemented.
6.	System performance should be monitored considering the following, but not limited to:
	a.	current and future business requirement;
	b.	the agreed upon SLA with the business;
	c.	critical IT infrastructures;
	d.	disruption and slowness in the underlying system(s) supporting customer channels; and
	e.	lessons learned from previous system performance issues.
7.	Deviations from established capacity and performance baselines/thresholds should be identified, documented, followed-up, and reported to the management and ITSC.

3.3.5 Manage Data Center

Principle

Adequate physical controls are designed and implemented to protect IT facilities and equipment from damage and unauthorized access.

Control Requirements

1.	Physical and environmental controls for managing the data center should be defined, approved and implemented.
2.	Physical and environmental controls should be monitored and periodically evaluated.
3.	Necessary physical and environmental controls should be implemented such as but not limited to:
	a.	access to the data center should be strictly controlled and provided on need to know basis;
	b.	visitors entry to data center should be logged and escorted by an authorized person;
	c.	smoke detectors;
	d.	fire alarms;
	e.	fire extinguishers;
	f.	humidity control;
	g.	temperature monitoring; and
	h.	CCTV.
4.	The outsourcing of data center should comply with the requirements published in SAMA circulars on the Rules of The Outsourcing and Cybersecurity Framework.
5.	Member Organizations should ensure that appropriate control measures are built into contracts with the service providers to whom they plan to outsource data center such as but not limited to:
	a.	have documented business case for outsourcing data center services; and
	b.	nature and type of access to data center by the service provider.

3.3.6 Network Architecture and Monitoring

Principle

IT event management and network architecture controls should be designed and implemented to continuously monitor IT operations in order to protect member organizations network from unauthorized access.

Control Requirements

1.	Member Organizations should define, approve and implement network architecture policy considering the following:
	a.	organization's stance with respect to acceptable network usage;
	b.	explicit rules for the secure use of specific network resources, services and applications;
	c.	consequences of failure to comply with security rules;
	d.	organization's attitude towards network abuse; and
	e.	rationale(s) for the policy, and for any specific security rules.
2.	Member Organizations should ensure the implementation of following network architecture controls, but not limited to:
	a.	network diagram showing the complete current infrastructure;
	b.	segmentation of network into multiple separate network domains based on the required trust levels (6.8. public domain, desktop domain, server domain) and in line with relevant architectural principles;
	c.	perimeter of each network domain should be well protected by a security gateway (e.g. firewall, filtering router). For each security gateway a separate service access (security) rules should be developed and implemented to ensure that only the authorized traffic is allowed to pass;
	d.	all internal traffic (head office users, branch users, third party users, etc.) passing to DMZ or internal servers should pass via 2 security gateway (firewall);
	e.	all outbound internet access from internal networks are routed via proxy server such that access is allowed only to approved authenticated users;
	f.	visitor network (wired/wireless network) should be isolated and segregated from the internal network;
	g.	the perimeter firewall to the DMZ should raise an alert and block active scanning;
	h.	web application firewall (WAF) should be implemented against customer facing applications;
	i.	ensure non-existence of single node of failure that affects the critical service availability;
	j.	centralized authentication server (AAA, TACACS or RADIUS, etc.) should be deployed for managing authentication and authorization of network devices;
	k.	centralized log server (e.g. syslog server) should be deployed to collect and store logs from all network devices;
	l.	retention period for logs should be 12 months minimum;
	m.	all network devices should synchronize their clock timings from a centralized NTP server;
	n.	all network communication over extranet (WLAN) and internet should be through an encrypted channel;
	o.	remote access should be restricted only to certain group of IP addresses;
	p.	remote administration should be over an encrypted channel (like SSL VPN, SSH);
	q.	remote administration access for vendors should be time-bound and granted on a need basis with approval;
	r.	scan for Member Organization's devices before accessing the network to ensure enforcement of security policies on devices before they access organization's network; and
	s.	segregation of duties within the infrastructure component (supported with a documented authorization profile matrix).
3.	Member Organizations should ensure that network monitoring is performed considering the following, but not limited to:
	a.	administrative trails including login and activity trails (like configuration change, rule change, etc.);
	b.	resource utilization (processor and memory); and
	c.	network connectivity to all branches and ATMs.

3.3.7 Batch Processing

Principle

Batch management process should be defined, approved and implemented in order to manage the bulk processing of automated tasks in an efficient and controlled manner.

Control Requirements

1.	Batch management process should be defined, approved, implemented and communicated.
2.	The effectiveness of the Batch management process should be measured and periodically evaluated.
3.	Batch Management process should include the following, but not limited to:
	a.	start and end of day schedules;
	b.	roles and responsibilities;
	c.	monitoring of batches; and
	d.	error or exception handling.
4.	Changes in the batch schedules should be approved by the relevant stakeholder(s).
5.	Member organizations should maintain log containing information about start and end of the day batch operations along with its status 6.8. (successful or unsuccessful).

3.3.8 IT Incident Management

Principle

IT incident Management process should be established to timely identify, respond and handle IT incidents impacting the Member Organization's information assets and to report relevant incidents to SAMA, according to a defined communication protocol.

Control Requirements

1.	IT incident management process should be defined, approved, implemented and communicated.
2.	The effectiveness of the IT incident management process should be measured and periodically evaluated.
3.	IT incident management process should include the following requirements, but not limited to:
	a.	the establishment of a designated team responsible for incident management;
	b.	communication plan;
	c.	details of key staff who need to be notified;
	d.	skilled and (continuously) trained staff;
	e.	the prioritization and classification of incidents;
	f.	the timely handling of incidents, recording and monitoring progress;
	g.	the protection of relevant evidence and loggings;
	h.	post-incident activities such as root-cause analysis of the incidents; and
	i.	lessons learned.
4.	IT incident management process should be automated such as through IT service desk.
5.	٨ process should be established for documenting the details of incident, steps taken which were successful and which were not successful, should be communicated to the relevant IT staff for hands on experience and also for future reference to enhance efficiency.
6.	All user requests and IT incident should be logged with the following information but not limited to:
	a.	unique reference number;
	b.	date and time;
	c.	name of the impacted services and systems;
	d.	update the relevant owner; and
	e.	categorization and prioritization based on the urgency and impact.
7.	All IT incident should be tracked and resolved as per agreed service level.
8.	Member organizations relevant teams should be involved (when applicable) to ensure adequate handling of the incident.
9.	The Member Organizations should inform 'General Department of Cyber Risk Control' immediately upon identification of 'Medium' or above classified incident that have impact on customers, as per SAMA BCM Framework.
10.	The Member Organizations should inform 'General Department of Cyber Risk Control' immediately upon identification of disruption and slowness in the critical and/or application(s) impacting customer.
11.	Member Organizations should notify 'General Department of Cyber Risk Control' before disclosing any information about the incident to the media.
12.	The Member Organizations should submit a detail incident report within five (5) days to 'General Department of Cyber Risk Control', including the following details as a minimum:
	a.	title of the incident;
	b.	identification, classification and prioritization of incident;
	c.	logging and monitoring of incident;
	d.	resolution and closure of incident;
	e.	impact assessment such as financial, data, customer and/or reputational;
	f.	date and time of the incident;
	g.	name of the impacted services and systems;
	h.	root-cause analysis; and
	i.	corrective actions with target dates.

3.3.9 Problem Management

Principle

Criteria and procedures to report problems should be defined to limit recurring incidents and to minimize the impact of incidents on the Member Organizations.

Control Requirements

1.	The problem management process should be defined, approved, implemented and communicated.
2.	The effectiveness of the problem management process should be measured and periodically evaluated.
3.	The problem management process should include the following requirements but not limited to:
	a.	identification, classification and prioritization of problem;
	b.	logging and monitoring of problem;
	c.	resolution and closure of problem;
	d.	the protection of relevant evidence and loggings;
	e.	impact assessment such as financial, data, customer and/or reputational;
	f.	date and time of the problem;
	g.	name of the impacted services and systems;
	h.	root-cause analysis; and
	i.	corrective actions.
4.	The Member Organizations should maintain a database for known error records.

3.3.10 Data Backup and Recoverability

Principle

Data backup management strategy along with backup and restoration procedures should be defined, approved and implemented to ensure reliability, availability, and recoverability of data of the Member Organizations.

Control Requirements

1.	Data backup management strategy should be defined, approved and implemented.
2.	The data backup management policy should consider the following, but not limited to:
	a.	alignment with SAMA Business Continuity Management Framework;
	b.	implementation of replication, backup and recovery capabilities;
	c.	data storage;
	d.	data retrieval; and
	e.	data retention as per the legal, regulatory and business requirements.
3.	Backup and restoration procedures should be defined, approved and implemented.
4.	The effectiveness of the backup and restoration procedure should be measured and periodically evaluated.
5.	Member Organizations should define its backup and restoration requirements considering the following, but not limited to:
	a.	legal and regulatory requirements;
	b.	business requirements in line with agreed RPO (Recover Point Objective);
	c.	type of backups (offline, online, full, incremental, etc.); and
	d.	schedule of the backup (daily, weekly, monthly, etc.).
6.	Member Organizations should ensure the following information are backed up at minimum:
	a.	applications;
	b.	operating systems software;
	c.	databases; and
	d.	device configurations.
7.	In case of replication of data between primary and disaster recovery site, Member Organizations should ensure that all replication issues are timely resolved such that data at the disaster recovery site are in sync with the primary site as per the agreed recovery point objective (RPO) and recovery time objective (RTO).
8.	Member Organizations should ensure that RTOs for critical services such as payment systems, customer related services, etc. are adequately defined considering the high availability of the supporting operations and minimum disruption in the event of disaster.
9.	Member Organization should ensure sufficient investment are made from people, process and technology perspective to achieve the targeted RTOs.
10.	Member Organizations should implement alternate mechanism for backup redundancy (e.g. transaction dumps in addition to full database backup).
11.	Member Organizations should conduct periodic testing and validation of the recovery capability of backup media.
12.	Backup media should be appropriately labelled.
13.	Backup media including USB disks, containing sensitive or confidential information should be encrypted before transportation to offsite for storage.

3.3.11 Virtualization

Principle

Formal process for creation, distribution, storage, use and retirement of virtualized images, snapshots or containerization should be defined and managed in a controlled and secured manner.

Control Requirements

1.	A process should be defined, approved, implemented and communicated by the Member Organizations to setup, deploy and configure a virtual environment.
2.	The process should be governed with well-defined policies, procedures and standards.
3.	The effectiveness of the virtualization or containerization process should be measured and periodically evaluated.
4.	All virtual components deployed in the Member Organizations should be provided with the same level of security as of non-virtualized environment.
5.	All virtual components should be adequately configured using defined and approved minimum baseline security standards (MBSS) specific to virtualization or containerization.
6.	Strong authentication mechanism should be implemented and access should be granted on need to know or least privileged basis for all virtual environments including host operating system, hypervisor, guest operating systems and any other related components.
7.	The creation, distribution, storage, use, retirement and destruction of the virtual images and snapshots should be handle in a controlled and secured manner.
8.	The following should be considered as part of virtualization/containerization but not limited to:
	a.	administrative access should be tightly controlled where access via local admin should be restricted;
	b.	management of hypervisors should be restricted to administrators only;
	c.	virtual test environment should be physically and/or logically segregated from the production environment and even should not operate on the same host;
	d.	unnecessary program and services should be disabled on virtual machines unless authorized by the business;
	e.	audit logging should be enabled and monitored for all virtual machines that should include but not limited to:
		1.	creation, deployment and removal;
		2.	root and administrative activities; and
		3.	creation, modification and deletion of system level objects.
	f.	appropriate controls should be in place to protect sensitive and critical data being used and managed through virtual images or snapshots; and
	g.	all virtual drives used by the guest operating systems should be backed-up and tested on regular basis, using the same policy for backup management as is used for non-virtualized systems.

3.4 System Change Management
System change management is a process of defining, designing, testing and implementing changes related to information assets including but not limited to application, software, device and data. Thus, risks factors related to system change management should be addressed by the Member Organizations through adequate implementation of required IT controls.

3.4.1 System Change Governance

Principle

A Change Management process should be established to ensure that changes to the Member Organization's information assets are classified, tested and approved before their deployment into production environments

Control Requirements

1.	System change management process should be defined, approved, implemented and communicated within the Member Organizations.
2.	The effectiveness of the system change management process should be measured and periodically evaluated.
3.	System change management process should be governed by the change management policy and procedure that should be approved, monitored, reviewed and updated on periodic basis and/or whenever significant changes occurs in the IT environment or changes in laws and regulatory requirements.
4.	System change management process should address the following, but not limited to:
	a.	change requirement definition and approval;
	b.	change severity and priority;
	c.	change risk and impact assessment;
	d.	change development;
	e.	change testing;
	f.	change roll-out and roll-back;
	g.	change roles and responsibilities;
	h.	change documentation;
	i.	change awareness and/or training for users; and
	j.	change advisory board (CAB) input, if applicable.
5.	A workflow system should be implemented to automate the change management process by the Member Organizations to the maximum extent possible.
6.	Any changes in the information assets should be logged, monitored and documented.
7.	System environments (i.e. development, testing, production, etc.) should be technically and logically segregated.
8.	Access to different system environments should be strictly controlled and monitored. In order to do so, segregation of duties (‘SoD’) should be ensured so that no individual have two conflicting responsibilities such as (develop, compile, test, migrate and deploy) at the same time.
9.	Emergency changes in the information assets should be performed in ه strictly controlled manner and should consider the following:
	a.	the number of emergency changes should be least preferred over planned changes in order to keep such changes as minimum as possible;
	b.	emergency changes should be assessed for their impact on the systems;
	c.	emergency changes should be approved by the Emergency Change Advisory Board ('ECAB');
	d.	minimum level of testing should be acceptable to implement the emergency changes;
	e.	formal documentation of emergency changes should be completed post implementation;
	f.	post implementation review should be conducted for all emergency changes; and
	g.	root cause analysis should be conducted to determine the cause due to which emergency change was required, as well as maintaining a register to reflect lesson learned and report to all concerned staff, management and ITSC.
10.	Sufficient auditing should be enabled to log emergency changes related to information assets for future reference or investigation purposes.

3.4.2 Change Requirement Definition and Approval

Principle

Changes to information assets should be formally defined, documented and approved by relevant asset owner prior to implementing the change in the information assets.

Control Requirements

1.	Change requirements should be formally initiated by the requestor of the change.
2.	Change requirements should specify both functional and non-functional requirements, where applicable.
3.	Change requirements should be formally reviewed and approved by the concern asset owner.
4.	Any changes in the information assets should be assessed for their impact on the systems prior to implement the change.
5.	Any change in the information assets should be endorsed by the Change Advisory Board (48") prior deploying to the production environment.
6.	Any changes in the information assets should be reviewed and approved by the cyber security function before submitting to ‘CAB’ (required as per SAMA Cyber Security Framework, 3.3.7 Change Management, Control Requirements, 4 - d).

3.4.3 System Acquisition

Principle

System acquisition process should be established to ensure risks associated with the system acquisition and related vendor service level are adequately assessed and mitigated prior acquiring system.

Control Requirements

1.	System acquisition process should be defined, approved, implemented and communicated by the Member Organizations.
2.	The effectiveness of the system acquisition process should be measured and periodically evaluated.
3.	System requirements (i.e. functional and non-functional) should be formally defined and approved as part of system acquisition.
4.	A feasibility study should be conducted to assess functional and non-functional requirements of the new system particularly in conformance with SAMA regulatory requirements, and other applicable regulatory requirements.
5.	Vendor evaluation should be incorporated in the system acquisition process to assess vendor for their offering and capabilities to support system during and post implementation.
6.	The system acquisition should be supported with a detail implementation plan describing the following, but not limited to:
	a.	system implementation milestones (including requirement gathering, development or customization, testing, go-live etc.);
	b.	timeline for each milestone and their dependencies; and
	c.	resources assigned to milestones.
7.	The off-the-shelf system or package should be evaluated based on the following, but not limited to:
	a.	system conformance with the requirements of the Member Organization;
	b.	system creditability and market presence, if required; and
	c.	vendor evaluation and service level.

3.4.4 System Development

Principle

System development methodology should be documented, approved and implemented to ensure that the development of Member Organization's system is performed in a strictly controlled manner.

Control Requirements

1.	The system development methodology should be defined, approved, implemented and communicated.
2.	The effectiveness of the system development methodology should be monitored and periodically evaluated.
3.	The system development methodology should address the following, but not limited to:
	a.	system development approach such as agile, waterfall, etc.;
	b.	secure coding standards;
	c.	testing types and approaches such as unit testing, regression testing, stress testing, etc.;
	d.	version controlling;
	e.	quality control;
	f.	data migration;
	g.	documentation; and
	h.	end user training.
4.	The system design document should be defined, documented and approved.
5.	The system design document should address the low level design requirements for the intended system, which includes but not limited to following:
	a.	configurations requirements;
	b.	integration requirements;
	c.	performance requirements;
	d.	cyber security requirements; and
	e.	data definition requirements.
6.	Member organizations relevant IT function or development team should conduct secure code review for:
	a.	applications developed internally; and
	b.	externally developed applications if the source code is available.
7.	Member Organizations should ensure that the secure code review report (or equivalent, such as an independent assurance statement) is formulated in case the source code is not available with the member organization.
8.	Cyber security controls should be embedded in the system development process in line with SAMA Cyber Security Framework.
9.	Version control system should be utilized to keep track of source code or build versions between various system environments (i.e. development, test, production, etc.).

3.4.5 Testing

Principle

All changes to information systems should be comprehensively tested on the test environment based on the defined and approved test cases to ensure that changes meets the business requirements as well as to identify defects or vulnerabilities before releasing changes to the production environment.

Control Requirements

1.	Test plan should be formally defined, approved and documented for the changes.
2.	Test case should be defined, approved and documented for the changes. In addition, test case should address the following, but not limited to:
	a.	test case name and unique ID;
	b.	test case designed by and tested by;
	c.	test case description with clear identification of negative and positive test cases;
	d.	test priority;
	e.	date of the test execution;
	f.	data use to test the cases;
	g.	status of the test case (i.e. pass or fail);
	h.	expected outcome of the test case; and
	i.	third party testing certification requirement, if applicable, i.e. MADA, Tanfeeth, etc.
3.	At a minimum, the following types of testing should be considered as part of system change management.
	a.	unit testing;
	b.	system integration testing (SIT);
	c.	stress testing (if applicable);
	d.	security testing; and
	e.	user acceptance testing (UAT).
4.	All changes to information system should be thoroughly tested on a separate test environment in accordance with the approved test cases.
5.	All changes should be formally tested and accepted by the concern business users.
6.	Testing should include positive and negative test cases scenarios.
7.	The results of UAT should be documented and maintained for future reference purposes.
8.	The production data should not be utilized for system testing in the test environment. Only sanitized data should be used for testing purposes.

3.4.6 Change Security Requirements
Principle
Cyber security requirements should be defined and thoroughly tested for all changes in the information system in a testing environment in order to identify and mitigate security vulnerabilities therein prior introducing them into the production environment.
Control Requirements
1. System change management process should consider SAMA Cyber Security Framework for defining, testing and implementing security requirements for any changes in the information assets.

3.4.7 Change Release Management

Principle

Change release management process should be defined to ensure that system changes are adequately planned and released to the production environment in a strictly controlled manner.

Control Requirements

1.	The release management process should be defined, approved, implemented and communicated.
2.	The release management process should be monitored and periodically evaluated.
3.	The release management process should address the following, but not limited to:
	a.	change release strategy and approach;
	b.	roles and responsibilities to carry out change releases;
	c.	change release schedule and logistics;
	d.	change roll-out and roll-back procedures; and
	e.	data migration, where applicable.
4.	The changes should be released in the corresponding system in disaster recovery site upon successful implementation of changes in the production environment at main site.
5.	Change should be introduced as part of an agreed change window, exceptions has to have their own approval process and seldom allowed without compelling reasons.

3.4.8 System Configuration Management

Principle

System Configuration Management Process should be defined, approved, communicated and implemented to maintain a reliable and accurate information about configuration items ('CIs') for Member Organization's information assets.

Control Requirements

1.	The configuration management process should be defined, approved, implemented and communicated by the Member Organizations.
2.	The configuration management process should be monitored and periodically evaluated.
3.	The configuration management process should address the following, but not limited to:
	a.	roles and responsibilities for carrying out configuration management;
	b.	identification and recording of configuration items and their criticality with respect to its supporting business processes;
	c.	interrelationships between configuration items among various information assets; and
	d.	periodic verification of configuration items.
4.	Member Organizations should implement configuration management database (‘CMCB’) to identify, maintain, and verify information related to Member Organization's Information assets.

3.4.9 Patch Management
Principle
Patch management process should be defined and implemented to ensure up-to-date with latest applicable and relevant patches (i.e. functional or non-functional) are installed in a timely manner to avoid technical issues including security breaches due to existing vulnerabilities in the system.
Control Requirements
1. The patch management process should be defined, approved, implemented and communicated by the Member Organizations.
2. The effectiveness of the patch management process should be monitored, measured and periodically evaluated.
3. All patches should be thoroughly assessed for impact by relevant stakeholders including cyber security before being implemented into the production environment.
4. All systems should be periodically scanned or inspected to identify any outdated patches and vulnerabilities in the systems.
5. Deployment of patches should follow a formal change management process.
6. All patches should be thoroughly tested in a separate test environment prior introducing to the production environment to avoid any compatibility issue with the system and related components.
7. Patches should be rolled out to systems and related components systematically.
8. Following deployment of patches to the production environment, systems should be monitored for any abnormal behavior and, if such behavior identified should be thoroughly investigated to identify the root cause and fix them properly.
9. Patch deployment window (i.e. schedule) should be communicated to business and relevant stakeholders in advance and preferable should be done during non-peak hours and non-freezing periods to avoid any business disruption.
10. The external feeds from software vendors or other acknowledged sources should be monitored to identify any new vulnerabilities in the system and to be patched accordingly.

3.4.10 IT Project Management

Principle

Formal process should be defined, approved and implemented to effectively manage IT project and related risks throughout the lifecycle of the project.

Control Requirements

1.	The IT project management process should be defined and approved by the Member Organizations.
2.	The IT project management process should be governed with a formally defined and approved IT project management framework, policy and procedure to manage IT project lifecycle from initiation till closure.
3.	The effectiveness of the IT project management process should be monitored, measured and periodically evaluated.
4.	All IT projects should be provided with detail project plan, which include the following, but not limited to:
	a.	detail scope of work including activities for a project or each phase of the project;
	b.	priorities, milestones and timelines associated with project or each phase of the project;
	c.	deliverables;
	d.	roles and responsibilities; and
	e.	risks associated with any IT projects.
5.	Necessary documentations for the IT project should be defined, approved and maintained for future reference purposes including but not limited to following:
	a.	project charter;
	b.	requirement analysis, business information flow and technical information flow;
	c.	feasibility as well as cost-benefit analysis; and
	d.	detail project plan.
6.	IT project steering committee should be established having representation from relevant business and technical teams to oversee plan, progress and risks associated with the IT projects.
7.	All IT projects should be assessed for the risks that could impact the scope, timeline and quality of the projects. Any identified risks should be mitigated and monitored throughout the project lifecycle.
8.	Any significant risks associated with the IT project should be reported to IT project steering committee and to senior management or board of directors of the member organization in a timely manner.
9.	All project deliverables should be reviewed by an independent quality assurance function or an independent person provided with such responsibly prior commencing project to the production environment.
10.	Post-implementation reviews should be planned and executed to determine whether IT projects delivered the expected benefits, met business/user requirements, and complied with the IT project management framework.
11.	The Member Organizations should inform 'General Department of Cyber Risk Control' for any major IT transformation projects, such as core system implementation, after the approval from the senior management.
12.	Cyber security should be involved during various phases of the IT project management lifecycle in line to the control considerations provided in SAMA Cyber Security Framework.

3.4.11 Quality Assurance

Principle

The quality assurance process should be defined, approved, communicated and implemented to independently ascertain quality of the changes or development in the information assets in line with the business/user requirements prior moving them to the production environment.

Control Requirements

1.	The quality assurance process should be defined, approved, implemented and communicated by the Member Organizations.
2.	The quality assurance process should be monitored and periodically evaluated.
3.	The quality assurance process should address the following, but not limited to:
	a.	clear roles and responsibilities for personnel carrying out quality assurance activities;
	b.	minimum quality requirements sets by the Member Organizations including business and any other applicable regulatory requirements; and
	c.	process for identification, maintenance and retirement of quality related records.
4.	The quality assurance function/department should have independent existence and reporting with authority to provide objective evaluation.
5.	All changes or development to information system should be assessed by the quality assurance team prior releasing to the production environment.
6.	The quality assurance function should report the reviewed results to the relevant stakeholder(s) within the Member Organizations and initiate improvements where appropriate.

Appendices

Appendix A - How to Request an Update to the Framework
Below the illustration of the process for requesting an update to the Framework.
- Detail information supported by pros and cons about the suggested update.
- The request should first be approved by CIO before submitting to IT steering committee.
- The request should be approved by Member Organization's IT steering committee.
- The request should be sent formally in writing to the manager 'General Department of Cyber Risk Control' via the Member Organization's CEO or managing director.
- 'General Department of Cyber Risk Control' will evaluate the request and informs the Member Organization.
- The current Framework remains applicable while the requested update is being considered, processed and if applicable is approved and processed.

Appendix B - Framework Update Request Form
Request to Update the IT Governance Framework
A submission to the manager of SAMA MA General Department of Cyber Risk Control.
The Saudi Arabia Monetary Authority (SAMA) will consider requests from a member organization (MO) to update its IT Governance Framework based on the information submitted using the form below. A separate form must be completed for each requested update. Please note that all required fields must be properly filled in before SAMA will begin the review process
Requestor Information
REQUESTOR'S SIGNATURE*
x REQUESTOR'S POSITION* DATE*
REQUESTOR'S NAME*
MEMBER ORGANIZATION OF REQUESTOR*

FRAMEWORK SECTION*:

PURPOSE OF REQUESTED UPDATE (including detailed information on its pros and cons)*:

PROPOSAL*:

Approvals
1. MO'S CIO APPROVAL*
DATE*

2. MO'S IT STEERING COMMITTEE APPROVAL*
APPROVER'S POSITION*
DATE*

3 SAMA DECISION
SAMA APPROVAL
DATE

* Denotes required fields

Appendix C - How to Request 2 Waiver from the Framework
Below the illustration of the process for requesting a waiver from the Framework.
- Detail description about the reasons that the member organization could not meet the required control.
- Details description about the available or suggested compensating controls.
- The waiver request should first be approved by CIO before submitting to IT steering committee.
- The waiver request should approved by the members of Member Organization's IT steering committee.
- The waiver request should be signed by the CIO and relevant (business) owner.
- The waiver request should be formally issued in writing to the manager of 'General Department of Cyber Risk Control' via the Member Organization's CEO or managing director.
- ‘General Department of Cyber Risk Control' will evaluate the waiver request and informs the Member Organization.
The current Framework remains applicable while the requested waiver is being evaluated and processed, until the moment of granting the waiver.

Appendix D - Framework Waiver Request Form
Request for Waiver from the SAMA IT Governance Framework
A submission to the manager of 'General Department of Cyber Risk Control'
The Saudi Arabia Monetary Authority (SAMA) will consider requests for waiver from a member organization (MO) from its IT Governance Framework based on the information submitted using the form below. A separate form must be completed for each requested waiver. Please note that all required fields must be properly filled in before SAMA will begin the review process.
Requestor Information
REQUESTOR'S SIGNATURE*
x REQUESTOR'S POSITION* DATE*
REQUESTOR'S NAME*
MEMBER ORGANIZATION OF REQUESTOR*

FRAMEWORK CONTROL*:

DETAILED DESCRIPTION OF WHY CONTROL CANNOT BE IMPLEMENTED*:

DETAILED DESCRIPTION OF AVAILABLE OR SUGGESTED COMPENSATING CONTROLS*:

Approvals
1 .MO's CIO APPROVAL*
DATE*

2. MO'S IT STEERING COMMITTEE APPROVAL*
APPROVER'S POSITION*
DATE*

3. SAMA DECISION
SAMA APPROVAL
DATE

* Denotes required fields
**The validity of this waiver is one year. It is the Member Organizations responsibility to ensure renewal of this waiver.

Appendix E - Glossary

Term	Description
Access Control	Means to ensure that access to assets is authorized and restricted based on business and security requirements.
Application Architects	Application Architects identify needed changes to the portfolio of applications across the ecosystem. They develop and administer application-specific standards such as user interface design, globalization, Web services, portal application programming interfaces, XML, and content. They provide design recommendations based on long-term development organization strategy and develop enterprise level application and custom integration solutions including major enhancements and interfaces, functions and features.
Asset Management	The systematic process of deploying, operating, maintaining, upgrading, and disposing of assets in a safe, secure and cost effective manner
Asset Owner	The term Asset owner identifies an individual or entity that has approved management responsibility for controlling the production, development, maintenance, use of the information assets.
Authorization Matrix	A. matrix that defines the rights and permissions for a specific role needs for information. The matrix lists each user, the business process tasks he or she performs, and the affected systems.
Audit	Independent review and examination of records and activities to assess the effectiveness of IT governance controls and to ensure compliance with established policies, operational procedures and relevant standard, legal and regulatory requirements.
Authentication	Verifying the identity of a user, process, or device, often as a prerequisite in order to allow access to resources in a system.
Backup	Files, devices, data and procedures available for use in case of a failure or loss, or in case of deletion or suspension of their original copies.
Business Application	Any software or set of computer programs that are used by business users to perform various business functions.
Batch Processing	Batch processing is the processing of the transactions in a group or batch with no or minimal human interaction.
Configuration Item (CI)	Component of an infrastructure-or an item, such as a request for change, associated with an infrastructure-which is (or is to be) under the control of configuration management
Change Management	The controlled identification and implementation of required changes within a business or information systems.
Chief Information Officer (CIO)	A senior-level executive referred as Chief Information Officer (CIO), Chief Technology Officer (10) / Head of IT or relevant stakeholder who is accountable for IT advocacy, aligning IT and business strategies, and planning, resourcing and managing the delivery of IT services, information and the deployment of associated human resources.
Classification	Setting the sensitivity level2 of data and information that results in security controls for each level of classification. Data and information sensitivity levels are set according to predefined categories where data and information is created, modified, improved, stored or transmitted. The classification level is an indication of the value or importance of the data and information of the organization.
Chief Operating Officer (COO)	A senior-level executive responsible for the daily operation of the organization.
Critical IT infrastructures	These are the information assets (i.e., facilities, systems, networks, processes, and key operators who operate and process them), whose loss or vulnerability to security breaches may result in significant negative impact on the availability, integration or delivery of basic services, including services that could result in serious loss of property, alongside observance of significant economic and/or social impacts.
Compensating Control	A management, operational, and/or technical control (i.e., safeguard or countermeasure) employed by an organization in place of a recommended control in the low, moderate, or high baselines that provides equivalent or comparable protection for an information system.
Containerization	Unit of software that packages up code and all its dependencies.
Data Masking	A. computerized technique of blocking out the display of sensitive information or PII.
Database Administrator	Database administrator, frequently known just by the acronym DBA, is a role usually within the Information Technology department, charged with the creation, maintenance, backups, querying, tuning, user rights assignment and security of an organization's database.
Disaster Recovery	Programs, activities and plans designed to restore the organizations critical business functions and services to an acceptable situation, following exposure to cyber and IT incidents or disruption of such services.
Enterprise Architect	Description of the fundamental underlying design of the components of the business system, or of one element of the business system (e.g., technology), the relationships among them, and the manner in which they support the enterprise's objectives.
Feasibility study	A phase of a system development life cycle (SDLC) methodology that researches the feasibility and adequacy of resources for the development or acquisition of a system solution to a user need.
Formally documented	Documentation that is written, approved by the senior leadership and disseminated to relevant parties.
Freezing period	e.g. Salaries deposit days, public or national holidays.
Hypervisor	A hypervisor allows one host computer to support multiple guest Virtual Machines (VMs) by virtually sharing its resources, like memory and processing.
Incident	An occurrence that actually or potentially jeopardizes the confidentiality, integrity, or availability of an information system or the information the system processes, stores, or transmits or that constitutes violation or imminent threat of violation of security policies, security procedures, or acceptable use policies.
Incident Management	The monitoring and detection of events on an information systems and the execution of proper responses to those events.
Information Asset	A piece of information, stored in any manner, which is recognized as 'valuable' to the organization.
Interdependencies	Set of interaction with dependence of information assets on each another in order to deliver set of works or tasks.
IT Change and Release Management	A holistic and proactive approach to managing the transition from a current to a desired organizational state, focusing specifically on the critical human or "soft" elements of change
IT facilities	The physical environment where the IT infrastructure is located.
IT risk	The business risk associated with the use, ownership, operation, involvement, influence and adoption of IT within an enterprise.
IT Steering committee	An executive-management-level committee that assists in the delivery of the IT strategy oversees day-to-day management of IT service delivery and IT projects, and focuses on implementation aspects.
Key Performance Indicator (KPI)	KPI is a type of performance measurement that evaluates the success of an organization or of a particular activity in which it engages to achieve particular objectives and goals.
Key Risk Indicator (KRI)	KRI is a measure used to indicate the probability an activity or organization will exceed its defined risk appetite. KRIs are used by organizations to provide an early signal of increasing risk exposures in various areas of the enterprise.
Likelihood	A weighted factor based on an analysis of the probability that a given threat is capable of exploiting a given vulnerability.
Member Organization	Organizations affiliated with SAMA.
Need-to-know	The restriction of data, which is considered sensitive unless one has a specific need to know; for official business duties.
Off-the-shelf system	Software that already exists and is available from commercial sources.
Outsourcing	Obtaining goods or services by contracting with a supplier or service provider.
Patch	An update to an operating system, application, or other software issued specifically to correct particular problems with the software.
Patch management	The systematic notification, identification, deployment, installation, and verification of operating system and application software code revisions.
Recovery	A procedure or process to restore or control something that is suspended, damaged, stolen or lost.
Recovery Point Objective (RPO)	The point in time to which data must be recovered after an outage. RPO is determined based on the acceptable data loss in case of a disruption of operations. It indicates the earliest point in time that is acceptable to recover the data. The RPO effectively quantifies the permissible amount of data loss in case of interruption.
Recovery Time Objective (RTO)	The amount of time allowed for the recovery of a business function or resource after a disaster occurs
Regression Testing	Testing of a previously tested program following modification to ensure that defects have not been introduced or uncovered in unchanged areas of the software, as a result of the changes made.
Residual risks	The remaining risk after management has implemented a risk response.
Retention	The length of time that information, data, event logs or backups must be retained, regardless of the form (i.e., paper and electronic).
Risk	A measure of the extent to which an organization is threatened by a potential circumstance or event, and typically a function of: (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence.
Risk register	Risk register is a table used as a repository for all risks identified and includes additional information about each risk, e.g. risk category, risk owner, and mitigation actions taken.
Risk Tolerance	The acceptable variation relative to performance to the achievement of objectives. Also refer to 'Risk appetite'.
Risk Treatment	A process to modify risk that can involve avoiding the risk by deciding not to start or continue with the activity that gives rise to the risk; taking or increasing risk in order to pursue an opportunity; removing the risk source; changing the likelihood; changing the consequences; sharing the risk with another party or parties; and retaining the risk by informed decision. Risk treatments that deal with negative consequences are sometimes referred to as "risk mitigation", "risk elimination", "risk prevention" and "risk reduction". Risk treatments can create new risks or modify existing risks.
Root-cause analysis	A principle-based, systems approach for the identification of underlying causes associated with a particular set of risks.
RACI Chart	Illustrates who is Responsible, Accountable, Consulted and Informed within an organizational framework.
Security Testing	A process intended to ensure that modified or new systems and applications include appropriate security controls and protection and do not introduce any security holes or vulnerabilities that might compromise other systems or applications or misuses of the system, application or its information, and to maintain functionality as intended.
Security-by Design	A methodology to systems and software development and networks design that seeks to make systems, software and networks free from cybersecurity vulnerabilities/weaknesses and impervious to cyber-attack as much as possible through measures such as: continuous testing, authentication safeguards and adherence to best programming and design practices.
Segregation of Duties	Key principle that aims at minimizing errors and fraud when processing specific tasks. It is accomplished through having several people with different privileges, required to complete a task.
Service level agreement (SLA)	Defines the specific responsibilities of the service provider and sets the customer expectations.
Stress Testing	A type of performance testing conducted to evaluate a system or component at or beyond the limits of its anticipated or specified workloads, or with reduced availability of resources such as access to memory or servers.
System Acquisition	Procedures established to purchase application software, or an upgrade, including evaluation of the supplier's financial stability, track record, resources and references from existing customers
System Configuration Management	The control of changes to a set of configuration items over a system life cycle.
Third-Party	Any organization acting as a party in a contractual relationship to provide goods or services (this includes suppliers and service providers).
Threat	Any circumstance or event with the potential to adversely impact organizational operations (including mission, functions, image, or reputation), organizational assets, or individuals through an information system via unauthorized access, destruction, disclosure, modification of information, and/or denial of service.
Unit Testing	A testing technique that is used to test program logic within a particular program or module.
User Acceptance Testing (UAT)	Taking use cases or procedures for how the system was designed to perform and ensuring that someone who follows the procedure gets the intended result.
Vulnerability	Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source.
Owner	Individual or group that holds or possesses the rights of and the responsibilities for an enterprise, entity or asset.

Counter Fraud

Counter-Fraud Framework
No: 000044021528 Date(g): 11/10/2022 | Date(h): 16/3/1444 Status: In-Force
Based on the supervisory and regulatory role of SAMA, and its commitment to enhancing the protection of the banking sector and its customers from financial fraud and fraudulent practices, and pursuant to the powers vested in it under its Law issued by Royal Decree No. (M/36) dated 11/4/1442H, and other related regulations,
We attach the updated version of the Counter Fraud Framework, which aims to improve the level of practices in combating fraud through the implementation of a set of controls that contribute to proactively and effectively enhancing fraud prevention maturity to mitigate fraud risks. Banks operating in the Kingdom are required to comply with its provisions according to the following procedures:
1. Conduct an accurate assessment of the current state of fraud prevention measures compared to the Counter Fraud Framework (Gap Assessment); to identify weaknesses within the bank and evaluate the maturity level as defined in the framework, providing SAMA with monthly reports starting from November 30, 2022G.
2. Develop a Roadmap to achieve at least the third maturity level for the controls outlined in the framework within nine (9) months from this date, following an accurate assessment of the current state of the bank's environment, and submit it to SAMA no later than November 30, 2022G.
3. Obtain the approval of the bank's Board of Directors on the Roadmap and the necessary means of support for its implementation.
4. The bank must fully comply with the requirements of the Counter Fraud Framework by no later than June 29, 2023G.
5. Prepare a detailed annual report by the Internal Audit Department – with the option to engage consulting firms – outlining the level of compliance with the Counter Fraud Framework requirements, starting from the end of Q4 2023G.
6. Submit the Roadmap mentioned in item (2) and the reports referenced in items (1) and (5) to the email address: CRC.compliance@SAMA.GOV.sa.
7. The attached Counter Fraud Framework replaces the previous framework issued under Circular No. (41071315) dated 27/12/1441H, effective from June 29, 2023G.
For your information and compliance effective immediately.

1. Introduction

1.1. Introduction to the Framework
The advancement of technology has brought rapid changes in the financial sector. While allowing customers instant access to products and services, this digital transformation has increased their vulnerability to fraud. Small scale incidents impacting individuals have been replaced by large scale cyber-enabled fraud attacks orchestrated by international organised groups. These attacks expose customers to ever more sophisticated threats and it is vital that financial institutions properly safeguard assets and mitigate the risk of customers being exploited. Fraud not only causes emotional harm and financial losses to customers, it can also damage the reputation and financial health of organisations, reducing confidence in the overall financial sector in the Kingdom of Saudi Arabia.

The financial sector recognizes the rate at which fraud risks are evolving and the importance of controls to prevent, detect and respond to suspected fraud. Delivering an effective approach to fraud risk management will help the Kingdom of Saudi Arabia achieve the 2030 Vision aim to build a stable, thriving, and diversified business environment while protecting members of society and making the Kingdom an unattractive place for fraudsters.

The Saudi Central Bank* ("SAMA") has established a Counter-Fraud Framework (“the Framework”) to enable organisations it regulates ("the Member Organisations”) to effectively identify and address risks related to fraud. The objectives of the Framework are as follows:
1. To create a common approach for addressing fraud risks within the Member Organisations.
2. To achieve an appropriate maturity level of fraud controls within the Member Organisations.
3. To ensure fraud risks are properly managed throughout the Member Organisations.
The Framework will be used to periodically assess the maturity level and evaluate the effectiveness of the Counter-Fraud controls at Member Organisations. The Framework is based on SAMA requirements and industry fraud standards.
* The "Saudi Arabian Monetary Agency" was replaced by the "Saudi Central Bank" in accordance with The Saudi Central Bank Law No. (M/36), dated 11/04/1442H, corresponding in 26/11/2020G.

1.2. Definition of Fraud
Fraud is defined as any intentional act that aims to obtain an unlawful benefit or cause loss to another party. This can be caused by exploiting technical or documentary means, relationships or social means, using functional powers, or deliberately neglecting or exploiting weaknesses in systems or standards, directly or indirectly.
To support the definition of fraud, Member Organisations should take note of the non-exhaustive list of fraud types included in the Appendix.

1.3. Scope
The Framework defines Principles and Control Requirements for initiating, implementing, maintaining, monitoring, and improving Counter-Fraud controls within Member Organisations regulated by SAMA. The Principles and Control Requirements span the prevention, detection, and response to fraud, as well as the governance of an organisation’s Counter-Fraud Programme. The Framework should be implemented in conjunction with other SAMA frameworks, in particular SAMA’s Cyber Security Framework (“The Cyber Security Framework”), which should be referred to for specific Cyber Security related requirements.

1.4. Applicability
The Framework is applicable to all Member Organisations operating in Saudi Arabia based on SAMA discretion. Member Organisations required to implement and comply with the Framework will be notified by SAMA.

1.5. Responsibilities
The Framework is mandated by SAMA and will be circulated to Member Organisations for implementation. SAMA is the owner and is responsible for periodically updating the Framework. The Member Organisations are responsible for implementing and complying with the Framework.

1.6. Interpretation
SAMA, as the owner of the Framework, is solely responsible for providing interpretations of the Principles and Control Requirements, if required.

1.7. Target Audience
The Framework is intended for Senior and Executive Management, business owners, members of the Member Organisation’s Counter-Fraud Department and those who are responsible for, and involved in planning, defining, implementing, and reviewing CounterFraud controls across the three lines of defence.

1.8. Review, Updates and Maintenance
SAMA will review the Framework periodically to determine the Framework’s effectiveness, including the effectiveness of the Framework to address emerging fraud threats and risks. If applicable, SAMA will update the Framework based on the outcome of the review.
If a Member Organisation considers that an update to the Framework is required, the Member Organisation should formally submit the requested update to SAMA. SAMA will review the requested update, and if applicable, the Framework will be adjusted on the next updated version. The Member Organisation will remain responsible to be compliant with the Framework pending the version update.
Please refer to ‘Appendix C - How to request an Update to the Framework’ for the process of requesting an update to the Framework.
Version control will be implemented for maintaining the Framework. Whenever any changes are made, the preceding version shall be retired and the new version shall be published and communicated to all Member Organisations. For the convenience of the Member Organisations, changes to the Framework shall be clearly indicated.

1.9. Reading Guide
The Framework is structured as follows. Chapter 2 elaborates on the structure of the Framework and provides instructions on how to apply the Framework. Chapters 3 to 6 present the actual Framework, including the Counter-Fraud domains and sub-domains, Principles, and Control Requirements.

2. Framework Structure and Features

2.1. Structure

The Framework is structured around four main domains, namely:

Governance
Prevent
Detect
Respond

For each domain, several sub-domains are defined. A sub-domain focuses on a specific Counter-Fraud topic. Where it is helpful to further delineate Control Requirements, a subdomain is split into sub-sectors. Per sub-domain (or sub-section), the Framework states a Principle and related Control Requirements.

A Principle summarises the main set of Counter-Fraud controls related to the sub-domain (or sub-section).
The Control Requirements reflect the mandated Counter-Fraud controls that should be considered by Member Organisations when designing and implementing a Counter-Fraud Programme.

The Framework should be implemented in view of the sub-domains’ Principles along with its associated Control Requirements.

Control Requirements have been uniquely numbered according to the following numbering system throughout the Framework:

Figure 1 - Control Requirements Numbering System

The figure below illustrates the overall structure of the Framework and indicates the Counter-Fraud Framework domains, sub-domains, and sub-sectors, including a reference to the applicable section of the Framework.

Figure 2 - Counter-Fraud Framework Structure

To aid consistency of implementation in Member Organisations, Appendix A contains a glossary of defined terms. Where a defined term is used in the domains and sub-domains in Chapters 3 to 6, it is included in italicised text (e.g., internal fraud, Fraud Risk Assessment, Intelligence Monitoring etc.).

2.2. Principle-Based
The Framework is principle-based, supported by a specific set of Control Requirements, allowing Member Organisations to adopt a risk-based approach within the applicable laws of the KSA. This means that it prescribes key Counter-Fraud principles to be embedded and achieved by the Member Organisations. The list of mandated Control Requirements provides additional direction and should be considered by Member Organisations. When a certain Control Requirement cannot be implemented, the Member Organisation should follow an exception process involving the consideration of compensating controls proportionate to business operations, pursuing an internal risk acceptance and finally requesting a formal waiver from SAMA. Approval of waiver requests will be at the discretion of SAMA. Please refer to Appendix E for details for the - How to request a Waiver from the Framework - process.

2.3. Self-Assessment, Review and Audit
The implementation of the Framework at the Member Organisations will be subject to a periodic self-assessment. The self-assessment will be performed by the Member Organisations based on a questionnaire. The self-assessments will be reviewed and audited by SAMA to determine the level of compliance with the Framework and the Counter-Fraud maturity level of the Member Organisations. Please refer to '2.4 Counter-Fraud Maturity Model' for more details about the Counter-Fraud Maturity Model.

2.4. Counter-Fraud Maturity Model

The Counter-Fraud maturity level will be measured with the help of a predefined maturity model. The Counter-Fraud Maturity Model distinguishes 6 maturity levels (0, 1, 2, 3, 4 and 5), which are summarised in the table below. In order to achieve levels 3, 4 or 5, Member Organisations should first meet all criteria of the preceding maturity levels.

Maturity Level	Definition and Criteria	Explanation
0 Non-existent	No documentation. There is no awareness or attention for certain Counter-Fraud controls.	Counter-Fraud controls are not in place. There may be no awareness of the particular risk area or no current plans to implement such Counter- Fraud controls.
1 Ad-hoc	Counter-Fraud controls are not or partially defined. Counter-Fraud controls are performed in an inconsistent way. Counter-Fraud controls are not fully defined.	Counter-Fraud control design and execution varies by department or owner. Counter-Fraud control design may only partially mitigate the identified risk and execution may be inconsistent.
2 Repeatable but informal	The execution of the Counter-Fraud controls is based on an informal and unwritten, though standardised, practice.	Repeatable Counter-Fraud controls are in place. However, the control objectives and design are not formally defined or approved. There is limited consideration for a structured review or testing of a control.
3 Structured and formalised	Counter-Fraud controls are defined, approved, and implemented in a structured and formalised way. Fraud detection system capability is implemented and embedded. The implementation of Counter-Fraud controls can be demonstrated. Reporting is in place to monitor Counter-Fraud control performance.	Counter-Fraud policies, standards and procedures are established Counter-Fraud controls are implemented and embedded. Fraud detection system capability is in place to prevent and proactively detect fraud across all products and channels. Compliance with Counter-Fraud documentation (i.e., policies, standards, and procedures) is monitored, preferably using a governance, risk, and compliance tool (GRC). Key Performance Indicators are defined and reported to monitor the implementation of controls.
4 Managed and measurable	The effectiveness of Counter-Fraud controls is periodically assessed and improved when necessary. This periodic measurement, evaluations and opportunities for improvement are documented.	Effectiveness of implemented Counter- Fraud controls is measured and periodically evaluated. Key Risk Indicators and trend reporting are used to monitor position against risk appetite and give an early warning of potential emerging issues. Results of measurement and evaluation are used to identify opportunities for improvement of the Counter-Fraud controls.
5 Adaptive	Counter-Fraud controls are subject to a continuous improvement plan.	The enterprise-wide Counter-Fraud Programme focuses on continuous compliance, effectiveness, and improvement of the Counter-Fraud controls. Counter-Fraud controls are integrated with enterprise risk management framework and practices.

Table 1 - Counter-Fraud Maturity Model

The objective of the Framework is to create an effective approach for addressing and managing Counter-Fraud risks within the financial sector. To achieve an appropriate CounterFraud maturity level, the Member Organisations should at least operate at maturity level 3 or higher as explained below.

2.4.1. Maturity Level 3
To achieve level 3 maturity, a Member Organisation should define, approve, and implement Counter-Fraud controls in line with the Control Requirements of this Framework. This includes the implementation of fraud detection system capability to prevent and proactively detect fraud.
In addition, a Member Organisation should monitor compliance with the Counter-Fraud documentation. The Counter-Fraud documentation should clearly indicate "why", "what" and "how" Counter-Fraud controls should be implemented. The Counter-Fraud documentation consists of Counter-Fraud policies, standards, and procedures.

Figure 3 - Counter-Fraud Documentation Pyramid

The Counter-Fraud Policy should be endorsed and mandated by the Board of the Member Organisation and state "why" countering fraud and protecting customers is important to the Member Organisation. The policy should highlight the overall scope of the Counter-Fraud
Programme, key Counter-Fraud responsibilities and “what” Counter-Fraud principles and objectives should be established.
Based on the Counter-Fraud Policy, Counter-Fraud standards should be developed. These standards define "what" Counter-Fraud controls should be implemented, such as, Due Diligence, authentication, prevention, and detection etc. The standards support and reinforce the Counter-Fraud Policy and are to be considered as Counter-Fraud baselines.
The step-by-step tasks and activities that should be performed by staff of the Member Organisation are detailed in the Counter-Fraud procedures. These procedures prescribe "how" the Counter-Fraud controls, tasks and activities have to be executed in the operating environment.
The actual progress of the implementation, performance and compliance of the Counter-Fraud controls should be periodically monitored using Key Performance Indicators (KPIs).

2.4.2. Maturity Level 4
To achieve maturity level 4, Member Organisations should periodically measure and evaluate the effectiveness of the Counter-Fraud controls implemented to achieve maturity level 3. In order to measure and evaluate whether the Counter-Fraud controls are effective, Key Risk Indicators (KRIs) should be defined. A KRI indicates the norm for effectiveness measurement and should define thresholds to determine whether the actual result of measurement is below, on, or above the targeted norm. KRIs are used to monitor a potential increase in fraud risk exposure and allow actions to be taken to mitigate the risk before an increase in fraud cases occurs.

2.4.3. Maturity Level 5
Maturity level 5 focuses on the continuous improvement of Counter-Fraud controls. Continuous improvement is achieved through continuously analysing the goals and achievements of Counter-Fraud governance and identifying structural improvements. Counter-Fraud controls should be integrated with enterprise risk management practices and supported with automated real-time monitoring to assess control effectiveness. Business process owners should be accountable for monitoring the compliance of the Counter-Fraud controls, measuring the effectiveness of the Counter-Fraud controls, and incorporating the Counter-Fraud controls within the enterprise risk management framework.

3. Governance
The Board and Executive Leadership of the Member Organisation is ultimately responsible for creation of a Counter-Fraud Programme; providing leadership and direction; and projecting a Counter-Fraud culture inside and outside the organisation. The programme should include a Counter-Fraud Strategy to define organisational objectives, a Counter-Fraud Policy outlining responsibilities and mandatory requirements, and a Governance Structure with associated internal and external reporting aligned to the organisation's size and complexity to monitor and oversee fraud risk management.

Figure 4 - Governance Domain

3.1. Governance Structure

Principle
Member Organisations should establish and maintain a Counter-Fraud Governance Structure owned by Senior Management with responsibility for oversight and control of all aspects of the organisational Counter-Fraud Programme.
Control Requirements
a.	Member Organisations should establish and maintain a dedicated Counter-Fraud Governance Committee (CFGC).
b.	The CFGC should be headed by a member of the Executive Committee (e.g., CEO, CRO or equivalent).
c.	The following positions at a minimum should be represented in the CFGC:
	1.	Head of Counter-Fraud/Senior Manager accountable for the Counter-Fraud Programme.
	2.	Chief Risk Officer.
	3.	Chief Operating Officer.
	4.	Head of Digital.
	5.	Heads of relevant business departments or product owners (e.g., General Manager of Retail/Corporate).
	6.	Senior Managers from all departments involved in fraud risk management (e.g., Operational Risk Management, Cyber Security, Counter-Fraud Department, Analytics, Compliance).
	7.	Internal Audit should attend as an “observer”.
d.	A CFGC charter should be developed, approved, and reflect the following:
	1.	Committee objectives.
	2.	Authority and accountability of the committee.
	3.	Roles and responsibilities.
	4.	Minimum number and role of meeting participants required to meet quorum.
	5.	Meeting frequency (minimum on a quarterly basis).
	6.	Escalation process for fraud issues or incidents to Board level.
	7.	Documentation and retention of meeting minutes and decisions.
e.	The CFGC should at a minimum be responsible for:
	1.	Approving, supporting, communicating, and monitoring:
		a.	Counter-Fraud Strategy.
		b.	Counter-Fraud Policy.
		c.	Fraud Risk Management Framework that should include at a minimum:
			i.	Intelligence Monitoring process.
			ii.	Fraud Risk Assessment.
			iii.	Fraud Risk Appetite
			iv.	KRIs for fraud.
		d.	Management Information
	2.	Providing leadership, direction, and oversight of the Member Organisation’s Counter-Fraud Programme.
f.	Member Organisations should appoint an appropriately qualified and experienced Head of Counter-Fraud as accountable for the Counter-Fraud Programme at Senior Management level (see control requirement 3.5.e).
g.	Member Organisations should establish a documented and approved process for Counter-Fraud budget and spending prioritisation which should align with fraud strategic objectives.
h.	The overall Counter-Fraud budget should be monitored, reviewed periodically, and adjusted accordingly by the CFGC to meet the Counter-Fraud and business needs.
i.	Member Organisations should define roles and responsibilities of Senior Management and Counter-Fraud Department employees using a responsibility assignment matrix, also known as RACI. The RACI Matrix should outline who is responsible and accountable for Counter-Fraud processes and controls, as well as who should be consulted or informed.

3.2. Counter-Fraud Strategy

Principle
Member Organisations should define, approve, implement and maintain a Counter-Fraud Strategy aligning to the overall strategic objectives of the organisation that identifies short and long-term Counter-Fraud initiatives and communicates a plan of action to achieve them.
Control Requirements
a.	Counter-Fraud Strategy should be defined, approved, implemented and maintained.
b.	Counter-Fraud strategic initiatives should be translated into a defined roadmap including but not limited to, consideration of:
	1.	Timescales to deliver initiatives.
	2.	The owner responsible for delivering the initiative.
	3.	How the initiatives will close the gaps between current and target environments.
	4.	The integration of initiatives into a coherent Counter-Fraud Strategy that aligns with the business strategy.
	5.	Dependencies, overlaps, synergies and impacts among projects, and prioritisation.
c.	Counter-Fraud Strategy should be aligned with:
	1.	The Member Organisation’s overall business strategic objectives.
	2.	Broader strategies that may influence fraud risks and controls, e.g., Cyber Security, IT, Financial Crime (Anti-Money Laundering (AML) & Customer Due Diligence (CDD)).
	3.	Legal and regulatory compliance requirements of the Member Organisation and any other applicable laws in the Kingdom of Saudi Arabia (KSA).
d.	Counter-Fraud Strategy should at a minimum address:
	1.	The current state maturity of the Member Organisation, including the most significant fraud related challenges faced.
	2.	The people, process, and technology requirements to deliver the strategy and proactively manage fraud within risk appetite.
	3.	The future direction of the Member Organisation’s Counter-Fraud Programme, and the initiatives required to successfully migrate to the desired future state.
	4.	Known changes to the fraud landscape (e.g., the increasing digitalisation of financial services products, new external threats, new regulation, or guidance).
e.	A Member Organisation should review and when required update its Counter-Fraud Strategy on a periodic basis or whenever there is a material change:
	1.	Internally (e.g., the Member Organisation’s business model, operational environment, or business strategy).
	2.	Externally (e.g., the fraud landscape or applicable laws and regulations).

3.3. Counter-Fraud Policy and Procedures

Principle
Member Organisations should define, approve, communicate, and implement a Counter-Fraud Policy to set the commitment and objectives for Counter-Fraud and provide requirements to relevant stakeholders; and associated procedures to outline the step-by-step tasks and activities that should be performed by employees.
Control Requirements
a.	Counter-Fraud Policy and procedures should be defined, approved, communicated and implemented.
b.	Counter-Fraud Policy and procedures should take into consideration the risks identified in the Fraud Risk Assessment, the evolving fraud landscape and the Member Organisation’s business model and operations, and should be periodically reviewed to ensure the identified risks are managed effectively.
c.	Counter-Fraud Policy should be readily accessible to all employees, contractors and relevant third parties, including all branches and majority-owned subsidiaries.
d.	Counter-Fraud Policy should require Member Organisations to follow all applicable Counter-Fraud laws and regulations, and payment operator requirements.
e.	Counter-Fraud Policy should include at a minimum, the following:
	1.	A defined owner of appropriate seniority and role (e.g., Head of Counter-Fraud).
	2.	The Member Organisation’s overall fraud objectives and scope.
	3.	A statement of the Board’s intent, supporting the fraud objectives.
	4.	Core requirements to provide a consistent, proportionate, and effective approach to the management of fraud risk.
	5.	Responsibilities for key stakeholders and relevant third parties who play a role in fraud governance, prevention, detection, or response across the three lines of defence (e.g., Senior Management, Compliance, Internal Audit).
	6.	Escalation and reporting requirements in the event of a policy breach.
f.	Counter-Fraud procedures should outline the step-by-step tasks and activities that should be performed by employees in the operating environment for Counter-Fraud process and control operation (e.g., product risk assessment, alert handling, investigations).
g.	For Member Organisations with a headquarters in the KSA, the Counter-Fraud Policy should apply across all international branches and subsidiaries. If the law of another jurisdiction prohibits compliance, an exemption should be documented and approved.

3.4. Roles and Responsibilities

Principle
Member Organisations should define, approve and implement Counter-Fraud roles and responsibilities across the three lines of defence and all relevant stakeholders should have an adequate level of understanding of the expectations related to their role.
Control Requirements
a.	Member Organisations should define, approve and implement Counter-Fraud roles and responsibilities for all relevant stakeholders and ensure they have been communicated and understood.
b.	The Board should be accountable for:
	1.	The establishment of a Counter-Fraud Programme.
	2.	Setting the tone from the top to establish a Counter-Fraud culture through a Code of Conduct (or equivalent).
	3.	Ensuring that a robust Fraud Risk Management framework is established and maintained to manage fraud risks.
	4.	Ensuring that sufficient budget for Counter-Fraud is allocated, utilised, and monitored.
	5.	Approving the CFGC charter.
	6.	Endorsing (after being approved by the CFGC):
		a.	The roles and responsibilities of Senior Management accountable for the Counter-Fraud Programme.
		b.	The Counter-Fraud Strategy.
		c.	The Counter-Fraud Policy.
		d.	The output of the Fraud Risk Assessment.
		e.	Fraud Risk Appetite.
c.	The Head of Counter-Fraud should be accountable for:
	1.	Developing, implementing, and maintaining:
		a.	Counter-Fraud Strategy.
		b.	Counter-Fraud Policy.
		c.	Fraud Risk Assessment.
		d.	Fraud Risk Appetite.
		e.	KRIs for fraud.
	2.	Reinforcing and maintaining the tone from the top to deliver a culture of compliance with the Code of Conduct.
	3.	Developing a risk-based Counter-Fraud Programme that addresses people, process, and technology, including adequate systems to prevent, detect and respond to fraud.
	4.	Ensuring that detailed Counter-Fraud standards and procedures are established, approved, and implemented.
	5.	Ensuring that Counter-Fraud systems and controls remain effective in light of evolving threats identified through Intelligence Monitoring.
	6.	Periodically informing CFGC on the latest developments on Counter-Fraud strategic initiatives and implementation status.
	7.	Establishing a Counter-Fraud Department that is adequately resourced and has responsibility for the requirements outlined in sub-domain 3.5.
	8.	Collating and overseeing organisation-wide Management Information reporting produced in relation to Counter-Fraud risks and performance.
	9.	Promptly notifying SAMA of new fraud typologies and significant fraud incidents in line with the Supervisory Notification requirements included in sub-domain 3.7.
	10.	Taking action when a notification is received of any significant fraud incidents, investigations or breaches of Counter-Fraud policy or standards, and reporting to the Board or CFGC as required.
	11.	Defining the organisation’s ongoing fraud awareness programme in coordination with relevant departments (e.g., operations, Communications, Human Resources (HR)).
d.	At a minimum, Senior Management should be accountable for:
	1.	Ensuring that employees are compliant with the Code of Conduct and CounterFraud policies, standards, and procedures.
	2.	Ensuring that employees receive training in line with the requirements of the fraud training and awareness programme.
	3.	Developing and reviewing regular Management Information reporting to monitor Counter-Fraud risks and performance.
	4.	Notifying the CFGC where escalation is required (e.g., adverse internal findings relating to Counter-fraud controls or fraud risk appetite is exceeded).
	5.	Managing fraud losses through processes and controls in own area of accountability within the organisation’s agreed Fraud Risk Appetite.
	6.	Maintaining appropriate systems and controls to prevent, detect and respond to fraud.
e.	Manager(s) accountable for fraud operations (e.g., managing fraud alerts, responding to reported fraud and dealing with fraud cases) should be responsible for:
	1.	Ensuring that all suspected fraud, including system alerts and manual employee and customer referrals are adequately prioritised, investigated and the outcome is appropriately recorded.
	2.	Taking immediate steps to prevent further exposure and corrective action(s) when a fraud is identified.
	3.	Notifying relevant external parties (e.g., law enforcement).
f.	The Internal Audit function should be responsible for:
	1.	The identification of a comprehensive set of auditable areas for fraud risk.
	2.	Assessment and prioritisation of fraud risks during audit planning.
	3.	Performing fraud audits and producing independent objective reports.
g.	All Member Organisation employees should be responsible for:
	1.	Complying with applicable Counter-Fraud policies, standards, and procedures.
	2.	Reporting any suspicions of fraud in a timely manner.
h.	Member Organisations should ensure that suspected or actual cases of internal fraud are investigated by individuals of appropriate seniority (e.g., if the fraud involves a manager, an individual of higher seniority should take responsibility for the oversight and approval of the investigation); and independence (e.g., internal audit or an equivalent control function should conduct the investigation with the investigators free from potential conflicts of interest).
i.	Member Organisations should periodically review the roles and responsibilities of employees with fraud related responsibilities to ensure they reflect best practice, address trending fraud typologies and are aligned with the fraud landscape and business model.
j.	Member Organisations should develop a formal Counter-Fraud succession plan in coordination with the HR Department taking into consideration the reliance on key Counter-Fraud employees having critical roles and responsibilities.

3.5. Counter-Fraud Department

Principle
Member Organisations should establish and maintain a Counter-Fraud Department that has responsibility for the day-to-day operation of the Counter-Fraud Programme.
Control Requirements
a.	Member Organisations should establish and maintain a Counter-Fraud Department that has responsibility for the day-to-day operation of the Counter-Fraud Programme, including at a minimum:
	1.	Monitoring and overseeing compliance with Counter-Fraud policies, standards, and procedures.
	2.	Designing and implementing organisation wide required counter-fraud controls covering people, process and technology dimensions.
	3.	Performing an in-depth organisation wide Fraud Risk Assessment.
	4.	Analysis of Counter-Fraud data and intelligence to proactively identify fraud trends.
	5.	Sharing Counter-Fraud Intelligence with SAMA and other organisations in the sector.
	6.	Proactively and reactively tuning Counter-Fraud systems.
	7.	Monitoring of Counter-Fraud Operations.
	8.	Performing comprehensive fraud investigations, identifying root causes of fraud incidents and documenting corrective actions.
	9.	Monitoring Fraud Risk Appetite measures and actively engaging a crisis management task force if the defined limit is breached with an impact on customers (see control requirement 4.1.3.d).
	10.	Ensuring alignment of Counter-Fraud capabilities with Cyber Security and Financial Crime.
	11.	Periodic reporting to senior management covering at minimum:
		a.	Fraud Risk Assessment results.
		b.	Fraud typologies identified.
		c.	Fraud Risk Appetite measures and performance against thresholds and limits.
		d.	Operational and customer fraud losses.
b.	Member Organisations should assess the most appropriate reporting line for the CounterFraud Department based on organisational structure; decision making authority; visibility to the Executive Committee/Board; and Senior Management accountability and responsibilities.
c.	Member Organisations should evaluate the staffing requirements of the Counter-Fraud Department on a periodic basis and in response to material changes to the business, operational and fraud landscape or the Member Organisation Fraud Risk Assessment.
d.	Evaluation of staffing requirements should consider both the capacity (number of resources) and the capability (skills and experience) required.
e.	The Head of Counter-Fraud should have skills and experience at a minimum consisting of:
	1.	An in-depth understanding of fraud risks in the financial sector.
	2.	Strong knowledge of digital fraud threats and common typologies, along with emerging trends impacting financial sector organisations and their customers.
	3.	Designing and implementing technology and controls based on use-cases to mitigate fraud risks and threats.
	4.	The use of data and analytics to proactively prevent fraud and protect customers.
f.	The Counter-Fraud Department should at a minimum include employees with skills and experience in:
	1.	Fraud risks and typologies related to the products offered by the organisation (e.g., experience in payment fraud; scams; and social engineering).
	2.	Fraud risks and typologies related to the delivery channels offered by the organisation, in particular digital channels such as online and mobile.
	3.	Counter-Fraud data analytics to enable the analysis of large volumes of transactions and proactive identification of fraud threats.
	4.	Counter-Fraud technology to ensure systems are operating effectively with scenarios relevant to the risks faced by the Member Organisation.
	5.	The analysis of intelligence and data to identify fraud trends and the root cause of fraud incidents.
	6.	Fraud investigations, from initial notification of a potential incident to closure and corrective actions.
	7.	Reporting and production of Management Information to monitor organisational fraud performance.
g.	Member Organisations should consider fraud qualifications for roles in the Counter-Fraud Department.
h.	Member Organisations should establish a training plan and provide periodic training to develop and maintain the competency of the employees in the Counter-Fraud Department.
i.	Where third party services or resources (e.g., contractors or Managed Services) are used to fulfil responsibilities of the Counter-Fraud Department, Member Organisations should ensure the resource is appropriately vetted and monitored.

3.6. Management Information

Principle
Member Organisations should define, approve and implement a process for the reporting of Management Information to enable Senior Management to monitor Counter-Fraud risks and performance.
Control Requirements
a.	Member Organisations should define, approve and implement a process for the reporting of Management Information to monitor Counter-Fraud risks and performance.
b.	Fraud Management Information should be reported to Senior Management and the CFGC on a periodic basis and on an ad hoc basis as required (e.g., if a new or unusual typology is identified).
c.	Member Organisations should coordinate the collation of fraud Management Information to ensure a holistic picture can be reported of all fraud impacting the organisation or its customers.
d.	Member Organisations should identify appropriate Management Information to adequately inform Senior Management of Counter-Fraud risks and performance. At a minimum this should include:
	1.	Fraud Risk Assessment results.
	2.	Fraud Risk Appetite measures and performance against thresholds and limits.
	3.	Volume of fraud alerts notified by:
		a.	Customers
		b.	Employees
		c.	Fraud systems
	4.	Volume and trends of Fraud cases handled, split by product and typology.
	5.	New typologies identified.
	6.	Value of near misses or potential frauds that were detected and prevented.
	7.	Case value of fraud handled (the total value of the fraud case, including actual and potential losses).
	8.	Fraud losses, split by product, payment type (where applicable) and typology, including:
		a.	Customer losses
		b.	Operational losses.
	9.	Value of customer refunds following fraud.

3.7. Supervisory Notifications

Principle
Member Organisations should immediately notify SAMA of new fraud typologies and significant fraud incidents to mitigate the risk of the fraud impacting additional customers, other organisations, or the financial sector in the KSA.
Control Requirements
a.	Member Organisations should notify SAMA General Department of Cyber Risk Control immediately of the following:
	1.	Any new fraudulent typology whether it resulted in financial loss or not (e.g., type of fraud not previously observed or new scam attempt detected).
	2.	Where an external person has committed or attempted to commit a significant fraud against it.
	3.	Where an employee of a Member Organisation has committed a significant internal fraud against one of its customers or may be guilty of serious misconduct concerning honesty or integrity related to the organisation's regulatory obligations.
	4.	Where Wholesale Payment Endpoint Security Fraud is suspected or identified.
	5.	Where a significant irregularity is identified in the organisation's accounting records that may be indicative of fraud.
b.	When assessing whether a fraud is considered significant to meet the notification requirements above, Member Organisations should consider at a minimum:
	1.	The value of any monetary loss or potential monetary loss to the organisation or its customers (the value should consider an individual fraud incident or total losses from connected incidents).
	2.	The number of customers impacted.
	3.	Reputational damage to the organisation and the wider financial sector.
	4.	Whether any regulation has been breached.
	5.	Whether the incident reflects weaknesses in the organisation's Counter-Fraud controls.
	6.	If the incident has the potential to impact other Member Organisations.
c.	Member Organisations should use the standard reporting template in Appendix G to notify SAMA.
d.	At a minimum, Member Organisations should include the origin of the incident; the methods used; related parties (internal and external); corrective actions; and losses, if any, in the notification to SAMA. Where all required information is not available at the time of notification, any gaps should be supplied to SAMA promptly as the investigation progresses.

3.8. Counter-Fraud Technology

Principle
Member Organisations should define, approve and implement a strategy for the sourcing or development and implementation of counter-fraud systems and technology to manage the fraud risks they are exposed to.
Control Requirements
a.	Member Organisations should define, approve and implement a strategy for the sourcing or development of Counter-Fraud systems and technology to prevent, detect and respond to fraud.
b.	Member Organisations should implement Counter-Fraud systems and technology and verify that they are operating as intended.
c.	The output of the Fraud Risk Assessment should inform the technology required, and systems should be proportionate to the risk appetite of the organisation.
d.	Whether a fraud system is sourced from a vendor or developed in-house, Member Organisations should consider the below requirements at a minimum:
	1.	The Counter-Fraud Department are engaged in the design and implementation of the system with oversight from the CFGC.
	2.	The rationale for scenarios developed and thresholds applied is documented.
	3.	The system and rules are designed or can be customised to align to the products, services, and fraud risks of the organisation.
	4.	New rules can be implemented on a timely basis to target prevention and detection of new or emerging typologies identified through Intelligence Monitoring.
	5.	Awareness of rules to prevent and detect potential internal fraud is limited to a restricted, documented set of roles which does not include employees or third parties responsible for the operation of processes and controls being monitored (e.g., branch/customer facing staff or operational payments teams).
	6.	Configuration changes should follow the System Change Management Principles and Control Requirements in SAMA’s Information Technology Governance Framework (“The IT Governance Framework”).
	7.	The organisation can explain and outline the fraud threats that scenarios are designed to monitor and mitigate.
	8.	Where Machine Learning or Artificial Intelligence are used the system should not be 'black box' and should be capable of being audited (e.g., the organisation should have the capability to test what the algorithms are designed to do and whether they are correctly implemented).
	9.	Business Continuity and IT Disaster Recovery Plans are in place aligned to the requirements of the SAMA Business Continuity Management Framework.

3.9. Counter-Fraud Internal Audits

Principle
Member Organisations should conduct audits in accordance with generally accepted auditing standards and relevant SAMA framework(s) to verify that the fraud control design is adequately implemented and operating as intended.
Control Requirements
a.	Member Organisations should ensure that Counter-Fraud audits are performed independently and according to generally accepted auditing standards and relevant SAMA frameworks.
b.	Member Organisations should establish an audit cycle that determines the frequency of Counter-Fraud audits.
c.	Member Organisations should develop a formal Counter-Fraud audit plan addressing people, process and technology components.
d.	The frequency of Counter-Fraud audit should be aligned with the output of the Fraud Risk Assessment and consider the criticality and risk of the Counter-Fraud system, control or process.
e.	The Internal Audit function of Member Organisations should complete periodic validation of the implementation of Counter-Fraud related corrective actions, including those resulting from SAMA instruction.
f.	Member Organisations should ensure that the Counter-Fraud auditors have the requisite level of competencies and skills to effectively assess and evaluate the adequacy of Counter-Fraud policies, procedures, processes and controls implemented.
g.	Counter-Fraud audit reports, at a minimum, should:
	1.	Include the findings, recommendations, management's response with defined action plan, and responsible party and limitations in scope with respect to the Counter-Fraud audits.
	2.	Be signed, dated and distributed according to the format defined.
	3.	Be submitted to the audit committee on periodical basis.
h.	A follow-up process for audit observations should be established to track and monitor Counter-Fraud audit observations.

4. Prevent
An effective Counter-Fraud Programme includes fraud prevention processes and controls to facilitate the identification of threats and mitigate the risk of fraud occurring. These processes and controls are proactive and have the objective of stopping a fraudster acting before they can cause harm to the organisation or its customers.

Figure 5 - Prevent Domain

4.1 Risk Management

Principle
A Fraud Risk Management Framework should be defined, approved and implemented, and should be aligned with the Member Organisation’s enterprise risk management process.
Control Requirements
a.	The Fraud Risk Management Framework should be defined, approved and implemented.
b.	The effectiveness of the Fraud Risk Management Framework should be measured and periodically evaluated using Key Performance Indicators, including at a minimum the volume and value of fraud cases.
c.	The Fraud Risk Management Framework should be aligned with the Member Organisation’s enterprise risk management process.
d.	The Fraud Risk Management Framework should address at a minimum:
	1.	Intelligence Monitoring.
	2.	Fraud Risk Assessment.
	3.	Fraud Risk Appetite.
	4.	Key Risk Indicators (KRIs).
e.	Fraud risk management activities should involve, but not be limited to, the following stakeholders:
	1.	Business owners and users.
	2.	Operational Risk.
	3.	Counter-Fraud Department.
	4.	Cyber and IT departments.
	5.	HR.
	6.	Digital Department.

4.1.1 Intelligence Monitoring

Principle
Member Organisations should draw on a variety of internal and external data sources to identify and monitor emerging fraud threats.
Control Requirements
a.	The fraud Intelligence Monitoring process should be defined, approved, and implemented.
b.	When defining the Intelligence Monitoring process, Member Organisations should consider the SAMA Cyber Threat Intelligence Principles.
c.	The effectiveness of fraud Intelligence Monitoring should be subject to periodic evaluation to assess whether the sources used are comprehensive and the intelligence collated is aiding the prevention of fraud.
d.	The Intelligence Monitoring process should include:
	1.	Scanning, collation, analysis, assessment and dissemination of information on existing and emerging threats.
	2.	Capturing relevant details on identified threats, such as modus operandi, actors, motivation, the origin of attacks (e.g., organised crime group, jurisdiction) and type of threats.
	3.	Taking action to act on existing and emerging threats.
	4.	Sharing relevant intelligence with internal and external stakeholders (e.g., Cyber, Business Operations or SAMA).
e.	Intelligence Monitoring activities should draw on a range of information sources to develop a holistic understanding of the Member Organisation’s fraud landscape. At a minimum, these should include:
	1.	Internal Audit reports, fraud investigation output and Fraud Scenario Analysis covering attempted and actual fraud to identify trending fraud tactics, techniques, and procedures (TTPs).
	2.	New and emerging fraud typologies identified by fraud detection systems, fraud investigators or the Counter-Fraud Department.
	3.	Insights from support functions (e.g., Internal Audit, Compliance, Cyber Security Event and Incident Management).
	4.	Reliable and relevant external sources on fraud trends both locally and globally, (e.g., government agencies, fraud forums and events, Counter-Fraud system vendors, open-source information, and subscription sources).
f.	Member Organisations should, to the extent not prohibited by law or contractual terms, collaborate in sharing Counter-Fraud information including emerging fraud typologies, fraud threat intelligence on the groups who may be perpetrating fraud, TTPs and market trends with Saudi Central Bank and other organisations in the sector.
g.	Member Organisations should share log-in information for confirmed fraud cases (e.g., mobile or Device ID, IP address) through the Sectorial Anti-Fraud Committee.
h.	Member Organisations should perform analysis of log-in information shared by other Member Organisations to assess the level of exposure for their own customers and record the actions completed on an analysis log sheet which may be subject to independent review.

4.1.2 Fraud Risk Assessment

Principle
Member Organisations should conduct a Fraud Risk Assessment to identify fraud risks to which they or their customers are subject and assess the effectiveness of controls in place to mitigate the risks.
Control Requirements
a.	A Member Organisation should conduct an enterprise-wide Fraud Risk Assessment as part of its Counter-Fraud Programme.
b.	The Fraud Risk Assessment should be based on a documented Fraud Risk Assessment Methodology.
c.	At a minimum, the Fraud Risk Assessment Methodology should include:
	1.	Identification of the inherent risk of fraud the Member Organisation and its customers are exposed to.
	2.	An assessment of the likelihood of the inherent risks occurring and the impact on the Member Organisation and its customers if the inherent risks were to occur.
	3.	Testing of the effectiveness of the controls in place to prevent, detect and respond to the inherent risks identified.
	4.	Determination of the residual risk of fraud that the Member Organisation remains exposed to following testing of implemented controls.
	5.	The development of action plans to address residual risk that is outside of risk appetite or could lead to a breach of regulations.
	6.	The ongoing monitoring of action plans to validate that the risk is brought within appetite.
d.	Risks identified in the Fraud Risk Assessment should be recorded in a formal centralised register.
e.	Actions to address gaps identified in the Fraud Risk Assessment should be documented in a treatment plan and reviewed for adequacy and effectiveness to reduce risks.
f.	The outcome of the Fraud Risk Assessment should be formally approved by the relevant business owner.
g.	When assessing fraud risks, Member Organisations should consider:
	1.	Both frauds committed by persons outside the organisation (external fraud) and frauds committed by or with the assistance of people employed by the organisation (internal fraud).
	2.	The output of Intelligence Monitoring and threat assessments.
	3.	Fraud incidents and loss events.
	4.	The modelling of potential threats to the organisation through Fraud Scenario Analysis.
	5.	Product risk - Products and services offered and how they could be used to commit fraud.
	6.	Customer risk - The customer base of the organisation, including, but not limited to the type of customer (e.g., Retail customer, corporate or regulated entity); the number of customers; the level of fraud awareness; and vulnerability to fraud.
	7.	Delivery channel risk - Channels that a customer can use to contact the Member Organisation or access their products and services, with particular consideration of the risks of remote interaction as digitalisation of products increases.
	8.	Transaction risk - The methods of conducting transactions, receiving funds, or transferring value.
	9.	Jurisdiction risk - The additional risks where products and services can be used in a foreign country.
	10.	Third Party Risk - The use of third parties to deliver services to the organisation or its customers.
	11.	Wholesale Payment Endpoint Security Risk - End-to-end wholesale payments risks, including communication (Member Organisation to other Member Organisation, Member Organisation to system); systems (Workstation terminal); people; and processes.
h.	Member Organisations should ensure that the Fraud Risk Assessment fully considers cyber enabled fraud, including the interaction with the member organisation's Cyber Security risk management model.
i.	The Fraud Risk Assessment should be performed at a minimum on an annual basis.
j.	Member Organisations should additionally update their Fraud Risk Assessment for changes in the internal or external fraud risk environment. These changes include, but are not limited to:
	1.	A new gap or weakness identified in the control environment.
	2.	New regulatory requirements.
	3.	New products and services.
	4.	New channels to market and new digital platforms.
	5.	New business acquisitions.
	6.	Sale or disposals of parts of the Member Organisation's business.
	7.	Changes in the internal environment (e.g., organisational structure).
	8.	New information obtained in fraud Intelligence Monitoring.

4.1.3 Risk Appetite

Principle
Member Organisations should define, approve, and apply their Fraud Risk Appetite when designing and implementing Counter-Fraud systems and controls.
Control Requirements
a.	The Fraud Risk Appetite of the Member Organisation should be defined to state the level of fraud risk the Member Organisation is willing to tolerate.
b.	The Member Organisation Fraud Risk Appetite should be based on the outcome of the Fraud Risk Assessment and aligned to the overall risk appetite of the organisation.
c.	When defining Fraud Risk Appetite, Member Organisations should put in place measures with associated thresholds and limits that address the impact on both:
	1.	The Member Organisation (e.g., fraud losses, reputational damage); and
	2.	Its customers (e.g., customer losses, number of fraud victims, inconvenience).
d.	In the event that a Fraud Risk Appetite limit is breached with an impact on customers, a Member Organisation should escalate to Senior Management and initiate a crisis management process that should:
	1.	Involve the CEO and other Senior Managers in the Member Organisation.
	2.	Require meetings on at least a weekly basis until the issue is resolved and the measure returns to a level within appetite.
e.	Fraud Risk Appetite should be reviewed on at least an annual basis and be formally endorsed by the Board.
f.	Fraud Risk Appetite should be monitored and updated for material changes to the Member Organisation’s business model.

4.1.4 Key Risk Indicators

Principle
Member Organisations should define, approve, and monitor KRIs to measure and evaluate position against agreed Fraud Risk Appetite and provide an early indication of increasing fraud risk exposure.
Control Requirements
a.	The KRIs defined by the Member Organisation should be based on a documented methodology which should require:
	1.	KRIs to monitor exposure against the risks identified in the Fraud Risk Assessment.
	2.	KRIs to consider risks to the organisation (e.g., fraud losses, reputational impact, operational management of fraud alerts) and its customers (e.g., customer losses).
	3.	KRIs to be approved by the CFGC or wider Risk Committee which governs the Counter-Fraud Programme in line with the requirements included in sub-domain 3.1.
	4.	All KRIs to have a documented owner who is responsible for monitoring the KRI and taking early action if risk exposure exceeds Fraud Risk Appetite.
	5.	KRIs to be periodically reported to Senior Management and relevant stakeholders (minimum on a quarterly basis).
	6.	KRIs to be reviewed and updated at a minimum on an annual basis and more frequently in response to material changes to the fraud landscape or the Member Organisation Fraud Risk Assessment.
b.	KRIs should be forward looking and provide an early indication of increasing fraud risk exposure rather than simply measuring fraud volumes or losses (e.g., controls rated as ineffective in control testing; failure of employees to complete mandatory fraud training; or fraud alerts not reviewed within defined service level agreements).
c.	When developing KRIs, Member Organisations should define thresholds that allow them to determine whether the actual result of measurement is below, on, or above the targeted risk appetite position.
d.	Member Organisations should ensure that metrics associated with KRIs are complete, accurate and generated on a timely basis.

4.2 Due Diligence

Principle
Member Organisations should define, approve and implement standards for assessing the fraud risk associated with employees, customers and third parties to prevent the establishment of relationships outside risk appetite and manage fraud risks throughout the duration of the relationship.
Control Requirements
a.	Due Diligence standards should be defined, communicated, and implemented.
b.	Due Diligence standards should be approved by individuals of appropriate responsibility (e.g., Employee Due Diligence in HR).
c.	Due Diligence standards should consider employees, customers and third parties.
d.	Due Diligence standards should be aligned to the risks identified in the Fraud Risk Assessment.
e.	Member Organisations should review and update Due Diligence standards on a periodic basis and in response to material changes to the fraud landscape, the Member Organisation Fraud Risk Assessment, customer groups serviced by the Member Organisation or changes to the products or services it offers.
f.	The effectiveness of the fraud Due Diligence standards should be measured and periodically evaluated.
g.	Due Diligence standards should include:
	1.	The Due Diligence checks and requirements that should be conducted to provide an informed understanding of fraud risk.
	2.	When Due Diligence should be conducted.
	3.	The role(s) responsible for conducting and approving Due Diligence.
	4.	Red flags or warning signs which may indicate increased fraud risk and result in the requirement for escalation or further checks to be completed.
	5.	Red flags or warning signs which indicate an employee, customer or third party is outside risk appetite and the relationship should be declined or exited.
	6.	Steps to be taken to exit relationships outside risk appetite.

4.2.1 Employee Due Diligence

Principle
Member Organisations should ensure background checks are conducted on employees, including contractors, to reduce the exposure to internal fraud risks and reputational damage resulting from the actions of staff of the Member Organisation.
Control Requirements
a.	Employee Due Diligence measures should reflect the risks of internal fraud impacting the Member Organisation.
b.	Employee Due Diligence should have the objective of establishing the identity, integrity, and verifying the credentials of the employee, enabling the Member Organisation to determine whether they are suitable for the position.
c.	Employee Due Diligence should consist of screening and background checks on the employee, including but not limited to:
	1.	Confirmation of identity.
	2.	Criminal background checks.
	3.	Conflict of interest checks.
	4.	Verification of qualifications claimed.
	5.	Previous employment checks.
d.	Employee Due Diligence should be:
	1.	Conducted as part of the hiring process.
	2.	Reassessed when an existing employee moves to a new role.
	3.	Reperformed periodically on a risk-based approach (e.g., re-performance of screening for criminal or fraudulent behaviour to validate that employees remain suitable for the position).
e.	Member Organisations should assess roles which represent a high risk of fraud and document any enhanced checks required.
f.	The outcome of Employee Due Diligence checks should be retained in line with the Member Organisation’s record management policies for personal information.

4.2.2 Customer Due Diligence

Principle
Member Organisations should establish controls to capture and validate the identity of customers to reduce the exposure to external fraud losses.
Control Requirements
a.	When establishing a new customer relationship, Member Organisations should check and verify the identity of the customer to reasonably ensure that it is not exposed to fraud risk.
b.	Customer Due Diligence should align with the Member Organisation’s policies on Anti Money Laundering (AML) and Countering Terrorist Financing (CTF).
c.	Customer Due Diligence should be conducted as a part of the onboarding process and at appropriate times in the ongoing relationship with the customer (e.g., addition of new credit product).
d.	Customer Due Diligence should be enhanced with additional checks for higher risk customers or in response to a perceived increased fraud threat (e.g., if impersonation is suspected or there is a concern on the validity or legitimacy of documents provided to prove identity or evidence financial history).
e.	Where a customer relationship is initiated on a remote basis (e.g., online), Member Organisations should assess the risk of impersonation and the set-up of mule accounts, implementing appropriate controls to mitigate the risk, including but not limited to:
	1.	Ensuring a phone number or National ID/Iqama is linked to one customer application only. In the event an exception is identified (e.g., dependent family member), additional due diligence checks should be conducted to validate the authenticity of the application and monitoring use cases should be developed.
	2.	Authentication of the account opening request via the National Single Sign-On portal using Biometric based authentication (e.g., facial identification from national trusted party).
	3.	Verification that the ownership of the phone number is registered to the same user through a trusted party (i.e., the name of the account applicant and national ID match).
	4.	Including a one-time-password mechanism (OTP) explaining that a new account is being opened as a form of verification. The OTP must be sent to the verified phone number.
	5.	Notification of the completion of account opening should be sent to verified phone number that is registered for the account as well as to the phone number that is registered in the national single sign-on portal.
	6.	Requiring the use of a registered National Address.
	7.	Where a physical card is to be provided, this should be:
		a.	Sent to the registered National Address of the customer only; or
		b.	Collected from an ATM with the customer verified using biometric authentication.
	8.	Following initial set up, restrictions should be placed on the account (e.g., reduced transaction value limit) until such time as the Member Organisation validates that the customer is genuine (e.g., use of biometric authentication mechanism through facial identification from national trusted party periodically, physical presence in a branch or kiosk supported by biometrics, regular pattern of account activity over a period of time).
	9.	Developing comprehensive use cases to proactively identify potential mule accounts and implementing monitoring of the use cases through detection software (e.g., value of incoming funds, high transaction frequency, transaction patterns that do not fit expected behaviours, sudden increase in activity following dormancy).
	10.	Measuring and periodically evaluating the effectiveness of controls to mitigate the risk of impersonation and set-up of mule accounts.

4.2.3 Third Party Due Diligence

Principle
Member Organisations should ensure proportionate Due Diligence is conducted on third parties to develop an understanding of fraud risk associated with business relationships and ensure third parties are appropriately managed to mitigate the risk.
Control Requirements
a.	Third Party Due Diligence should consist of checks and vetting procedures on a risk-based approach to allow an assessment of the fraud risks presented by the relationship.
b.	Third Party Due Diligence should be conducted prior to entering into a commitment for a new relationship
c.	Third Party Due Diligence should be reviewed periodically or following a trigger which indicates increased fraud risk (e.g., concerns on the conduct of a third party or its employees; or negative media articles).
d.	Third Party Due Diligence should be enhanced for:
	1.	Higher risk third parties or their representatives
	2.	Third parties providing critical services to the Member Organisation.
e.	Enhanced Third Party Due Diligence checks should include additional steps to assess the fraud risks presented by the relationship (e.g., additional vetting or assessing the third party approach to managing the risk of fraud).
f.	Where a Member Organisation outsources services to a third party organisation, that third party should comply with the Member Organisation’s Counter-Fraud Policy or apply an equivalent approach.

4.3 Training and Awareness

Principle
A fraud awareness programme should be defined, approved, and conducted for employees, customers and third parties of the Member Organisation.
Control Requirements
a.	The fraud awareness programme should be defined, approved, and conducted to promote awareness of fraud risks, provide education on preventing, detecting, and responding to potential fraud and create a positive Counter-Fraud culture.
b.	The fraud awareness programme should include coverage of:
	1.	Employees of the Member Organisation.
	2.	Customers of the Member Organisation.
	3.	Third parties who hold relationships with the Member Organisation.
c.	The fraud awareness programme should consist of training, education and awareness materials directly linked to risks and threats identified in the Fraud Risk Assessment.
d.	The fraud awareness programme should:
	1.	Outline the nature, scale and scope of training and education to be delivered.
	2.	Be tailored to the different target groups.
	3.	Be delivered via multiple channels.
e.	The activities of the fraud awareness programme should be conducted periodically and throughout the year.
f.	Member Organisations should ensure that the programme is updated at least annually to account for changes in the fraud threat landscape or in response to new fraud threats identified in Intelligence Monitoring.
g.	Where a new or emerging fraud typology may impact the Member Organisation and its customers, Member Organisations should take immediate action to make employees, customers and relevant third parties aware of the threat and preventive measures to be taken (where applicable).
h.	Member Organisations should monitor and evaluate the effectiveness of the fraud awareness programme and implement improvements where required.

4.3.1 Employee Fraud Training and Awareness

Principle
Member Organisations should define and deliver an employee fraud training and awareness programme to enable employees to identify fraud and report it promptly.
Control Requirements
a.	Counter-Fraud training should enable employees to develop a clear understanding of the Member Organisation's Counter-Fraud policies and procedures and their personal responsibilities in relation to fraud prevention and detection.
b.	Training should be provided to all employees at, or shortly after, onboarding and be refreshed at regular intervals.
c.	The Member Organisation's fraud training and awareness programme should be risk based, including the requirement for certain employees to be provided with specialised training depending upon the fraud risk associated with their role (e.g., managers with positions of authority, customer facing staff in branches, employees operating CounterFraud controls and fraud investigators).
d.	Counter-Fraud training should include a knowledge check to assess whether the employee has understood the content. Employees who do not pass the knowledge check should be required to repeat the training and pass rates should be monitored, with action taken if there are repeated failures (e.g., re-training via another delivery method or removal of authority to operate a Counter-Fraud control until successful).
e.	The Board of Directors and Senior Management at Member Organisations should be provided with fraud training tailored to the seniority of the role (e.g., fraud awareness, setting an appropriate culture and governance).
f.	Formally delivered training should be augmented by ongoing employee education activity to maintain the general fraud awareness of employees (e.g., issuing reminders and circulars on potential indicators of fraud and common fraud typologies).
g.	Member Organisations should maintain records of fraud training delivered to employees and awareness activity conducted.
h.	Member Organisations should have a documented process to manage employees who are non-compliant with the training requirements for their role.

4.3.2 Customer Fraud Awareness

Principle
Member Organisations should define and conduct a customer fraud awareness programme of activity to increase customer understanding of fraud risks; help customers to recognise and resist fraud attempts; and inform them how to report fraud.
Control Requirements
a.	Customer fraud awareness activity should deliver relevant and timely education to customers and promote fraud awareness.
b.	The activity delivered through the customer fraud awareness programme should include, at a minimum:
	1.	Information on the fraud threats and scams customers may be exposed to.
	2.	Customer responsibilities about countering fraud.
	3.	How customers can prevent themselves from becoming victims.
	4.	How to report to the Member Organisation if the customer believes they have been a victim of fraud.
c.	Customer fraud awareness activity should be tailored to the current fraud trends impacting the Member Organisation and its sector, including but not limited to the fraud typologies observed and the point of compromise which led to the fraud (e.g., SMS, email, social media).
d.	Customer fraud awareness activity should cover the duration of the customer lifecycle (e.g., onboarding, changes to product holdings, transactions and settlements).
e.	Member Organisations should deliver customer awareness materials through all communication channels offered to the customer (e.g., website, mobile app, email, post, and SMS).
f.	Member Organisations should provide additional education on fraud protection to customers who may be vulnerable to or have been the victim of a scam (e.g., support on the phone or additional materials via email or post).

4.3.3 Third Party Fraud Awareness

Principle
Member Organisations should define and deliver a proportionate fraud awareness programme to third parties outlining expectations in respect of Counter-Fraud activity and prompt reporting of suspicious activity.
Control Requirements
a.	Third party fraud awareness requirements should be documented and agreed in contractual arrangements where applicable.
b.	Member Organisations should provide risk-based fraud awareness materials to third parties at the outset of a relationship and refresh periodically as required.
c.	Third party fraud awareness requirements should as a minimum include:
	1.	The creation of a positive Counter-Fraud culture.
	2.	Third party roles and responsibilities regarding fraud.
	3.	Tailored messaging aligned to the fraud risks of the services provided by the third party.
	4.	Reporting mechanisms available to the third party.

4.4. Authentication

Principle
Member Organisations should define, approve, implement and maintain a standard for the authentication of customer, employee and third party credentials and instructions to ensure information is protected and unauthorised access or actions are prevented. This should be risk-based and utilise multi-factor authentication.
Control Requirements
a.	A Member Organisation should define, approve, implement and maintain an authentication standard with input from both the Counter-Fraud Department and Cyber Security Team.
b.	A Member Organisation's authentication standard should consider the risks identified in its Fraud Risk Assessment and Cyber Security Risk Assessment.
c.	The authentication standard should consider both customer access to products and services, and employee and third party access to Member Organisation systems.
d.	When defining the authentication standard, Member Organisations should take note of the following Control Requirements outlined in The Cyber Security Framework:
	1.	3.3.5 Identity and access management
	2.	3.3.13 Electronic Banking Services
e.	A Member Organisation's authentication standard should cover both digital (e.g., online services and mobile app) and non-digital (e.g., phone, ATM and branch) channels.
f.	Member Organisations should adopt a risk-based approach to authentication with higher risk instructions or activity subject to multi-factor authentication before they are acted upon.
g.	Multi-factor authentication conducted by Member Organisations for identification or transaction verification should not solely consist of One Time Passwords (OTPs) sent via SMS. Member Organisations should implement additional factors, including but not limited to:
	1.	Approval of transactions through Mobile App (e.g., sending a push notification to mobile app on a trusted device).
	2.	Device characteristics (e.g., trusted/known mobile device).
	3.	Geolocation (e.g., verifying location, IP address or checking mobile network).
	4.	Behavioural profile (e.g., variations to usual transaction volume, value, frequency and/or currency).
	5.	Biometric behavioural profile (e.g., identification of changes in the way a customer or employee uses a browser or device).
h.	Where an OTP is sent via SMS, the purpose, amount and merchant name should be clearly defined in line with SAMA approved notification templates.
i.	OTPs sent via SMS should be in the language selected by the customer on the account (e.g., Arabic, English).
j.	Member Organisations should define high-risk instructions or activity in the authentication standard which should include, but not be limited to:
	1.	Registration process for online or mobile app product access.
	2.	Activating a token on a new or additional device.
	3.	Adding a credit/debit card to a digital wallet on a mobile device.
	4.	Reset of security credentials following failed attempts to access phone, online or remote facilities.
	5.	Logging in to digital products from a previously unknown device or location.
	6.	Payments to an e-wallet or digital wallet.
	7.	High risk transaction, withdrawals, or transfer of funds (e.g., exceeding pre-defined limits/thresholds, transfers large relative to overall balance or remittance/international transfers).
	8.	Adding or modifying beneficiaries.
	9.	Change of account holder details (e.g., address or contact details).
	10.	Change of language used on the account (e.g., Arabic to English).
	11.	Reset of password or PIN.
	12.	Issue and activation of a new debit/credit card.
	13.	Reactivation of dormant accounts or blocked services.
	14.	A combination of activity(s) which may be indicative of fraud or account takeover (e.g., aggregated risk score following failed log-in attempts, buying gift cards, use of new device or new geolocation).
k.	Member Organisations should require a third authentication factor (e.g., a phone call to the number on the account requiring verification of secure information, a physical visit to a branch, generating a token with a temporary password linked to a device, OTP) to validate an instruction when:
	1.	A user log-in attempt to mobile and online services is detected as an anomalous session (e.g., a device ID or location is different from previously known log-in parameters, or the IP address is flagged as a risk).
	2.	A transaction is instructed from a non-trusted device to a newly added beneficiary.
	3.	An abnormal transfer rate (e.g., five transfers per hour for a retail customer) is exceeded.
l.	Member Organisations should restrict activity where an anomalous session is identified to low level transactions until the organisation is able to authenticate the request originates from the genuine customer and can make the device trusted.
	1.	Low level transactions should be defined by the Member Organisation in Fraud prevention standards (see 4.6).

4.5. Fraud, Financial Crime and Cyber Alignment

Principle
Member Organisations should ensure that Cyber Security, Counter-Fraud and Financial Crime Team operational capabilities are aligned to deter fraud.
Control Requirements
a.	Member Organisations should define and implement a process for the alignment of the Counter-Fraud, Cyber Security and Financial Crime Team operational capabilities which should include at a minimum:
	1.	Defining clear roles and responsibilities between the Counter-Fraud Department, Financial Crime and Cyber Security teams.
	2.	Cross training between the Counter-Fraud Department, Financial Crime and Cyber Security Teams.
	3.	The establishment of multi-disciplinary contacts between Cyber, Financial Crime and Counter-Fraud Departments to regularly share knowledge.
	4.	Development of joint task forces between Counter-Fraud, Financial Crime and Cyber Departments to align working practice and collectively engage the wider organisation.
	5.	Undertaking joint threat assessment workshops or Fraud Scenario Analysis with business units to collectively identify threats and share insights from Intelligence Monitoring.
	6.	Storing relevant threat intelligence in a centralised repository, with access restricted to relevant stakeholders.
	7.	Identification of opportunities to unify fraud and cyber prevention and detection systems and tools (e.g., provision of data on user monitoring or customer location through IP address).
	8.	Alignment of Cyber, Financial Crime and Fraud incident response approach where incidents occur across capabilities.
	9.	Co-ordination of corrective actions to disrupt the organised groups orchestrating fraud (e.g., taking down fake websites set up to capture customer details).
	10.	Conducting joint retrospective lessons learnt exercises following fraud incidents that relate to data, systems, processes and controls spanning the Counter-Fraud, Financial Crime and Cyber capabilities.

4.6. Fraud Prevention Standards

Principle
Member Organisations should have defined, approved, implemented and maintained standards for the prevention of fraud which should be aligned to the fraud risks impacting the organisation and its customers.
Control Requirements
a.	Member Organisations should define, approve, implement and maintain standards to aid the prevention of fraud addressing both internal fraud and external fraud risks impacting the organisation.
b.	Member Organisations should review and update fraud prevention standards on a periodic basis and in response to material changes to the fraud landscape or the Member Organisation Fraud Risk Assessment.
c.	The compliance with the fraud prevention standards should be monitored.
d.	The effectiveness of the fraud prevention standards and related controls should be measured and periodically evaluated.
e.	The output of the Fraud Risk Assessment should be used to determine where prevention activity is focused, and controls should be proportionate to the risk appetite of the organisation.
f.	Fraud prevention standards may be manual or automated, and should include at a minimum:
	1.	The controls implemented to prevent fraud (e.g., segregation of duties, approval and escalations, employee training, access restrictions, due diligence and integrity checks, notification of account changes, transaction limits, underwriting checks).
	2.	Systems and technology implemented to prevent fraud (e.g., identity and access management, authentication, issuance of one-time-passwords, biometrics).
	3.	Roles and responsibilities for fraud prevention (e.g., customer application review at onboarding, training design, due diligence, system testing).
	4.	Rationale outlining why the prevention controls are appropriate to the risks faced by the organisation.
g.	Member Organisations should define the approach to setting limits and thresholds for preventive controls (where applicable) in fraud prevention standards, considering:
	1.	The outcome of the Fraud Risk Assessment.
	2.	Fraud incidents and losses experienced.
	3.	Fraud Risk Appetite.

4.6.1 Internal Fraud

Principle
Member Organisation fraud prevention standards should include controls designed to prevent internal fraud.
Control Requirements
a.	A Member Organisation should include in its fraud prevention standards, controls to mitigate the risk of internal fraud occurring, including but not limited to:
	1.	Requiring employees to adhere to a Code of Conduct.
	2.	Requiring all employees to take block leave of a minimum continuous period of 10 working days each year.
	3.	Segregation of duties in payment and fulfilment processes supported by documented authorisation matrices.
	4.	Dual controls or secondary checking of control operation, with an additional review or approval process for transactions above thresholds defined by the Member Organisation (e.g., value of transaction or payments to a new supplier) or higher risk transactions (e.g., access to dormant accounts).
	5.	Restricting access to secret customer details for all employees (e.g., online credentials, OTP messages).
	6.	Restricting access to confidential customer account data (e.g., account balance, loan amount) where visibility is not required in the job role (e.g., IT employees). Where access is required, activity should be logged and securely stored (see control requirement 5.3.b).
	7.	Requirements for appropriate handling of confidential data.
	8.	Controls over access to cheques and cash.
	9.	Controls to safeguard the physical security of assets (e.g., requiring staff identification at all times, securing and tracking equipment and restricting access to sensitive assets).
b.	Member Organisations should take note of the Identity and Access Management Control Requirements relating to user access management and privileged access management outlined in The Cyber Security Framework.
c.	Member Organisations should ensure that individuals responsible for operating internal fraud controls are sufficiently independent from the individuals they are monitoring.
d.	Member Organisations should put in place appropriate processes and controls to deter and avoid conflicts of interest and related party transactions for their directors, managers, employees, external businesses, and contractors, including but not limited to:
	1.	Creating a policy that clearly outlines prohibited behaviour.
	2.	Limiting the flow of information between internal departments and employees through information barriers.
	3.	Providing guidance, instructions and examples on avoiding conflicts of interest.
	4.	Requiring immediate disclosure of any conflicts or potential conflicts.

4.6.2 External Fraud

Principle
Member Organisation fraud prevention standards should include controls designed to prevent external fraud.
Control Requirements
a.	A Member Organisation should include in its fraud prevention standards, controls to mitigate the risk of external fraud occurring, including but not limited to:
	1.	Hotline available 24 hours to report suspected fraud and take immediate action to respond to the fraud (e.g., blocking account access or cards).
	2.	The provision of an emergency stop self-service capability for customers to immediately freeze their account and block further transactions if they suspect their account has been compromised.
	3.	Customer identity and access management controls for online/mobile accounts and digital products.
	4.	Use of blacklists to screen and block transactions, card provisioning or access from identified high risk:
		a.	Accounts
		b.	IP addresses
		c.	Email addresses
		d.	Compromised devices or those that have previously been used for fraud (e.g., mobile phone app registered to an account which has been used to conduct fraud).
	5.	The capability to swiftly block transactions from customer accounts/cards, with defined safeguards in place to release the block.
	6.	Requiring users of online and mobile services to consent to the activation of GPS during an active session to allow the organisation to monitor location.
	7.	The capability for mobile apps to detect use on devices which have subject to jailbreaking or rooting, and subsequently block the use of the app or restrict access to sensitive data or features.
	8.	Prohibiting the use of VPN services when accessing online or mobile services.
	9.	Device registration which allows users to register trusted devices for access management.
	10.	A restriction on concurrent log-ins to mobile app or a limitation on the number of devices which a mobile app can be installed and accessed.
	11.	The identification of mule accounts (e.g., accounts set-up to receive fraudulently obtained funds and launder the proceeds of crime).
	12.	User behaviour profiles which allow rules to be implemented to prevent access to customer accounts if unusual behaviour is identified.
	13.	Monitoring of product inactivity and dormancy, particularly where products are reactivated.
	14.	Notification sent to the customer when changes are made to static data to previous and new details.
	15.	Online, mobile and phone payments:
		a.	Sending an OTP to verify all payments instructed (new and existing beneficiaries), including transactions through remittance accounts.
		b.	Notification to the customer of new payees added (e.g., SMS, call back).
		c.	Setting a default limit for single and daily transactions which should be periodically reviewed and updated where required (e.g., review of customer profiles and behaviours, and actual fraud cases/customer losses).
		d.	Notify the customer if the default transaction limit is increased (e.g., if the customer account type is upgraded).
		e.	The option for customers to reduce the default limit for a single transaction.
		f.	The option for customers to reduce the default limit for daily transactions.
		g.	An immediate block on further transactions if a transaction limit is reached either through individual or recurring payments whether to one or multiple beneficiaries.
		h.	Additional verification checks to authenticate:
			i.	Unusual transactions (e.g., transactions after a period of account dormancy, changes to customer behaviours).
			ii.	Unusual patterns of transactions (e.g., multiple payments to the same beneficiary in a short period).
			iii.	Transactions exceeding a defined value threshold.
			iv.	Requests to increase the single or daily transaction limit.
			v.	Initial transactions after registration for online banking or mobile services, or registration of a new device.
		i.	Additional verification checks should include but not be limited to, one or more of the following:
			i.	Automated call-backs.
			ii.	Manual call-backs.
			iii.	SMS to registered mobile number.
			iv.	Authentication via biometrics on registered mobile device.
	16.	Credit and debit cards:
		a.	Adherence to all card scheme rules (e.g., mada business rules, Visa CVV2 code, Mastercard CVC2 code).
		b.	Use of one-time passwords (OTPs) to approve online transactions.
		c.	For high risk transactions, the use of extra authentication measures in addition to OTPs or mobile app approval (e.g., automated call-back to the phone number on the account).
		d.	Address/Postal code verification for online card payments.
		e.	New cards issued to require activation before use.
	17.	Validation controls to ensure the authenticity of cheques and similar instruments.
	18.	Periodic inspection of ATMs for evidence of suspicious activity or devices that could compromise card security.
	19.	Removal of clickable links in all emails and SMS sent to customers.
b.	Member Organisations should additionally implement the following preventive controls on a risk-based approach:
	1.	A delay to activation when a customer requests an increase in online/mobile transaction limits.
	2.	Robotic prevention mechanisms prior to the instruction of a payment to mitigate the risk of automated bot activity.
	3.	Functionality for customers to request instant notification of all account and card transactions to their registered mobile device.
	4.	Geofencing when transactions occur in a location outside the customers home area (e.g., using mobile device geolocation data to require verification if a user attempts to access products and services while in a foreign country which is not in line with user behaviour profile).
	5.	Procedures for holding suspicious transfers to countries classed as high-risk in the organisation's jurisdiction risk model.
	6.	A delay to payments requested for new payees added via online/mobile services until further verification is completed.
	7.	Introducing a delay before a new soft token can be activated on a mobile device.
	8.	Notifying the customer of the registration of a new device and identifying critical services (e.g., card provisioning, addition of new payees) which should be disabled for a period following the new device registration.
c.	Member Organisations providing lending and credit products should include in fraud prevention standards, controls to mitigate the risk of external fraud occurring, including but not limited to:
	1.	Review of applications/proposals to check for potential application fraud (e.g., manipulation of details or misrepresentation of the applicant's financial position).
	2.	Checks for fraudulent or counterfeit documents provided for identification or as security on lending.
	3.	Panel management controls for agents, intermediaries, valuers and other third parties.

5. Detect
It is vital for the security and protection of customers to quickly identify actual or attempted fraud where preventative controls are insufficient or have failed. Fraud detection systems and controls are risk-based measures to identify fraud by looking for indicators in customer behaviours, transactional and non-transactional information. Effective detection of fraud enables proportionate and timely action to minimise organisational losses and customer impact. Detective controls can be manual, but typically given the volume of activity in financial institutions and digital nature of products and services, rely on technology to perform automated monitoring.

Figure 6 - Detect Domain

5.1. Fraud Detection Standards

Principle
Member Organisations should have defined, approved, implemented and maintained fraud detection standards which should be aligned to the fraud risks impacting the organisation and its customers.
Control Requirements
a.	Member Organisations should define, approve, implement and maintain fraud detection standards addressing both internal fraud and external fraud risks impacting the organisation.
b.	Member Organisations should review and update fraud detection standards on a periodic basis and in response to material changes to the fraud landscape or the Member Organisation Fraud Risk Assessment.
c.	The compliance with fraud detection standards should be monitored.
d.	The effectiveness of fraud detection standards and related controls should be measured and periodically evaluated.
e.	The output of the Fraud Risk Assessment should be used to determine where detection activity is focused, and controls should be proportionate to the risk appetite of the organisation.
f.	Where the inherent risk of fraud is assessed as higher, the fraud detection standards should require additional detection controls (e.g., real time monitoring, additional data sources or Machine Learning models) or more stringent detection threshold criteria (e.g., lower monetary limits before an alert is raised).
g.	Fraud detection standards should include at a minimum:
	1.	Data sources used to inform detection of suspicious activity and fraud (e.g., core customer records, transactional/payment systems, identity and access management, external databases).
	2.	The controls implemented to detect suspected fraudulent activity (e.g., escalation of high-risk events and transactions, secondary checking, reconciliations, exception reporting, internal training).
	3.	The controls implemented to detect suspected fraudulent activity relating to Wholesale Payment Endpoint Security (e.g., monitoring of payments behaviour and out-of-band reports, the creation of a counterparty white-list, anomalous payment tracking, blocking of payments in real-time).
	4.	Systems and technology implemented to detect potential fraud (e.g., fraud detection software, alerts on high-value events or transactions, access monitoring, link analysis).
	5.	Roles and responsibilities for fraud detection (e.g., system calibration, reviewing manual fraud referrals, alert triaging and management, escalation point for potentially significant incidents, supervision and oversight).
	6.	Rationale outlining why the detection systems and controls are appropriate to the risks faced by the organisation.
h.	Member Organisations should consider the following areas of activity when documenting the people, process, and technology requirements for fraud detection:
	1.	Employee activity data (e.g., system access, invoices and payments, approvals).
	2.	Customer account activity (e.g., transactions, payments, settlement).
	3.	Customer account access and management (e.g., log-in geolocation, device usage, changes to static data).
	4.	Third party activity data (e.g., access to and use of Member Organisation systems or data, instructions on behalf of customers, referrals from agents).
i.	Where a Member Organisation determines a manual control is required (e.g., due to the scale of the Member Organisation, lack of systems or analytics, or coverage of products and channels), the nature of the fraud risk should be reviewed to assess the number of employees and skills required to provide adequate manual coverage.
j.	Member Organisations should have adequate resources in place to manage the outputs from manual and automated fraud detection (e.g., sufficient employees to work alerts, appropriate skills and training for employees to complete investigations, workflow system to allocate alerts).

5.2. Fraud Detection Systems

Principle
Member Organisations should implement and maintain fraud detection systems to identify anomalies in transactional and non-transactional data, and customer or employee behaviour that may be indicators of fraud.
Control Requirements
a.	Member Organisations should implement and maintain fraud detection systems to monitor customer products and services, and internal systems for transactions or behaviours that may be indicative of fraud.
b.	Fraud detection systems should operate 24/7 with appropriate resources in place to manage outputs on a timely basis.
c.	Member Organisations should develop holistic and current sources of data to be used to inform detection of suspicious activity and fraud, including at a minimum:
	1.	Customer products and services held across all lines of business.
	2.	All contact channels (e.g., online, mobile, phone).
	3.	External information (e.g., credit reference data, blacklists, vendor provided data sets).
	4.	The insights gathered from Intelligence Monitoring (see sub-section 4.1.1).
	5.	Transactional or settlement data (e.g., payment values into or out of accounts, payment recipients added, authority for payment instruction, transfer from custodian of funds).
	6.	Non-transactional data (e.g., employee behaviour, online access, device usage, geo-location, changes to static data).
d.	Member Organisations should implement controls (e.g., data governance, de-duplication, data quality alerts, regular audit, integration testing, regression testing for change management) to ensure that the underlying data is:
	1.	Timely - Supplied to the detection system at an appropriate frequency based on the rate of change and urgency of information (e.g., payment data should be real-time to allow intervention before funds are transferred, while new products sold may be updated daily, and external information refreshed when lists change).
	2.	Complete - Includes all required data from all relevant systems identified in the Counter-Fraud detection standards (e.g., data mapping from source system to the detection system should be validated).
	3.	Accurate - Of sufficient quality to enable effective monitoring (e.g., up to date, tested to ensure data quality).
e.	Member Organisations should ensure fraud detection system capability includes at a minimum:
	1.	Analysis of structured data (data in a standardised, well-structured format).
	2.	Monitoring of customer and internal accounts.
	3.	Baselining of user behaviour patterns into profiles which allow deviations from normal activity to be identified (e.g., expected frequency or value of transactions).
	4.	Definition of a library of rules based on known fraud typologies to identify activity which could be indicative of fraud (e.g., employee access patterns, unknown or remote customer location, increased frequency of transactions, new transaction type, high value amount, recurring transactions whether to one beneficiary or multiple beneficiaries, single source of transfer to many accounts).
	5.	Segmentation of customer groups to enable tailoring of rules (e.g., modifying rules and thresholds based on different expected behaviours of a high-net-worth Private Banking customer vs. a standard Retail customer or a new account opened online vs. an established relationship managed customer).
	6.	Applying a weighting to rules based on the assessed level of fraud risk and assigning risk scoring to identify activity that may be indicative of fraud.
	7.	The aggregation of risk scores to assess patterns of transactional and non-transactional activity across multiple channels that when combined may be indicators of fraud.
	8.	Linking outputs (e.g., alerts and cases for further investigation) to a Case Management System.
f.	Member Organisations should use the output of Intelligence Monitoring and information from across the organisation in data analytics to deeply analyse current status, predict future fraud threats and take proactive action to prevent fraud. Analytics should use multiple data sources, including but not limited to historical and current trends, customer data, transactions and non-transactional activity.
g.	Where a higher risk of fraud is identified in the Fraud Risk Assessment or higher incidences of fraud occur, Member Organisations should additionally implement system capability of:
	1.	Big data mining to facilitate advanced analytics over large quantities of structured and unstructured data, with associated orchestration to create a centralised data repository (e.g., using data refinement and comparison algorithms to perform queries on very large volumes of data, and storage in a data lake).
	2.	Analytical tools and capabilities to enhance rules-based monitoring (e.g., trend analysis, keyword analysis, predictive analytics, and anomaly detection).
	3.	Overlaying Artificial Intelligence and Machine Learning algorithms (e.g., decision trees, random forests, neural networks) to:
		a.	Enhance system decision making capability.
		b.	Predict the likelihood of fraud.
		c.	Learn from historical patterns of fraudulent and legitimate behaviour.
	4.	Network Visualisation/Link analytics or Entity Resolution to reveal hidden or previously unknown connections and identify networks across different data sources (e.g., identify connections from devices or IP addresses known to have been used for fraudulent purposes and link with other data points to create a threat score associated with a network, by looking at location, payment cards used, beneficiaries etc.).
	5.	Analysis of additional unstructured external data (e.g., scanned customer documents) to widen data sources.
h.	Where a deviation from the baselined user behaviour patterns is identified, Member Organisations should either:
	1.	Require further authentication of the user or their instructions.
	2.	Generate an alert for further investigation to determine whether fraud has occurred.
i.	To ensure the effectiveness and optimisation of fraud detection systems, Member Organisations should:
	1.	Calibrate and test detection scenarios to validate they are working as designed and enabling monitoring in accordance with the organisations risk appetite (e.g., rule logic review, threshold testing, precision and recall testing).
	2.	Implement feedback loops to monitor and enhance the performance of systems and effectiveness of scenarios and parameters by reviewing false positives, false negatives and alerts which identified fraud.
	3.	Periodically review scenarios and parameters to ensure they remain appropriate in view of the insights gathered in Intelligence Monitoring and/or the outcome of the Fraud Risk Assessment.
	4.	Periodically test the effectiveness of systems, through ongoing tuning and calibration measures such as data mapping and input validation, model validation, scenario effectiveness testing and reporting.
	5.	Update user behaviour patterns and rules to account for the latest threats and fraud typologies.
	6.	Retain a documented record of changes made to configuration or rules and the rationale for the decision.
	7.	Monitor for unauthorised changes to the system (e.g., rule tampering or disabling of monitoring).
j.	The fraud detection systems should have the capability to monitor and report metrics and Management Information in respect of:
	1.	Data integrity.
	2.	Rule and scenario effectiveness (e.g., false positive rate).
	3.	Operational performance.

5.3. Monitoring to Detect Fraud

Principle
Member Organisations should design and implement controls to monitor activities and behaviour in order to detect potential indicators of e xternal fraud and internal fraud.
Control Requirements
a.	Member Organisations should design and implement controls to monitor customer products and services for behaviours that may be indicative of external fraud. At a minimum these should address the risk presented by:
	1.	First party fraud - Where a customer of the Member Organisation misrepresents their identity or gives false information to commit fraud using their own account, loan application or other product.
	2.	Second party fraud - Where a customer or individual knowingly provides their personal information or allows their identity to be used to commit fraud.
	3.	Third party fraud - Where a non-customer of the Member Organisation obtains a customer's details without their consent or knowledge, then uses the information to commit fraud.
b.	Member Organisations should design and implement controls to monitor employees in roles which have been identified in the Fraud Risk Assessment as presenting a risk of internal fraud, including but not limited to:
	1.	Audit trail of employee access to the Member Organisation's core systems.
	2.	Systematic log of staff activity for all customer and financial accounting systems and databases (e.g., recording an audit trail of an employee making changes to a customer address, adding a payee, instructing a payment, authorising a withdrawal).
	3.	Monitoring for unusual behaviours or activity (e.g., transactions outside working hours, process exceptions or overrides completed without appropriate approvals).
	4.	Reconciliation and settlement of finance systems and organisation internal bank accounts.
	5.	Enhanced oversight of payments to Member Organisation employee's accounts.
	6.	Monitoring and appropriate approval of corporate card use and expense claims.
	7.	Monitoring of employee complaints and anonymous reporting lines.

5.4. Whistle Blowing

Principle
Member Organisations should define, approve, implement and maintain a process to enable concerned employees and third parties to report potential fraud violations without the fear of negative consequences or repercussions.
Control Requirements
a.	Member Organisations should define, approve, implement and maintain a whistle blowing process across multiple channels for employees and third parties to report potential fraud violations.
b.	The process should comply with SAMA's Whistle Blowing Policy for Financial Institutions (Whistle Blowing Policy).
c.	Member Organisations should take no action against whistle blowers for any disclosures of potential fraud violations reported in good faith.

6. Respond
A timely and effective response to incidents of actual or suspected fraud is key to minimising losses and maximising the opportunity for recovery. Where fraud is suspected or detected, a robust Fraud Response Plan including clear procedures is required to manage the response, enabling effective investigation; a prompt, fair resolution; and corrective action where required. Following resolution, it is key to evaluate the root cause of an incident and assess effectiveness of control frameworks to avoid recurrence.

Figure 7 - Respond Domain

6.1. Fraud Response Plan

Principle
Member Organisations should define, approve, implement and maintain a Fraud Response Plan to outline the organisational response to an actual or suspected fraud incident.
Control Requirements
a.	The Fraud Response Plan should be defined, approved, implemented, maintained and where appropriate aligned with the enterprise incident management process.
b.	The compliance with the Fraud Response Plan should be monitored.
c.	The effectiveness of the Fraud Response Plan and related controls should be measured and periodically evaluated.
d.	The Fraud Response Plan should require prompt and competent assessment, investigation, and resolution of all suspected or identified fraud.
e.	The Fraud Response Plan should include at a minimum:
	1.	The methods through which the Member Organisation is alerted to suspected or identified fraud, including reporting channels available to customers, employees and third parties.
	2.	Roles and responsibilities for individuals and teams required to respond to a potential fraud.
	3.	Decision making authority and referral procedures for escalations within and outside the Member Organisation (e.g., referral to specialists for complex cases, Senior Management for potentially material frauds, external counsel if there are legal concerns).
	4.	Service Level Agreements (SLAs) for response to initial fraud reports.
	5.	Procedures to quickly respond to potential fraud cases identified by the Member Organisation, informed by the customer or notified by other organisations. This should include precautionary measures to freeze funds received until the integrity of the source is verified if it is suspected that inbound transactions are the result of fraud.
	6.	The actions the Member Organisation will take when fraud is suspected or has been identified, including but not limited to:
		a.	Coordinating appropriate resources to manage alert and case volumes.
		b.	Recording and performing an initial assessment of all alerts or formally submitted reports of fraud.
		c.	Where an alert or referral is assessed as not requiring further investigation, recording a rationale explaining the decision.
		d.	Investigating all instances where it is suspected fraud may have been committed or has been identified.
		e.	Keeping a comprehensive record of all evidence and investigations of potential and actual fraud for a period defined in the record retention schedule of the Member Organisation and in compliance with Article 12 of the Anti-Money Laundering Law.
	7.	The process to be followed in the event a potential fraud incident is detected outside of the normal working hours of the Member Organisation.
	8.	The requirement to initiate an immediate response when a potential Wholesale Payment Endpoint Security fraud is identified.
	9.	Where an actual or potential fraud relates to services offered to a customer or a payment to/from a Member Organisation or a customer, the Fraud Response Plan should require Member Organisations to:
		a.	Identify if a potentially fraudulent transaction has been completed or is in the process of being completed.
		b.	If a transaction has not been completed: Take immediate action to block or hold the transaction and proactively coordinate with any corresponding Member Organisations to take the required actions taking into consideration the role of Sharing Room - Operational Centre.
		c.	Proactively respond to requests relating to suspected fraudulent transactions when receiving a notification from another Member Organisation based on agreed protocols for the Sharing Room - Operational Centre.
		d.	Block or freeze the product (or any associated services such as compromised credit or debit cards) to prevent further transactions until the investigation is complete and where necessary security credentials are reset or a new card is issued.
		e.	Block any further transactions to or from any IBANs outside the Member Organisation which were used to perpetrate the fraud and share the IBAN with the external organisation to freeze the account.
		f.	Cooperate with other organisations if a request for freezing a product is received and there are justifications for suspicion.
		g.	If a transaction has been completed and an investigation confirms a transaction is fraudulent: Reverse the transaction or seek return of funds where possible.
		h.	Contact the customer or third party to communicate actions taken and next steps.
		i.	Verify the identity of the customer before re-activating services after an account has been frozen due to exposure to fraud.

6.2. Alert and Case Management

Principle
Member Organisations should implement and maintain a Case Management System to manage the response to fraud. This should facilitate the recording, monitoring and storage of data on the assessment, investigation, and resolution of suspected and identified fraud.
Control Requirements
a.	Member Organisations should implement and maintain a Case Management System to manage the response to fraud and act as a database for fraud case data.
b.	The Case Management System should be used to record and monitor suspected fraud alerts, internal and external reports, and case investigations from initial assessment to resolution.
c.	The Case Management System should have the capability to:
	1.	Restrict user access to authorised individuals and roles.
	2.	Create a workflow aligned to the operating model of the Member Organisation.
	3.	Be configurable to adapt to changes in the Member Organisation operating model or Fraud Response Plan.
	4.	Allocate cases to owners.
	5.	Categorise suspicions of fraud to inform reporting and trend analysis.
	6.	Track a case from initial alert or report to resolution.
	7.	Record investigative steps followed.
	8.	Act as a repository for all information required to investigate and resolve the fraud case (e.g., related party information, case notes, documentary evidence, customer communication, rationale for decision).
	9.	Capture an outcome at resolution of the case, including any losses and corrective actions.
	10.	Maintain records in line with the Member Organisation’s record retention schedule.
d.	The Case Management System should require the capture and allow the extract of Management Information for reporting on fraud cases, including but not limited to:
	1.	Alert unique identifier (where applicable).
	2.	Fraud transaction unique identifier.
	3.	Date of alert or initial notification.
	4.	Date and time of fraudulent transactions.
	5.	Customer name and account number.
	6.	Case status.
	7.	Origin of the incident (e.g., website, social media account or phone number used by the fraudster).
	8.	Channel used for fraudulent transactions.
	9.	Related parties.
	10.	Information on the fraudster (e.g., IP address, Device ID, Geolocation).
	11.	Outcome of the investigation.
	12.	Corrective actions.
	13.	Value of the fraud.
	14.	Losses (business and non-business).
	15.	The methods used to conduct the fraud/fraud typology (e.g., how the fraud was committed, where the funds were transferred if lost).

6.3. Fraud Investigation

Principle
Member Organisations should define, approve, implement and maintain a fraud investigation standard to direct a consistent approach to fraud investigation.
Control Requirements
a.	Member Organisations should define, approve, implement and maintain a fraud investigation standard.
b.	The compliance with the fraud investigation standard should be monitored.
c.	The effectiveness of the Fraud Investigation standard and related controls should be measured and periodically evaluated.
d.	The fraud investigation standard should direct a consistent approach to fraud investigation, including but not limited to:
	1.	Allocation of the case to an individual or team with the required skills and experience.
	2.	Assessing the time sensitivity of the fraud or potential fraud (e.g., will losses increase if the case is not resolved, has a customer been left without access to funds).
	3.	Assessing the materiality of the fraud or potential fraud (e.g., number of customers impacted, potential losses, systemic threat).
	4.	Gathering and analysing information to review the suspicion of fraud (e.g., transaction information, IP addresses used, phone recordings, CCTV footage).
	5.	Collaborating with relevant internal subject matter experts and stakeholders (e.g., Legal, Cyber, HR, Financial Crime) and where relevant forming a multi-disciplinary investigation team.
	6.	Assessing the skills required to conduct the investigation in more complex cases (e.g., forensic accounting, data analysis).
	7.	Contacting the customer or third parties to obtain further information.
	8.	Liaising with other Member Organisations to share information.
	9.	Documenting the investigative steps taken.
	10.	Managing and retaining information gathered.
	11.	Evaluating whether fraud has occurred and resolving or closing the investigation.
	12.	Recording an outcome of the investigation.
	13.	Producing a case report and internally reporting the outcome of the investigation where required.
	14.	Taking corrective action at the conclusion of the investigation.
	15.	Determining external notifications required (e.g., liaising with law enforcement, notifying credit reference agencies, reporting to SAMA, reporting to the General Directorate of Financial Intelligence (FIU) if the Member Organisation has any suspicion that rises to the level stated in article 15 of AML Law and article 17 of CTF law).
	16.	Identifying the root cause of fraud incidents and near misses.
	17.	Extracting lessons learnt and providing feedback to:
		a.	The Counter-Fraud Department.
		b.	Team responsible for developing and maintaining Counter-Fraud systems.
		c.	Business owners of standards, processes, and controls where a vulnerability is identified.
		d.	Intelligence Monitoring.
e.	The fraud investigation standard should require corrective action to be taken where relevant at the resolution of a fraud investigation.

6.4. Fraud Remediation

Principle
Member Organisations should define, approve, implement and maintain a process to identify the root cause of a fraud incident, determine any lessons learnt and take corrective actions to prevent a recurrence.
Control Requirements
a.	Member Organisations should define, approve, implement and maintain a process to identify the root cause of a fraud incident at the conclusion of an investigation. At a minimum the process should include:
	1.	Understanding the point of compromise (e.g., the channel which was used to perpetrate the fraud or take control of an account).
	2.	Determining whether other parties could have been involved in the fraud (e.g., additional employees through collusion or persons known to the customer).
	3.	Reviewing whether a preventive control has failed or been bypassed by an employee.
	4.	Evaluating whether the fraud was identified proactively by a detective control or relied on reactive customer notification.
b.	Following determination of the root cause, Member Organisations should define, approve and implement a process to determine lessons learnt and inform corrective actions to prevent a recurrence. At a minimum the process should include:
	1.	Collating data which may support the analysis of patterns in fraud cases, including but not limited to IP addresses used, beneficiary accounts, device IDs involved.
	2.	Assessing whether there is a gap in the current control framework.
	3.	Determining whether other departments of the Member Organisation have the same vulnerability.
	4.	Evaluating whether the issue could impact other Member Organisations and sharing relevant information that may prevent a recurrence (e.g., fake websites impersonating government entities or social media accounts).
	5.	Documenting corrective actions to address the root cause and prevent a recurrence.
c.	Member Organisations should take corrective actions to remediate the root cause and/or the impact of a fraud incident, which may include but are not limited to:
	1.	Implementing a new control or enhancing an existing control.
	2.	Providing training or communicating new awareness materials to improve employee, customer or third party awareness.
	3.	Putting a fraud victim back into the position they were in prior to the incident (e.g., reimbursing stolen funds, chargebacks, refunding a scam payment, repaying a third party).
	4.	Providing support to a victim of fraud (e.g., informing of next steps, providing a new card, providing education).
	5.	Attempting to recover funds or assets.
	6.	Exiting a customer or third party relationship if they are found to be the perpetrator of a fraud.
	7.	Internal disciplinary action where internal fraud is identified.
	8.	Liaising with law enforcement.
d.	The acceptance and implementation of corrective actions should be tracked by the Counter-Fraud Department with escalation to the CFGC where actions are rejected by the business or remedial action is delayed.

Appendices

Appendix A – Defined Terms

The following are considered defined terms for the purpose of this Framework.

Defined Term	Definition
Access Management	The process of granting authorised users the right to use a service, while preventing access to non-authorised users.
Anomalous Session	Log-in sessions to mobile or online services that have different log-in parameters to those previously used by the customer, e.g., Device ID or location; or when the IP address is flagged as a risk.
Anomaly Detection	Finding patterns in data that depart significantly from the expected behaviour. Fraud anomaly detection can be implemented as an intelligence tool using unsupervised Machine Learning algorithms.
Artificial Intelligence	The use of computer systems to perform tasks typically requiring human knowledge and logical capabilities, often in problem solving scenarios.
Black Box System	A complex system where the internal rules and mechanisms are not visible to or understood by the system owner.
Blacklist	A list of untrustworthy or high risk individuals or entities that should be excluded and avoided. Also known as block-list.
Case Management System	A system used to manage alerts and fraud incidents from an initial report, through investigation, resolution and remediation where required.
Code of Conduct	A defined set of expectations which outline principles, values, and behaviours that an organisation considers important to its operations and success.
Contractor	An individual or organisation under contract for the provision of services to an organisation.
Counter-Fraud Culture	The shared values, beliefs, knowledge, attitudes and understanding about fraud risk within an organisation. In a strong Counter-Fraud culture people proactively identify, discuss, and take responsibility for fraud risks.
Counter-Fraud Governance	A set of responsibilities and practices exercised by the Board, Executive and Senior Management with the goal of providing strategic direction for countering fraud, ensuring that Counter-Fraud objectives are achieved, ascertaining that fraud risks are managed appropriately and verifying that the enterprise's resources are used responsibly.
Counter-Fraud Governance Committee (CFGC)	An established group of individuals tasked with providing oversight and direction, and ensuring that the organisation’s combined Counter-Fraud capabilities are functioning appropriately and efficiently.
Counter-Fraud Maturity	The extent to which an organisation’s resources are effectively implemented for the purpose of countering fraud in comparison to global accepted standards and best practice.
Counter-Fraud Policy	A set of criteria for the provision of Counter-Fraud activities. It sets the commitment and objectives for Counter-Fraud and documents responsibilities.
Counter-Fraud Programme	A collection of policies, processes, guidelines, risk management approaches, actions, training, best practices, assurance, and technologies that are used to protect the Member Organisation and its customers against internal and external fraud threats.
Counter-Fraud Strategy	A high-level plan, consisting of projects and initiatives, to mitigate fraud risks while complying with legal, statutory, contractual, and internally prescribed requirements.
Counter-Fraud Department	A dedicated department or team established for the purpose of managing the implementation of the organisation’s Counter-Fraud objectives.
Critical services	Services provided by a third party where a failure or disruption in the provision of services could leave the Member Organisation unable to serve its customers or meet its regulatory obligations.
Cyber Security	Cyber security is defined as the collection of tools, policies, security concepts, security safeguards, guidelines, risk management approaches, actions, training, best practices, assurance, and technologies that can be used to protect the Member Organisation's information assets against internal and external threats.
Due Diligence	The investigation of an employee, customer or third party to confirm facts and that it is as presented.
Emergency Stop	A self-service capability for customers to immediately freeze their account and block further transactions if they suspect their account has been compromised
Employee	Employees encompass members of the Board of Directors and its committees, Executives, permanent and contract employees, consultants, and employees working through a third party
Entity Resolution	A process to identify data records in a single data source or across multiple data sources that refer to the same real-world entity and to link the records together.
External Fraud	A fraudulent event conducted by any persons on the ‘outside’ of the organisation i.e., not employed by the organisation.
Financial Crime	Criminal activities to provide economic benefit including money laundering; terrorist financing; bribery and corruption; and market abuse and insider dealing.
Fraud	Any act that aims to obtain an unlawful benefit or cause loss to another party. This can be caused by exploiting technical or documentary means, relationships or social means, using functional powers, or deliberately neglecting or exploiting weaknesses in systems or standards, directly or indirectly.
Fraud case	An individual occurrence of fraud recognised by an organisation.
Fraud Landscape/Threat Landscape	Fraud threats, trends, and developments in the political, economic, social, technological, or legal environment.
Fraud Response Plan	A plan which details the actions to be undertaken when a fraud is suspected or has been detected. This will include reporting protocols, team responsibilities and information logging.
Fraud Risk Appetite	The level of fraud risk that an organisation is willing to accept or tolerate in pursuit of its objectives.
Fraud Risk Assessment	A process aimed at addressing the organisation’s vulnerability to fraud. This will include identification of fraud risks, assessment of the likelihood that fraud risks will occur and the resulting impact, determination of the appropriate response, and review of the control framework.
Fraud Risk Management	The ongoing process of identifying, analysing, monitoring, and responding to fraud risks to which the organisation and its customers are exposed.
Fraud Scenario Analysis	The testing of devised fraud scenarios for the purpose of assessing the current capability of fraud systems within the organisation.
Fraud Threat	Any circumstance or event with the potential to result in a fraud event occurring.
Fraud Typology	A categorisation of a fraud event based on its methodology and common themes with other fraud events.
Geofencing	Restricting access to online or mobile services based upon the user's geographical location.
Incident	A fraud case or series of associated cases.
Inherent Risk	The fraud risks posed to the organisation’s business operations or its customers if there were no controls present.
Intelligence Monitoring	The process of continually reviewing and gathering intelligence on new and emerging fraud threats and typologies from a comprehensive range of sources.
Internal Fraud	Fraud committed by or with the assistance of people employed by the organisation.
Key Risk Indicators (KRIs)	A measure used to indicate the probability an activity or organisation will exceed its defined risk appetite. KRIs are used by organisations to provide an early signal of increasing risk exposures in various areas of the enterprise.
Keyword Analysis	Codifying rules to match key words on a look-up table to those within key fields of a fraud case record. Complexity can be added to rules such as requiring the words to be in a particular order or high-risk terms that have often indicated fraud.
Machine Learning	The use of computer systems that have the capability to learn and adapt without explicit instruction through the use of algorithms or models to analyse and build on patterns and trends in data.
Management Information	Information collated and then presented, often in the form of a report or statement, to management or decision makers for the purpose of identifying trends, solving issues and/or forecasting the future.
Member Organisation	All financial institutions or financial services providers regulated by SAMA.
Model Validation	Analysis to assess whether the outputs of a system are performing as expected.
Mule accounts	Accounts set-up (often via remote or online channels) to receive fraudulently obtained funds and launder the proceeds of crime.
Multi-Factor Authentication	Authentication using two or more factors to achieve authentication. Factors include something you know (e.g., password/PIN), something you have (e.g., cryptographic identification device, token), or something you are (e.g., biometric).
Near Misses	Potential fraud incidents that are detected and remediated prior to the fraud incident resulting in a monetary loss.
Policy Breach	The failure to comply with or disregard of policy requirements.
Precision and Recall Testing	Metrics to evaluate the effectiveness of models. Precision: The ability of a classification model to identify only the relevant data points. Recall: The ability of a model to find all the relevant cases within a data set.
Predictive Analytics	The use of statistics and modelling techniques to determine future outcomes or performance.
RACI Matrix	Illustrates who is Responsible, Accountable, Consulted and Informed within an organisational framework.
Residual Risk	The remaining risk after management has implemented a risk response.
Risk	A measure of the extent to which an organisation is threatened by a potential circumstance or event, and typically a function of: (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence.
Risk Factors	Different categories of risk that organisations must consider considered when performing a Fraud Risk Assessment
Rules	Rules used in fraud prevention and detection systems use correlation, statistics, and logical comparison of data to identify a pattern based on insights gained from previous known fraud incidents.
Scams	Where an individual is tricked into making or authorising a payment to a criminal’s account. Scammers typically use social engineering and can impersonate banks, investment opportunities, utility companies and government bodies using emails, phone calls and SMS that appear genuine.
Sectorial Anti-Fraud Committee	A committee governed by SAMA to combat fraud involving Member Organisations operating in the Kingdom (e.g., Banking Anti-Fraud Committee).
Senior Management	The highest level of management in an organisation (the level below the Board) and their direct reports.
Service Level Agreement (SLA)	The specific responsibilities for delivery, typically an agreement on timeliness or quality, for example relating to management of fraud alerts.
Static Data	Data with low change frequency (e.g., name, email address, mobile phone number, signatory rights, specimen signatures, power-of-attorney).
The Cyber Security Framework	SAMA's Cyber Security Framework.
Third Party	A separate unrelated entity that provides an organisation with a service. This may include suppliers, technology providers (e.g., Absher, Nafath), outsourcers, intermediaries, brokers, introducers, and agents.
Threat Intelligence	Threat intelligence is evidence-based knowledge, including context, mechanisms, indicators, implications, and actionable advice, about an existing or emerging menace or hazard to assets that can be used to inform decisions regarding the subject's response to that menace or hazard.
Trend Analysis	The process of collecting and reviewing information to identify patterns and predict future trends.
Trusted Device	A trusted device is a device that the customer owns, controls access to, and uses often.
Violation	Any act, or concealment of acts, of fraud, corruption, collusion, coercion, unlawful conduct, misconduct, financial mismanagement, accounting irregularities, conflict of interest, wrongful conduct, illegal or unethical practices or other violations of any applicable laws and instructions.
Whistle Blowing Policy	SAMA Whistle Blowing Policy for Financial Institutions.
Wholesale Payment Endpoint Security	Measures taken with respect to endpoint hardware, software, physical access, logical access, organisation and processes at a point in place and time at which payment instruction information is exchanged between two parties in the ecosystem.

Appendix B – Fraud Types that May Impact a Member Organisation and Its Customers.
The following is a non-exhaustive list of fraud types that should be considered by a Member Organisation when relevant to its products.
- Social engineering (e.g., capture of customer credentials; investment scams; purchase scams; invoice scams; advance fee scams).
- Account takeover (e.g., gaining access to a customer product or device to control assets or transact).
- Impersonation (e.g., obtaining personal information to use for own benefit; assuming the identity of another to access products; impersonating a government body to obtain customer information).
- Internal fraud (e.g., misappropriation of assets; procurement fraud; theft of assets or cash; theft of intellectual property; falsification of information; unauthorised passing of information to third parties; false expense claims; abuse of authority; collusion; use of organisation assets for own gain; diversion of funds).
- Accounting fraud (e.g., concealment; false invoicing; payroll fraud; improper revenue recognition; overstatement of assets; understatement of liabilities; customer overbilling; treasury and investment fraud).
- Application fraud (e.g., failing to disclose information; falsification of information; providing false documents).
- Wholesale Payment Endpoint Security fraud.
- Banking and payment products: Credit/Debit card fraud; Online or mobile app payment fraud; Cheque fraud; ATM fraud; Mule fraud.
- Credit and lending products: Mortgage fraud; Loan fraud.

Appendix C – How to Request an Update to the Framework
- Below is an illustration of the process for requesting an update to the Framework.
- Detail information supported by pros and cons about the suggested update.
- The request should first be approved by the Head of Counter-Fraud before submitting to the Counter-Fraud Governance Committee (CFGC).
- The request should be approved by Member Organisation's CFGC.
- The request should be sent formally in writing to the manager 'General Department of Cyber Risk Control' via the Member Organisation's CEO or managing director.
- 'General Department of Cyber Risk Control' will evaluate the request and inform the Member Organization.
- The current Framework remains applicable while the requested update is being considered, processed and if applicable is approved and processed.

Appendix D – Framework Update Request Form
Request to Update the Counter-Fraud Framework

A submission to the manager of SAMA General Department of Cyber Risk Control.

SAMA will consider requests from a member organisation (MO) to update its Counter-Fraud Framework based on the information submitted using the form below. A separate form must be completed for each requested update. Please note that all required fields must be properly filled in before SAMA will begin the review process

Requestor Information

REQUESTOR'S SIGNATURE*
x REQUESTOR'S POSITION* DATE*
REQUESTOR'S NAME*
MEMBER ORGANISATION OF REQUESTOR*

FRAMEWORK SECTION*:

PURPOSE OF REQUESTED UPDATE (including detailed information on its pros and cons)*:

PROPOSAL*:

Approvals

1. MO’s HEAD OF COUNTER-FRAUD APPROVAL*
DATE*

2. MO’S COUNTER-FRAUD GOVERNANCE COMMITTEE
APPROVAL*
APPROVER’S POSITION*
DATE*

3. SAMA DECISION
SAMA APPROVAL
DATE

* Denotes required fields

Appendix E – How to Request a Waiver from the Framework
Below is an illustration of the process for requesting a waiver from the Framework.
- Detail description about the reasons that the member organisation could not meet the required control.
- Detail description about the available or suggested compensating controls.
- The waiver request should first be approved by the Head of Counter-Fraud before submitting to the Counter-Fraud Governance Committee (CFGC).
- The waiver request should be approved by the members of Member Organisation’s Counter-Fraud Governance Committee.
- The waiver request should be signed by the Head of Counter-Fraud and relevant (business) owner.
- The waiver request should be formally issued in writing to the manager of ‘General Department of Cyber Risk Control’ via the Member Organisation’s CEO or managing director.
- ‘General Department of Cyber Risk Control’ will evaluate the waiver request and inform the Member Organisation.
The current Framework remains applicable while the requested waiver is being evaluated and processed, until the moment of granting the waiver.

Appendix F – Framework Waiver Request Form
Request for Waiver from the SAMA Counter-Fraud Framework

A submission to the manager of 'General Department of Cyber Risk Control’
SAMA will consider requests for waiver from a member organisation (MO) from its Counter-Fraud Framework based on the information submitted using the form below. A separate form must be completed for each requested waiver. Please note that all required fields must be properly filled in before SAMA will begin the review process.

Requestor Information

REQUESTOR'S SIGNATURE*
x REQUESTOR'S POSITION* DATE*
REQUESTOR'S NAME*
MEMBER ORGANISATION OF REQUESTOR*

FRAMEWORK CONTROL*:

DETAILED DESCRIPTION OF WHY CONTROL CANNOT BE IMPLEMENTED*:

DETAILED DESCRIPTION OF AVAILABLE OR SUGGESTED COMPENSATING CONTROLS*:

Approvals

1. MO’s HEAD OF COUNTER-FRAUD APPROVAL*
DATE*

2. MO’S COUNTER-FRAUD GOVERNANCE COMMITTEE
APPROVAL*
APPROVER’S POSITION*
DATE*

3.SAMA DECISION
SAMA APPROVAL
DATE**

* Denotes required fields
** The validity of this waiver is one year. It is the Member Organisations responsibility to ensure renewal of this waiver.

Appendix G – Supervisor Notification Form

Fraud Supervisory Notification

A submission to the manager of SAMA General Department of Cyber Risk Control.

SAMA requires immediate notification of new fraud typologies and significant fraud incidents to mitigate the risk of the fraud impacting additional customers, other organisations, or the financial sector in the KSA. This form should be used to provide the notification. Please note that all required information must be provided, however it is understood that not all information may be available at the time of notification. Where information is not available at the time of notification, any gaps should be supplied to SAMA promptly as the investigation progresses.

Notifier Information

NOTIFIER’S SIGNATURE*	NOTIFIER’S POSITION*	DATE*
NOTIFIER’S NAME*	MEMBER ORGANISATION OF NOTIFIER*

FRAUD NOTIFICATION TYPE*		DATE OF INCIDENT*
☐ New typology	☐ Significant internal fraud
☐ Significant external fraud	☐ Significant accounting irregularity
☐ Wholesale Payment Endpoint Security Fraud
ORIGIN OF THE INCIDENT*:
METHODS USED*:
RELATED PARTIES (INTERNAL AND EXTERNAL)*:
OUTCOME (INCLUDING LOSSES WHERE APPLICABLE)*:
CORRECTIVE ACTIONS*:
ADDITIONAL INFORMATION:

* Denotes required fields

Data Privacy

Adherence to the Personal Data Protection Law and Data Governance Policies, Regulations and Rules
Referring to the Personal Data Protection Law, issued by Royal Decree No. (M/19) dated 09/02/1443H*, and to the policies, controls and rules issued by the Saudi Data and Artificial Intelligence Authority and the National Data Management Office regarding data governance, based on the powers vested to the same under Cabinet Resolution No. (292) dated 27/04/1441H. Given that the Law, policies, controls and rules referred to above contribute to protecting and building confidence in the data sector in KSA, and that some of the above shall be implemented by the financial institutions supervised by SAMA, SAMA would like to emphasize the following:
First: Review the approved internal policies and procedures and ensure their compatibility and/or amendment in accordance with the following:
- Personal Data Protection Law issued by the Royal Decree * referred to above, within the legally specified period for commitment.
- Policies, controls and rules issued by the Saudi Data and Artificial Intelligence Authority, which can be accessed via the following electronic link: (sdaia.gov.sa/ndmo).
Second: Evaluate the organizational gaps (Gap Analysis) with the Law, policies, controls and rules referred to above and develop a time plan to correct and present them to the Board of Directors for approval.
Pursuant to Circular No. (44043873) dated 24/05/1444H; based on the powers vested to SAMA under the relevant laws and regulations; and given what has been observed that there are some practices that require individual customers to disclose some of their personal data before providing the service or product without it being necessary, whether directly or through a third party, SAMA affirms that all financial institutions shall fully adhere to the protection of customers’ personal data in accordance with the regulations and instructions referred to above and SAMA’s instructions in this regard; review the procedures related to the practices of disclosing customers’ personal data and take the necessary measures to preserve them; develop the necessary procedures and controls to ensure its security, integrity, and use for the purposes for which it was collected; and provide SAMA with a report explaining the measures taken in this regard
Communication in this regard with SAMA shall be via the following e-mail: (CRC.Compliance@SAMA.GOV.SA).
*This Law has been amended by Royal Decree No. M/148 dated 05/09/1444H.

Soft Launch

Cyber Risk Control

Glossary

Cyber Resilience

Cyber Resilience Fundamental Requirements (CRFR)

1 Introduction

1.1 Objective

1.2 Applicability

1.3 Responsibilities

1.4 Compliance

1.5 Interpretation

1.6 Target Audience

1.7 Review, Updates and Maintenance

1.8 Reading Guide

2 Fundamental Requirements Structure and Features

2.1 Structure

2.2 Risk-Based Approach

2.3 Entities Self-Assessment and Saudi Central Bank Audit

3 Control Requirements

3.1 Cyber Security Leadership and Governance

3.2 Cyber Security Operations and Technology

3.3 Resilience

4 Appendices

Appendix A: Glossary

Cyber Security Framework

1 Introduction

1.1 Introduction to the Framework

1.2 Definition of Cyber Security

1.3 Scope

1.4 Applicability

1.5 Responsibilities

1.6 Interpretation

1.7 Target Audience

1.8 Review, Updates and Maintenance

1.9 Reading Guide

2 Framework Structure and Features

2.1 Structure

2.2 Principle-Based

2.3 Self-Assessment, Review and Audit

2.4 Cyber Security Maturity Model

2.4.1 Maturity Level 3

2.4.2 Maturity Level 4

2.4.3 Maturity Level 5

3 Control Domains

3.1 Cyber Security Leadership and Governance

3.1.1 Cyber Security Governance

3.1.2 Cyber Security Strategy

3.1.3 Cyber Security Policy

3.1.4 Cyber Security Roles and Responsibilities

3.1.5 Cyber Security in Project Management

3.1.6 Cyber Security Awareness

3.1.7 Cyber Security Training

3.2 Cyber Security Risk Management and Compliance

3.2.1 Cyber Security Risk Management

3.2.1.1 Cyber Security Risk Identification

3.2.1.2 Cyber Security Risk Analysis

3.2.1.3 Cyber Security Risk Response

3.2.1.4 Cyber Risk Monitoring and Review

3.2.2 Regulatory Compliance

3.2.3 Compliance with (Inter)national Industry Standards

3.2.4 Cyber Security Review

3.2.5 Cyber Security Audits

3.3 Cyber Security Operations and Technology

3.3.1 Human Resources

3.3.2 Physical Security

3.3.3 Asset Management

3.3.4 Cyber Security Architecture

3.3.5 Identity and Access Management

3.3.6 Application Security

3.3.7 Change Management

3.3.8 Infrastructure Security

3.3.9 Cryptography

3.3.10 Bring Your Own Device (BYOD)

3.3.11 Secure Disposal of Information Assets

3.3.12 Payment Systems

3.3.13 Electronic Banking Services

3.3.14 Cyber Security Event Management

3.3.15 Cyber Security Incident Management

3.3.16 Threat Management

3.3.17 Vulnerability Management