Entire Section | SAMA Rulebook

All Financial Institutions

Anti Money Laundering and Combating the Financing of Terrorism
Instructions under this section should be read in conjunction with the Anti-Money Laundering Law and its Implementing Regulations and the Law on Combating the Financing of Terrorism and its Implementing Regulations.

The Guidance of Anti Money Laundering and Combating Terrorist Financing

I. Introduction
The Kingdom of Saudi Arabia is committed to detecting and preventing laundering of proceeds of ML/FT crimes as well as to punish perpetrators in accordance with the Anti-Money Laundering Law, the Law on Terrorism Crimes and Financing, and their Implementing Regulations. Saudi Arabia had previously ratified and signed agreements at the international level. It signed the United Nations Convention against Illicit Traffic in Narcotic Drugs and Psychotropic Substances in Vienna in 1988 and the United Nations Convention against Corruption in January 2004. It also ratified the International Convention for the Suppression of the Financing of Terrorism in New York in 1999 and the United Nations Convention against Organized Crime in Palermo in 2000. Saudi Arabia joined the Financial Action Task Force (FATF) in June 2019 to be the 1st Arab country and the 37th country in the world to obtain the membership. At the regional level, Saudi Arabia ratified the Arab Anti-Terrorism Agreement under the auspices of the Arab League at a conference held in April 1998. It also signed and ratified the Organization of Islamic Conference (OIC) Agreement for the suppression of international terrorism in July 1999 as well as the GCC Anti-Terrorism Agreement in May 2004. Saudi Arabia is a founding member of the Middle East and North Africa Financial Action Task Force (MENAFATF), which created in November 2004. Furthermore, many developments in the international financial sector have been witnessed in the recent years, including the efforts made for combating ML/TF. SAMA has adopted various initiatives that include measures and other criteria in response to international developments in this field. This includes the issuance of a guide for the implementation of Security Council Resolutions relevant to combating terrorism and its financing to ensure optimal application of updated procedures and mechanisms relating to such resolutions. SAMA also issued a guide for the implementation of Security Council Resolutions relevant to preventing proliferation of weapons of mass destruction and their financing to ensure that financial institutions optimally apply the relevant procedures and mechanisms. Due to the importance of financial institutions in detecting and preventing ML/TF transactions, SAMA has prepared this Guide to help financial institutions abide by the minimum regulatory requirements and to protect these institutions from being used as a conduit for illegal transactions arising from ML/TF activities and other crimes. This can contribute to enhancing and maintaining confidence in the integrity and reputation of the financial system in Saudi Arabia.

Chapter II: Purpose

•	The purpose of this Guide is to help financial institutions operating in Saudi Arabia and licensed by SAMA to develop and adopt a risk-based approach for conducting their business to meet the requirements of the Anti-Money Laundering Law, issued by Royal Decree No. (M/20) dated 05/02/1439H, and its Implementing Regulations, issued under the Decision of the Presidency of State Security No. (14525) dated 19/02/1439H, as well as the Law on Combating Terrorism Crimes and Financing, issued by Royal Decree No. (M/21) dated 12/02/1439H, and its Implementing Regulations, issued pursuant to the Council of Ministers’ Resolution No. (228) dated 02/05/1440H.
•	The requirements mentioned in this Guide reflect the obligations stated in the Anti-Money Laundering Law, the Law on Terrorism Crimes and Financing, and their Implementing Regulations. Such requirements do not impose any additional obligations on financial institutions supervised by SAMA.
•	The requirements stated in this Guide are obligatory and are the minimum requirements to be complied with by financial institutions. Moreover, a financial institution should put in place additional appropriate measures as required by the results of its approved risk assessment.

Chapter III: Legal Framework

•	Article (24) of the Anti-Money Laundering Law stipulates that “To carry out their mandate, supervisory authorities shall: (d) issue guidance, instructions, rules or any other instruments to financial institutions, designated non-financial businesses or professions, and non-profit organizations in pursuance of the provisions of this Law.”
•	Article (82) of the Implementing Regulations of the Law on Combating Terrorism Crimes and Financing stipulates that “To carry out their mandate, supervisory authorities shall: (4) issue instructions, rules, guidance, or any other instruments to financial institutions, designated non-financial businesses or professions, and non-profit organizations in implementation of the provisions of this Law.”
•	Paragraph (4) of Article (1) of the Implementing Regulations of the Anti-Money Laundering Law stipulated that “The supervisory authorities as stipulated in Paragraph (12) of this Article include: (a) The Saudi Central Bank.”
•	Paragraph (4) of the Implementing Regulations of the Law on Combating Terrorism Crimes and their Financing stipulates that “The supervisory authorities bellow, each according to its jurisdiction, referred to in Article 1/22 of the Law shall include (4) Saudi Central Bank.”
•	Supreme Royal Order No. (55871) dated 09/11/1436H providing for the approval for making King Salman Humanitarian Aid and Relief Center as the sole authority to collect relief, charitable or humanitarian donations, whether from government or private sources, to deliver them to those in need outside the country.
•	The Council of Ministers Resolution No. (226) dated 02/05/1440H states that SAMA is the competent authority by law to operate, monitor and supervise payment and financial settlement systems and their services in Saudi Arabia. It may issue rules, instructions and licenses in accordance with the standards applied by SAMA in this regard.

Chapter IV: Definitions

•	Anti-Money Laundering Law: The Anti-Money Laundering Law issued by Royal Decree No. (M/20) dated 05/02/1439H.
•	Law on Combating Terrorism Crimes and Financing: The Law on Terrorism Crimes and Financing issued by Royal Decree No. (M/21) dated 12/02/1439H.
•	Implementing Regulations of the Anti-Money Laundering Law: The Implementing Regulations issued by the Decision of the Presidency of State Security No. (14525) dated 19/02/1439H.
•	Implementing Regulations of the Law on Combating Terrorism Crimes and Financing: the Implementing Regulations of the Law on Combating Terrorism Crimes Financing issued under the Council of Ministers Resolution No. (228) dated 02/05/1440H.
•	SAMA: The Saudi Central Bank*.
•	Saudi Arabia Financial Intelligence Unit (SAFIU): A national center that receives information and reports related to crimes of money laundering, terrorist financing, predicate offenses, or proceeds of crime according to the Anti-Money Laundering Law, the Law on Combating Terrorism Crimes and Financing, and their Implementing Regulations. The SAFIU analyzes and investigates such reports and information before submitting related results to the competent authorities, promptly or upon request. The SAFIU reports to the President of State Security and has sufficient operational independence, and the President of State Security determines the organizational structure of the SAFIU.
•	Financial Action Task Force (FATF): An inter-government organization (established in 1989 in Paris by the G7) whose tasks include setting standards and promoting effective implementation of legal, regulatory and operational measures to combat money laundering, terrorist financing, and proliferation financing as well as other threats to the integrity of the international financial system.
•	Designated Non-Financial Businesses or Professions (DNFBPs):
This includes any of the following commercial or professional activities:
a)	Real estate brokerage when entering into business relationships for buying and selling real estate of all kinds.
b)	Dealing in gold, precious stones or precious metals when engaging in cash transactions with a customer equal to or over SAR 50 thousand or more, whether the transaction is carried out in a single operation or in several operations, which appear to be linked, whether through sole proprietorships or commercial companies.
c)	Lawyers and anyone who provides legal or accounting services in the exercise of their professional activities when they prepare, execute or conduct transactions in relation to any of the following activities:
	i.	Purchase or sale of real estate.
	ii.	Management of a customer’s funds, including bank accounts and other assets.
	iii.	Establishment, operation, or management of legal persons or legal arrangements, or the organization of related subscriptions.
	iv.	Sale or purchase of commercial companies.
•	Financial group: A local group consisting of a company or any other type of legal or natural persons that exercises control and coordinating functions over the rest of the group to implement group supervision, together with branches or subsidiaries that are subject to AML/CTF policies and procedures at the group level.
	a)	Financial institution: An entity conducting, for or on behalf of a customer, one (or more) of the following financial activities or operations: Acceptance of deposits and other funds payable by the public, including private banking services¹.
	b)	Lending, financial leasing, or any other financing activities.
	c)	Money or value transfer services.
	d)	Issuance and management of payment instruments (such as credit cards, debit cards, prepaid cards, checks, traveler’s checks, payment orders, bank transfers, and digital currency).
	e)	Issuance of letters of guarantee or other financial guarantees.
	f)	Trading in the following:
	i.	Checks, bills of exchange and other instruments.
	ii.	Currencies.
	iii.	Currency exchange, interest rate and financial index instruments.
	iv.	Negotiable securities and derivatives.
	v.	Commodity futures.
	g)	Foreign exchange transactions.
	h)	Participation in issuing securities and providing financial services.
	i)	Safekeeping and managing of cash or securities on behalf of another person.
	j)	Concluding protection and/or savings insurance contracts and other types of investment-related insurance as a provider, an agent or a broker of the insurance contract or any other insurance products stipulated in the Law on Supervision of Cooperative Insurance Companies and its Implementing Regulations.
	k)	Investment, management or operation of funds on behalf of another person.
•	Shell bank: A bank or a financial institution that is incorporated or licensed in a country where it has no physical presence and that is unaffiliated with a financial group subject to regulation and supervision.
•	Senior management: It includes the managing director, the chief executive officer, the general manager, their designates, the chief financial officer, and directors of key departments in charge of functions of risk management, internal audit, compliance, AML/CFT in a financial institution as well as those equivalent and any other positions specified by SAMA.
•	Senior management position: It includes the managing director, the chief executive officer, the general manager, their deputies, the chief operating officer, the chief financial officer, or the chief actuarial officer.
•	Financial institution staff: Members of the board of directors and its committees, executives, employees ( permanent and contracted), advisors and staff of a third party.
•	Customer: Any person who conducts, or intends to conduct, any of the following activities with the financial institution:
	a)	Arranging or undertaking a transaction, establishing a business relationship, or opening an account.
	b)	Signing a transaction, business relationship or account.
	c)	Assigning an account according to a transaction.
	d)	Transferring an account, rights or obligations according to a transaction.
	e)	Obtaining permission to conduct a transaction or to control a business relationship or an account.
•	Occasional customer: A person who does not have an existing business relationship with the financial institution but wishes to conduct a transaction through it.
•	Business relationship: A relationship of a continuing or temporary nature that is established between a financial institution and its customers related to the activities and services provided to them.
•	Beneficiary: A natural or legal person that benefits from a business relationship with a financial institution.
•	Beneficial owner: A natural person who ultimately owns or exercises direct or indirect control over a customer or a natural person on whose behalf a transaction is conducted, including over a financial institution or any other legal person.
•	Person acting on behalf of a customer: A person legally authorized to carry out or initiate any of the activities that a customer may conduct, such as an authorized person or a legal attorney.
•	Politically Exposed Persons (PEPs): Individuals who are entrusted with prominent public functions domestically or in a foreign country or who occupy senior management positions or positions in an international organization, including the following:
	a)	Heads of states or governments, senior politicians, senior government, judicial or military officials, senior executives of state-owned companies, and high-ranking officials of political parties.
	b)	Directors and deputy directors of international organizations, chairmen and members of the board of directors, and similar positions.
•	Family member of a PEP: Any natural person related to a PEP by virtue of blood or marriage until the second degree of kinship.
•	Person close to a PEP: Any natural person who is involved with a PEP by having a real partnership in a legal entity or a legal arrangement, who has a close business relationship with such PEP, or who is a beneficial owner of a legal entity or a legal arrangement ultimately owned or controlled by such PEP.
•	Preventive measures: All measures, procedures and controls adopted by a financial institution to mitigate the risks of ML/TF and proliferation.
•	Due diligence measures: The process of obtaining or verifying information of a customer or a beneficial owner to enable the financial institution to assess the extent to which the customer exposes it to risks.
•	Simplified measures: The application of preventive measures in a streamlined and simplified manner consistent with ML/TF risks posed by a customer, beneficial owner or business relationship. This includes taking simplified due diligence measures to identify and verify a customer, apply a simplified method of monitoring, and take any other simplified measures specified by the financial institution in its policy and procedures.
•	Enhanced measures: Additional measures are taken by a financial institution when the risks of ML/TF become high. These include enhanced due diligence measures to identify and verify a real customer or beneficial owner, additional control measures, and any other measures or procedures that the financial institution specifies in its policy.
•	Transaction: It includes all actions involving funds, properties or proceeds in cash or in kind. Examples of such actions include: Depositing, withdrawing, transferring, selling, purchasing, lending, swapping, extending of credit, mortgaging, gifting, financing and exchanging of funds in any currency, whether in cash or checks, payment orders, stocks, bonds, or any other financial instruments in addition to the use of safe deposit boxes or any other disposition of funds.
•	Funds: These are assets, economic resources and property of any value, type or ownership, whether material or immaterial, tangible or intangible, movable or immovable, as well as documents, deeds, instruments, transfers and letters of credit in any form, whether inside or outside Saudi Arabia. They also include electronic or digital systems, bank credits that indicate ownership or interest, and all types of commercial papers, securities, and any other interests, profits or incomes resulting from these funds.
•	Monitoring process: Follow-up of all transactions performed by customers of financial institutions, occasional customers, or the financial institution staff, with the aim of detecting any abnormal transactions.
•	Suspicious transaction: A transaction for which a financial institution has reasonable grounds to suspect its association with money laundering, terrorism financing, a predicate offense, or proceeds of a crime, including the attempt to conduct such transaction.
•	Records: Paper and electronic documents and reports related to transactions, business relationships, and commercial and monetary deals, whether local or external, including documents obtained under standard/enhanced/simplified due diligence measures and any documents that contribute to the interpretation of financial, commercial and cash transactions.
•	National address: The general place of residence of a natural or legal person unless such person chooses a specific address for receiving notifications. Each address (general or specific) prepared by the Saudi Post, as the case may be, is considered an approved address subject to all legal consequences.
•	Reliable source: The originating source of information or data on which a financial institution relies to identify a customer.
•	Third party: The entity on which a financial institution relies on implement the due diligence measures, provided that such entity is another financial institution or an owner of a DNFBP.
•	Correspondence relationship: It is a relationship between a correspondent financial institution and a respondent institution through an account or any other related services, such as cash management, international money transfers, check clearing, foreign exchange services, trade finance, liquidity management, and short-term lending. This includes correspondent relationships established for securities transactions or money transfers.
•	Correspondence payment accounts: These are demand deposit accounts opened by a foreign financial institution with a local financial institution to credit deposits and checks of its customers to those accounts. Foreign customers have the power to sign their account’s transactions, which enables them to carry out normal business activities at the international level. Financial institutions are prohibited from accepting this type of accounts.
•	Wire transfer: A financial transaction carried out by a financial institution on behalf of a wire transfer originator to make an amount of funds available to a beneficiary in another financial institution, regardless of whether the originator and the beneficiary are the same person.

¹ Private banking services are provided to high net worth individuals. A financial institution assigns a certain officer or a relation manager for such clients to facilitate their use of a wide range of financial services and products that usually include sophisticated operations and huge amounts. Such clients require a high level of confidentiality and thus private services are more vulnerable to ML/FT activities or proliferation.

* 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.

Chapter V: Concept of Money Laundering

A money laundering offence shall be deemed a separate offence from the predicate offense. A conviction for the predicate offense shall not be necessary for a conviction for money laundering or to establish that funds are proceeds of crime, whether the predicate offense was committed inside or outside Saudi Arabia. The intent, knowledge, or purpose of committing the money laundering offence shall be inferred from objective factual circumstances of the case. Anyone who commits any of the following acts shall be considered to have committed a money laundering offence:
	1.	Transfer, transportation, or performing of any transaction with funds while knowing that they are proceeds of crime in order to conceal or disguise the illegitimate origin of those funds or to assist a person involved in the predicate offense that generated those funds to evade the consequences of committing such crime.
	2.	Acquiring, possession or use of funds with the knowledge that they are proceeds of crime or from an illegal source.
	3.	Concealment or disguise of the nature, source, movement, ownership, place, manner of disposition of, or rights associated with funds that the person knows are proceeds of crime.
	4.	The attempt to commit any of the acts stated in Paragraphs (1, 2 and 3) above or participation in those acts by means of agreement, assistance, incitement, counseling, advice, facilitation, collusion, plotting, or concealment.
A legal person shall be considered to have committed a money laundering offence if any of the acts mentioned above was committed in its name or for its account. Criminal liability of a legal person shall not exclude the criminal liability of its chairpersons, members of its boards of directors, its owners, employees, authorized representatives, auditors, or any other natural person who acts in its name or for its account.
There are usually three stages of money laundering, explained as follows:
	1.	Depositing or Placement: In this stage, illegally obtained funds are introduced into the financial system, with the aim of depositing cash resulting from illegal activities into the financial system in a manner that does not attract attention. This is usually achieved through financial institutions when a customer or a person acting on their behalf engages in any of the financial activities and transactions, including acceptance of cash deposits, currency exchange, purchase of shares, and conclusion of finance contracts or protection and/or savings insurance contracts, without taking sufficient preventive measures by the financial institution to protect itself from money laundering risks.
	2.	Layering: It is the stage in which funds are transferred and moved with the purpose of concealing their origin. The aim is to disguise the illegal source of the funds introduced into the financial system. This stage may involve sending wire transfers to other financial institutions, purchase and sale of investments and financial instruments, cancellation of finance contracts or protection and/or savings insurance policies during the free look period², fraudulent investments, or business schemes.
	3.	Integration: In this stage, funds are brought into the economy again so that it becomes difficult to distinguish them from funds of legitimate origin. The aim is to legitimize illegal funds and integrate them into the domestic or global economy, through the purchase of financial assets, shares, or luxury goods or the investment in real estate.

² The period of time during which a beneficiary can review the insurance policy and assess its suitability as the policyholder has the option to cancel the insurance policy (Article 26 of the Insurance Market Code of Conduct Regulations).

Chapter VI: Concept of Terrorism Financing

Terrorist crime is any criminal act committed, individually or collectively, directly or indirectly, by a perpetrator, with the intention to disturb public order, destabilize the national security or state stability, endanger national unity, suspend the Basic Law of Governance or some of its provisions, cause damage to state facilities or its natural or economic resources, attempt to coerce any of its authorities into a particular action or inaction, harm or cause death to any person, when the purpose -by its nature or context- is to terrorize people or coerce any government or international organization into a particular action or inaction, or threaten to carry out acts that would lead to any of the aforementioned objectives or purposes or instigate such acts. It also includes acts constituting a crime according to Saudi Arabia's obligations to any international conventions or protocols pertaining to terrorism or its financing and to which Saudi Arabia is a party, and acts included in the Annex of the International Convention for the Suppression of the Financing of Terrorism. The crime of terrorism financing is achieved through provision of funds for the commission of a terrorist crime or for the benefit of a terrorist entity or person, including the financing of a terrorist’s travel and training.
Transactions related to terrorism financing are distinguished from those related to money laundering as follows:
	1.	Small transactions, including bank transfers and currency exchange, can be used to finance terrorist activities.
	2.	Terrorists can be financed using funds obtained legitimately, making it difficult for the financial institution to determine the stage in which legitimate funds become funds used to finance terrorist operations. Terrorists can derive their financing from legal and/or illegal sources.
Therefore, financial institutions shall ensure that their internal control and monitoring systems do not focus only on high-value transactions. They shall add indicators into these control systems relating to terrorism financing and the search for transactions without a clear economic purpose. In addition, financial institutions shall implement effective controls and procedures for customer identification and verification as well as continuous transaction monitoring and reporting of suspicious transactions to ensure that Saudi Arabia's financial system is not misused to finance terrorists, terrorist organizations, or terrorist acts.

Chapter VII:Governance and Responsibilities of Financial Institution
The financial institution is responsible for the effective implementation of the AML/CTF requirements and adoption of a risk-based approach to mitigate the money laundering and terrorism financing risks it faces. The financial institution shall not consider combating money laundering and terrorism financing in isolation from other regulations and needs in the financial institution, but as part of its comprehensive risk management strategies. Therefore, the board of directors and senior management in the financial institution shall ensure that the policies, procedures and controls in place related to AML/CTF are based on the results of money laundering and terrorism financing risks. To ensure the effectiveness of the AML/CTF strategy at the level of the financial institution, the risk management process shall be reviewed continuously and updated periodically, and appropriate mechanisms, policies and procedures shall be developed to mitigate risks. The financial Institution must ensure that its employees are sufficiently aware of all the policy requirements, procedures and internal controls and are working to implement them.

Section 1: Board of Directors

The board of directors of the financial institution is generally responsible for ensuring compliance with AML/CTF requirements. In this regard, the oversight exercised by the board concerning combating ML/TF shall be in line with international best practices, including SAMA Governance Guidelines. The board shall also ensure that there is documentation relevant to its oversight function, such as minutes of meetings of the board (or board committees). The main responsibilities of the board include, but are not limited to, the following:
	a)	Ensuring that the ML/TF risk assessment in the financial institution is conducted accurately and covers all risks facing the financial institution in order to develop appropriate policies to manage such risks.
	b)	Adopting an internal policy to mitigate ML/TF risks and ensure its effective implementation.
	c)	Providing sufficient budget and resources, including adequate and qualified employees as well as appropriate systems and tools in order to ensure that the application of internal policies, procedures and controls is effective and consistent with the ML/TF risks identified.
	d)	Following up on the implementation of the ongoing and annual training programs in the field of AML/CTF for all employees as well as members of the board of directors and senior management.
	e)	Ensuring that appropriate independent audit mechanisms are in place so that the board can monitor the ongoing effectiveness of internal controls.
	Ensuring that the appropriate actions are promptly taken and that violations are not committed when a branch or subsidiary in a country or region is unable to implement the AML/CTF requirements as stated in the Anti-Money Laundering Law, the Law on Combating Terrorism Crimes and Financing, and their Implementing Regulations due to the weakness of laws, regulations, or other domestic measures in that country or the inability to implement the appropriate measures.
	f)	Ensuring the receipt of regular comprehensive reports on ML/TF risks facing the financial group or financial institution, including but not limited to:
		•	Corrective action plans, if any, to process the results of independent audits (whether internal or external), observations of the AML/CTF compliance department and inspection reports from SAMA regarding the evaluation of the financial institution’s compliance with AML/CTF requirements.
		•	Developments and updates in the laws and regulations for combating money laundering and terrorism financing as well as their implications on the financial institution, if any.
		•	Details of high ML/TF risks and potential effects on the financial institution.
		•	Details on the implementation of financial sanction procedures related to the UN Security Council resolutions regarding those on terrorist lists, combating proliferation, or the decisions communicated by SAMA.

Section 2: Senior Management

The senior management is responsible for the continuous implementation and monitoring of compliance with the AML/CTF requirements in the financial institution. The main responsibilities of the senior management include, but are not limited to, the following:
	a)	Identifying, assessing, and understanding ML/TF risks arising from new products or services, distribution channels, or customers.
	b)	Establishing a program for AML/CTF that includes setting up and developing policies, procedures, and controls in line with the latest means, techniques and methods of ML/TF.
	c)	Adopting internal procedures and controls to mitigate ML/TF risks.
	d)	Reviewing policies and procedures periodically (at least once a year) by establishing an appropriate mechanism for periodic review of the main AML/CTF policies and procedures to ensure that they are continuously effective and consistent with the changes in products and services of the financial institution and to address new and emerging risks from ML/TF activities.
	e)	Taking actions with regard to all important recommendations issued by the AML/CTF compliance department, the independent auditor, and supervisory authorities concerning the level of compliance with AML/CTF requirements.
	f)	Providing the board of directors with sufficient relevant information in a timely manner about matters relating to AML/CTF.
	g)	Providing appropriate specialized training for employees in the AML/CTF compliance department and those working in the same field on an annual basis to ensure effective performance of their duties and functions.
	h)	Creating a continuous training program for employees of the financial institution to enable them to obtain sufficient knowledge and understanding and fulfill their responsibilities related to AML/CTF.
	i)	Supporting the functions of AML/CTF compliance and independent audit appropriately in terms of staff, technical systems, information, and budget in order to effectively implement, manage and monitor the AML/CTF program requirements.
	j)	Following up on the implementation of the instructions and circulars issued by SAMA regarding AML/CTF.

Section 3:Financial Institution Staff

Employees of the financial institution are responsible for the implementation of policies, procedures, and controls of AML/CTF, including:
	a)	Following and implementing policies and procedures of AML/CTF and being aware of the need to comply with the laws, regulations, and guidelines applicable in this field.
	b)	Ensuring that no actions are taken on behalf of a customer when such actions are required to be taken by that customer in accordance with the internal instructions.
	c)	Performing daily tasks in accordance with the internal work procedures of the financial institution and in a manner consistent with the relevant laws and instructions.
	d)	Reporting immediately to the AML/CTF compliance officer when there are reasonable grounds for suspicion of a ML/TF transaction.
	e)	Refraining from disclosing or implying any information about suspicious transactions linked to a certain customer or that certain transactions are under investigation internally or externally.
	f)	Taking the appropriate measures to ensure that no clues are given when requesting information from a customer.
	g)	Providing full assistance in investigations related to ML/TF.

Chapter VIII: General Framework

The principles in this Guide have been developed in accordance with the regulatory requirements provided for in the Anti-Money Laundering Law, the Law on Combating Terrorism Crimes and Financing, and their Implementing Regulations, which aim to establish effective requirements, guidelines, and procedures to prevent the use of Saudi Arabia’s financial system for purposes of ML/TF. These principles fall under the following headings:
	•	ML/TF Risk Assessment.
	•	Internal Policies, Procedures and Controls to Mitigate Risks.
	•	Due Diligence Measures.
	•	Enhanced Due Diligence Measures.
	•	Simplified Due Diligence Measures.
	•	Record Keeping.
	•	Monitoring of Transactions and Activities.
	•	Reporting of Suspicious Transactions.
	•	Arrangements of AML/CTF Compliance Function.
	•	Independent Audit Function.
	•	AML/CTF Training.
	•	Recruitment and Follow-up Criteria.
	•	Correspondent Relationship.
	•	Wire Transfer.
Based on the above requirements, a financial institution shall prepare and adopt a risk-based approach commensurate with the nature and size of its business. Such approach shall be prepared according to the following steps:
	•	First Step: Identifying the inherent risks of business and business relationships as well as any other risks.
	•	Second Step: Determining the financial institution’s risk appetite.
	•	Third Step: Developing preventive measures to mitigate risks based on the results of risk assessment.
	•	Fourth Step: Reviewing residual risks after developing the preventive measures.
	•	Fifth Step: Implementing the preventive measures to mitigate risks.
	•	Sixth Step: Reviewing and updating the risk-based approach.
Risks to which a financial institution is exposed are variable and changing over time as new products, business practices, or means of providing services, products, or transactions are developed. Therefore, the risk-based approach shall be regularly reassessed and updated when the risk factors associated with the financial institution change. The financial institution shall ensure that the risk-based approach is updated once every two years at a minimum or when risk factors change.

Chapter IX: The AML/CTF Guide

Section 1: ML/TF Risk Assessment

The main step for a financial institution to adopt a risk-based approach is to assess, understand and document its ML/TF risks and to identify the weaknesses that could be used to carry out ML/TF transactions. The risk assessment shall be comprehensive and include an analysis of the risks arising from:
		Customers and beneficial owners;
The nature of products, services and transactions offered; -countries or geographical regions in Saudi Arabia, The channels used for providing services and products; and Other risk factors. The principles of this Guide do not aim to encourage financial institutions to reduce risks by excluding certain services or a certain class of customers due to the high risks associated with them as financial institutions are not prohibited from dealing with high-risk customers and business relationships. Rather, a financial institution shall develop and implement preventive risk mitigation measures commensurate with the results of the risk assessment it conducted. Responsibilities of financial institutions to assess ML/TF risks are mentioned in Article (5) of the Anti-Money Laundering Law, Article (63) of the Law on Combating Terrorism Crimes and Financing, and Article (16) of its Implementing Regulations.
1.1	The financial institution shall take the appropriate steps to identify, assess, understand, and document in writing its ML/TF risks, provided that the nature and scope of the risk assessment are commensurate with the nature and size of the financial institution's business. Such risk assessment shall be updated regularly (once every two years at a minimum) and shall be documented and approved by the senior management. When carrying out the risk assessment process, the financial institution can focus on the following factors:
	a)	Risk factors associated with the financial institution’s business, with an emphasis on:
		-	Products and services.
		-	Transactions.
		-	Channels used for delivering services and products.
		-	Countries or geographical areas within Saudi Arabia where the business of the financial institution or its subsidiaries, in which the financial institution owns the majority of shares, is conducted.
	b)	Risk factors associated with customers, beneficial owners, or the financial institution’s beneficiary, with an emphasis on:
		-	Products or services used by customers, beneficial owners, or beneficiaries.
		-	The type of transactions executed by a customer.
		-	The volume of deposits and transactions made by a customer.
		-	Countries/geographical areas in which customers, beneficial owners, or beneficiaries conduct their businesses, or the source or destination of transactions.
		-	Characteristics of a customer, beneficial owner, or beneficiary (e.g. Profession, age and type of legal entity).
	c)	Other risk factors, including:
		-	ML/TF risks as issued by the Anti-Money Laundering Permanent Committee (AMLPC) and the Permanent Committee for Countering Terrorism (PCCT).
		-	Results of the risk assessment issued by SAMA, competent authorities and other supervisory authorities, when available.
		-	Purpose of the account or business relationship.
		-	The frequency of transactions or duration of the business relationship.
		-	Attractiveness of products and services provided to money launderers including, but not limited to, private banking services and products offered to high net-wealth individuals as well as quick transfers to high-risk geographical areas.
		-	Regulatory risks associated with regulations and decisions issued by government entities.
		-	Business risks associated with the organizational and operational structure of the financial institution.
		-	ML/TF risks that may arise from the development of new products, business practices, or means of providing services, products or transactions, or those arising from the use of new technologies or technologies under development with new or existing products.
		-	Any additional risks arising from other countries with which customers are associated, including intermediaries and service providers.
		-	Any other variables that may increase or reduce the risk of ML/TF in a particular situation.
		-	Results of ML/TF risk assessments issued by international bodies and organizations such as the FATF, the Basel Committee, the World Bank, the International Monetary Fund, the United Nations, and Transparency International.
1.2	Before developing and implementing controls, policies and procedures to mitigate ML/TF risks, the financial institution shall determine its risk appetite with respect to the results of ML/TF risk assessment, taking into account regulatory, reputational, legal, financial, and operational risks.
1.3	The financial institution shall develop and implement controls, policies and procedures to mitigate ML/TF risks based on the risk assessment results referred to in Paragraph (1.1). The financial institution shall ensure that such procedures are effective, appropriate and sufficient to mitigate the risks associated with the assessment results. Furthermore, the financial institution shall take into account that its activities will be exposed to risks regardless of the appropriateness and sufficiency of the measures taken. Therefore, it shall strengthen and update these measures whenever the need arises.
1.4	The financial institution shall classify all its customers according to the risk assessment results and take the necessary preventive measures to mitigate ML/TF risks. The financial institution can classify the level and degree of risks as (high, medium, or low) or using other categories as it determines based on the risk assessment results. This classification shall be consistent with the size and nature of the financial institution's business.
1.5	The financial institution shall review and update the customer risk profile regularly and based on the level of ML/TF risks.
1.6	The risk assessment shall be broad-based and at a level of sophistication commensurate with the business complexity of financial institutions with a complex organizational structure. For a financial institution with a less complex organizational structure, a simpler approach to conduct the risk assessment may be appropriate.
1.7	The financial institution shall assess risks before launching new products, services or business practices and before using new technologies or technologies under development, and it shall take appropriate measures to manage and reduce the identified risks as stated in Paragraph (1.3) under the ML/TF Risk Assessment Section.
1.8	The financial institution shall set up an appropriate mechanism for providing and submitting the information and reports on which the ML/TF risk assessment is based to SAMA upon request.
1.9	In the event that a customer is classified as high-risk, the financial institution shall obtain the senior management’s approval on the classification, provided that the information on which such classification is based is acceptable and reasoned.
1.10	Periodic reports shall be submitted to the board of directors regarding risk assessment at the level of the financial institution. The reports shall include the following:
	a)	Results of the ML/TF monitoring activities carried out by the financial institution.
	b)	The level of exposure to ML/TF risks based on major activities or customer categories.
	c)	General indicators and patterns of suspicious transactions as well as general trends and indicators of requests received from the SAFIU and the competent authorities.
	d)	Details of significant incidents, occurring internally or externally, and how they are handled in addition to their impact or potential effect on the financial institution.
	e)	Domestic and international developments in the AML/CTF laws, regulations, instructions and requirements as well as their impact on the financial institution.
	f)	The level of effectiveness of preventive measures in mitigating the effects of risks.

Section 2: Internal Policies, Procedures and Controls to Mitigate Risks

The development and implementation of a program for AML/CTF will be an effective and essential tool for applying the risk-based approach, provided that such a program should include controls, policies and procedures approved by the financial institution to mitigate ML/TF risks. The financial institution will have the discretion to determine the appropriate level of AML/CTF policies, procedures and controls, which shall be established based on the risk assessment results referred to under Section (1) of this Guide.
Article (14) of the Anti-Money Laundering Law and its Implementing Regulations and Article (18) of the Implementing Regulations of the Law on Combating Terrorism Crimes and Financing include the provisions and obligations that the financial institution shall include in its internal policies and procedures.
2.1	The financial institution shall develop an AML/CTF program that includes internal policies, procedures and controls to mitigate ML/TF risks in line with the risk assessment results approved by it as stated in Paragraph (1.1). The program shall also be documented, reviewed and enhanced continuously and approved at the level of the board of directors. Furthermore, the program should be commensurate with the nature and size of the financial institution’s business.
2.2	The AML/CTF program shall include the detailed elements and strategic plans of the financial institution to ensure application of the AML/CTF requirements. This includes preparing and updating the AML/CTF policy based on the risk assessment results mentioned in Paragraph (1.1) under the ML/TF Risk Assessment Section in addition to developing and implementing relevant internal work procedures, including those related to due diligence/enhanced due diligence measures.
2.3	The financial institution shall include ,as a minimum, the following elements in its internal policy and procedures for combating ML/TF:
	a)	Due diligence, including enhanced and simplified due diligence measures.
	b)	Record keeping.
	c)	Monitoring and following up transactions and activities.
	d)	Reporting of suspicious transactions.
	e)	Arrangements of AML/CTF compliance function.
	f)	Independent audit function.
	g)	AML/CTF training.
	h)	Recruitment and follow-up criteria.
2.4	The AML/CTF policies, procedures and controls in the financial institution shall be clearly documented and communicated to all relevant employees in the financial institution departments. All the employees shall be adequately trained to implement such policies and procedures.
2.5	The AML/CTF program shall be applied by the financial group to all of its branches and subsidiaries in which it owns the majority shares. The policies and procedures of the financial group shall include the sharing of information among group members and the provision of customer and transaction information for the purpose of carrying out AML/CTF compliance or independent auditing tasks, provided that such information Should be kept confidential.
2.6	If the foreign host country of the company, in which the financial group or institution owns the majority shares, does not allow the implementation of the AML/CTF program in a manner consistent with the AML/CTF requirements in Saudi Arabia, the financial group or institution shall take the following preventive measures:
	a)	Implementing appropriate additional measures to manage ML/TF risks.
	b)	Submitting reports to the AML/CTF Department at SAMA on the gaps in the implementation of the program and on the additional measures taken to manage arising ML/TF risks.
	c)	Considering discontinuing of the subsidiary’s operations if the financial group or institution is unable to put in place appropriate measures and procedures to mitigate ML/TF risks.
	d)	Adhering to any instructions received from SAMA in this regard.

Section 3: Due Diligence Measures

A. Due Diligence Measures

To establish a solid foundation for applying the risk-based approach, the financial institution shall know its customers and beneficial owners sufficiently to classify customer and business relationship risks from an AML/CTF perspective to direct its necessary resources to high-risk customers and business relationships to mitigate ML/TF risks. To achieve this objective, the financial institution shall classify customers based on the risks associated with them, as mentioned in the ML/TF Risk Assessment Section in this Guide. The information obtained from customers is the main basic tool for classifying customer risks. Therefore, the financial institution shall obtain reliable information from customers, verify such information, and ensure that it is updated and appropriate.
The volume of business that a financial institution is willing to accept should be matched with preventive measures that mitigate the risks associated with it. The financial institution is expected to develop a clear policy on customer and business acceptance and ensure that it has a sufficient level of internal controls to manage and mitigate ML/TF risks. Such preventive measures include the application of due diligence measures to identify and verify a customer, a person acting on his behalf, or a beneficial owner.
Article (7) of the Anti-Money Laundering Law and its Implementing Regulations and Article (17) of the Implementing Regulations of the Law on Combating Terrorism Crimes and Financing include the obligations of the financial institution upon application of due diligence measures.
3.1	The financial institution shall develop a policy for acceptance of new customers and business relationships, which includes due diligence measures to identify and verify a customer, a person acting on his behalf, or a beneficial owner. The policy shall be consistent with the risk assessment results and shall be documented and approved at the level of the board of directors.
3.2	The financial institution shall apply due diligence measures according to the type and level of risk posed by a certain customer, beneficial owner, or business relationship. Such measures shall be implemented in the following cases:
	a)	Prior to starting a new business relationship.
	b)	Prior to making a transaction for a natural or legal person with whom there is no business relationship, whether such transaction is carried out in a single operation or in several operations that appear to be linked.
	a)	Upon suspicion of ML/TF transactions.
	b)	When suspecting the credibility or adequacy of customer information previously obtained.
	c)	When a customer carries out a transaction inconsistent with his behavior or information.
3.3	At a minimum, due diligence measures shall comprise the following:
	a)	The financial institution shall identify the customer and verify the customer’s identity based on documents, data or information received from an authenticated and autonomous source that is well known, reputable and trusted by the financial institution. In all cases, the source of information shall not be the financial institution or the customer, but rather an independent source. For example, information and documents issued by government bodies are considered to be from reliable and independent sources. Moreover, customer identification shall be made as follows³:
		-	Natural Person: The person’s full name according to official documents shall be obtained and verified in addition to the residence or national address, date and place of birth, nationality, and source of income.
		-	Legal Person: The person’s name shall be obtained and verified in addition to the information about its legal status, proof of incorporation, powers regulating and governing the legal person’s work or the legal arrangement, names of all of its managers and senior executives, registered official address, place of business (if different), and the legal person’s sources of revenue.
	b)	The financial institution should identify the person acting on behalf of the customer and verify its identity through an authenticated and autonomous source to ensure that such person is actually authorized to act in this capacity. Adequate measures shall be taken to identify the person acting on behalf of the customer, including the nature of business relationship between that person and the customer in addition to applying the measure set under Item (a).
	c)	The financial institution shall identify the beneficial owner and take adequate measures to verify the identity of the beneficial owner using documents, data or information from an authenticated and independent source as mentioned under the Beneficial Owner Section.
	d)	The financial institution shall understand the purpose and nature of the business relationship and obtain additional related information if needed.
	e)	The financial institution shall understand the ownership and control structure of the (legal person) customer.
3.4	The financial institution shall develop the necessary procedures to collect sufficient information about customers and their expected use of products and services. The details and nature of the information are determined according to the degree and level of risks as high-risk customers and business relationships require greater scrutiny compared to those with lower risk. Therefore, the financial institution shall specify whether it should collect and verify any additional information based on the degree of risk posed by the customer and the business relationship.
3.5	The financial institution may choose not to carry out due diligence measures for each of the customer’s transactions since it can rely on the information previously obtained in this regard, provided that such information is updated, appropriate, and not suspicious.
3.6	The financial institution shall not accept customers or business relationships or carry out transactions without knowing the name and verifying the information of the customer or beneficial owner. The financial institution shall not accept customers, establish business relationships, or carry out transactions under names consisting of numbers or codes or using anonymous or fictitious names.
3.7	The financial institution shall continuously apply due diligence measures to customers, business relationships, and beneficial owners based on the type and level of risk. It shall also verify transactions conducted throughout the business relationship in order to:
	a)	Ensure that the information of the customer or beneficial owner and their activities are consistent with the risks they pose.
	b)	Ensure that the documents, data and information obtained under the due diligence measures are up-to-date, appropriate, and consistent with the customer's activity and transactions.
	c)	Consider reporting a suspicious transaction to the SAFIU when there are sufficient grounds for the suspicion.
	d)	Reassess customers’ risks based on their transactions and activities.
	e)	Verify business relationships and transactions of beneficial owners on a continuous basis.
	f)	Verify whether the customer is a politically exposed person (PEP).
3.8	The financial institution shall determine the number of times of reviewing and updating customer information based on the level and degree of risk posed by the customer, provided that due diligence measures are carried out continuously and more frequently for high-risk customers along with the appropriate enhanced measures.
3.9	The customer is not required to come to the financial institution when updating and reviewing their information for identity verification as long as electronic authentication services approved by the National Information Center are used. However, the financial institution shall determine the need for further documentation or the customer’s presence based on the level of risk posed by the customer.
3.10	When using reliable and independent electronic services to verify a customer’s identity, the financial institution shall determine if more documentation is required based on the level of risk posed by the customer. In addition, it must implement the necessary preventive measures to mitigate business relationship risks and set the necessary procedures and measures to verify and review the customer information obtained, including the information provided by the customer, using reliable and independent electronic services.
3.11	The financial institution shall take all the measures required to update and review information of customers and beneficial owners. If its preventive measures are found to be unsuccessful, this shall be clarified and documented as stated in Paragraph (6.6) in the Record Keeping Section. If the financial institution is unable to comply with the due diligence requirements, it must not establish a business relationship or execute a transaction for a customer. If an existing business relationship or customer is involved, the financial institution shall terminate the related business relationship and consider reporting suspicious transactions to the SAFIU.
3.12	The financial institution shall develop effective procedures to verify all the names of customers and beneficial owners, including all managers, senior executives, owners, and persons acting on behalf of customers, and compare them with those included in the sanction lists by local authorities and the United Nations before or during a business relationship or a transaction, taking into account Paragraph (8.15) in the Reporting of Suspicious Transactions Section.
3.13	The financial institution shall follow up on the available sanction lists of other countries⁴, verify all transactions and transfers, and use these lists for comparison in order to avoid potential legal problems that the financial institution or any other local or international parties might face and to avoid freezing of customer transactions or transfers.
3.14	In the event of suspicion of a ML/TF operation and when the financial institution has strong justifications and reasonable grounds that the customer may become aware of the suspicion upon application of the due diligence measures, the financial institution shall decide, at its discretion, not to carry out due diligence, provided that it shall comply with Paragraph (8.8) in the Reporting of Suspicious Transactions Section.
3.15	The financial institution shall use the best technologies to identify and record information in accordance with the due diligence requirements, so that changes in the data and their dates can be monitored and identified. Recorded and entered information shall be correct and consistent with the information provided by the customer after being verified. This shall include:
	a)	Information of customers.
	b)	Information of beneficial owners.
	c)	Information of owners and all managers and senior executives of the customer.
	d)	Information of the person acting on behalf of the customer.
3.16	The financial institution may accept the execution of a transaction for an occasional customer who does not have a business relationship with it. This applies to individuals (citizens and residents) and visitors with a visa of temporary residence, taking into consideration Paragraph (4.4) in the Enhanced Due Diligence Section.

³ Financial institutions must implement due diligence measures according to Paragraph (3.3) in addition to the relevant provisions in the Implementing Regulations of the Law on Supervision of Cooperative Insurance Companies, the Insurance Market Code of Conduct Regulations, the Implementing Regulations of the Finance Companies Control Law, the Implementing Regulations of the Financial Leasing Law, the Rules for Bank Accounts, the Rules Regulating Banking Agency in Saudi Arabia, the Regulations for Issuance and Operations of Credit and Charge Cards, the Regulatory Rules for the Prepaid Payment Services, and the Rules Regulating Money Changing Business.
⁴ Such as the sanctions lists of the European Union, the Office of Foreign Assets Control (OFAC) of the US Treasury Department, the US State Department, Interpol, etc.

B. Beneficial Owner

To implement the risk-based approach, the financial institution shall be certain of the identity of the beneficial owner or any person controlling the business relationship. The beneficial owner may not be a legal person, but rather a natural person who owns or controls the legal person directly or indirectly.
Concealing ownership information related to business and operations is one of the methods used for ML/TF. Therefore, collecting the necessary information and verifying the identity of the beneficial owner or anyone controlling the business relationship is important in combating ML/TF.
Article (7/3) of the Implementing Regulations of the Anti-Money Laundering Law and Article (17) of the Implementing Regulations of the Law on Combating Terrorism Crimes and Financing stipulate the measures that must be taken by the financial institution to identify and know the beneficial owner.
3.17	The financial institution shall know the identity of the beneficial owner and take sufficient and appropriate measures to verify that identity, using documents, data or information from an authenticated and independent source. In order to verify the beneficial owner’s identity, the financial institution shall obtain and review all necessary details and information, provided that the due diligence measures taken by the financial institution shall be consistent with the degree and level of risk.
3.18	The financial institution shall know the identity of the natural person who owns or controls (25%) or more of the legal person’s shares and take sufficient and reasonable measures to verify that identity, taking into account that a natural person who controls (25%) of the shares may not necessarily be the beneficial owner. In this case or when there is no natural person who owns or controls (25%) or more of the legal person’s ownership, or if there is suspicion that the owner of the controlling share is not the beneficial owner, the financial institution may take the following preventive measures:
	a)	Identifying the natural persons who occupy senior management positions with the legal person, so that the financial institution becomes sufficiently satisfied that these persons control the legal person.
	b)	Identifying the owners who control less than (25%) of the shares if it becomes clear to the financial institution that these owners are the beneficial owners or controlling the legal person.
	c)	Identifying the natural person who holds the position of senior management officer.
	d)	Identifying the high-risk customer and taking preventive measures, including enhanced due diligence measures and continuous monitoring of the customer.
	e)	Keeping records of the measures and procedures taken by the financial institution in addition to the reasons for suspecting that the owner of the controlling share is not the beneficial owner.
3.19	The financial institution shall not rely primarily on the written statement of a customer to identify the beneficial owner; it shall take reasonable and adequate measures to verify the beneficial owner by understanding the ownership and control structure of the legal person. In order to understand that structure, the financial institution can refer to any of the following documents:
	a)	The data of joint stock companies listed on the Capital market.
	b)	The stockholders register.
	c)	The memorandum of association.
	d)	Minutes of board meetings.
	e)	The company’s commercial register.
	f)	The articles of association.
3.20	The financial institution shall maintain records and documents related to the identification and verification of the beneficial owner as mentioned in Paragraph (6.1) of the Record Keeping Section.
3.21	If the customer of the financial institution is an individual, it shall ensure that the business relationship with that customer is used for the benefit of the individual whose name is registered and for the purposes specified (and determine whether the customer is acting in his own interest). In the event that there is a suspicion that the customer is acting in the interest of others, the financial institution must specify the capacity in which the customer, or anyone acting on his behalf, acts. The beneficial owner is then identified to the satisfaction of the financial institution. It shall also ensure that any person claiming to act on behalf of a customer is authorized and shall identify and verify that person's identity.

C. Reliance on a Third Party to Implement Due Diligence Measures

The financial institution may rely on another financial institution or any of the owners of DNFBPs to implement the due diligence measures. However, when a financial institution carries out the due diligence measures itself, it will be in a better position to identify and assess customer risks, especially when such measures involve meeting customers in person.
In all cases, in accordance with the obligations mentioned in the Anti- Money Laundering Law, the Law on Combating Terrorism Crimes and Financing, and their Implementing Regulations, the responsibility for implementing due diligence measures shall rest with the financial institution seeking assistance from another party as such financial institution is fully responsible for complying with the regulatory requirements relating to due diligence and SAMA’s Instructions for Outsourcing.
Article (7/10) of the Implementing Regulations of the Anti-Money Laundering Law allows the financial institution to rely on another financial institution or any of the owners of DNFBPs to carry out the due diligence measures, including entities that are part of the same financial group. Articles (7/11) and (7/13) of the Implementing Regulations specify the conditions that must be fulfilled by the financial institution prior to reliance on another party.
3.22	The financial institution may rely on a third party, whether it is a financial institution or any of the owners of DNFBPs, to implement the due diligence measures, in accordance with the following:
	a)	The financial institution shall ensure that the third party is subject to regulation and supervision and that it applies due diligence and record-keeping measures as stated in the Anti-Money Laundering Law, the Law on Combating Terrorism Crimes and Financing, and their Implementing Regulations.
	b)	The financial institution shall take actions to ensure that due diligence information is provided by the third party upon request and without delay.
	c)	The financial institution shall immediately obtain all information related to due diligence, including simplified and enhanced due diligence measures, from the third party.
	d)	The financial institution shall take into consideration the information available to the AMLPC, the PCCT, and the SAFIU on high-risk countries when determining the countries in which the third party may be conducting business.
3.23	The financial institution shall assess the ML/TF risks associated with reliance on a third party and, therefore, it shall develop and apply appropriate policies and procedures for risk management. Such procedures may include the following:
	a)	Identification of the minimum due diligence requirements to be met by the third party.
	b)	Conduct frequent examination of obtained information and documents to apply the due diligence measures, including enhanced or simplified due diligence.
	c)	Monitoring of customers and business relationships established them through reliance on a third party as well as application of intensive control measures towards them in accordance with the ML/TF risk assessment results.
3.24	The financial institution shall periodically verify (at least annually) that the third party has the sufficient capabilities and powers required to fulfill the due diligence requirements in a professional manner. The financial institution shall also continuously assess the third party's compliance with such requirements.
3.25	The financial institution has the right to directly obtain the customer due diligence information from the third party relied upon to perform due diligence, if such party has previously implemented due diligence measures for the same customer when dealing with another financial institution, taking into account that the required information shall be complete and that due diligence measures are constantly applied according to the requirements mentioned in Paragraph (3.7) in the Due Diligence Section.

Section 4: Enhanced Due Diligence Measures

A. Enhanced Due Diligence Measures

Customer classification according to the level of risks is a key element in the financial institution’s risk-based approach. The financial institution shall identify the risk factors to be taken into consideration when classifying a customer in the high-risk customer category from the AML/CTF perspective. It shall also take additional steps to collect information about high-risk customers and business relationships in order to understand and assess risks and monitor transactions more accurately. It is the responsibility of the financial institution to identify high-risk customers, either individually or by category, and accordingly implement enhanced due diligence measures in a manner that ultimately leads to mitigating risks.
The financial institution may also refer to a set of available resources to classify the degree and level of risk for high-risk customers, including the data collection form prepared by SAMA and the FATF guidelines that aim to assist financial institutions in identifying high-risk customers.
Article (7/14) of the Implementing Regulations of the Anti-Money Laundering Law and Article (17) of the Implementing Regulations of the Law on Combating Terrorism Crimes and Financing state that it is the responsibility of the financial institution to implement enhanced due diligence measures in the case of ML/TF high risks based on the type and level of risk posed by a specific customer or business relationship. Article (11) of the Anti-money Laundering Law and Article (66) of the Low on Combating Terrorism Crimes and Financing require the financial institution to apply enhanced due diligence measures commensurate with the risks involving business relationships and transactions with a person from a country identified as a high-risk country by the financial institution, the PCCML, or the PCCT.
4.1	The financial institution shall design and implement its risk-based approach in a manner that enables it to identify high-risk customers and beneficial owners according to the risk elements specified in Paragraph (1.1) in the ML/TF Risk Assessment Section. When a customer or business relationship is classified as high risk, the financial institution shall take enhanced risk mitigation measures, including enhanced due diligence measures.
4.2	The financial institution shall include in its approved AML/CTF policies and procedures the enhanced due diligence measures to be taken to identify high-risk customers and business relationships. These measures may include the following:
	a)	Obtaining and verifying information about the customer's job, activity or profession.
	b)	Identifying and knowing the source of funds/income at the beginning of dealing with the customer and when carrying out transactions for the customer as well as verifying the data and information.
	c)	Obtaining information regarding the customer’s size of assets and transactions.
	d)	Conducting on-site visits to verify the nature of the customer's business.
	e)	Obtaining any additional documents or information to know the customer.
4.3	Upon identifying a high-risk customer before/after establishing the business relationship, the financial institution shall obtain approval from the senior management to deal with and continue the business relationship with the customer.
4.4	The financial institution shall apply enhanced due diligence measures to high-risk customers and business relationships with any natural or legal person, even if the financial institution does not have a business relationship with that person, if such person poses high risk from the AML/CTF perspective.
4.5	When discovering that another financial institution has refused to deal with a specific customer, the financial institution shall implement enhanced due diligence measures, know the reasons behind that refusal, and take additional due diligence measures if the reason for refusal was a suspicion related to ML/TF.
4.6	The financial institution shall apply enhanced due diligence measures to customers with a complex organizational structure so it can understand and identify customer risks and verify the beneficial owner.
4.7	The financial institution shall take appropriate measures to identify high-risk countries associated with ML/TF risks and implement enhanced due diligence measures that are commensurate with the risks that may arise from business relationships and transactions with a person from such countries. This includes the following:
	a)	Following up what is issued by the PCCML regarding high-risk countries.
	b)	Following up what is issued by the PCCT regarding high-risk countries.
	c)	Following up on the guidance issued by the FATF concerning the deficiencies of countries in the implementation of preventive measures to protect the international financial system against ML/TF risks.
4.8	When taking enhanced customer due diligence measures, the financial institution shall properly document these measures in accordance with Paragraph (6.1) in the Record Keeping Section.

B. Politically Exposed Persons (PEPs)

Identifying a PEP and the extent to which that person is considered politically exposed is one of the customer due diligence measures taken by the financial institution to implement the risk-based approach in conducting its business. The political influence and power of such person may lead to misuse of this power for illicit enrichment. Proceeds in this case are often transferred under names of relatives or persons close to a PEP for the purpose of concealment.
Therefore, the financial institution shall take reasonable measures to identify whether a customer or beneficial owner is a PEP. In cases of high-risk business relationships with PEPs, the financial institution shall apply enhanced due diligence measures and apply the same to all types of PEPs, their family members, and persons close to those PEPs.
Article (8) of the Anti-Money Laundering Law and its Implementing Regulations require the financial institution to develop internal procedures and provide appropriate tools to identify PEPs and implement enhanced due diligence measures regarding them.
4.9	The financial institution shall use appropriate tools and measures to determine if a customer or beneficial owner is a PEP, whether that person is foreign or local. These tools and measures may include the following:
	a)	Searching for the customer in any available information sources.
	b)	Relying on a credible database to identify and verify the information of PEPs, including the use of programs or information systems that enable the financial institution to determine if a customer, potential customer, or beneficial owner is a PEP.
	c)	Include specific questions regarding a customer being a PEP at the start of the business relationship or when updating and reviewing customer information.
	d)	Verify the customer’s position and the potential use of power related to it.
4.10	The financial institution shall take into consideration that mere reliance on electronic systems and programs does not guarantee full compliance with the Anti-Money Laundering Law and its Implementing Regulations. The financial institution is responsible for determining whether a customer is a PEP or not, and combining the tools mentioned in Paragraph (4.9) may be highly effective in identifying and verifying the PEP.
4.11	The financial institution shall determine if a customer or beneficial owner is a PEP in the following cases:
	a)	Prior to starting a new business relationship.
	b)	Prior to making a transaction for a natural or legal person with whom there is no business relationship, whether such transaction is carried out in a single operation or in several operations that appear to be linked.
	c)	When updating or reviewing customer information.
	d)	Upon suspicion that the customer is a PEP.
4.12	The financial institution shall continuously apply due diligence to customers, business relationships, and beneficial owners to verify if a customer is a PEP, as mentioned in Paragraph (3.7) in the Due Diligence Section.
4.13	The financial institution shall classify the foreign person as a high-risk PEP customer and implement enhanced due diligence measures to mitigate risks, including:
	a)	Obtaining approval of the senior management before establishing or continuing a business relationship with that person.
	b)	Taking all reasonable measures to identify the source of the customer’s wealth and funds.
	c)	Implementing enhanced and continuous due diligence measures for the business relationship.
The financial institution shall apply the same measures to local PEPs when the level of ML/TF risks is high.
4.14	The financial institution shall apply the same enhanced due diligence measures to the family members of the PEP as well as any person close to the PEP.
4.15	To determine the level and degree of risk posed by a local PEP, the financial institution shall observe the requirements mentioned in Paragraph (1.1) under the ML/TF Risk Assessment Section. It may also rely on the following information:
	a)	The period of time for which a local PEP has been entrusted with prominent public functions in Saudi Arabia or in a foreign country.
	b)	Corruption risks associated with the entity where a local PEP occupies his position and the extent to which that entity is exposed to corruption risks.
	c)	The customer's attempt to conceal or present inaccurate information related to the application of due diligence/enhanced due diligence, such as:
		-	Concealing or providing inaccurate information related to the customer's job and the extent to which it is associated with high public positions or functions in Saudi Arabia or any foreign country.
		-	Concealing or providing inaccurate information related to the source of income/wealth.
	d)	Reliance on the family members of a local PEP or persons close to that person to act on his behalf.
4.16	The financial institution shall have sufficient, reasonable and documented grounds based on the ML/TF risk assessment results if it decides that a local PEP, their family members, or persons close to that PEP do not pose high risk from the AML/CTF perspective.
4.17	If it is established from protection and/or savings policies or investment- related insurance documents that a beneficiary or beneficial owner is a PEP, the financial institution shall take enhanced due diligence measures to mitigate risks before the payment of benefits or exercise of any rights under those documents. Such measures shall include the following:
	a)	Notifying the senior management before the payment of benefits or exercise of any rights under those documents.
	b)	Carrying out a thorough examination of the business relationship with the customer and considering reporting to the SAFIU in case of a suspicious transaction.
	The rights exercised by a customer under a policy may include:
	•	Cancellation of the policy.
	•	Cancellation of the policy during the free-look period.
	•	Partial withdrawal of the investment amount.
	•	Change of investment fund.
	•	Payment of additional premiums.
4.18	If the financial institution fails to identify a PEP or has suspicions regarding a PEP, it shall include the following in its records:
	a)	The measures taken to determine the customer type.
	b)	Reasons for suspicions about the nature of the customer’s position or job or association with a PEP.
	c)	Reasons why the measures did not work.
	d)	The date on which the measures were taken.

Section 5: Simplified Due Diligence Measures

The financial institution's adoption of the risk-based approach can result in identifying and classifying customers and business relationships of low risk from the AML/CTF perspective. Thus, it is possible for the financial institution to implement simplified measures in cases where the ML/TF risk assessment results indicate low risk.
In order for the financial institution to reach such result, sufficient information about the customer must be collected to determine the related level of risk.
Article (5/5) of the Implementing Regulations of the Anti-Money Laundering Law and Article (17) of the Implementing Regulations of the Law on Combating Terrorism Crimes and Financing state that the financial institution may apply simplified measures when the ML/TF risks are low subject to the necessary conditions.
5.1	When the level of ML/TF risks is low, the financial institution may take simplified measures, provided that there is no suspicion of any ML/TF transaction. Such simplified measures shall be commensurate with the low risks and must include the adoption of simplified due diligence to identify and verify the customer’s identity.
5.2	The financial institution shall include the simplified measures and procedures applied to low-risk customers and business relationships in the approved AML/CTF policies and procedures.
5.3	Application of the simplified measures does not mean exemption from the requirements of customer due diligence, but rather the application of due diligence measures in a streamlined and simplified manner consistent with the ML/TF risks posed by the customer or beneficial owner. Regardless of the level of risk posed by the customer or business relationship, the financial institution shall comply with the following when applying due diligence:
	a)	Verifying the identity of the customer or the person acting on his behalf, relying on an authenticated and independent source.
	b)	Identifying and verifying the identity of the beneficial owner through a reliable and independent source to the satisfaction of the financial institution that it knows the beneficiary owner.
	c)	Understanding the nature and purpose of the business relationship.
	d)	Understanding the ownership and control structure of the customer who is a legal person.
5.4	The financial institution may apply simplified due diligence measures for all the criteria mentioned in Paragraph (5.3) in the Simplified Due Diligence Section. The financial institution determines the nature and quality of these simplified due diligence measures according to its ML/TF risk assessment results. Such measures are usually associated with the following elements:
	a)	Timing of verification of the customer's information and associated documents.
	b)	The intensity and periodicity of the verification of customer information.
	c)	Details and nature of the information obtained from the customer.
5.5	Having identified the customer, the financial institution may postpone the identity verification process, provided that it shall adhere to the following:
	a)	Verifying the information and documents of the customer as soon as possible.
	b)	Ensuring that it is necessary to postpone the verification of the customer’s identity to avoid interruption of usual business procedures.
	c)	Applying appropriate and effective measures to control ML/TF risks.
	d)	Ensuring that measures for risk management are in place regarding the situations in which a customer can benefit from a business relationship prior to the verification process.
5.6	If simplified due diligence measures have been applied to certain customers and business relationships, they shall be subjected to monitoring by the financial institution, as described in Paragraph (7.3) in the Monitoring of Transactions and Activities Section. Based on continuous monitoring, the financial institution shall consider applying enhanced due diligence in the case of high ML/TF risks.
5.7	When carrying out a transaction for an occasional customer, the financial institution shall obtain the information of the identity of the citizen/resident or the passport and visa information of the visitor/temporary resident and record the executed transactions number as a reference. If the transaction involves a money transfer or check, a copy of the ID or passport and visa shall be obtained and the requirements under the Wire Transfer Section shall be met.
5.8	An occasional customer is allowed to execute the following transactions:
	a)	Payment of utility bills.
	b)	Payment of amounts payable to government entities.
	c)	Currency exchange, money transfer, and cashing of checks with a maximum amount of SAR 5,000 or its equivalent per transaction, or no more than SAR 50,000 or its equivalent in one year.
	d)	Purchase of visitor mandatory insurance policies.

Section 6: Record Keeping

The financial institution shall make its records available to the competent authorities and to its relevant departments in order to allow analysis of data, tracking and structuring of financial transactions, tracing of the origin and executor of transactions as well as those authorized to sign or carry out transactions.
Article (12) of the Anti-Money Laundering Law and Article (65) of the Law on Combating Terrorism Crimes and Financing state the financial institution’s obligations relating to the manner of record keeping, the minimum record-keeping period, and the possibility for extending that period according to the regulatory requirements.
6.1	The financial institution shall keep records for a period of no less than ten years from the date of the end of the business relationship or contract, conclusion of the transaction, or closure of the account, or the date of completion of a transaction for a customer who has no business relationship with the financial institution (occasional customer). The financial institution shall also comply with any instructions issued by the competent authority to extend the record-keeping period.
6.2	The financial institution shall put in place approved internal procedures and controls for record keeping and documentation and ensure that they are reviewed and enhanced on an ongoing basis and effectively implemented. These shall at least include the following:
	a)	The manner for record keeping (paper or electronic) and the mechanism and authorization for access to records and their retrieval.
	b)	The measures taken to meet the regulatory requirements related to record keeping outside Saudi Arabia to ensure that there are no obstacles to having access to the records.
	c)	Arrangements of the record keeping department that ensure meeting the regulatory requirements for AML/CTF.
6.3	The financial institution shall provide the record keeping department with adequate resources, take the necessary measures to maintain and protect its electronic archiving systems, and conduct periodic tests (at least annually) to verify the effectiveness of the record-keeping process.
6.4	The financial institution shall keep records in a retrievable and auditable manner and maintain a complete and appropriate status of the records to allow analysis of data and tracking of transactions, provided that the financial institution provides SAMA with the necessary records as requested.
6.5	In the case of outsourcing, the financial institution should consider the following:
	a)	The contract must clearly state the obligations requiring the third party to enable the financial institution to obtain records and exercise the right to directly access the data related to outsourcing in addition to the right of access to the service provider’s workplace.
	b)	The contract must clearly state the obligations requiring the third party not to provide any other party with the data or records or allow access to the areas or technological systems used for document and record keeping, except through the financial institution after coordination with SAMA.
	c)	The financial institution shall conduct periodic checks by asking the third party to provide various samples of the records to ensure that the third party is compliant with the obligations and requirements of the contract in line with the regulatory requirements.
	d)	The requirements stated in Paragraphs (3.21) and (3.22) in the Due Diligence Section shall be observed.
6.6	When unsuccessful preventive measures have been taken by the financial institution, it shall keep a document explaining these measures for no less than ten years from the date on which the measures were taken, provided that the document includes the reasons why the measures did not work. In all cases, the financial institution shall observe Paragraph (3.11) under the Section on Due Diligence Measures.
6.7	The financial institution shall keep documents related to internal investigations, inspections, and suspicious activity reports for a period of no less than ten years from the date of reporting to the competent authorities or taking the decision not to report, taking into account that:
	a)	Reports and internal investigations shall be confidential.
	b)	Specify employees authorized to have access to the documents.
6.8	When conducting wire transfers, the financial institution shall maintain all information related to the wire transfer originator and the beneficiary as stated under the Record Keeping Section.
6.9	In cases of wire transfers outside Saudi Arabia, the intermediary financial institution in the payment chain shall ensure that all information relating to the originator and beneficiary remains with the wire transfer and shall keep all of that information in its records as stated under the Record Keeping Section.
6.10	In cases where technological restrictions prevent the retention of information about the originator or beneficiary associated with a wire transfer outside Saudi Arabia and it is intended to be kept with the relevant local wire transfer data, the intermediary financial institution shall keep a record containing all information received from the financial institution that originated the transfer or from the intermediary institution for a period of ten years from the date of completion of the transaction or closure of the account.

Section 7: Monitoring of Transactions and Activities

The monitoring of transactions and activities, including those unusual and suspicious, is an important element for applying the risk-based approach as it enables the financial institution to identify and report any suspicious transactions or activities to the SAFIU. In addition, monitoring systems in the financial institution allow continuous assessment of preventive measures and controls as well as enhancement of their efficiency by making use of any unusual activities detected that led to suspicion of ML/TF.
Article (13) of the Anti-Money Laundering Law and Article (69) of the Law on Combating Terrorism Crimes and Financing state the financial institution’s responsibilities to continuously monitor transactions, documents and data to ensure that they are consistent with the information the financial institution has about the customer or business relationship. These responsibilities also include giving particular attention to unusual transactions and activities, especially when they involve high ML/TF risks.
7.1	The financial institution shall put in place measures and procedures based on the risk assessment results to monitor transactions and identify unusual transactions and activities. The measures and procedures shall be effectively implemented and documented by the financial institution; and approved at the senior management level.
7.2	When developing the oversight measures and procedures, the financial institution shall apply a risk-based monitoring approach according to the degree and levels of risk derived from the ML/TF risk assessment results. This risk-based monitoring approach shall enable the financial institution to:
	a)	Implement enhanced measures by improving the process and degree of oversight on high-risk customers and transactions, including:
		•	Review and monitoring of high-risk transactions.
		•	Frequent monitoring of the activities and transactions of high-risk customers in addition to preparing relevant reports and frequently carrying out the required internal investigations.
		•	Tracking and financial analysis of unusual activities or transactions carried out by customers.
	b)	Implement simplified measures for low-risk customers and businesses, including reducing the rate and frequency of monitoring in the case of low ML/TF risk.
7.3	Carrying out simplified oversight on low-risk customers and businesses does not mean exemption from the requirements of monitoring as the financial institution shall monitor all customers and transactions on an ongoing basis. However, it allows the financial institution to implement control procedures in a streamlined and simplified manner consistent with the ML/TF risk posed by the customer or business relationship in order to be able to focus its resources on high-risk customers and transactions.
7.4	To apply the risk-based oversight approach, the financial institution shall observe the following:
	a)	The financial institution shall provide supervisory tools commensurate with the risks identified in accordance with Paragraph (1.1) under the ML/TF Risk Assessment Section, to enable it to analyze and detect unusual transactions, patterns, and activities in real time of execution or before that. The financial institution shall provide adequate human resources in this regard to monitor transactions and activities and detect any unexpected or unusual behavior from customers. Such tools shall be consistent with the nature, size, and complexity of the financial institution’s business and it shall ensure adequate and continuous monitoring.
	b)	The financial institution shall develop indicators and patterns commensurate with the risks identified, the complexity of its business and activities, and modern ML/TF technologies so that it can detect unusual transactions or activities according to the requirements, development and diversity of the methods used in the execution of such operations and transactions. The indicators can be transformed into strategies for assessing ML/TF risks and designing controls to mitigate such risks.
7.5	The supervisory tools of the financial institution shall include appropriate technological systems that enable it to monitor transactions and activities and detect any unusual or unexpected behavior from customers as manual monitoring of transactions alone is not sufficient. It is necessary for the financial institution to use effective electronic systems for its continuous oversight of transactions, and the systems used shall be commensurate with its risk complexity and outcomes. However, these systems shall be integrated with the basic systems of the financial institution to achieve the following:
	a)	Linking the risk-based customer classification to the technological system to allow further monitoring of high-risk customers and transactions in accordance with the requirements stated in Paragraph (7.2) in the Monitoring of Transactions and Activities Section.
	b)	Following-up all the business of the financial institution as appropriate to ensure adequate monitoring and control.
	c)	Applying a simplified monitoring approach consistent with the risks posed by low-risk customers and businesses, in accordance with Paragraph (7.2) under the Monitoring of Transactions and Activities Section.
7.6	The financial institution shall test the supervisory tools periodically (Once a year a maximum) to ensure that they are effective and adequate and shall develop these tools based on the results of periodic tests that must be documented.
7.7	The financial institution shall monitor customers and transactions on an ongoing basis and take the necessary preventive measures to review and update customer information and categorize customers based on the monitoring results, in accordance with Paragraph (3.7) in the Due Diligence Section. This is to detect any inconsistency between the information disclosed by customers at the beginning of or during a business relationship and the activities monitored. Customers and transactions shall continue to be monitored until the conclusion of the business relationship.
7.8	The financial institution must qualify and train its employees to carry out the monitoring process according to their various work tasks and it shall not only rely on technological systems and programs, taking into consideration its prescribed ML/TF indicators.
7.9	The financial institution shall develop indicators and typologies commensurate with the nature and risks of its business that point to the suspicion of ML/TF transactions, taking into account the diversity and development of ML/TF methods. Moreover, the financial institution shall constantly update these indicators as required and according to development and diversity of the methods used for ML/TF. It shall also observe the instructions issued by SAMA, the PCCML, or the PCCT and those issued by other local or international bodies, such as the FATF.
7.10	The financial institution’s key positions/posts that might be targeted for ML/TF purposes shall be identified. The financial institution shall closely monitor those holding these positions and ensure that they consistently implement AML/CTF policies and procedures.

Section 8: Reporting of Suspicious Transactions

The financial institution shall set up and effectively implement internal procedures for reporting unusual transactions or activities to protect itself from being exploited as a channel to carry out ML/TF transactions. The financial institution shall have a database that helps employees determine if unusual transactions or activities provide reasonable grounds to suspect ML/TF.
Articles (15) and (16) of the Anti-Money Laundering Law and Articles (70) and (71) of the Law on Combating Terrorism Crimes and Financing set forth the financial institution’s obligations to report suspicious transactions in addition to the regulatory requirements related to non-alerting customers .
8.1	The financial institution shall set up and document procedures for reporting suspicious transactions, implementing them effectively, and ensuring that they are approved at the level of the board of directors. The procedures may include the following:
	a)	Internal procedures to be followed by the its employees and senior officers in the event of suspicion of ML/TF.
	b)	A mechanism that facilitates employees’ communication with the officer responsible for reporting suspicious transactions to raise inquiries and report suspicions.
	c)	Internal investigation procedures relating to suspicion cases, including the stages of investigation.
	d)	Levels of approval and review of suspected cases if reports are approved or closed.
	e)	Determining the employee or officer responsible for reporting to the SAFIU about suspicious transactions.
	f)	Adequate measures to maintain confidentiality of reports and ensure that customers are not alerted.
8.2	The financial institution shall provide sufficient resources that allow effective follow-up and sufficient investigations of all internal reports to determine whether submitting a suspicion report to the SAFIU is justified.
8.3	The financial institution shall immediately and directly inform the SAFIU upon suspicion or the presence of information or reasonable grounds to suspect that a customer’s behavior is related to ML/TF acts. If the financial institution submits a report to the SAFIU, it shall respond to and provide the SAFIU with any additional information that it requests directly in order to analyze the submitted report.
8.4	The financial institution shall report all suspicious transactions, including unsuccessful attempts to carry out transactions, if there are reasonable grounds for suspicion, regardless of the transaction’s value.
8.5	The financial institution shall inform the SAFIU upon suspicion of wire transfer transactions.
8.6	The financial institution shall not submit any report to the SAFIU based on speculation or lack of information or reasonable grounds for suspicion. The financial institution has reasonable grounds to report on suspicions in the following cases:
	a)	When the financial institution knows, through its conduct of its business or investigations, that the activity or operation to be carried out is related to a suspicious transaction.
	b)	When the financial institution has sufficient information indicating that the activity or transaction to be carried out is related to a suspicious transaction.
8.7	The financial institution shall decide, at its discretion, not to apply the due diligence measures in the event of suspicion of an ML/TF act when it has strong justifications and reasonable grounds that the customer may become aware of the suspicion if the financial institution applies due diligence. In this case, it shall submit a report on a suspicious transaction to the SAFIU. The report shall include the reasons and justifications for not applying due diligence.
8.8	The financial institution shall submit suspicious transaction reports according to the reporting mechanism and form approved by the SAFIU, on the condition that the SAFIU is provided with an additional detailed report that includes all data and information available to the financial institution on that transaction and the parties involved.
8.9	The financial institution shall submit a technical report on the reported cases to the SAFIU. The report shall include the following:
	a)	The account statement or transactions carried out under the contract for a period of six months.
	b)	Documents obtained to apply due diligence measures.
	c)	A technical report examining the account or contract subject of suspicion.
8.10	If a decision not to inform the SAFIU of an internal report is made, the officer responsible for reporting suspicious transactions shall document this including the reasons for not reporting in a detailed and sufficient manner, taking into account the levels of approval and review mentioned under Paragraph (8.1/d).
8.11	The financial institution shall keep records of all suspicious transaction reports submitted, including a copy of reports submitted to the SAFIU and internal reports on cases that were under investigation and were not reported due to the lack of sufficient grounds for suspicion. Investigation documents and reports shall be kept independently without prejudice to the requirements of confidentiality of investigations and reports, and the persons authorized to access these records shall be specified.
8.12	The financial institution shall examine and review suspicion cases, internal reports, and feedback received from the SAFIU and take them into account when developing/updating the indicators and typologies of ML/TF mentioned in Paragraph (7.9) in the Monitoring of Transactions and Activities Section.
8.13	The financial institution should educate and raise the awareness of all its employees, including the members of the board of directors and senior management, regarding the following:
	a)	The requirements related to identifying and reporting the suspicious activity or transaction.
	b)	The regulatory requirements concerning civil and criminal liability and other liabilities related to violations of required confidentiality obligations.
	c)	The regulatory requirements related to reporting and not alerting customers or disclosing any suspicious transaction incidents, reports or information.
8.14	The financial institution shall notify SAMA immediately of any accounts, business relationships, or financial transactions involving the names included in the lists of the UN Security Council committees, Committee 2253/1989/1267 and Committee 1988, as well as the names included in the national list in implementation of the Security Council Resolution No. (1373) according to the data available in the lists. For optimal implementation, the financial institution shall adhere to the provisions of SAMA’s relevant circulars, including:
	a)	The Guide on the Implementation of Security Council resolutions relevant to combating terrorism and its financing.
	b)	The Guide on the Implementation of Security Council resolutions relevant to proliferation of weapons of mass destruction and financing.
8.15	The financial institution shall put in place an effective and comprehensive mechanism and consider the suitability of technological systems for continuous comparison with the names included in the sanctions list in Paragraph (8.14) under the Reporting of Suspicious Transactions Section.

Section 9: Arrangements of AML/CTF Compliance Function

In order for the financial institution to implement the risk-based approach effectively and adequately, its board shall provide sufficient resources, including human and technological resources that are commensurate with the nature and volume of the financial institution's business and the risk assessment results to combat ML/TF so as to ensure the effective implementation of AML/CTF internal policies, procedures and controls. This shall include setting up appropriate arrangements at the level of the financial institution and appointing an officer for the AML/CTF compliance function with specified work duties. The AML/CTF compliance function shall be an administrative and technical reference for the board and a sub-reference for the senior managements.
Article (14/1) of the Implementing Regulations of the Anti-Money Laundering Law and Article (18) of the Implementing Regulations of the Law on Combating Terrorism Crimes and Financing set forth the obligations of the financial institution, which include setting up appropriate AML/CTF arrangements.
9.1	The financial institution shall set up appropriate arrangements for the AML/CTF Compliance Unit/department, which shall at least include the following:
	a)	The AML/CTF compliance function.
	b)	Appointing the person responsible for the AML/CTF compliance function at the senior management level.
	c)	Ensuring that the officer responsible for the AML/CTF compliance function works independently and administratively and technically reports to the board of directors and its committees.
	d)	The officer responsible for the AML/CTF compliance function shall have the power to have timely access to any information, including customers’ data under the due diligence measures, records of other related transactions, or any data necessary to carry out all his work.
9.2	The financial institution shall establish an independent and specialized AML/CTF unit and provide it with sufficient resources, including human and technological resources, to carry out its work perfectly as well as the necessary professional competence and capabilities when recruiting qualified personnel to occupy positions in the AML/CTF unit that shall be solely restricted to Saudi nationals.
9.3	The financial institution shall specify the duties and responsibilities of the AML/CTF compliance function officer approved in job description. The responsibilities shall include all AML/CTF work, such as the following:
	a)	Developing an AML/CTF program commensurate with the volume and nature of the financial institution’s business and the ML/TF risks it has identified in order to reduce and effectively manage these risks.
	b)	Continuously reviewing the business policies and procedures of the financial institution and monitoring their implementation in addition to recommending measures to be taken to meet the AML/CTF requirements and strengthening these measures as needed.
	c)	Continuous monitoring and examination of activities and transactions to ensure that their volume is consistent with the information that the financial institution has about the customer, its business activities, and the risks posed by that customer in order to detect activities that may include suspicious transactions in addition to making use of such examinations in the preparation and update of AML/CTF monitoring methods approved.
	d)	Receiving reports on suspicious ML/TF transactions, taking the necessary measures to collect and analyze information about them, and documenting this in writing.
	e)	Reporting suspicious transactions to the SAFIU as soon as the suspicion is detected in accordance with the reporting procedures followed in addition to preparing a technical report on the suspicion case as stated in the Reporting of Suspicious Transactions Section.
	f)	Reporting any accounts, business relationships, or financial transactions related to the names included in the lists of the Security Council committees, Committee 2253/1989/1267 and Committee 1988, as well as the names included in the national list in implementation of Security Council Resolution No. (1373) to SAMA, as mentioned in Paragraph (8.15) under the Reporting of Suspicious Transactions Section.
	g)	Conducting frequent visits to the different departments and branches of the financial institution to ensure that AML/CTF requirements are met in addition to documenting such visits in writing.
	h)	Preparing and submitting on-site visit reports and periodic reports on activities carried out by the AML/CTF unit/function to the board of directors.
	i)	Preparing and approving a survey related to the AML/CTF internal controls approved by the financial institution when it enters into a business relationship with another financial institution.
	j)	Approving the internal controls survey, data collection forms, and any information related to combating ML/TF submitted to SAMA.
	k)	Participating in AML/CTF work committees.
9.4	The reports submitted to the board on the activities carried out by the AML/CTF unit/function shall not be limited to statistical data only; they shall also include the identified obstacles and challenges facing the financial institution when implementing the AML/CTF requirements along with the necessary recommendations to improve performance and effectiveness.

Section 10: Independent Audit Function

In order for the financial institution to ensure the adequacy and appropriateness of the risk-based approach, the financial institution shall have the AML/CTF internal controls tested by an independent party to ensure that they are adequate to ML/TF risks and implemented effectively. However, the internal or external auditors involved shall have sufficient experience to conduct a risk-based test of the effectiveness of implementing the AML/CTF policies and procedures approved by the financial institution.
Article (14/1) of the Implementing Regulations of the Anti-Money Laundering Law and Article (18) of the Implementing Regulations of the Law on Combating Terrorism Crimes and Financing state the obligations of the financial institution that include setting up an independent audit mechanism to test the effectiveness and adequacy of the AML/CTF policies, procedures and controls.
10.1	The financial institution shall put in place appropriate arrangements for the independent audit function, including providing sufficient resources to test compliance with the AML/CTF requirements and ensuring that the independent audit employees are qualified and have the necessary professional competence and capabilities to examine the compliance of all units in the financial institution with the AML/CTF requirements.
10.2	The auditor in the financial institution shall work independently of the AML/CTF function, and the financial institution shall ensure that the independent auditor is not involved in any of the functions or measures audited.
10.3	The independent auditor shall conduct an independent test of the appropriateness, adequacy and effectiveness of the AML/CTF compliance program and procedures at the level of the financial institution, document the audit results and send them to the board of directors to take the proper actions.
10.4	The independent auditor shall conduct independent tests of the AML/CTF controls, policies, and procedures and their adequacy for the risks identified.
10.5	When testing the appropriateness, adequacy and effectiveness of the AML/CTF compliance program and procedures, the independent auditor’s work shall be based on ML/TF risks and focus on the risk areas that are more likely than others to be exploited in carrying out ML/TF transactions.
10.6	When necessary, the financial institution should consider including the auditing of the appropriateness, adequacy and effectiveness of the AML/CTF compliance function within the scope of the external auditor's work.
10.7	The senior management should take adequate measures to ensure that any weaknesses or deficiencies discovered as a result of the independent audit are addressed.

Section 11: AML/CTF Training

The financial institution should allocate sufficient budget for training the senior management and employees to achieve the required efficiency in combating ML/TF. The training needs to be inspired by real experiences and should include the updates and new methods used in ML/TF transactions and the internal controls of the financial institution. The responsibility for determining the appropriate level and type of training rests with the financial institution as it has to ensure the ability of its employees to apply the risk-based approach.
Article (14/1) of the Implementing Regulations of the Anti-Money Laundering Law and Article (18) of the Implementing Regulations of the Law on Combating Terrorism Crimes and Financing state the obligations of the financial institution including providing ongoing employee training programs in the field of AML/CTF.
11.1	The financial institution should organize ongoing training programs for all employees to acquaint them with the regulations, instructions and updates in the field of AML/CTF in a way that enhances the efficiency of employees to identify these transactions and their typologies and know how to deal with them. These programs shall enable the employees to achieve a degree of knowledge sufficient to effectively reduce the occurrence of such crimes and combat them. In this regard, the financial institution should allocate sufficient budget to provide AML/CTF training.
11.2	The financial institution should provide appropriate training to its employees, taking into account the level of their position and nature of work. The training programs should include the various position levels in the financial institution, including members of the board of directors and its committees, managers, and executives. In addition, the following shall be observed:
	a)	Training and education about the importance of AML/CTF policies and measures shall be provided for all current employees and new employees before they start work. Such training must be repeated to ensure that employees are continuously reminded of their responsibilities and informed of the updates and developments in this regard.
	b)	Providing more comprehensive and detailed training for employees responsible for implementing due diligence, in line with the risks to which the financial institution is exposed.
	c)	Specialized and adequate AML/CTF training should be provided for the AML/CTF compliance function employees as well as the independent audit function employees.
	d)	All employees, directors and board members of the financial institution should be made aware of their responsibilities and duties as well as the penalties that may be imposed in case of failure to comply with the relevant requirements, as stated in the Anti-Money Laundering Law, the Law on Combating Terrorism Crimes and Financing, their Implementing Regulations, and the instructions issued by SAMA and the authorities concerned.
11.3	When seeking assistance from specialized institutes to provide training, the financial institution should take the following measures:
	a)	Verifying the suitability of the training offered for the AML/CTF requirements.
	b)	Ensuring that the training takes into account the nature of activities and the risks to which the financial institution is exposed.
	c)	Verifying the academic and work history of the trainer.
	d)	Polling the opinions of trainees on the suitability of the training materials and the style, experience and capabilities of the trainer in addition to analyzing the survey results after each training program to benefit from the trainees’ observations.
11.4	The financial institution should conduct the necessary tests to assess the employees' knowledge of the AML/CTF requirements and the quality of training provided in this regard, provided that such assessment is carried out periodically (at least annually), taking into account the relevant modern requirements.
11.5	The financial institution shall keep records that include documents of the AML/CTF training provided, attendance data, and the date of training.

Section 12: Recruitment and Following-up Criteria

The financial institution shall implement effective internal control systems that ensure the integrity of employees and reduce the risk of their involvement or collusion with criminals in order to ensure integrity and professional criteria among its employees.
Article (14/1) of the Implementing Regulations of the Anti-Money Laundering Law and Article (18) of the Implementing Regulations of the Law on Combating Terrorism Crime and Financing set forth the obligations of the financial institution, which include developing adequate screening procedures to ensure high standards when hiring employees.
12.1	The financial institution shall develop and implement an appropriate process for background checks for qualified candidates when hiring employees to ensure high efficiency standards.
12.2	The financial institution should verify the records of the board members, occupants of leadership positions, or employees to ensure that they have no criminal background breaching honor or integrity, whether in Saudi Arabia, the country of nationality, or the country where they have previously worked.
12.3	The financial institution shall maintain the background verification procedures applied as stated in Paragraphs (12.1) and (12.2) and submit them to SAMA upon request.
12.4	The financial institution should comply with the provisions stated in the Requirements for Appointments to Senior Positions in Financial Institutions Supervised by SAMA.
12.5	The financial institution should study its need for a job rotation policy to reduce the risk of employees circumventing internal controls.
12.6	The financial institution should ensure that employees use their leave days regularly (at least once a year) and/or according to internal policies approved by the financial institution. It should also ensure that employees do not work during leave days.

Section 13: Correspondence Relationship⁵

Before entering into a correspondence relationship, the financial institution should collect sufficient information about the correspondent institution to obtain a full understanding of the nature of its work and learn about its reputation, the level of supervision applied to it, and the extent to which it applies the AML/CTF requirements.
Article (9) of the Anti-Money Laundering Law and Article (68) of the Law on Combating Terrorism Crime and Financing set forth the obligations that must be fulfilled by the financial institution before entering into a correspondence relationship.
13.1	Before entering into a correspondence relationship, the financial institution shall take sufficient measures to mitigate risks. These measures may include the following:
	a)	Collecting sufficient information about the correspondent institution to fully understand the nature of its work, the supervision applied to it and the risks to which it is exposed as well as evaluate its reputation based on the information available to the financial institution. This may include:
		•	The geographical areas in which the correspondent institution provides its services, taking into account those areas with shortcomings in the application of the AML/CTF requirements, as mentioned in Paragraph (4.7) under the Enhanced Due Diligence Section.
		•	Ownership structure of the correspondent financial institution, taking into account the case of correspondent institutions with a complex organizational structure as the financial institution should implement the measures mentioned in Paragraph (4.6) under the Enhanced Due Diligence Section.
		•	Services and products provided by correspondent institution, taking into account the products and services that may involve high risk from the perspective of ML/TF.
		•	Customers of the correspondent institution, taking into account the information available on customers that pose high risks due to their activities or characteristics when a large part of the correspondent institution’s business income depends on these customers.
		•	The supervisory authority of the correspondent institution, taking into account that the correspondent institution must be supervised by the central bank or a similar regulatory body as well as an internationally recognized regulatory environment and its compliance with the FATF Recommendations.
	b)	Verifying the extent to which the correspondent institution is subject to an investigation or control procedure related to ML/TF.
	c)	Evaluating the internal policies, controls and procedures to mitigate risks that are adopted by the correspondent institution to combat ML/TF by preparing a questionnaire that covers basic AML/CTF requirements and assesses the effectiveness of measures.
13.2	The financial institution should clearly understand the responsibilities of each party in the correspondence relationship from an AML/CTF perspective.
13.3	The financial institution should apply appropriate control measures as indicated under the Monitoring of Transactions and Activities Section, including continuous control measures for correspondence accounts to detect any unusual activity or behavior in the correspondence relationship.
13.4	The financial institution should be sufficiently satisfied that the correspondent institution does not allow its accounts to be used by a shell bank. The financial institution shall refrain from entering into -or continuing- a correspondence relationship with a shell bank or with a financial institution outside Saudi Arabia that allows its accounts to be used by a shell bank.
13.5	Approval of the senior management should be obtained before establishing new correspondence relationships, provided that the approval includes taking the measures mentioned in Paragraph (13.1) under the Correspondence Relationship Section and obtaining recommendations from the officer responsible for the AML/CTF compliance function.

⁵ Financial institutions must comply with the Correspondence Relationship Section in addition to the requirements of Rule (300-2-5) regarding non-resident commercial banks in the Rules Governing the Opening of Bank Accounts

Section 14: Wire Transfer

When carrying out cross-border or domestic wire transfers in any currency, including serial and coverage payments, that are received, sent or processed by a financial institution in Saudi Arabia, the financial institution should obtain information of the wire transfer originator and beneficiary, including cases in which a credit card, debit card, prepaid card, mobile phone, or any other similar digital prepaid or postpaid device is used.
Article (10) of the Anti-Money Laundering Law and Article (68) of the Law on Combating Terrorism Crimes and Financing state the obligations of the financial institution when conducting cross-border and domestic wire transfers in any currency, including serial payments and coverage payments, that are received, sent or processed by a financial institution in Saudi Arabia.
14.1	Before processing a wire transfer, the financial institution should obtain information about the wire transfer originator and beneficiary, keep that information with each wire transfer, and verify that information. Such information shall at least include the following:
	a)	Full name of the wire transfer originator.
	b)	The originator’s account number used for conducting the transaction, and if there was no account, a transfer number must be included to allow the transaction to be tracked.
	c)	The originator's address, ID number, customer identification number, or place and date of birth.
	d)	Full name of the wire transfer beneficiary.
	e)	The beneficiary’s account number used for conducting the transaction, and if there was no account, a transfer number must be included to allow the transaction to be tracked.
	f)	The purpose of the wire transfer and the relationship between the originator and the beneficiary.
14.2	Before executing a wire transfer, the financial institution should obtain a declaration from the customer stating his knowledge that Saudi Arabia’s laws prohibit the transfer of funds without the customer’s knowledge of the beneficiary (transferee), without a legal relationship with the beneficiary, or without a legitimate purpose.
14.3	In cases where several individual cross-border wire transfers are combined from a single originator in a combined transfer to beneficiaries, the financial institution responsible for originating the transfer shall verify the information attached, including the originator’s previously verified information as well as the beneficiary’s full information, as stated in Paragraph (14.1). This is to allow tracking of the transfer within the country in which the beneficiary is located in addition to the originator’s account number and the reference number of the transfer.
14.4	In the case of a domestic wire transfer and when the financial institution originating the transfer was able -through other means- to provide all information about the wire transfer originator and beneficiary to the financial institution receiving the transfer or the competent authorities, the financial institution is exempt from adding information to each wire transfer. The financial institution originating the transfer may include an account number or a transfer number that allows linking the transaction with relevant information about the wire transfer originator or beneficiary. Furthermore, the financial institution originating the transfer should provide all information about the wire transfer originator and beneficiary within three working days starting from the date of receiving a request for that information from the financial institution or the competent authority.
14.5	The financial institution and the intermediary financial institution receiving a wire transfer from outside Saudi Arabia should prepare and implement policies, procedures and controls for the following purpose:
	a)	To identify wire transfers that lack the required information regarding the originator or beneficiary.
	b)	To determine cases of executing, rejecting or suspending a wire transfer due to lack of required information related to the originator or beneficiary based on risks.
	c)	To conduct adequate monitoring based on risks that may include restricting or terminating the business relationship.
14.6	The financial institution receiving a wire transfer from outside Saudi Arabia shall take reasonable measures to identify transfers that lack the required information relating to the originator or beneficiary. These measures may include follow-up procedures after implementation or during implementation, as applicable. In the event of not having the identity of the beneficiary previously verified, the financial institution receiving a wire transfer shall verify the beneficiary’s identity and keep this information as stated under the Record Keeping Section.
14.7	The confidentiality requirements stated under domestic laws do not preclude the financial institution from exchanging information with another local or foreign financial institution that is processing any part of the transaction as required under the Wire Transfer Section.
14.8	The scope of the Wire Transfer Section requirements does not include the following:
	a)	Transfers that result from a transaction carried out using a credit card, debit card, prepaid card, mobile phone, or any other similar digital prepaid or postpaid device only for the purchase of goods or services, provided that the credit or debit or prepaid card number accompanies the transfer resulting from the transaction.
	b)	Transfers that constitute a transfer or settlement between two financial institutions when the originator and the beneficiary are financial institutions acting on their own behalf.
14.9	In the event that the financial institution is unable to comply with the requirements of Paragraph (14.1), it should not perform the wire transfer.
14.10	The financial institution and the intermediary financial institution should not accept executing a cross-border wire transfer in any currency for charitable purposes⁶ regardless of the source of funds or the beneficiary, taking into account what is stated in Paragraph (14.7).
14.11	The financial institution and the intermediary financial institution receiving wire transfers from outside Saudi Arabia shall not accept these transfers in any currency for charitable purposes, regardless of the source of funds or the beneficiary, taking into account what is mentioned in Paragraph (14.7).
14.12	Business of the intermediary financial institution providing wire transfer services related to transactions executed through the financial institution, with which it has a contract, should be subject to supervision and control.
14.13	The information exchanged with a correspondent financial institution or an intermediary financial institution providing wire transfer services must only be used for authorized purposes subject to the terms and conditions of confidentiality and should never be used for any other purposes.
14.14	The financial institution and the intermediary financial institution shall not receive a wire transfer from outside Saudi Arabia to a beneficiary in a financial institution abroad if the wire transfer is in a currency other than the Saudi riyal.
14.15	The financial institution may receive a wire transfer from outside Saudi Arabia to a beneficiary in a financial institution abroad only when the wire transfer is in the Saudi riyal currency, taking into consideration what is stated in Paragraphs (14.1), (14.5) and (14.8).
14.16	The financial institution and intermediary financial institution receiving a wire transfer in the Saudi riyal currency from outside Saudi Arabia to a beneficiary in a financial institution abroad shall clearly detail the purpose of the transfer.

⁶ In the event that a financial institution receives an approval from SAMA indicating that some parties are allowed to transfer gifts, subsidies, or donations to a beneficiary, whether it be a legal or natural person, in accordance with certain conditions, the financial institution must act according to that approval.

Guide to Enforcing Security Council Resolutions Related to Combating Terrorism and its Financing
No: 391000014326 Date(g): 26/10/2017 | Date(h): 6/2/1439 Status: In-Force
Translated Document

Introduction
Security Council resolutions aimed at combating terrorism and its financing mandate that States promptly freeze all funds, financial assets, or other economic resources owned or controlled directly or indirectly by individuals, groups, institutions, or entities designated in the resolutions. This includes funds derived from property owned or controlled by them or by individuals acting on their behalf, under their direction or control, directly or indirectly. States are further required to take all necessary measures to prevent such funds, financial assets, and economic resources from being made available, directly or indirectly, for the benefit of these individuals, groups, institutions, or entities, or for the benefit of any persons acting on their behalf, directly or indirectly, or through their nationals or individuals within their territory.
In fulfillment of this obligation, Royal Order No. 25505, dated 22/05/1433 H, corresponding to 13/04/2012, was issued, endorsing the mechanism for implementing Security Council Resolution No. (1267/1989) and Resolution No. (1988). These directives were disseminated to the pertinent enforcement agencies, as per Ministry of Interior Cable No. 38954, dated 06/06/1433H, corresponding to 27/04/2012. On 25/04/1438 H, corresponding to 23/01/2017, the first update to the implementation mechanisms of Security Council resolutions combating terrorism and its financing was issued, as per Ministry of Interior’s Cable No. (109130) dated 25/04/1438H. This update was executed in accordance with Article (32) of The Law on Combating Terrorism Crimes and Its Financing, promulgated by Royal Decree No. (M/16) dated 24/02/1435H.
Subsequently, on 04/05/1440H, the second update concerning the implementation mechanisms for Security Council resolutions addressing terrorism and its financing was issued under Presidency of State Security Cable No. 32576 dated 04/05/1440H. This update was authorized by Article (75) of the Law on Combating Terrorism Crimes and Its Financing, as stipulated by Royal Decree No. (M/21) dated 12/02/1439H. This article provides that “The Permanente Committee for Combating Terrorism and its financing receives requests from States and organizations for the implementation of UN Security Council Resolutions relating to combating terrorism and financing of terrorism. The Committee shall put in place, and update, mechanisms, and take the necessary measures to implement the said resolutions. The mechanisms shall be issued pursuant to a decision by the Presidency of State Security”. This includes:
1. The implementation mechanism of Security Council resolutions regarding individuals, groups, institutions, and entities on the Security Council Committee consolidated list No. (1267/1989/2253) concerning ISIL (Da'esh), Al-Qaida, and other individuals, groups, institutions, and entities associated therewith, known as the "Sanctions List regarding ISIL (Da'esh), Al-Qaida, and the individuals, groups, institutions, and entities associated therewith."
2. The implementation mechanism of Security Council Resolution No. (1988) and subsequent pertinent resolutions. The resolution includes the names of individuals and entities who, prior to the date of adoption of resolution no.1988, were designated as part of the Taliban, as well as other individuals, groups, institutions and entities collaborating with the Taliban movement in jeopardizing peace, stability, and security in Afghanistan, as determined by the committee established under paragraph 30 of Resolution no.1988.
3. The implementation mechanism of Security Council Resolution No. (1373) targets individuals who, by any means whatsoever, directly or indirectly, willingly provide or collect or attempt to provide or collect, funds with the intention of using them to commit a terrorist offense, or who know that the funds will be used wholly or partly for this purpose, or for the benefit of a terrorist organization or person for any purpose whatsoever, even if the terrorist act does not occur, is not attempted, or the funds are not actually used for its execution or attempt, or are linked to a specific terrorist act, regardless of the country in which the terrorist crime took place or was planned to take place. This includes individuals, groups, institutions, and entities targeted nationally by states for their involvement in activities for the benefit of ISIL (Da'esh), Al-Qaida, and other individuals, groups, institutions, and entities listed on the Committee's consolidated list (1267/1989/2253) as well as those listed on the unified list (1988). It is noted that updates to the list are issued solely by the Presidency of State Security.
Accordingly, SAMA has directed the financial institutions under its supervision to take several measures for the implementation of the aforementioned updated mechanisms, as outlined in Circular No. 381000077863 dated 22/07/1438H, corresponding to 19/04/2017.
To ensure the effective implementation of procedures and mechanisms by the financial institutions under its supervision, SAMA has revised and updated this guide for implementing the mechanisms outlined in the updated Security Council resolutions pertaining to combating terrorism and its financing. This updated guide was disseminated through Circular No. 391000014326 dated 06/02/1439H.

Guide to Enforcing Security Council Resolutions Related to Combating Terrorism and its Financing

1. Freezing the Designated Funds in Accordance With the Mechanisms Issued to Enforce Security Council Resolutions Related to Combating Terrorism and its Financing

1.1	In adherence to Security Council resolutions on combating of terrorism and its financing, and in execution of the corresponding mechanisms, financial institutions shall promptly freeze, within hours and without prior notification, any funds, economic resources, or property, whether wholly or partially owned, controlled, or possessed, directly or indirectly, by any of the following:
		(a)	Any individual, group, or entity listed by the Security Council Committee (1267/1989/2253) or the Security Council Committee (1988).
		(b)	Any individual acting on behalf of, at the direction of, or directly or indirectly owned or controlled by a person, group, or entity included in the Security Council lists referred to above in paragraph (a).
1.2	The implementation mechanisms of Security Council resolutions aimed at combating terrorism and its financing strictly forbid any natural or legal person, including all categories of financial institutions, from providing funds, economic resources, or property to any listed person, group, or entity. This covers preparations to offer any form of financial or other services, directly or indirectly, to these individuals or for their benefit, unless their names have been delisted by the Security Council committees or explicit prior authorization has been granted by SAMA.
1.3	The mechanisms additionally mandate continuous updating of the data of those on the United Nations lists on a daily basis, by referencing the websites of the (1267/1989/2253) Committee and the (1988) Committee. Both committees maintain websites containing updated lists of the names of listed individuals. These websites can be accessed at the following two addresses: https://www.un.org/sc/suborg/ar/sanctions/1988/materials http://www.un.org/sc/committees/1267/aq_sanctions_list.shtml All resolutions adopted by the United Nations Security Council can be found at: http://www.un.org/ar/sc/documents/resolutions/
1.4	SAMA must be notified within a maximum of five working days in the event of a freeze, and complete details of the account or transaction must be provided as outlined in Paragraph (3.3-c) of this guide. In case of name similarity, SAMA will be promptly notified, and appropriate measures will be taken by financial institutions. These measures may include freezing or not freezing funds until directives are received from SAMA. The decision will be based on the degree of similarity assessed by the financial institutions, utilizing the information and data available to them.
1.5	Freezing will be promptly put in place for names designated by the Kingdom of Saudi Arabia in accordance with Security Council Resolution No. (1373). Freeze requests are issued through the Presidency of State Security (the Permanent Counter-Terrorism Committee) and transmitted to financial institutions via SAMA.
1.6	Payments made to listed individuals, groups, institutions, or entities may be permitted to be credited to the frozen accounts, on the condition that these payments remain frozen and that SAMA is notified accordingly.

2. Funds to be Frozen Under the Resolutions

2.1	The obligations outlined in the mechanisms for implementing Security Council resolutions related to combating terrorism and its financing extend to any "funds," a term that is broadly defined to include: “various forms of assets, economic resources, or property, regardless of their origin or value. This includes tangible or intangible assets, movable or immovable property, as well as documents, instruments, or tools in any form, including electronic or digital systems and bank credits indicating ownership or interest. Examples of such assets include but are not limited to all types of checks, transfers, stocks, securities, bonds, bills of exchange, letters of credit, and any associated interest, profits, or income derived from these funds or assets, whether located within or outside Saudi Arabia”.
2.2	The freezing order extends to funds owned or controlled, directly or indirectly, in whole or in part, by the person concerned. The freezing order encompasses entities that the listed person controls directly or indirectly, even if not officially owned, such as joint bank accounts, trust funds, or entities owned indirectly through minors or spouses. It also includes shell or front companies utilized by the listed person, joint ventures they're part of, and entities with complex or ambiguous ownership structures aimed at concealing control or ownership by the listed person. These examples serve to illustrate that any funds subject to the control or ownership of a designated person, irrespective of the method directly, indirectly, or through any mechanism are covered by Security Council resolutions.
2.3	It is imperative to highlight that funds jointly owned, controlled, or held by the listed person, group, or entity and a non-listed person, group, or entity are subject to the freezing order in full. This includes the portion owned or controlled by the unlisted person, group, or entity. Disposition of such funds will only occur after consultation with SAMA, which subsequently notifies the Presidency of State Security (the Permanent Committee for Combating Terrorism) for investigation, with each case being handled individually.

3. Financial Institutions’ Mechanism to Verify All Customers Against the Listed Names

3.1	Financial institutions shall conduct daily and ongoing checks of customer databases and any relevant information concerning potential or existing customers. They must compare this data with the names listed by the two Security Council committees tasked with combating terrorism and its financing as outlined in this guide. This process aims to identify whether the financial institutions possess or manage any funds subject to the decisions of these committees. Hence, it is essential to maintain an updated list of the entities and individuals included in these lists within the database. This requirement extends to the names classified nationally in accordance with Security Council Resolution No. 1373, which are received from the State Security Presidency and disseminated by SAMA to the financial institutions it supervises.
3.2	Certain financial institutions utilize electronic service programs to ascertain that their clients are not subject to any penalties associated with the (1267/1989/2253) and (1988) Committees. It's noteworthy that while electronic services are valuable tools, they should not be solely relied upon as guarantees of compliance with imposed procedures. Daily and continuous verification remains essential to compare the names listed by the United Nations sanctions committees. The primary method for staying informed about updates and ensuring compliance with sanctions imposed on the individuals listed by the Security Council Committees (1267/1989/2253) and (1988) is through regularly consulting the respective websites of these committees, as mentioned in Paragraph (1.3).
3.3	If a financial institution identifies that any funds in its possession or under its management are subject to freezing, it must adhere to the following steps:
		(a)	Immediately and without delay (within hours), freeze all such funds, along with any funds derived or resulting from them, without prior warning.
		(b)	Refrain from providing any financial or other services or transferring funds to or for the benefit of any listed person, group, or entity. This prohibition covers all types of services provided to the listed person, group, or entity, including but not limited to opening accounts or offering any form of advice, financial services, brokerage and investment services, or any type of assets or property, directly or indirectly, whether physical or non-physical, tangible or intangible, movable or immovable.
		(c)	The freeze must be notified to SAMA within a maximum of five business days from the date it is imposed. The notification shall include details about the status of the funds, any actions taken, the nature and quantity of the frozen funds, and any other pertinent information that may aid in compliance with the decisions. Financial institutions should ensure that the information provided is accurate.
3.4	If a financial institution determines that it does not possess or manage any targeted funds, it must promptly inform SAMA if any former or current client it engaged with is identified as a listed person, group, or entity.
3.5	In cases where names are similar, financial institutions must conduct thorough searches using legally available means to confirm whether the names match or not. If the financial institutions do not obtain information confirming whether the name matches or not, they must notify SAMA immediately without taking any action.

4. Procedures to be Put in Place by Financial Institutions if the Freezing Order is Lifted

4.1	If the Security Council Committees (1267/1989/2253) and (1988) delists the name, the freeze must be promptly lifted without prior notice,(within hours), and SAMA must be informed accordingly, (as outlined in Paragraph 4.2 below), unless prior notice of non-lifting is received as a result of the designation in accordance with Security Council Resolution No. (1373). As for names whose transactions were previously frozen based on directives from SAMA, they remain frozen until instructions are received from the SAMA to lift the freeze.
4.2	SAMA must be informed of the lifting of the freeze within five working days from the date of the freeze being lifted, providing it with information on the status of the funds, any measures taken, the nature and amount of the unfrozen funds and any other information relevant to the decisions. Financial institutions should ensure that the information provided is accurate.
4.3	If the Security Council approves the partial lifting of frozen funds and other assets identified based on Security Council Resolution No. (1452), SAMA will promptly inform the financial institutions under its supervision regarding this development.

5. Confidentiality of Information
Financial institutions must ensure the confidentiality of information concerning the names listed in accordance with Security Council resolutions pertaining to combating terrorism and its financing, in accordance with relevant regulations and instructions, including those outlined in the Anti-Money Laundering law, the Law on Combating the Financing of Terrorism, as well as the rules governing anti- money laundering and combatting terrorist financing issued by SAMA.

6. SAMA Mechanism to Verify the Financial Institutions’ Compliance With the Implementation of Security Council Resolutions Concerning the Combatting of Terrorism and its Financing
Financial institutions must take all necessary measures to ensure their full compliance with the sanctions imposed on individuals listed by the Security Council Committees (1267/1989/2253) and (1988), as well as those provided by SAMA in accordance with Security Council Resolutions (1373). Full compliance will be verified through field visits, with penalties applied as per regulations in cases of negligence, non-compliance, or failure to adhere to instructions by financial institutions.

7. Penalties That are Applied in the Event of Non-Compliance With the Requirements and Procedures Stipulated in the Mechanisms for Implementing Security Council Resolutions Related to Combating Terrorism and its Financing
Anyone who fails to impose a freeze or enforce a freezing order against names subject to the mechanisms for the implementation of relevant Security Council resolutions on combating terrorism and its financing, as well as anyone who makes funds or financial services or other related services available to the designated person or for their benefit in violation of the relevant Security Council resolutions on combating terrorism and its financing, or fails to disclose information, provides false information intentionally or due to negligence, or delays in providing information, shall be held accountable in accordance with the relevant regulations.

8. Obtaining Information
The financial institution must obtain accurate information, whether basic or pertaining to potential or existing customers, to ensure comparison with the names listed by the two Security Council committees dedicated to combating terrorism and its financing, as referred to in this guide. This includes information related to the beneficial owner of legal entities (such as front companies) when investigating crimes or violations related to Security Council resolutions concerning the financing of terrorism.

9. Notification and Grievance Mechanism
Individuals designated in accordance with Security Council resolutions have the right to be notified when procedures outlined in these resolutions are applied to them due to their appearance on one of the lists associated with these resolutions.
The designated individual also retains the right, in accordance with Security Council resolutions, to initiate grievance cases, whether within or outside KSA, against any decisions issued against them. This right is governed by the provisions outlined in the Law of the Board of Grievances, as well as the Law on Combating the Financing of Terrorism. It is crucial to consider the rights of bona fide third parties who act in good faith while fulfilling their obligations.

10. Other Guidelines and Instructions
Reporting financial institutions are required to identify, assess, understand, document, update and provide their risk assessment to the Central Bank upon request, taking into account a wide range of risk factors including those associated with their customers, countries or geographic regions, products or services, transactions or delivery channels, including a risk assessment study for new products, business practices and technologies prior to use.
The national consolidated list, associated with Security Council Resolution No. (1373), should be continuously updated through referencing the website of the Presidency of State Security (Permanent Committee for Combating Terrorism and its Financing), on a daily and an ongoing basis. Any amendments to the national consolidated list, including new additions, deletions, or modifications to data, should be promptly noted. It is essential that these updates are directly monitored through the website of the Permanent Committee for Combating Terrorism and Its Financing at the Presidency of State Security.
An assessment must be made of the quality of the procedures applied for the purposes of (1) designation/listing, (2) freezing or unfreezing, and (3) delisting, and the extent to which these procedures comply with the requirements of Security Council resolutions.

Guide to Enforcing Security Council Resolutions Concerning the Prevention of WMD Proliferation and Their Financing
No: 391000077627 Date(g): 25/3/2018 | Date(h): 9/7/1439 Status: Modified
Translated Document
This guide was issued under Circular No. 391000077627 dated 09/07/1439 H (corresponding to 26/03/2018) as amended under Circular No. 130885/486 dated 04/09/1440 H (corresponding to 09/05/2019).

Introduction
Security Council resolutions adopted under Chapter VII of the UN Charter concerning the prevention of WMD and their financing require states to immediately and without delay freeze all funds and assets of any person, group, or entity identified by the UN Security Council or its relevant committees as being associated with WMD proliferation financing activities, and to take all measures to prevent any funds or assets from being made available to or for the benefit of such persons, groups, or entities from any person, group, or entity within or under the jurisdiction of Saudi Arabia. Under this obligation, Royal Order No. 10130 was enacted on 01/03/1439 AH, endorsing “the implementation mechanism of Security Council resolutions under Chapter VII of the United Nations Charter concerning the prevention of WMD proliferation and their financing”.
Circular No. (391000054107) dated 12/05/1439 AH, directing the financial institutions under its supervision to undertake several measures to implement the aforementioned mechanism. In order to ensure the optimal execution of these procedures and mechanisms by the financial institutions under its supervision, the Saudi Central Bank has meticulously prepared this guide for enforcing the mechanisms outlined in the Security Council resolutions aimed at preventing the proliferation of WMD and their financing. Accordingly, the mechanism for implementing the Security Council resolutions related to preventing the proliferation of WMD and their financing has been updated and accordingly, paragraph 3.4 of the guide was updated and directed to all financial institutions in Circular No. 130885/486 dated 04/09/1440 AH.

Guide to Enforcing Security Council Resolutions concerning the prevention of WMD proliferation and their financing

1. Freezing of Funds Designated in Accordance With the Mechanisms Issued to Enforce Security Council Resolutions Concerning Prevention of the WMD Proliferation and Their Financing

1.1	In compliance with Security Council resolutions concerning the prevention of the WMD proliferation and their financing, and in implementation of the mechanism issued accordingly, financial institutions are required to promptly freeze (within hours) and without prior notice any funds, economic resources, assets, or property owned, controlled, or possessed, either wholly or partially, directly or indirectly, by any of the following:
		(a)	Any person, group, or entity designated by the United Nations Security Council or any relevant committee of the Security Council under any of the pertinent Security Council resolutions.
		(b)	Any person who acts on behalf of, at the direction of, or is owned or controlled, directly or indirectly, by a person, group, or entity listed by the Security Council. including through illegal means.
1.2	The implementation mechanism of Security Council resolutions on preventing the WMD proliferation and their financing prohibits any natural or legal person, including all categories of financial institutions, from providing any funds, economic resources, assets, or property to any listed person, group, or entity. It also prohibits the provision of any form of financial or other services, directly or indirectly, to or for the benefit of such persons, unless the designation is removed from the Security Council committees or a reasoned written authorization is obtained from the Saudi Central Bank (SAMA).
1.3	The mechanism mandates the continuous updating of data for individuals on the lists of the Security Council sanctions committees on a daily basis. This involves referencing the website of the resolutions adopted by the United Nations Security Council at the following address: un.org/ar/sc/documents/resolutions/
1.4	SAMA must be notified within a maximum of five working days in the event of a freeze, and complete details of the account or transaction must be provided as outlined in Paragraph (3.3-c) of this guide.
1.5	Payments made to listed individuals, groups, institutions, or entities may be credited to the frozen accounts, on the condition that these payments remain frozen and that SAMA is notified accordingly.

2. Funds to be Frozen Under the Resolutions

2.1	The obligations outlined in the mechanisms for implementing Security Council resolutions on the prevention of the proliferation of WMD and their financing extend to any "funds," a term that is broadly defined to include: “assets, economic resources, or property, regardless of their origin or value. This includes tangible or intangible assets, movable or immovable property, as well as documents, instruments, or tools in any form, including electronic or digital systems and bank credits indicating ownership or interest. Examples of such assets include but are not limited to all types of checks, transfers, stocks, securities, bonds, bills of exchange, letters of credit, and any associated interest, profits, or income derived from these funds or assets, whether located within or outside Saudi Arabia”.
2.2	The freezing order extends to funds owned or controlled, directly or indirectly, in whole or in part, by the person concerned. The freezing order covers entities that the listed person controls directly or indirectly, even if not officially owned, such as joint bank accounts, trust funds, or entities owned indirectly through minors or spouses. It also includes shell or front companies utilized by the listed person, joint ventures they're part of, and entities with intricate or ambiguous ownership structures designed to conceal control or ownership by the listed person. These examples serve to illustrate that any funds subject to the control or ownership of a designated person, irrespective of the method—directly, indirectly, or through any mechanism—are covered by Security Council resolutions.
2.3	It is imperative to highlight that funds jointly owned, controlled, or held by the listed person, group, or entity and a non-listed person, group, or entity are subject to the freezing order in full. This includes the portion owned or controlled by the unlisted person, group, or entity. Disposal of the frozen funds will not occur without first consulting SAMA, which subsequently notifies the Ministry of Foreign Affairs (the Permanent Committee responsible for implementing Security Council resolutions issued under Chapter Seven of the United Nations Charter, established by Royal Order No. 7753/MB dated 29/10/1427 AH) for deliberation. Each case will be handled on an individual basis.

3. Financial Institutions’ Mechanism to Verify all Customers Against the Listed Names of the Security Council

3.1	Financial institutions must conduct daily and continuous checks of customer databases and any information obtained regarding potential or existing customers. They must compare this information with the names included in the Security Council lists related to the prevention of the proliferation of WMD and their financing. Financial institutions are tasked with determining whether they are in possession or under their management of any funds subject to Security Council resolutions. An up-to-date list of individuals and entities on these lists must be maintained in the database.
3.2	Certain financial institutions utilize electronic service programs to ensure that their clients are not subject to any sanctions linked to the Security Council lists related to the prevention of the proliferation of WMD and their financing. While electronic services are valuable tools, they should not be relied upon as foolproof guarantees of compliance with imposed procedures. Daily and continuous verification must be conducted to compare the names listed by the Security Council sanctions committees. The basis for tracking updates and ensuring the enforcement of sanctions imposed on individuals listed in Security Council lists remains the website mentioned in paragraph (1.3) above.
3.3	When a financial institution identifies funds in its possession or under its management that must be frozen, it is required to take the following actions:
		a–	Without delay (within hours), the financial institution must immediately freeze all such funds and any funds derived or resulting from them, without prior warning.
		b–	Abstain from offering any financial or other services or providing funds to or for the benefit of any listed person, group, or entity. This prohibition covers all types of services provided to the listed person, group, or entity, including but not limited to opening accounts or offering any form of advice, financial services, brokerage and investment services, or any type of assets or property, directly or indirectly, whether physical or non-physical, tangible or intangible, movable or immovable.
		c–	In the event of a freeze, SAMA must be notified within a maximum of five working days from the date of the freeze being imposed. This notification should include information about the status of the funds, any measures taken regarding them, the nature and quantity of the frozen funds, and any other relevant information that may facilitate compliance with the decisions. Financial institutions shall ensure the accuracy of the information provided to SAMA.
3.4	If a financial institution is not found to be in possession or control of any targeted funds, it must promptly notify SAMA of any transactions carried out with a former or transient client who is later identified as a person, group, or entity listed on the Security Council's lists. Furthermore, the institution must immediately inform SAMA of any attempted transactions involving individuals listed on the Security Council's lists.*
3.5	Financial institutions, in the event of name similarity, are required to immediately search using available system resources for information to confirm whether the name matches or not. If the financial institutions fail to obtain information confirming the match, SAMA must be notified immediately without taking any further action.

Paragraph (3.4) has been amended in accordance with Circular No. (486/130885) dated 04/09/1440H, corresponding to 09/05/2019G.

4. Procedures to be Put in Place by Financial Institutions if the Freezing Order is Lifted

4.1	In case a name is delisted by the Security Council sanctions committees, financial institutions are mandated to promptly and directly lift the freeze, without any prior notice, within hours. Subsequently, they must notify SAMA, as detailed in paragraph 4.2 below. No prior written notification of the non-lift from SAMA is required.
4.2	SAMA must be informed of the lifting of the freeze within five working days from the date of the freeze being lifted, providing it with information on the status of the funds, any measures taken, the nature and amount of the unfrozen funds and any other information relevant to the decisions. Financial institutions must ensure the accuracy of the information provided.
4.3	In case the Security Council authorize the partial release of funds and other frozen assets as identified in accordance with Security Council resolutions, SAMA will promptly notify the financial institutions under its supervision regarding this matter.

5. Confidentiality of Information
Financial institutions shall ensure the confidentiality of information pertaining to names listed in accordance with Security Council resolutions aimed at preventing the proliferation of WMD and their financing. This obligation is to be strictly observed in compliance with pertinent regulations and instructions, including those set forth in the Anti-Money Laundering Law, the Law on Combating the Financing of Terrorism, and the Anti-Money Laundering and Combating the Financing of Terrorism rules issued by SAMA.

6. SAMA's Mechanism for Verifying Financial Institutions' Commitment to Implementing and Financing Security Council Resolutions Aimed at Preventing the Spread of WMD
Financial institutions shall take all necessary measures to ensure their complete compliance with sanctions imposed on individuals or entities listed by the Security Council sanctions committees. Compliance will be verified through on-site inspections, and penalties outlined in relevant regulations will be enforced in cases of negligence or failure by financial institutions to adhere to instructions.

7. Penalties Enforced in Cases of Non-Compliance With the Requirements and Procedures Outlined in the Mechanism for Implementing Security Council Resolutions Aimed at Preventing the Proliferation of WMD and Their Financing
Individuals who fail to impose a freeze or enforce a freezing order against individuals listed under the mechanism for implementing Security Council resolutions aimed at preventing the proliferation of WMD and their financing, as well as those who facilitate the availability of funds or offer financial or related services to them, will be held accountable according to applicable regulations. Any designated person who breaches the mechanism for implementing Security Council resolutions related to preventing the proliferation of WMD and their financing, intentionally or negligently withholds or provides inaccurate information, delays in furnishing information, or commits other infractions will also face accountability measures.

Questionnaire of Compliance with the Requirements of the Fight against Money Laundering and Terrorism Financing and Statistic Data
In line with the supervisory and regulatory role of SAMA and its commitment to protecting the financial sector and its reputation from being exploited in money laundering or terrorist financing activities, and Based on the powers granted to SAMA under Article Twenty-Four of the Anti-Money Laundering Law issued by Royal Decree No. M/20 dated 05/02/1439H, and Article Eighty-Two of the Law on Combating the Financing of Terrorism issued by Royal Decree No. M/21 dated 12/02/1439H.
SAMA wishes to inform you about the preparation of a questionnaire regarding internal controls for anti-money laundering and terrorist financing in financial institutions, along with a statistical data template for each sector supervised by SAMA. This data should be provided to SAMA on a semi-annual basis, with a deadline of the end of September for data related to the first half of the same year, and the end of March for data related to the second half of the previous year.
We hope the compliance in submitting the data within the specified deadlines, approved that SAMA is supplied with a copy after it is approved by the authorized persons in the financial institution, and provide an electronic copy of the questionnaire and statistical data in (Excel) format to SAMA at the following email address:
AML-CTF@SAMA.GOV.SA
Questionnaire on Compliance with Anti-Money Laundering and Terrorist Financing Requirements and Statistical Data for Money Exchange Centers
Questionnaire on Compliance with Anti-Money Laundering and Terrorist Financing Requirements and Statistical Data for Finance Companies

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.

Corporate Governance for Financial Institutions

Key Principles of Governance in Financial Institutions
No: 42081293 Date(g): 30/6/2021 | Date(h): 21/11/1442 Status: In-Force
Based on the supervisory and regulatory role of SAMA, and its keenness to enhance effective management in financial institutions, and based on the powers vested to it under its law, issued by Royal Decree No. (M/36) dated 11/04/1442 H, and other relevant regulations.
Facilities of the main principles of governance in financial institutions subject to the supervision and oversight of SAMA, to replace the principles of governance for banks operating in Saudi Arabia, issued under Circular No. (35100006351) dated 17/05/1435 H.
For information, and to act accordingly for the financial institutions to which it is mandatory starting from 01/01/2022.

Chapter I Definitions and General Provisions

1. Definitions

The following terms – whenever they occur in these Principles – shall have the meanings assigned thereto unless the context requires otherwise:

Term

Definition

SAMA

Saudi Central Bank*.

Financial Institution

An entity subject to the control and supervision of the Central Bank.

Board

The Board of Directors of the financial institution.

Executive Management (Senior Management)

Persons entrusted with managing the daily activities of the financial institution, and proposing and implementing strategic decisions.

Member

A member of the Board or any of its committees.

Executive Member

A full-time member of the executive management of the financial institution, who participates in managing its daily activities.

Non-Executive Member

A member who is not a full-time member of the executive management of the financial institution and who does not participate in performing its daily activities.

Independent Member

A member who has complete independence in his position and decisions, and who shall not be subject to the following factors affecting independence, to name but a few:

	a.	if he holds 5% or more of the shares of the financial institution or any other company within its group, or is a relative of a person who owns such percentage;
	b.	if he is a relative of any member or senior executive of the financial institution, or any other company within its group;
	c.	if he is a member of any company within the group of the financial institution for which he is nominated to be a member;
	d.	if he works or used to work, within the preceding two years, for the financial institution, for any company within its group, for it's Substantial Shareholders, or for main suppliers and external auditors, or he held controlling interests in the financial institution, any company within its group, Substantial Shareholders, or any party dealing therewith like external auditors or main suppliers within the preceding two years.
	e.	if he has a direct or indirect interest in the businesses and contracts executed for the benefit of the financial institution;
	f.	if he receives financial consideration from the financial institution in addition to the remuneration for his membership of the Board or of any of its committees that exceeds an amount of SAR 200,000 or 50% of his remuneration of the last year for his membership of the Board or any of its committees, whichever is less;
	g.	if he engages in a business where he competes with the main business activity of the financial institution, or if he conducts business in any of the activities practiced by the financial institution;
	h.	if he served for more than nine years, consecutive or inconsecutive, as a member of the financial institution.
	i.	If he has a credit relationship, in his name or in the name of any of his relatives, with the financial institution that exceeds SAR 1,000,000.

Relatives

Fathers and mothers; grandfathers and grandmothers; children and grandchildren; and husbands and wives.

Substantial Shareholders

Any person who owns 5% or more of the shares of the financial institution or voting rights therein.

Related Parties

	a.	Substantial shareholders in the financial institution;
	b.	Board members of the financial institution or any of its affiliates and their relatives;
	c.	Senior executives of the financial institution or any of its affiliates, and their relatives;
	d.	Board members and senior executives of substantial shareholders of the financial institution;
	e.	Establishments – other than companies – owned by a member or a senior executive, or their relatives;
	f.	Companies in which a member or senior executive or any of their relatives is a partner;
	g.	Companies in which a member or senior executive or any of their relatives is a member of their Board or a senior executive thereof;
	h.	Joint stock companies in which a member or senior executive or any of their relatives owns 5% or more, subject to the provisions of Paragraph (d) of this definition.
	i.	Holding companies or affiliates of the financial institution.

Stakeholder

Any person who has an interest in the financial institution, including shareholders, investors, customers, and suppliers.

* 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.

2. General Provisions

a.	These principles aim to set the minimum requirements that would enhance the effective management of financial institutions, direct their financial and non-financial resources towards achieving their strategic objectives, maintain their stability, and preserve the rights of stakeholders.
b.	An effective governance system requires independence of and separation between the position of the Chairman of the Board of Directors and that of the Chief Executive Officer (CEO). This would require good organizational and administrative structures and explicit powers and responsibilities among the main parties of the financial institution, including members and executives, in addition to establishing a general framework for control through a risk management department, an internal audit department, and a compliance department, as well as internal control systems and an external auditor.
c.	These principles shall not prejudice the requirements imposed on financial institutions under other relevant laws, regulations, and instructions.
d.	SAMA has issued several regulations related to governance; these principles shall be read alongside these regulations, as the case may be, including the following:
	•	Principles of conduct and business ethics in financial institutions;
	•	Principles of compliance for commercial banks operating in the Kingdom of Saudi Arabia;
	•	Requirements for appointment to leadership positions in financial institutions that are under the supervision of the Central Bank;
	•	Shariah-compliant governance framework for local banks operating in the Kingdom; and
	•	Sharia-compliant governance instructions for finance companies.
e.	Corporate governance has received international attention, as a number of international agencies and organizations have issued guiding instructions for governance. These agencies and organizations include the following, among others:
	•	Basel Committee on Banking Supervision (BCBS);
	•	Organization for Economic Cooperation and Development (OECD);
	•	Islamic Financial Services Board (IFSB);
	•	The World Bank (WB); and
	•	Committee on Payments and Market Infrastructure (CPMI).

3. Scope of Application

These principles shall apply on a mandatory basis for local banks, finance companies, and real estate refinancing companies.

Subject to the mandatory provisions stipulated in relevant laws and regulations, these principles shall apply as guiding rules to credit information companies, payments and financial technology companies, money exchange companies and institutions¹, consumer microfinance companies, finance support companies, financial lease contract registration companies, and debt-based crowdfunding companies. The Central Bank may, at any time, enforce all or some of the provisions of these principles on a mandatory basis.

¹ The provisions contained in "the Governance Controls of the Money Exchange Sectors" shall apply to money exchange companies and institutions on a mandatory basis.

Chapter II Key Principles of Governance

1^st Principle: Qualifications of Board Members

Board members shall be qualified to carry out the work entrusted to them, have a clear understanding of their required roles, and have the ability to make decisions impartially and objectively without any external influence whether from inside or outside the financial institution. They shall particularly fulfill the following:
4.	Their CVs shall be publicly available in order to enable stakeholders to assess their efficiency and ability to carry out their tasks effectively.
5.	A member shall have professional competence and shall possess various practical and administrative skills and experiences, as well as appropriate personal qualities, especially honesty and integrity, in addition to the following:
	a.	Leadership: He shall possess leadership skills that enable him to delegate powers in order to promote performance, to apply best practices in effective management, and to disseminate professional values and ethics.
	b.	Competence: This attribute shall appear through the level of education, experience, skills, and willingness to continue learning.
	c.	Guidance: He shall possess technical and administrative capabilities, speed in making decisions, understanding of the technical requirements related to workflow, ability to provide strategic orientation, long-term planning, and a clear future vision.
	d.	Financial Literacy: He shall have the skills to read and understand financial statements and reports and the ratios used to assess performance.
	e.	Physical Fitness: He shall not have a health condition that hinders him from exercising his duties and competencies.
6.	A member shall have the following qualities:
	a.	Truthfulness: He shall have an honest professional relationship with the financial institution, and shall disclose thereto any relevant information before conducting any transaction or entering into a contract with the financial institution or with any of its affiliates.
	b.	Loyalty: He shall avoid transactions that may entail a conflict of interest, and shall ensure the fairness of dealings and their conduct for the benefit of the financial institution and stakeholders.
	c.	Care: He shall perform his duties and responsibilities effectively, and shall be keen to provide all the information that would ensure that the decisions made are in the interest of the financial institution. In order to achieve the foregoing, he shall undertake the following responsibilities:
		•	Attend Board meetings regularly, and not be absent without a justifiable excuse, and prepare for such meetings and effectively participate therein, including raising relevant questions and holding discussions with senior executives;
		•	Make decisions on the basis of complete information and in good faith. A member shall not be relieved of responsibility if he abstains from voting without clarifying his opinion on the decision in question;
		•	Develop his knowledge of the financial institution's activities and other related areas;
		•	Ensure that significant and major topics are included in the Board meeting agenda;
		•	An executive member shall provide full information to the Board when requested.

2^nd Principle: Formation, Appointment and Board Affairs

7.	The bylaws of the financial institution shall specify the number of members in proportion to its size and the nature of its business, taking into account the following:
	a.	The number of members shall not be less than five and not more than eleven.²
	b.	The number of independent members shall not be less than two members, or one third of the Board members, whichever is greater.
	c.	The number of executive members shall not exceed two.
8.	The General Assembly shall elect Board members for the period stipulated in the bylaws of the financial institution, provided that their term membership does not exceed three years; these members may be reelected unless the bylaws of the financial institution stipulate otherwise.
9.	The procedures for nominating and selecting Board members shall be clear-cut and explicit, and shall observe the diversity of experiences, qualifications, and qualities referred to in the first principle.
10.	Members shall choose a non-executive member to serve as the Chairman of the Board³ and another as his deputy, provided that the Chairman and his deputy do not exercise any of the functions of the executive management.
11.	The Board shall conduct an annual evaluation of the extent of independence of the independent member, and shall ensure that there are no relationships or circumstances that affect or may affect his independence; the member shall also inform the Board in the event that circumstances affecting his independence may arise.
12.	A written no-objection letter shall be obtained from the Central Bank prior to nominating any member of the Board and its committees, or appointing any of the holders of leadership positions, in accordance with the relevant Central Bank instructions. The Central Bank shall be notified in writing upon accepting the resignation/departure from work/termination of service of any holder of a leadership position, the termination of membership of any member of the Board and its committees, or the independent member’s loss of independence, within five working days.
13.	A member may not become a member of the board of directors of a similar financial institution operating inside the Kingdom.
14.	A member may not become a member of the board of directors of more than five joint stock companies listed on the stock market simultaneously; in the event of a conflict of interest, said member shall be subject to the conflict-of-interest policy.
15.	A member may preferably retain his membership for a period not exceeding 12 consecutive or inconsecutive years.
16.	Any person who wishes to nominate himself for Board membership shall disclose to the Board and the General Assembly any of the following cases of conflict of interest:
	a.	If he has a direct or indirect interest in the businesses and contracts made for the benefit of the financial institution wherein he desires to be nominated as a board member; and/or
	b.	If he engages in a business that may compete with the financial institution or with any of its activities.
17.	Each member shall immediately inform the Board of any direct or indirect interest he has in the businesses and contracts executed for the financial institution’s account, and shall not participate in voting on the decision to be taken in this regard.
18.	Each member shall maintain the confidentiality of the information of the financial institution, and shall not disclose any information that he has been privy to through his Board membership to third parties, or to any of the shareholders of the financial institution, unless such disclosure takes place during the General Assembly meetings.
19.	Each member shall be presented with an induction program that explains the mission, strategic objectives and activities of the financial institution, and with a memorandum explaining the duties and responsibilities of his membership.
20.	Members shall carry out the tasks and responsibilities assigned to them through explicit and appropriate procedures; the Board shall review the effectiveness of these procedures on an ongoing basis, and shall identify weaknesses and make the necessary changes whenever required.
21.	Members shall be aware of the rules, regulations, and instructions related to the financial institution's business, and shall keep pace with any new developments in this regard.
22.	The Board shall hold at least four meetings per year, with one meeting every three months, in order to exercise its duties and responsibilities effectively. Meetings shall also be held whenever required. Nonexecutive and independent members may preferably hold closed meetings without the attendance of the executive board members, by at least one meeting per year.
23.	Board meetings shall only be valid if attended by half the members, provided that the number of attending members be not less than three, unless the bylaws of the financial institution provide for a larger number. All decisions shall be made by the majority votes of the members; in case of a tie, the Chairman of the Board shall have the casting vote.
24.	Members shall attend Board meetings regularly, and may do so by technological means; they shall only be absent with an acceptable reason to be reported to the Chairman of the Board in advance. In the event that a member fails to attend three meetings per year without a valid reason, another member shall be appointed to replace his membership.
25.	The Board shall draft meeting minutes wherein to note the meeting place, date, beginning and ending time, names of attending and absent members, names of attendees from outside the Board, including an external party such as an external auditor or an internal party such as the financial manager, and a statement of the meeting discussions and deliberations, and the reservations expressed - if any - together with an explanation of the reasons. The meeting minutes shall be signed by all attendees, attested with the decisions and voting results, and kept in a special and organized register.
26.	The Board shall, at the beginning of each year, set a specific schedule for receiving reports from committees and internal and external auditors, and shall ensure that the mechanism for drafting, collecting, and submitting reports is appropriate and consistent with the approved internal policy, including submitting same to the Board at the due times.
27.	The Board shall appoint a secretary from among its members or others, and shall determine the conditions to be met by him. He shall hold a university degree in law, finance, accounting, or administration - or its equivalent - and shall have relevant practical experience of not less than three years. In the event that he does not hold a university degree in any of these disciplines, he shall have at least five years of relevant work experience.
28.	The Board secretary shall perform his responsibilities as per the directives of the Chairman of the Board. He may not be dismissed except by a decision of the Board. His responsibilities shall particularly include the following:
	a.	Draft the meeting minutes of the Board, wherein to note the meeting place, date, beginning and ending time, names of attending and absent members, names of attendees from outside the Board, including an external party such as an external auditor or an internal party such as the financial manager, and a statement of the meeting discussions and deliberations, and the reservations expressed - if any -together with an explanation of the reasons. The minutes shall be signed by all attendees, attested with the decisions and voting results, and kept in a special and organized register;
	b.	Retain the reports submitted to the Board and the reports drafted thereby;
	c.	Inform the members of the dates of Board meetings well in advance of the specified date;
	d.	Provide the members with the meeting agenda, working papers, documents and relevant information, as well as any additional documents or information requested by any member in relation to the topics included in the meeting agenda;
	e.	Ensure that the members comply with the procedures approved by the Board;
	f.	Submit draft minutes to the members to express their opinions thereon prior to signing same;
	g.	Ensure that the members have full and prompt access to a copy of the minutes, as well as to the information and documents related to the financial institution;
	h.	Regulate the disclosure register of the members and the executive management; and
	i.	Follow up on Board recommendations pursuant to a mechanism to be approved by the Board.
29.	If a member resigns and he has comments on the performance of the financial institution, he shall submit a written statement to the Chairman of the Board. Said statement shall be presented to the rest of the members, and a copy thereof shall be furnished to the Central Bank.

² As for banks, the number of Board members shall not be less than nine, and not more than eleven, as per the best applicable practices.
³ As for banks, this member would rather be independent, as per the best applicable practices.

3^rd Principle: Responsibilities of the Board

The financial institution shall have an effective Board to direct its activities, safeguard its interests, and develop its values. The Board shall bear responsibility for its businesses, even if it delegates committees, agencies, or individuals to exercise some of its powers. In all cases, the Board may not issue a general or indefinite delegation. It shall:
30.	Form the executive management, regulate, monitor and supervise its operating procedures, and ensure its performance of the tasks assigned thereto.
31.	Set and monitor the implementation of the plans, policies, strategies and main objectives of the financial institution, and review same on a regular basis.
32.	Ensure the integrity and financial solvency of the financial institution, and maintain effective relationships with the supervisory authorities.
33.	Set and comply with clear limits for responsibility and accountability at all levels of the financial institution. Responsibilities shall be completely separated at the level of the executive management.
34.	The organizational structure of the financial institution shall determine the competencies and the distribution of tasks between the Board and the executive management as per the best governance practices, improve the efficiency of decision-making, and achieve balance between powers and authorities. In order to achieve this, the Board shall:
	a.	Approve and develop the internal policies related to the financial institution’s business; this shall include defining the tasks, competencies and responsibilities assigned to the various organizational levels;
	b.	Approve a written and detailed policy that defines the powers delegated to the executive management, provided that it includes an account of each power, its method of implementation, and delegation period; it may request the executive management to submit periodic reports on its exercise of the delegated powers;
	c.	Determine the issues that it has the power to decide on.
35.	Ensure the adequacy of human and financial resources to achieve the main objectives and plans of the financial institution and carry out its obligations.
36.	Ensure the existence and development of effective units for compliance, internal auditing and risk management, make sure that such departments are independent from business departments, ensure the availability of the adequate powers and resources therein, and train their staff and develop their capabilities in the field.
37.	Develop and monitor the implementation of a comprehensive risk management strategy and policies in proportion to the nature and size of the financial institution’s activities, and review same on an annual basis, taking into account to link the level of risks that the financial institution desires to bear in a specific period of time with its strategy and capital plan.
38.	Ensure the existence of an effective system for an objective and systematic performance assessment of the financial institution's employees at all levels. The performance assessment of the executive management shall specifically be long-term, and shall not be limited to the performance of a single year only.
39.	Select senior executives, and ensure that an appropriate replacement policy is applied and that the substitute is highly qualified and possesses the required skills.
40.	Notify the Central Bank in writing of any penalties imposed by any supervisory, regulatory or judicial authority that may affect the functioning of the financial institution, within a period of ten working days as of the date of the penalty.
41.	Ensure the independence of the internal and external auditors, and the accuracy and integrity of the information and data to be disclosed in accordance with the disclosure and transparency requirements.
42.	Be aware of the main risks that may affect the financial institution and its affiliate companies, and exercise an appropriate supervisory role over these companies, taking into account the legal independence and governance requirements of these affiliates.
43.	Set a clear written policy to deal with actual or potential cases of conflict of interest that may affect the performance of members, executive management or other employees of the financial institution upon dealing therewith or with other stakeholders, provided that said policy at least includes the following rules:
	a.	Emphasize that members, senior executives and other employees of the financial institution avoid situations that may lead to a conflict of their interests with those of the financial institution, and deal with such cases as per the provisions of the relevant laws and regulations;
	b.	Provide illustrative examples of conflict-of-interest situations that are relevant to the nature of the financial institution's activities.
	c.	Set clear procedures for disclosing conflict of interest in businesses over which a conflict of interest may arise, and obtain the necessary license or approval;
	d.	Make sure to constantly disclose any situations that may lead to a conflict of interest or upon the occurrence of such conflicts;
	e.	Abstain from voting or taking part in decision-making when there is a conflict of interest;
	f.	Set clear procedures when the financial institution enters into a transaction with a related party. Said transactions shall be carried out on a commercial basis only, and shall include notifying the public and the Central Bank without delay about this transaction if it is equal to or exceeds 1% of the total revenues of the financial institution pursuant to the latest annual audited financial statements.
44.	The Board shall not be exempted from responsibility, and shall be held accountable in the event that the operations of the financial institution are outsourced to another party; it shall be aware of the risks arising from the assignment process and shall ensure that the assignment operations be governed by the relevant Central Bank instructions.
45.	Evaluate the following on an annual basis:
	a.	A member’s performance; this evaluation may be assigned to an external party to ensure its objectivity;
	b.	Effectiveness of the controls, working procedures, structure, and composition of the Board, together with identification of weaknesses and making the necessary changes when required;
	c.	Effectiveness of the applicable governance policies and procedures and practices; it shall be determined whether they require any improvements or changes. The findings of these assessments shall be used by the Board as part of its ongoing improvement efforts, even if it is required to share such results with the Central Bank.
46.	Subject to the relevant Central Bank instructions, the Board shall ensure the operation and effectiveness of the following policies and procedures, including, for example:
	a.	Policies and procedures for IT and cybersecurity governance;
	b.	A policy for the professional conduct and business ethics to be applied in the financial institution;
	c.	A policy defining the mechanism for reporting violations in the financial institution and protecting whistleblowers;
	d.	Policies and procedures for resolving complaints and objections that may arise between the financial institution and stakeholders;
	e.	Policies and procedures to maintain the confidentiality of information.
47.	Approve the remuneration policy for the financial institution employees, which shall include, at a minimum, the types of remuneration (e.g. fixed or performance-related remunerations, or remunerations granted in the form of shares).
48.	Verify the accuracy and integrity of the annual and quarterly financial statements and approve same before publication thereof.
49.	Form an appropriate number of committees - in accordance with the provisions of the 5^th Principle herebelow - and approve their work regulations. As an exception, the nomination and remuneration committee and the audit committee shall be approved by the General Assembly. These regulations shall comprise specifying the tasks of each committee, its duration and scope of work, the powers granted thereto, the responsibilities assigned thereto, and the mechanism governing Board supervision of said committee. The Board shall constantly ensure that committee members exert serious efforts upon performing their work.
50.	Announce the Board committees, their scope of work, and the names of their members in the annual report of the Board. The Chairman of the Board shall provide the Central Bank with a list of these committees, their tasks, working procedures, and the names of their members.
51.	Without prejudice to the competencies of the Board of Directors, the Chairman of the Board shall undertake the following tasks:
	a.	Chair the Board and supervise the effectiveness of its workflow, and perform his competencies effectively;
	b.	Ensure that all Board members have timely access to complete, clear and correct information;
	c.	Represent the financial institution before third parties in accordance with the provisions of the relevant laws, regulations, and instructions, as well as the provisions of the financial institution's bylaws;
	d.	Encourage effective participation between the Board and the executive management;
	e.	Oversee the drafting of the Board meeting agenda, taking into account any point raised by a Board member or auditor, and consult with the members upon preparing the meeting agenda.
52.	Ensure that the financial institution adopts social responsibility programs, in line with the social responsibility policy approved by the General Assembly, and that the objectives of these programs are directed towards supporting various social projects, increase financial awareness, meet the credit needs of the local economy through granting loans and facilities for productive businesses, and innovate products that encourage economic development without compromising the solvency of the financial institution and stakeholders.
53.	Ensure that the services rendered by the financial institution meet the needs and requirements of society at fair costs, and that the financial institution takes the initiative to provide facilities to support and encourage small and medium enterprises.

4^th Principle: Responsibilities of Executive Management

The executive management shall monitor and manage the daily activities of the financial institution, and shall ensure that these activities are in line with the business strategy, risk level, and policies approved by the Board. It shall undertake the following responsibilities:
54.	Implement the plans, policies, strategies, and main objectives of the financial institution that are approved by the Board.
55.	Propose the most appropriate capital structure of the financial institution and its strategies and financial objectives.
56.	Propose and implement a comprehensive strategy for the financial institution, as well as the principal and interim business plans, and the policies and mechanisms for investment, financing, risk management, and emergency administrative circumstances management plans.
57.	Propose the main capital expenditures of the financial institution, and acquire and dispose of assets.
58.	Propose the organizational and functional structures of the financial institution that clarify the role, powers, and responsibility of the various positions within the executive management, including the CEO, and submit same to the Board for approval.
59.	Propose a policy of professional conduct and work ethics for the financial institution, and submit same to the Board for approval.
60.	Propose a policy for the remunerations granted to employees, including, at minimum, the types of remunerations, such as fixed or performance-related remunerations or remunerations granted in the form of shares, and submit same to the Board for approval.
61.	Apply the financial and accounting systems correctly, including the procedures relating to drafting financial reports.
62.	Apply appropriate control systems for risk management by generally forecasting the risks that the financial institution may encounter, create an environment that is aware of the culture of risk mitigation at the level of the financial institution, and present same to the Board and other stakeholders with transparency.
63.	Manage the resources of the financial institution pursuant to its strategic plans and objectives approved by the Board.
64.	Implement internal control and risk management systems, including the conflict-of-interest policy, verify the effectiveness and efficiency of these systems, and ensure their compliance with the level of risks approved by the Board.
65.	Submit to the Board an annual report on the internal control system and the implementation thereof to enable the Board to review the system and ensure its effectiveness.
66.	Keep the Board constantly and adequately informed of substantial issues, and provide it with such information as it may require, in order to carry out its responsibilities and to supervise the executive management and evaluate its quality.
67.	Understand and direct the financial and non-financial structures at the group level, and provide an appropriate mechanism to obtain updated information on the group structure.
68.	Set appropriate procedures for regular communication with the financial institution’s major clients to assess their risks, and take into consideration the governance frameworks used by clients prior to entering into credit relationships with them.

5^th Principle: Committees Formed by the Board

The formation of Board committees ensures and supports the effectiveness of decision-making to achieve the objectives of the financial institution in accordance with the best practices and specialized technical standards. It also assists the Board to perform its duties and responsibilities, contributes to the effectiveness of performance and to reviewing and monitoring the financial institution’s businesses on a regular basis. Committee members may be appointed from within or outside the Board. The formation of these committees shall not relieve the Board of its responsibilities, and it shall observe the following:
69.	A member may preferably not be a member of more than two committees.
70.	A member shall attend committee meetings regularly and may do so by using technological means. For a meeting to be valid, it shall be attended by half the members. All decisions shall be made by the majority vote of members; in case of a tie, the chairman of the committee shall have the casting vote. The opinion of a dissenting member shall be recorded in the meeting minutes. Members may not cast their votes by proxy.
71.	A member shall act in good faith, and with due diligence and care for the benefit of stakeholders. He shall perform his duties aloof from any external influence, whether from inside or outside the financial institution. He shall not give precedence to his personal interests or the interests of persons whom he represents over those of the financial institution, shareholders and other stakeholders.
72.	Each committee shall have a secretary from among its members or from outside. A committee secretary may preferably not serve as the secretary of another committee, and he shall have the necessary qualifications, skills and abilities to perform the following tasks, as a minimum:
	a.	Record committee meetings and draft minutes therefor, taking into account to submit the drafts to the members to express their opinions thereon before signing same;
	b.	Prepare and submit committee reports to the Board and retain same;
	c.	Inform committee members of meeting dates well in advance of the specified date.
73.	The number of committees to be formed by the Board shall be determined pursuant to the nature of operations and the size of the financial institution, in addition to the relative experience and qualifications of the Board members. These committees shall comprise the following, among others:

• The Executive Committee

74.	This committee shall consist of no less than three and no more than five members, and it may not be chaired by the CEO.
75.	The committee shall hold no less than six meetings per year; the risk manager or any person whom the committee deems necessary may be invited to attend committee meetings without having the right to vote on committee decisions.
76.	The committee chairman shall submit a report to the Board on any important issue, and shall, upon consultation with the Chairman of the Board, determine the items to be included in the Board meeting agenda, in addition to any subjects not falling within the competence of other committees.
77.	The Board shall determine committee powers and responsibilities, and shall monitor the implementation thereof.

• The Audit Committee

78.	This committee shall be composed of no less than three and no more than five members, all of whom shall be non-executive members, including at least one independent member.⁴ It shall be chaired by an independent member, and the number of the members from outside the Board shall exceed that of the members from within the Board. This committee may not be chaired by the Chairman of the Board.
79.	The General Assembly shall, upon a recommendation of the Board, approve committee work regulations, provided that it comprises its work controls and responsibilities, procedures for appointing its members, their membership term, and their remuneration.
80.	Committee members shall have academic qualifications and professional experience in auditing and risk management, including knowledge of accounting and auditing standards, ability to understand financial reports, and understanding of the laws, regulations and instructions issued by the relevant agencies.
81.	The number of meetings to be held by the committee shall depend on the size of the financial institution and the scope of the tasks assigned thereto, provided that it holds no less than four meetings per year, in addition to any other meetings to be held when required. The committee may invite to its meetings any employee to discuss with him the topics raised therein; this invitation shall include the CEO and the internal and external auditors. The minutes of committee meetings shall be distributed to all members, who shall be entitled to request the committee for clarification of any issues.
82.	The committee shall have the competence to monitor the financial institution’s work, verify the integrity and impartiality of its reports and financial statements, and ensure the availability of internal control systems therein. Committee tasks shall include the following:
a.	Financial Reports
	-	Examine the quarterly and annual financial statements of the financial institution before submitting same to the Board, and provide its opinion and recommendation thereon, in order to ensure their integrity, fairness and transparency;
	-	Provide its technical opinion - at the request of the Board - on whether the Board report and the financial statements of the financial institution are fair, balanced and understandable, and contain information that allows shareholders and investors to assess the financial position of the financial institution, its performance, business model, and strategy;
	-	Examine any important or unfamiliar issues contained in the financial reports;
	-	Scrutinize any issues raised by the financial manager or the auditor of the financial institution;
	-	Examine the accounting estimates pertaining to significant issues contained in the financial reports.
	-	Examine the accounting policies applied by the financial institution, and provide its opinion and recommendation thereon to the Board.
b.	Internal Audit
	-	Examine and review the financial institution’s internal and financial control systems and risk management system;
	-	Examine the internal audit reports and follow up on the implementation of corrective measures with regard to the remarks contained therein;
	-	Monitor and oversee the performance and activities of the internal auditor and the internal audit department of the financial institution, in order to ensure the availability of the necessary resources and their effectiveness in performing the activities and tasks assigned thereto;
	-	Submit a recommendation to the Board to appoint/terminate the service of the manager of the internal audit unit or department or the internal auditor and propose his remuneration;
	-	Evaluate the effectiveness and efficiency of internal controls, policies and procedures, the reporting mechanism and the extent of compliance therewith, and provide recommendations for improvement thereof.
c.	The Auditor
	-	Submit a recommendation to the Board to nominate/dismiss auditors, determine their fees and evaluate their performance, after verifying their independence and reviewing the scope of their work and the terms of their contracts;
	-	Verify the auditor's independence, objectivity and fairness, and the effectiveness of audit activities, taking into account the relevant rules and standards;
	-	Review and provide its opinion on the auditor’s plan and activities for the financial institution, and ensure that he does not provide any technical or administrative works beyond the scope of audit work;
	-	Respond to the queries of the financial institution's auditor;
	-	Examine the auditor's report and comments on the financial statements and follow up on the procedures taken in connection therewith.
d.	Compliance
	-	Review the findings of the reports made by supervisory authorities, and ensure that the financial institution has taken the necessary measures with regard thereto;
	-	Report to the Board any issues that it deems necessary to take action on, and provide recommendations as to the procedures to be taken in connection therewith;
	-	Ensure the financial institution's compliance with the relevant laws, regulations, policies and instructions, and take the necessary measures to improve the financial institution’s level of regulatory compliance.

• The Nomination and Remuneration Committee

83.	This committee shall consist of no less than three and no more than five members, including at least two independent members. It shall be chaired by an independent member, and shall not be chaired by the Chairman of the Board.
84.	The General Assembly shall, upon a recommendation of the Board, approve the committee work regulations, provided that they include its working rules and procedures, tasks, procedures for appointing its members, and their membership term and remuneration.
85.	The committee shall be in charge of identifying and proposing candidates for selection as members of the Board and the executive management, and preparing a clear policy for the remuneration of said members, as per the relevant Central Bank instructions.
86.	The committee shall hold no less than two meetings per year, wherein to examine and evaluate members' performance, nominate new members, and discuss the policy for remunerations and incentives.
87.	Committee tasks shall include the following:
	a.	Coordinate with the Human Resources Department to develop the replacement and succession policy, and ensure the executive management’s compliance therewith;
	b.	Establish a record of the qualifications and skills of Board members in order to identify the additional skills required to activate the role of the Board and ensure its implementation of its tasks and responsibilities;
	c.	Ensure that the remuneration amount is consistent with the prevailing local norms and control systems, and is appropriate to achieve the shareholders’ interests and the financial institution's long- term strategic goals, and ensure that the incentive system is reviewed periodically and that it does not encourage participation in high-risk operations to achieve short-term profits, in addition to its agreement with the risk policy of the financial institution approved by the Board.

• The Risk Committee⁵

88.	This committee shall be composed of no less than three and no more than five members, three of whom shall be non-executive members, and it shall not be chaired by the CEO.
89.	Committee members shall have an appropriate level of knowledge of risk management, and shall include an expert in cyber and technical risks.
90.	The financial institution’s risk manager shall report to the Board through the risk committee, which shall have to submit its opinion on the risk management reports to the Board.
91.	The committee shall hold at least four meetings per year, and it may invite the risk manager to attend its meetings without being a member therein.
92.	Committee tasks shall comprise the following:
	a.	Develop a comprehensive risk management strategy and policies, in line with the nature and size of the financial institution’s activities, and taking into account cyber and technical risks, ensure their implementation, and review and update same pursuant to the internal and external changes that occur to the financial institution;
	b.	Determine and maintain an acceptable risk level to which the financial institution may be exposed, and ensure that the financial institution does not go beyond said level;
	c.	Verify the feasibility of the financial institution's successful continuation of its activities, and identify the risks that threaten its existence over the following twelve months;
	d.	Oversee the financial institution’s risk management system, and evaluate the effectiveness of the systems and mechanisms for identifying, assessing and monitoring the risks that may endanger the financial institution so as to determine areas of inadequacy therein;
	e.	Reassess the financial institution's ability to bear and be exposed to risks on a regular basis, for example, by conducting stress tests;
	f.	Prepare and submit to the Board detailed reports on exposure to risks and the proposed steps to manage these risks;
	g.	Provide recommendations to the Board as per the appointment/termination of service of the manager of the risk unit or department;
	h.	Provide recommendations to the Board on risk management-related issues;
	i.	Ensure the availability of adequate resources and systems for risk management;
	j.	Review the organizational structure of risk management and provide recommendations thereon prior to approval thereof by the Board;
	k.	Verify the independence of the risk management staff from business departments;
	l.	Ensure that the risk management staff are aware of the risks threatening the financial institution, and endeavor to raise awareness of a culture of risks;
	m.	Review any issues raised by the audit committee that may affect the financial institution’s risk management.

⁴ As for banks, all committee members shall be independent.

⁵ In finance companies, this committee is referred to as the "Risk and Credit Management Committee".

6^th Principle: Rights of Shareholders

93.	The Board shall ensure that the financial institution’s corporate governance policies protect the rights of shareholders and enable them to exercise their rights with ease, and help to provide effective communication channels and various means of contact with all shareholders of the financial institution. It shall also ensure that all shareholders, including minority shareholders, are treated fairly, and shall constantly urge them to participate in the General Assembly meetings and to submit proposals related to the financial institution’s performance and the development of its operations.
94.	The financial institution shall have specific procedures to ensure that shareholders exercise their rights and obtain appropriate information without delay. These rights shall comprise the following: obtaining profits, attending shareholder assemblies and participating in their deliberations, and voting on their decisions in person or through the use of technology, as determined by the relevant laws and instructions.
95.	The financial institution shall provide the Central Bank with a copy of the General Assembly meeting minutes within a period not exceeding 15 days from the meeting date.
96.	The main rights of shareholders shall comprise the following:
	a.	Obtain all relevant information that enables them to fully exercise their rights on a regular basis and without delay without prejudice to the interests of the financial institution;
	b.	Participate and cast their votes in the General Assembly meetings, taking into account the topics that they wish to raise therein;
	c.	Discuss the topics listed on the General Assembly agenda, direct queries to Board members and the certified accountant, and obtain a statement thereon;
	d.	Select Board members by using cumulative voting.
97.	Shareholders shall be provided with information about the venue, date and agenda of the General Assembly 21 days prior to its meeting.
98.	Shareholders may nominate and elect members, inquire about their qualifications, experience and ability to perform their work, discuss the amount of remuneration and financial incentives received by members and senior executives. Moreover, they shall be entitled to submit any inquiry to the Board regarding any unprofessional practices and to obtain a statement thereon.

7^th Principle: Disclosure and Transparency

99.	The Board shall set forth in writing the disclosure policies in line with the disclosure requirements contained in the relevant laws, regulations, and instructions, subject to the following:
	a.	Those policies shall include appropriate disclosure methods to enable stakeholders to access financial and non-financial information pertaining to the financial institution and its performance, including the financial institution’s future orientations and strategic plans, as well as the credit ratings granted thereto by international credit rating agencies.
	b.	The disclosure shall be made in an explicit, correct and non-misleading fashion, and in a timely regular and accurate manner.
	c.	Disclosure policies shall be reviewed periodically and their compliance with the best practices and with the provisions of relevant laws, regulations, and instructions shall be verified.
100.	The Board shall draft an annual report indicating the operations of the ended fiscal year, provided that it includes, at a minimum, the following:
	a.	Names of the members of the Board, the committees, and the executive management, and their current and previous jobs, qualifications and experience;
	b.	Names of companies inside or outside the Kingdom in which a Board member of the financial institution is a member of their current or previous boards or manager;
	c.	Composition of the Board and classification of its members as follows: an executive member, a non executive member, and an independent member;
	d.	Number of Board meetings held during the ended fiscal year, their dates, and the attendance record of each meeting, listing the names of attendees;
	e.	Any punishment or penalty imposed on the financial institution by the Central Bank or by any supervisory, regulatory or judicial authority, together with a statement of the reasons for the violation and the agency imposing such punishment/penalty;
	f.	Details of the financial institution’s social contributions;
	g.	A list of the dates of the General Assembly meetings held during the ended fiscal year, and the names of members who attended same;
	h.	Name of each affiliate company or its group, its capital, the financial institution’s ownership percentage therein, its main business activity, its principal country of operation, and its country of incorporation;
	i.	Information related to any businesses or contracts to which the financial institution is a party, or in which any related party has an interest. This shall include the names of persons engaged in these businesses or contracts, and the nature, terms, duration, and amount of same. If no such businesses or contracts exist, the financial institution shall submit a statement of same;
	j.	Disclosure of the remunerations granted to members of the Board and its committees, as well as to five senior executives who received the highest remunerations, including the CEO and the financial manager;
	k.	Results of the annual audit and the effectiveness of the financial institution’s internal control procedures, as well as the efficiency of its internal control system.

Requirements for Appointments to Senior Positions
No: 199400000067 Date(g): 9/9/2019 | Date(h): 10/1/1441
These Requirements were issued by circular No (1994/67), dated 10/01/1441H, and updated by Circular No. (42064776), dated 13/09/1442H, corresponding to 24/04/2021G, and amended by SAMA Circular No. (4919/67) dated 25/01/1441H, corresponding to 24/09/2019G and Circular No. (42080755) dated 19/11/1442H, corresponding to 28/06/2021G.
The English version displayed herein is not the last updated version. Please refer to the Arabic version to read the last updated version.

Chapter 1 Definitions

1. The following terms and phrases, where used in these Requirements, shall have the corresponding meanings, unless the context requires otherwise:

Term	Definition
SAMA	The Saudi Central Bank*.
Requirements	Requirements for Appointments to Senior Positions in Financial Institutions Supervised by SAMA (Second Version- 2019).
Financial Institutions	The entity that is supervised by SAMA, including banks, foreign bank branches, insurance companies, reinsurers companies, licensed insurance service providers, foreign insurance companies, finance companies, refinance companies, contract registration companies, credit bureau companies, money changers, and payment and fintech companies operating in Saudi Arabia.
Senior Positions	The functions, roles and responsibilities entrusted to those positions who take, propose and implement strategic decisions and manage the Financial Institution’s business processes, including the board of directors and senior management according to the positions specified in Article (7) hereof.

* 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.

Chapter 2 General Provisions

2. Purpose and Scope

2.1	The purpose of these Requirements is to:
	a.	determine the Senior Positions in the Financial Institutions that require SAMA’s written non-objection on the appointment or interim appointment of candidates, and set out the minimum fit and proper criteria that the Financial Institution has to adopt to assess the fitness and propriety of candidates; and
	b.	set out the minimum fit and proper criteria and process that Financial institutions have to adopt to assess the fitness and propriety of candidates for positions that do not require SAMA’s non-objection.
2.2	Without prejudice to any other relevant regulations or instructions, these Requirements shall be applicable to Financial Institutions.

3. Priority for Appointment or Interim Appointment

Priority for appointment to Senior Positions shall be given to Saudi candidates. If the Financial Institution nominates a non-Saudi candidate to be appointed or interim appointed to a Senior Position, the Financial Institution shall provide justifications for the nomination, demonstrate the non-availability of a qualified Saudi candidate for the position, develop and include an approved plan for replacement in the written non- objection request submitted to SAMA. The plan shall include the procedures, programs and courses the Financial Institution use and conduct to train and qualify Saudi candidates for such positions, as well as the time period required.

4. Appointment or Interim Appointment to the Following Positions Shall be Limited to Saudi Candidates:

a.	Director of Human Resources;
b.	Director of Information Security/ Cyber Security;
c.	Director of Information Technology;
d.	Chief Compliance Officer;
e.	Director of Anti-Money Laundering and Counter-Terrorist Financing;
f.	Director of Anti - Financial Crimes;
g.	Director of Anti -Fraud;
h.	Director of Legal Affairs;
i.	Director of Governance/ Secretary of Board of Directors;
j.	Director of the department concerned with providing information or executing the decisions issued against customers by SAMA (Financial Enforcement Department);
k.	Director of Customer Services in insurance companies;
l.	Director of Motor Claims in insurance companies; and
m.	Director of Individual Sales in insurance companies.

5. Replacement and Succession Planning :

5.1	The Financial Institution shall develop a policy approved by the board of directors as follows:
	a.	replacement: determine the senior management positions in the Financial Institution that are held by non-Saudis, and then train Saudi staff to be qualified to hold such positions within a specified period of time; and
	b.	succession planning: determine the key positions affecting the work and stability of the Financial Institutions, and then train Saudi staff to be qualified to hold such positions once they become vacant, enabling the Financial Institution to continue its work.
5.2	The Policy provided for in paragraph (1) of this Article shall, as a minimum, include the following:
	a.	such positions, including, as a minimum, the senior management positions indicated in the attached appendices (1, 2, 3, 4, 5 & 6);
	b.	specialized training programs and courses to be continuously implemented by the Financial Institutions to train and qualify the Saudi candidates for such positions; and
	c.	regulatory framework developed for the Policy that includes implementation procedures.
5.3	The Policy shall ensure the provision of qualified Saudi talents to hold such positions gradually by using the best practices and programs in the field.
5.4	The Financial Institution’s board of directors and chief executive officer/ managing director/ general director shall follow up the commitment to implement the Policy referred to in this Article.

6. Certificates Verification

The Financial Institution shall verify the authentication of the academic and professional certificates of the Senior Positions’ holders and candidates as follows:
a.	verify the authentication of the academic certificates issued from institutions outside Saudi Arabia by checking the official seal and the authentication of a government authority, such as the Ministry of Foreign Affairs or Ministry of Education, if the holder is a national of the country issuing the certificate, or the authentication of the Cultural Bureau if the holder is not a national of the country issuing the certificate;
b.	verify the authentication of the professional certificates through the website of the issuer, if available, or through direct contact by e-mail or other reliable method; and
c.	verify the authentication of the academic and professional certificates issued by different educational and professional institutions through agencies that carry out certificate verification.

Chapter 3 Senior Positions that Require SAMA’s Non-objection

7.	The Financial Institution shall obtain SAMA’s written non-objection on the nomination of the members of the board of directors, as well as the appointment, interim appointment and renewal of interim appointment of any person to carry out the tasks and responsibilities of the senior management positions indicated in the appendices especially prepared for each Financial Institution as follows:
		Appendix (1): Senior Positions in banks operating in Saudi Arabia that require SAMA’s written non-objection.
		Appendix (2): Senior Positions in credit bureau companies operating in Saudi Arabia that require SAMA’s written non-objection.
		Appendix (3): Senior Positions in insurance and reinsurance companies and insurance service providers operating in Saudi Arabia that require SAMA’s written non-objection. (SAMA may require insurance service providers to obtain written non-objection for some or all senior management positions specified for insurance and/or reinsurance companies).
		Appendix (4): Senior Positions in finance and refinance companies and contract registration companies operating in Saudi Arabia that require SAMA’s written non-objection.
		Appendix (5): Senior Positions in money changers operating in Saudi Arabia that require SAMA’s written non-objection.
		Appendix (6): Senior Positions in payment and fintech companies operating in Saudi Arabia that require SAMA’s written non-objection.
8.	Candidates for Senior Positions shall not assume their responsibilities, exercise their roles or announce their appointment or interim appointment prior to obtaining SAMA’s written non-objection.
9.	The Financial Institution must obtain SAMA’s written non-objection on interim appointment to senior management positions, provided that the term of the appointment does not exceed six months, renewable for one term with the approval of SAMA. SAMA’s written non-objection shall not be required for interim appointment that do not exceed (20) business days.
10.	The Financial Institution shall submit the requests for SAMA’s written non-objection on the nomination of the members of the board of directors, or the appointment, the interim appointment or the renewal of interim appointment term for senior management positions accompanied by the required documents according to Appendix (B) herein, within a period not exceeding (30) business days from the date of holding the General Assembly meeting during which the member of the board of directors will be elected, or within a period not exceeding (20) business days from the expected date of the appointment of the candidate to the senior management position, as the case may be.
11.	While making any job offers for appointment and interim appointment to Senior Positions, The Financial Institution shall inform candidates that such positions require obtaining SAMA’s written non-objection.
12.	The Financial Institution shall establish policies, standards and procedures for nomination to Senior Positions to ensure that all candidates and position holders meet and continue to meet the fitness and propriety criteria set forth in these Requirements and in the Financial Institution's policy throughout their tenure, taking into consideration the provisions of the relevant laws, regulations, policies and instructions. Such policies, standards and procedures shall, as a minimum, include the following:
	a.	the minimum fit and proper criteria as stated in the Requirements;
	b.	procedures for conducting fit and proper assessments;
	c.	procedures to be taken when holders of Senior Positions do not meet all the criteria; and
	d.	requirements of reviewing and updating the policy from time to time, and as needed.

Additional provisions pursuant to SAMA Circular No. (42007671) dated 12/02/1442.

This section is currently available only in Arabic, please click here to read the Arabic version

Chapter 4 Fit and Proper Criteria and Disclosure

13.	The Financial Institution’s board of directors shall be responsible for ensuring the fitness and propriety of candidates for Senior Positions, in accordance with the Financial Institution’s relevant policy, requirements and procedures.
14.	The Financial Institution shall adopt clear and precise standards and procedures to assess and verify the fitness and propriety of the Senior Position holders or candidates. The fit and proper criteria shall, as a minimum, include the following:
	a.	Honesty, integrity and good reputation and fairness: The candidate must have personal qualities, such as honesty; integrity; good reputation and fairness, and must not have been convicted of any crime impinging on honor or integrity, unless rehabilitated.
	b.	Competence and capability: The candidate must have the necessary academic qualification, or adequate experience, skills to perform his/her role effectively, as well as the ability to understand the technical requirements of the business, the risks and the management process. In addition, the candidate must meet all requirements set by SAMA.
	c.	Financial capability efficiency: The candidate must have the efficiency and experience needed to manage his/her financial obligations and affairs prudently and properly, this does not mean the limited financial possibilities of the candidate.
	d.	Independence: The candidate must have the necessary independence to perform the tasks and duties of the proposed Senior Position and shall not have employment interests or obligations, or any other situations which might give rise to conflict of interests or which could, in any way, impair the candidate’s ability to independently perform the duties of the proposed position.
15.	The assessment process carried out by the Financial Institution, on a regular basis or prior to requesting SAMA’s non-objection, shall be documented and supported by relevant documents and information. The Financial Institution shall check the validity of the information provided by the candidates for the Senior Positions from independent and reliable internal and external sources. The information and the results of the assessment process obtained by the Financial Institution shall be kept confidential. The approval of the candidate, if necessary, shall be obtained to access the information.
16.	The Financial Institution shall explain the Fit and Proper Form to candidates and ensure the completeness and accuracy of the information provided. The Financial Institution shall also disclose in writing to SAMA any information it may find relevant to the fitness and propriety of the candidate and any changes that may affect the validity, accuracy and completeness of the information provided in the Form, even if after obtaining SAMA’s non-objection, within a period not exceeding (5) business days from the date on which such information was obtained or the change has occurred.
17.	The Financial Institution and candidates for Senior Positions shall fully and clearly disclose to SAMA all information relevant to the fit and proper requirements. The information provided shall, as a minimum, include the following:
	a.	all the information and documents required in the Fit and Proper Form;
	b.	any material information that may affect SAMA's decision to issue non-objection on the nomination, appointment, interim appointment or the renewal of interim appointment term; and
	c.	any other relevant information becomes known to the financial institution or candidate.
18.	SAMA may request any information or documents it deems necessary for evaluating requests for non-objection on the nomination, appointment, interim appointment or the renewal of interim appointment term and may request to interview the candidate as well. The Financial Institution shall provide SAMA with the required information and documents within a period determined by SAMA or within (10) business days, as a maximum, from the date of requesting such information and/or documents. If the Financial Institution fails to provide so within the specified period, SAMA shall have the right to close the request.
19.	SAMA may conduct background checks using various means it deems appropriate to ensure the validity, accuracy and completeness of the information and documents provided by the Financial Institution, and to ensure the fitness and propriety of candidates. Accordingly, SAMA will take actions it deems appropriate whether to grant non-objection on requests received or to reject such requests without any responsibility whatsoever on SAMA. Subsequently, the Financial Institution shall inform the candidate in that.
20.	SAMA may cancel the non-objection granted to the Financial Institution on the appointment, interim appointment or the renewal of interim appointment term for a current Senior Position holder if SAMA finds that he/she does not cooperate, neglects or omits his/her duties, or if SAMA detects any concealment, misrepresentation or misreporting of information or any violation or circumvention of these Requirements or any other instructions issued by SAMA without prejudice to the statutory procedures towards the financial institution and the person concerned.
21.	The Financial Institution shall periodically, and at least annually, assess the fitness and propriety of the Senior Position holders. In the event of such assessments leading to any information or findings that may materially compromise the fitness and propriety of the candidates, the Financial Institution shall immediately report such information and findings to SAMA.
22.	The Financial Institution shall notify SAMA in writing, in accordance with email addresses indicated in Appendix (C), when the person appointed commence his/her work, when resignation is accepted, when position holder leaves work and when employment is terminated for whatever reason, within (5) business days from the date of such events.
23.	The Financial Institution shall provide SAMA with biannual reports (at the end of both June and December) including data of Senior Position holders and data on vacant Senior Positions, in accordance with Appendix (A) hereof.

Chapter 5 Senior Positions that Do Not Require SAMA’s Non-Objection

24.	The Financial Institution shall establish clear and precise policy, standards and procedures to ensure that candidates for and holders of positions that do not require SAMA’s non-objection meet and continue to meet the fitness and propriety criteria throughout their tenure. Such policy, standards and procedures shall, as a minimum, cover the provisions hereof.
25.	The Financial Institution’s board of directors shall be responsible for ensuring the fitness and propriety of candidates for positions that do not require SAMA’s non-objection, including candidates for Senior Positions in the Financial Institution’s subsidiaries or its overseas branches, in accordance with these Requirements and the Financial Institution’s relevant policies and procedures.
26.	All assessments of candidates conducted by the Financial Institution shall be supported by relevant information and data and shall be properly documented.
27.	SAMA shall have access to the data collected or procedures conducted by the Financial Institution in the context of the nomination, appointment or interim appointment to Senior Positions that do not require SAMA’s non-objection.

Chapter 6 Effectiveness

28.	These Requirements shall supersede the Requirements for Appointments to Senior Positions in Financial Institutions Supervised by SAMA, promulgated by Circular No. 341000115396 dated 25/09/1434H.
29.	These Requirements shall come into effect as of the date of the issuance.

Appendix (1): Senior Positions in Banks Operating in Saudi Arabia that Require SAMA’s Written Non-Objection

This Appendix is amended in accordance to SAMA Circular No. (4919/67) dated 25/01/1441H and Circular No. (42080755) dated 19/11/1442H.

• Board of Directors

Members of the board of directors (including the board’s chairman and vice-chairman); and
Chairs and members of committees emerging from the board of directors.

• Senior Management