Regulation on information and communication technologies and security risk management

1 of 22 Pursuant to Article 35, paragraph 1 subparagraph 1.1 and Article 65, of the Law No. 03/L-209 on Central Bank of the Republic of Kosovo (Official Gazette of the Republic of Kosovo, No.77 / 16 August 2010), amended and supplemented by Law No. 05/L –150 (Official Gazette of the Republic of Kosovo / No. 10 / 03 April 2017) and pursuant to article 136 and article 95, paragraph 3 of the Law No. 10/L-026 on Payment Services (Official Gazette of the Republic of Kosovo, No.10 / 14 May 2026) and article 8 and article 51, paragraph 10 of the Law No. 08/L-304 on Banks, the Board of the Central Bank of the Republic of Kosovo, on the meeting held on June 29, 2026, approved the following: REGULATION ON INFORMATION AND COMMUNICATION TECHNOLOGIES AND SECURITY RISK MANAGEMENT CHAPTER I GENERAL PROVISIONS Article 1 Purpose and scope

1. This regulation defines the requirements of establishing the regulatory measures, rules and guidelines for the application of the management of operational and security risks related to the application and management of Information and Communication Technology-ICT and security risks within financial institutions, as defined in Article 2 of this regulation.
2. This Regulation shall apply to financial institutions, which for the purpose of this Regulation refers to payment service providers, as defined in paragraph 1 of Article 1 of Law No. 10/L-026 on Payment Services.
3. For financial institutions other than payment service providers, as defined in Articles 2 and 3 of this Regulation, this Regulation applies to all the activities that they provide.
4. This Regulation shall be applicable in total or in part, to microfinance institutions and non-bank financial institutions, taking into account their size and risk profile. Article 2 Definitions
5. The terms and definitions used in this Regulation shall have the same meaning as in Law No. 10/L￾026 on Payment Services and Article 3 of the Law No. 08/L-304 on Banks.
6. In addition to paragraph 1 of this Article, for the purpose of implementing this Regulation, the following terms and abbreviations shall have the following meanings: 2.1. “CBK” means the Central Bank of the Republic of Kosovo;

2 of 22 2.2. “financial institution” means a bank, a microfinance institution, a non-bank financial institution, a PSP referred to in subparagraphs 1.4, 1.5 and 1.6 of Article 1 of the Law on Payment Services, a payment institution or an electronic money institution, subject to this Regulation pursuant to this Article; 2.3. “ICT” means information and communication technologies, as defined in Law No. 04/L-145 on Information Society Government Bodies; 2.4. ICT and security risks address the operational and security risks defined in Article 95 of Law No. 10/L-026 on Payment Services for the provision of payment services. 2.5. “ICT and security risk” means risk of loss due to breach of confidentiality, failure of integrity of systems and data, inappropriateness or unavailability of systems and data or inability to change information and communication technology within a reasonable time and with reasonable costs when the environment or business requirements change (i.e. agility). This includes security risks resulting from inadequate or failed internal processes or external events including cyber-attacks or inadequate physical security; 2.6. “management body” means: 2.6.1. for banks, microfinance institutions and non-bank financial institutions, this terms as the same meaning as in Article 36, of the Law No. 08/L-304 on Banks, or, where applicable, Article 96 of Law No. 04/L-093 on Banks, Microfinance Institutions and Non-Bank Financial Institutions; 2.6.2. for payment institutions or electronic money institutions, this term means directors or persons responsible for the management of the payment institutions and electronic money institutions and, where relevant, persons responsible for the management of the payment services activities of the payment institutions and electronic money institutions; 2.6.3. for PSPs referred to in subparagraphs 1.4, 1.5 and 1.6 of Article 1 of the Law on Payment Services, this term has the meaning conferred to it by the applicable law. 2.7. “operational or security incident” means a singular event or a series of linked events unplanned by the financial institution that has or will probably have an adverse impact on the integrity, availability, confidentiality and/or authenticity of services; 2.8. “PSP” means a payment service provider. In the context of this Regulation, unless otherwise specified or evident from the surrounding text, the term refers to payment institutions and electronic money institutions authorized or exempted from authorization under the Law on Payment Services; 2.9. “senior management” means: 2.9.1. for banks, microfinance institutions and non-bank financial institutions, this term has the same meaning as the definition in Article 47, of the Law No. 08/L-304 of Banks, or, where applicable, Article 96 of Law No. 04/L-093 on Banks, Microfinance Institutions and Non-Bank Financial Institutions. 2.9.2. for payment institutions and electronic money institutions, this term means natural persons who exercise executive functions within an institution and who are

3 of 22 responsible, and accountable to the management body, for the day-to-day management of the institution; 2.9.3. for PSPs referred to in subparagraphs 1.4, 1.5 and 1.6 of Article 1 of the Law on Payment Services, this term has the meaning conferred to it by the applicable law. 2.10. “risk appetite” means the aggregate level and types of risk that the financial institutions are willing to assume within their risk capacity, in line with their business model, to achieve their strategic objectives; 2.11. “audit function” means: 2.11.1. for banks, microfinance institutions and non-bank financial institutions, the audit function is as referred to in Article 49, of the Law No. 08/L-304 of Banks. 2.11.2. for PSPs other than banks, the audit function must be independent within or from the PSP and may be an internal and/or an external audit function. 2.12. “ICT projects” means any project, or part thereof, where ICT systems and services are changed, replaced, dismissed or implemented. ICT projects can be part of wider ICT or business transformation programmes; 2.13. “third party” means an organisation that has entered into business relationships or contracts with an entity to provide a product or service; 2.14. “information asset” means a collection of information, either tangible or intangible, that is worth protecting; 2.15. “ICT asset” means an asset of either software or hardware that is found in the business environment; 2.16. “ICT systems” means ICT set-up as part of a mechanism or an interconnecting network that supports the operations of a financial institution; 2.17. “ICT services” means services provided by ICT systems to one or more internal or external users. Examples include data entry, data storage, data processing and reporting services, but also monitoring, and business and decision support services; 2.18. “Law on Payment Services” means Law No. 10/L-026 on Payment Services; 2.19. “PSU” means a payment service user as defined in the Law on Payment Services. Article 3 Proportionality All financial institutions should comply with the provisions set out in this Regulation in such a way that is proportionate to, and takes account of, the financial institutions’ size, their internal organization, and the nature, scope, complexity and riskiness of the services and products that the financial institutions provide or intend to provide.

4 of 22 CHAPTER II ICT AND SECURITY RISK MANAGEMENT Governance and Strategy Article 4 Governance

1. The management body should ensure that financial institutions have adequate internal governance and internal control framework in place for their ICT and security risks. 1.1. the management body should set clear roles and responsibilities for ICT functions, information security risk management, and business continuity, including those for the management body and its committees.
2. The management body should ensure that the quantity and skills of financial institutions’ staff is adequate to support their ICT operational needs and their ICT and security risk management processes on an ongoing basis and to ensure the implementation of their ICT strategy. 2.1. the management body should ensure that the allocated budget is appropriate to fulfil the above. Furthermore, financial institutions should ensure that all staff members, including key function holders, receive appropriate training on ICT and security risks, including on information security, on an annual basis, or more frequently if required.
3. The management body has overall accountability for setting, approving and overseeing the implementation of financial institutions’ ICT strategy as part of their overall business strategy as well as for the establishment of an effective risk management framework for ICT and security risks for ensuring compliance to applicable legislation. Article 5 Strategy
4. The ICT strategy should be aligned with financial institutions’ overall business strategy and should at least the following: 1.1. how financial institutions’ ICT should evolve to effectively support and participate in their business strategy, including the evolution of the organisational structure, ICT system changes and key dependencies with third parties; 1.2. the planned strategy and evolution of the architecture of ICT, including third party dependencies; 1.3. clear information security objectives, focusing on ICT systems and ICT services, staff and processes.
5. Financial institutions should establish sets of action plans that contain measures to be taken to achieve the objective of the ICT strategy. 2.1. these should be communicated to all relevant staff (including contractors and third-party providers where applicable and relevant);

5 of 22 2.2. the action plans should be periodically reviewed to ensure their relevance and appropriateness; 2.3. financial institutions should also establish processes to monitor and measure the effectiveness of the implementation of their ICT strategy. Article 6 Use of third-party providers

1. Subject to the CBK Regulations on outsourcing arrangements and Article 21 of the Law on Payment Services, financial institutions should ensure the effectiveness of the risk-mitigating measures as defined by their risk management framework, including the requirements set out in this Regulation, when operational functions of payment services and/or ICT services and ICT systems of any activity are outsourced, including to group entities, or when using third parties.
2. To ensure continuity of ICT services and ICT systems, and without prejudice to other applicable requirements pursuant to CBK Regulation on outsourcing arrangements, financial institutions should ensure that contracts and service level agreements (both for normal circumstances as well as in the event of service disruption — see also Article 28 of this Regulation) with providers (outsourcing providers, group entities, or third-party providers) include the following: 2.1. appropriate and proportionate information security-related objectives and measures including requirements such as minimum cybersecurity requirements; specifications of the financial institution’s data life cycle; any requirements regarding data encryption, network security and security monitoring processes, and the location of data centers; 2.2. operational and security incident handling procedures including escalation and reporting.
3. Financial institutions should monitor and seek assurance on the level of compliance of these providers with the security objectives, measures and performance targets of the financial institution. CHAPTER III ICT AND SECURITY RISK MANAGEMENT FRAMEWORK Article 7 Organization and objectives
4. Financial institutions should identify and manage their ICT and security risks. The ICT function(s) in charge of ICT systems, processes and security operations should have appropriate processes and controls in place to ensure that all risks are identified, analyzed, measured, monitored, managed, reported and kept within the limits of the financial institution’s risk appetite and that the projects and systems they deliver and the activities they perform are in compliance with external and internal requirements.
5. Financial institutions should assign the responsibility for managing and overseeing ICT and security risks to a control function, adhering to the requirements of Article 9, paragraph 5 of CBK Regulation on corporate governance of banks. Financial institutions shall ensure the independence and objectivity of this control function by appropriately segregating it from ICT operational processes.

6 of 22 2.1. this control function should be directly accountable to the management body and responsible for monitoring and controlling adherence to the ICT and security risk management framework 2.2. it should ensure that ICT and security risks are identified, measured, assessed, managed, monitored and reported 2.3. financial institutions should ensure that this control function is not responsible for any internal audit. 3. The internal audit function should, following a risk-based approach, have the capacity to independently review and provide objective assurance of the compliance of all ICT and security related activities and units of a financial institution with the financial institution’s policies and procedures and with external requirements, adhering to the requirements of Article 17 on CBK Regulation on Internal Governance. 4. Financial institutions should define and assign key roles and responsibilities, and relevant reporting lines, for the ICT and security risk management framework to be effective. This framework should be fully integrated into, and aligned with, financial institutions’ overall risk management processes. 5. The ICT and security risk management framework should include at least the following processes: 5.1. determine the risk appetite for ICT and security risks, in accordance with the risk appetite of the financial institution; 5.2. identify and assess the ICT and security risks to which a financial institution is exposed; 5.3. define mitigation measures, including controls, to mitigate ICT and security risks; 5.4. monitor the effectiveness of these measures as well as the number of reported incidents, including for PSPs the incidents reported in accordance with Article 96 of the Law on Payment Services affecting the ICT-related activities, and take action to correct the measures where necessary; 5.5. report to the management body on the ICT and security risks and controls; 5.6. identify and assess whether there are any ICT and security risks resulting from any major change in ICT system or ICT services, processes or procedures, and/or after any significant operational or security incident. 6. Financial institutions should ensure that the ICT and security risk management framework is documented, and continuously improved, based on ‘lessons learned’ during its implementation and monitoring. 6.1. the ICT and security risk management framework should be approved and reviewed, at least once a year, by the management body. Article 8 Identification of functions, processes and assets

1. Financial institutions should identify, establish and maintain updated mapping of their business functions, roles and supporting processes to identify the importance of each and their interdependencies related to ICT and security risks.

7 of 22 2. In addition, financial institutions should identify, establish and maintain updated mapping of the information assets supporting their business functions and supporting processes, such as ICT systems, staff, contractors, third parties and dependencies on other internal and external systems and processes, to be able to, at least, manage the information assets that support their critical business functions and processes. Article 9 Classification and risk assessment

1. Financial institutions should classify the identified business functions, supporting processes and information assets referred to this Article in terms of criticality.
2. To define the criticality of these identified business functions, supporting processes and information assets, financial institutions should, at a minimum, consider the confidentiality, integrity and availability requirements. There should be clearly assigned accountability and responsibility for the information assets.
3. Financial institutions should review the adequacy of the classification of the information assets and relevant documentation, when risk assessment is performed.
4. Financial institutions should identify the ICT and security risks that impact the identified and classified business functions, supporting processes and information assets, according to their criticality. 4.1. this risk assessment should be carried out and documented annually or at shorter intervals if required; 4.2. such risk assessments should also be performed on any major changes in infrastructure, processes or procedures affecting the business functions, supporting processes or information assets, and consequently the current risk assessment of financial institutions should be updated.
5. Financial institutions should ensure that they continuously monitor threats and vulnerabilities relevant to their business processes, supporting functions and information assets and should regularly review the risk scenarios impacting them. Article 10 Risk mitigation
6. Based on the risk assessments, financial institutions should determine which measures are required to mitigate identified ICT and security risks to acceptable levels and whether changes are necessary to the existing business processes, control measures, ICT systems and ICT services. 1.1. a financial institution should consider the time required to implement these changes and the time to take appropriate interim mitigating measures to minimise ICT and security risks to stay within the financial institution’s ICT and security risk appetite.
7. Financial institutions should define and implement measures to mitigate identified ICT and security risks and to protect information assets in accordance with their classification.

8 of 22 Article 11 Reporting Financial institutions should report risk assessment results to the management body in a clear and timely manner. Such reporting is without prejudice to the obligation of PSPs to provide the CBK with an updated and comprehensive risk assessment, as laid down in Article 95 paragraph 2 of the Law on Payment Services. Article 12 Audit

1. A financial institution’s governance, systems and processes for its ICT and security risks should be audited on a periodic basis by auditors with sufficient knowledge, capabilities and competences in ICT and security risks and in payments (for PSPs) to provide independent assurance of their effectiveness to the management body. 1.1. the auditors should be independent within or from the financial institution; 1.2. the frequency and focus of such audits should be commensurate with the relevant ICT and security risks.
2. A financial institution’s management body should approve the annual audit plan, including any ICT audits and any material modifications thereto. 2.1. the audit plan and its execution, including the audit frequency, should reflect and be proportionate to the inherent ICT and security risks in the financial institution and should be updated regularly.
3. A formal follow-up process including provisions for the timely verification and remediation of critical ICT audit findings should be established. CHAPTER IV INFORMATION SECURITY Article 13 Information security policy
4. Financial institutions should develop and document an information security policy that should define the high-level principles and rules to protect the confidentiality, integrity and availability of financial institutions’ and their customers’ data and information. 1.1. for PSPs this policy is identified in the security policy document to be adopted in accordance with Article 12 subparagraph 1.10 of the Law on Payment Services; 1.2. the information security policy should be in line with the financial institution’s information security objectives and based on the relevant results of the risk assessment process 1.3. the policy should be approved by the management body.
5. The policy should include a description of the main roles and responsibilities of information security management, and it should set out the requirements for staff and contractors, processes

9 of 22 and technology in relation to information security, recognising that staff and contractors at all levels have responsibilities in ensuring financial institutions’ information security. 2.1. the policy should ensure the confidentiality, integrity and availability of a financial institution’s critical logical and physical assets, resources and sensitive data whether at rest, in transit or in use; 2.2. the information security policy should be communicated to all staff and contractors of the financial institution. 3. Based on the information security policy, financial institutions should establish and implement security measures to mitigate the ICT and security risks that they are exposed to. These measures should include: 3.1. organization and governance in accordance with paragraphs 1, 2 and 3 of Article 8 of this Regulation; 3.2. logical security (Article 14 of this Regulation); 3.3. physical security (Article 15 of this Regulation); 3.4. ICT operations security (Article 16 of this Regulation); 3.5. security monitoring (Article 17 of this Regulation); 3.6. information security reviews, assessment and testing (Article 18 of this Regulation); 3.7. information security training and awareness (Article 19 of this Regulation). Article 14 Logical security

1. Financial institutions should define, document and implement policies and procedures for logical access control (identity and access management). 1.1. these procedures should be implemented, enforced, monitored and periodically reviewed. 1.2. the procedures should also include controls for monitoring anomalies 1.3. these procedures should, at a minimum, implement the following elements, where the term ‘user’ also includes technical users: 1.3.1. need to know, least privilege and segregation of duties: financial institutions should manage access rights to information assets and their supporting systems on a “need￾to-know” basis, including for remote access. Users should be granted minimum access rights that are strictly required to execute their duties (principle of “least privilege”), i.e. to prevent unjustified access to a large set of data or to prevent the allocation of combinations of access rights that may be used to circumvent controls (principle of “segregation of duties”); 1.3.2. user accountability: financial institutions should limit, as much as possible, the use of generic and shared user accounts and ensure that users can be identified for the actions performed in the ICT systems; 1.3.3. privileged access rights: financial institutions should implement strong controls over privileged system access by strictly limiting and closely supervising accounts with

10 of 22 elevated system access entitlements (e.g. administrator accounts). In order to ensure secure communication and reduce risk, remote administrative access to critical ICT systems should be granted only on a need-to-know basis and when strong authentication solutions are used; 1.3.4. logging of user activities: at a minimum, all activities by privileged users should be logged and monitored. Access logs should be secured to prevent unauthorized modification or deletion and retained for a period commensurate with the criticality of the identified business functions, supporting processes and information assets, in accordance with Article 10, without prejudice to the retention requirements set out in other applicable law or regulation. A financial institution should use this information to facilitate the identification and investigation of anomalous activities that have been detected in the provision of services; 1.3.5. access management: access rights should be granted, withdrawn or modified in a timely manner, according to predefined approval workflows that involve the business owner of the information being accessed (information asset owner). In the case of termination of employment, access rights should be promptly withdrawn; 1.3.6. access recertification: access rights should be periodically reviewed to ensure that users do not possess excessive privileges and that access rights are withdrawn when no longer required; 1.3.7. authentication methods: financial institutions should enforce authentication methods that are sufficiently robust to adequately and effectively ensure that access control policies and procedures are complied with. Authentication methods should be commensurate with the criticality of ICT systems, information or the process being accessed. This should, at a minimum, include complex passwords or stronger authentication methods (such as two-factor authentication), based on relevant risk. 2. Electronic access by applications to data and ICT systems should be limited to a minimum required to provide the relevant service. Article 15 Physical security

1. Financial institutions’ physical security measures should be defined, documented and implemented to protect their premises, data centres and sensitive areas from unauthorised access and from environmental hazards.
2. Physical access to ICT systems should be permitted to only authorised individuals. 2.1. authorisation should be assigned in accordance with the individual’s tasks and responsibilities and limited to individuals who are appropriately trained and monitored 2.2. physical access should be regularly reviewed to ensure that unnecessary access rights are promptly revoked when not required.
3. Adequate measures to protect from environmental hazards should be commensurate with the importance of the buildings and the criticality of the operations or ICT systems located in these buildings.

11 of 22 Article 16 ICT operations security

1. Financial institutions should implement procedures to prevent the occurrence of security issues in ICT systems and ICT services and should minimise their impact on ICT service delivery. These procedures should include the following measures: 1.1. identification of potential vulnerabilities, which should be evaluated and remediated by ensuring that software and firmware are up to date, including the software provided by financial institutions to their internal and external users, by deploying critical security patches or by implementing compensating controls; 1.2. implementation of secure configuration baselines of all network components; 1.3. implementation of network segmentation, data loss prevention systems and the encryption of network traffic (in accordance with the data classification); 1.4. implementation of protection of endpoints including servers, workstations and mobile devices; financial institutions should evaluate whether endpoints meet the security standards defined by them before they are granted access to the corporate network; 1.5. ensuring that mechanisms are in place to verify the integrity of software, firmware and data; 1.6. encryption of data at rest and in transit (in accordance with the data classification).
2. Furthermore, on an ongoing basis, financial institutions should determine whether changes in the existing operational environment influence the existing security measures or require adoption of additional measures to mitigate related risks appropriately. 2.1. these changes should be part of the financial institutions’ formal change management process, which should ensure that changes are properly planned, tested, documented, authorised and deployed. Article 17 Security monitoring
3. Financial institutions should establish and implement policies and procedures to monitor and detect anomalous activities that may impact financial institutions’ information security and to respond to these events appropriately. 1.1. as part of this continuous monitoring, financial institutions should implement appropriate and effective capabilities for detecting and reporting physical or logical intrusion as well as breaches of confidentiality, integrity and availability of the information assets; 1.2. the continuous monitoring and detection processes should cover: 1.2.1. relevant internal and external factors, including business and ICT administrative functions; 1.2.2. transactions to detect misuse of access by third parties or other entities and internal misuse of access; 1.2.3. potential internal and external threats.

12 of 22 2. Financial institutions should establish and implement processes and organisation structures to identify and constantly monitor security threats that could materially affect their abilities to provide services. 2.1. financial institutions should actively monitor technological developments to ensure that they are aware of security risks 2.2. financial institutions should implement detective measures, for instance to identify possible information leakages, malicious code and other security threats, and publicly known vulnerabilities in software and hardware and should check for corresponding new security updates. 3. The security monitoring process should also help a financial institution to understand the nature of operational or security incidents, to identify trends and to support the organisation’s investigations. Article 18 Information security reviews, assessment and testing

1. Financial institutions should perform a variety of information security reviews, assessments and testing to ensure the effective identification of vulnerabilities in their ICT systems and ICT services, as follows: 1.1. financial institutions may perform gap analysis against information security standards, compliance reviews, internal and external audits of the information systems, or physical security reviews 1.2. the financial institution should consider good practices such as source code reviews, vulnerability assessments, penetration tests and red team exercises.
2. Financial institutions should establish and implement an information security testing framework that validates the robustness and effectiveness of their information security measures and ensure that this framework considers threats and vulnerabilities, identified through threat monitoring and ICT and security risk assessment process.
3. The information security testing framework should ensure that tests: 3.1. are carried out by independent testers with sufficient knowledge, skills and expertise in testing information security measures and who are not involved in the development of the information security measures; 3.2. include vulnerability scans and penetration tests (including threat-led penetration testing where necessary and appropriate) commensurate to the level of risk identified with the business processes and systems.
4. Financial institutions should perform ongoing and repeated tests of the security measures. 4.1. for all critical ICT systems (Article 10 paragraph 1 of this Regulation), these tests should be performed at least on an annual basis and, for PSPs, they will be part of the comprehensive assessment of the security risks related to the payment services they provide, in accordance with Article 95 paragraph 2 of the Law on Payment Services;

13 of 22 4.2. noncritical systems should be tested regularly using a risk-based approach, but at least every 3 years. 5. Financial institutions should ensure that tests of security measures are conducted in the event of changes to infrastructure, processes or procedures and if changes are made because of major operational or security incidents or due to the release of new or significantly changed internet￾facing critical applications. 6. Financial institutions should monitor and evaluate the results of the security tests and update their security measures accordingly without undue delays in the case of critical ICT systems. 7. For PSPs, the testing framework should also encompass the security measures relevant to: (i) payment terminals and devices used for the provision of payment services, (ii) payment terminals and devices used for authenticating the PSUs, and (iii) devices and software provided by the PSP to the PSU to generate/receive an authentication code. 8. Based on the security threats observed and the changes made, testing should be performed to incorporate scenarios of relevant and known potential attacks. Article 19 Information security training and awareness

1. Financial institutions should establish a training programme, including periodic security awareness programmes, for all staff and contractors to ensure that they are trained to perform their duties and responsibilities consistent with the relevant security policies and procedures to reduce human error, theft, fraud, misuse or loss and how to address information securityrelated risks. 1.1. financial institutions should ensure that the training programme provides training for all staff members and contractors at least annually. CHAPTER V ICT OPERATIONS MANAGEMENT Article 20 ICT operations management
2. Financial institutions should manage their ICT operations based on documented and implemented processes and procedures (which, for PSPs, include the security policy document in accordance with subparagraph 1.10 of Article 12 of the Law on Payment Services) that are approved by the management body. 1.1. The policies and procedures referred to in paragraph 1 of this Article should define how financial institutions operate, monitor and control their ICT systems and services, including the documenting of critical ICT operations and should enable financial institutions to maintain up-to-date ICT asset inventory.
3. Financial institutions should ensure that performance of their ICT operations is aligned to their business requirements.

14 of 22 2.1. financial institutions should maintain and improve, when possible, efficiency of their ICT operations, including but not limited to the need to consider how to minimise potential errors arising from the execution of manual tasks. 3. Financial institutions should implement logging and monitoring procedures for critical ICT operations to allow the detection, analysis and correction of errors. 4. Financial institutions should maintain an up-to-date inventory of their ICT assets (including ICT systems, network devices, databases, etc.). 4.1. the ICT asset inventory should store the configuration of the ICT assets and the links and interdependencies between the different ICT assets, to enable a proper configuration and change management process. 5. The ICT asset inventory should be sufficiently detailed to enable the prompt identification of an ICT asset, its location, security classification and ownership. Interdependencies between assets should be documented to help in the response to security and operational incidents, including cyber-attacks. 6. Financial institutions should monitor and manage the life cycles of ICT assets, to ensure that they continue to meet and support business and risk management requirements. 6.1. financial institutions should monitor whether their ICT assets are supported by their external or internal vendors and developers and whether all relevant patches and upgrades are applied based on documented processes. 6.2. the risks stemming from outdated or unsupported ICT assets should be assessed and mitigated. 7. Financial institutions should implement performance and capacity planning and monitoring processes to prevent, detect and respond to important performance issues of ICT systems and ICT capacity shortages in a timely manner. 8. Financial institutions should define and implement data and ICT systems backup and restoration procedures to ensure that they can be recovered as required. 8.1. the scope and frequency of backups should be set out in line with business recovery requirements and the criticality of the data and the ICT systems and evaluated according to the performed risk assessment; 8.2. testing of the backup and restoration procedures should be undertaken on a periodic basis. 9. Financial institutions should ensure that data and ICT system backups are stored securely and are sufficiently remote from the primary site so they are not exposed to the same risks. Article 21 ICT incident and problem management

1. Financial institutions should establish and implement an incident and problem management process to monitor and log operational and security ICT incidents and to enable financial institutions to continue or resume, in a timely manner, critical business functions and processes when disruptions occur.

15 of 22 1.1. financial institutions should determine appropriate criteria and thresholds for classifying events as operational or security incidents, as defined in Article 3, as well as early warning indicators that should serve as alerts to enable early detection of these incidents; 1.2. such criteria and thresholds, for PSPs, are without prejudice to the classification of major incidents in accordance with Article 96 of the Law on Payment Services and the CBK Regulation on major incident reporting. 2. To minimize the impact of adverse events and enable timely recovery, financial institutions should establish appropriate processes and organizational structures to ensure a consistent and integrated monitoring, handling and follow-up of operational and security incidents and to make sure that the root causes are identified and eliminated to prevent the occurrence of repeated incidents. The incident and problem management process should establish: 2.1. the procedures to identify, track, log, categorize and classify incidents according to a priority, based on business criticality; 2.2. the roles and responsibilities for different incident scenarios (e.g. errors, malfunctioning, cyber-attacks); 2.3. problem management procedures to identify, analyze and solve the root cause behind one or more incidents — a financial institution should analyze operational or security incidents likely to affect the financial institution that have been identified or have occurred within and/or outside the organization and should consider key lessons learned from these analyses and update the security measures accordingly; 2.4. effective internal communication plans, including incident notification and escalation procedures — also covering security-related customer complaints — to ensure that: 2.4.1. incidents with a potentially high adverse impact on critical ICT systems and ICT services are reported to the relevant senior management and ICT senior management; 2.4.2. the management body is informed on an ad hoc basis in the event of significant incidents and, at least, informed of the impact, the response and the additional controls to be defined as a result of the incidents. 2.5. incident response procedures to mitigate the impacts related to the incidents and to ensure that the service becomes operational and secure in a timely manner; 2.6. specific external communication plans for critical business functions and processes in order to: 2.6.1. collaborate with relevant stakeholders to effectively respond to and recover from the incident; 2.6.2. provide timely information to external parties (e.g. customers, other market participants, the supervisory authority) as appropriate and in line with an applicable regulation.

16 of 22 CHAPTER VI ICT PROJECT AND CHANGE MANAGEMENT Article 22 ICT project management

1. A financial institution should implement a programme and/or a project governance process that defines roles, responsibilities and accountabilities to effectively support the implementation of the ICT strategy.
2. A financial institution should appropriately monitor and mitigate risks deriving from their portfolio of ICT projects (programme management), considering also risks that may result from interdependencies between different projects and from dependencies of multiple projects on the same resources and/or expertise.
3. A financial institution should establish and implement an ICT project management policy that includes as a minimum: 3.1. project objectives; 3.2. roles and responsibilities; 3.3. a project risk assessment; 3.4. a project plan, timeframe and steps; 3.5. key milestones; 3.6. change management requirements.
4. The ICT project management policy should ensure that information security requirements are analyzed and approved by a function that is independent from the development function.
5. A financial institution should ensure that all areas impacted by an ICT project are represented in the project team and that the project team has the knowledge required to ensure secure and successful project implementation.
6. The establishment and progress of ICT projects and their associated risks should be reported to the management body, individually or in aggregation, depending on the importance and size of the ICT projects, regularly and on an ad hoc basis as appropriate. 6.1. financial institutions should include project risk in their risk management framework. Article 23 ICT systems acquisition and development
7. Financial institutions should develop and implement a process governing the acquisition, development and maintenance of ICT systems, designed using a riskbased approach.
8. A financial institution should ensure that, before any acquisition or development of ICT systems takes place, the functional and non-functional requirements (including information security requirements) are clearly defined and approved by the relevant business management.

17 of 22 3. A financial institution should ensure that measures are in place to mitigate the risk of unintentional alteration or intentional manipulation of the ICT systems during development and implementation in the production environment. 4. Financial institutions should have a methodology in place for testing and approval of ICT systems prior to their first use. 4.1. this methodology should consider the criticality of business processes and assets; 4.2. the testing should ensure that new ICT systems perform as intended; 4.3. they should also use test environments that adequately reflect the production environment. 5. Financial institutions should test ICT systems, ICT services and information security measures to identify potential security weaknesses, violations and incidents. 6. A financial institution should implement separate ICT environments to ensure adequate segregation of duties and to mitigate the impact of unverified changes to production systems. 6.1. specifically, a financial institution should ensure the segregation of production environments from development, testing and other non-production environments; 6.2. a financial institution should ensure the integrity and confidentiality of production data in non￾production environments. Access to production data is restricted to authorised users. 7. Financial institutions should implement measures to protect the integrity of the source codes of ICT systems that are developed in-house. 7.1. financial institutions should also document the development, implementation, operation and/or configuration of the ICT systems comprehensively to reduce any unnecessary dependency on subject matter experts; 7.2. the documentation of the ICT system should contain, where applicable, at least user documentation, technical system documentation and operating procedures. 8. A financial institution’s processes for acquisition and development of ICT systems should also apply to ICT systems developed or managed by the business function’s end users outside the ICT organisation (e.g. end user computing applications) using a risk-based approach. 8.1. the financial institution should maintain a register of these applications that support critical business functions or processes. Article 24 ICT change management

1. Financial institutions should establish and implement an ICT change management process to ensure that all changes to ICT systems are recorded, tested, assessed, approved, implemented and verified in a controlled manner and in accordance with policies and procedures in place. 1.1. financial institutions should handle the changes during emergencies (i.e. changes that must be introduced as soon as possible) following procedures that provide adequate safeguards.
2. Financial institutions should determine whether changes in the existing operational environment influence the existing security measures or require the adoption of additional measures to mitigate

18 of 22 the risks involved. These changes should be in accordance with the financial institutions’ formal change management process. CHAPTER VII BUSINESS CONTINUITY MANAGEMENT Article 25 Business continuity management process Financial institutions should establish a sound business continuity management (BCM) process to maximize their abilities to provide services on an ongoing basis and to limit losses in the event of severe business disruption. Article 26 Business impact analysis

1. As part of sound business continuity management, financial institutions should conduct business impact analysis (BIA) by analyzing their exposure to severe business disruptions and assessing their potential impacts (including on confidentiality, integrity and availability), quantitatively and qualitatively, using internal and/or external data (e.g. third-party provider data relevant to a business process or publicly available data that may be relevant to the BIA) and scenario analysis. 1.1. the BIA should also consider the criticality of the identified and classified business functions, supporting processes, third parties and information assets, and their interdependencies, in accordance with Article 10.
2. Financial institutions should ensure that their ICT systems and ICT services are designed and aligned with their BIA, for example with redundancy of certain critical components to prevent disruptions caused by events impacting those components. Article 27 Business continuity planning
3. Based on their Business Impact Analysis - BIA, financial institutions should establish plans to ensure business continuity (business continuity plans, BCPs), which should be documented and approved by their management bodies. 1.1. the plans should specifically consider risks that could adversely impact ICT systems and ICT services; 1.2. the plans should support objectives to protect and, if necessary, re-establish the confidentiality, integrity and availability of their business functions, supporting processes and information assets 1.3. financial institutions should coordinate with relevant internal and external stakeholders, as appropriate, during the establishment of these plans.

19 of 22 2. Financial institutions should put BCPs in place to ensure that they can react appropriately to potential failure scenarios and that they are able to recover the operations of their critical business activities after disruptions within a recovery time objective (RTO, the maximum time within which a system or process must be restored after an incident) and a recovery point objective (RPO, the maximum time period during which it is acceptable for data to be lost in the event of an incident). 2.1. in cases of severe business disruption that trigger specific business continuity plans, financial institutions should prioritize business continuity actions using risk-based approach, which can be based on the risk assessments carried out under Article 10; 2.2. for PSPs this may include, for example, facilitating the further processing of critical transactions while remediation efforts continue. 3. A financial institution should consider a range of different scenarios in its BCP, including extreme but plausible ones to which it might be exposed, including a cyber-attack scenario, and it should assess the potential impact that such scenarios might have. 3.1. based on these scenarios, a financial institution should describe how the continuity of ICT systems and services, as well as the financial institution’s information security, are ensured. Article 28 Response and recovery plans

1. Based on the BIAs (paragraph 1 of Article 27 of this Regulation) and plausible scenarios (paragraph 3 of Article 27 of this Regulation), financial institutions should develop response and recovery plans. 1.1. these plans should specify what conditions may prompt activation of the plans and what actions should be taken to ensure the availability, continuity and recovery of, at least, financial institutions’ critical ICT systems and ICT services; 1.2. the response and recovery plans should aim to meet the recovery objectives of financial institutions’ operations.
2. The response and recovery plans should consider both short-term and long-term recovery options. The plans should: 2.1. focus on the recovery of the operations of critical business functions, supporting processes, information assets and their interdependencies to avoid adverse effects on the functioning of financial institutions and on the financial system, including on payment systems and on payment service users, and to ensure execution of pending payment transactions; 2.2. be documented and made available to the business and support units and readily accessible in the event of an emergency; 2.3. be updated in line with lessons learned from incidents, tests, new risks identified and threats, and changed recovery objectives and priorities.
3. The plans should also consider alternative options where recovery may not be feasible in the short term because of costs, risks, logistics or unforeseen circumstances.
4. Furthermore, as part of the response and recovery plans, a financial institution should consider and implement continuity measures to mitigate failures of third-party providers, which are of key

20 of 22 importance for a financial institution’s ICT service continuity (in line with the provisions of the CBK Regulations on outsourcing arrangements regarding business continuity plans). Article 29 Testing of plans

1. Financial institutions should test their BCPs periodically. In particular, they should ensure that the BCPs of their critical business functions, supporting processes, information assets and their interdependencies (including those provided by third parties, where applicable) are tested at least annually, in accordance with paragraph 3 of this Article.
2. BCPs should be updated at least annually, based on testing results, current threat intelligence and lessons learned from previous events. Any changes in recovery objectives (including RTOs and RPOs) and/or changes in business functions, supporting processes and information assets, should also be considered, where relevant, as a basis for updating the BCPs.
3. Financial institutions’ testing of their BCPs should demonstrate that they are able to sustain the viability of their businesses until critical operations are re-established. In particular they should: 3.1. include testing of an adequate set of severe but plausible scenarios including those considered for the development of the BCPs (as well as testing of services provided by third parties, where applicable); this should include the switch-over of critical business functions, supporting processes and information assets to the disaster recovery environment and demonstrating that they can be run in this way for a sufficiently representative period of time and that normal functioning can be restored afterwards; 3.2. be designed to challenge the assumptions on which BCPs rest, including governance arrangements and crisis communication plans; and 3.3. include procedures to verify the ability of their staff and contractors, ICT systems and ICT services to respond adequately to the scenarios defined in subparagraph 3.1 of this Article.
4. Test results should be documented and any identified deficiencies resulting from the tests should be analyzed, addressed and reported to the management body. Article 30 Crisis communications In the event of a disruption or emergency, and during the implementation of the BCPs, financial institutions should ensure that they have effective crisis communication measures in place so that all relevant internal and external stakeholders, including the CBK, and also relevant providers (outsourcing providers, group entities, or third-party providers) are informed in a timely and appropriate manner.

21 of 22 CHAPTER VIII PAYMENT SERVICE USER RELATIONSHIP MANAGEMENT Article 31 Payment service user relationship management

1. PSPs should establish and implement processes to enhance PSUs’ awareness of the security risks linked to the payment services by providing PSUs with assistance and guidance.
2. The assistance and guidance offered to PSUs should be updated in the light of new threats and vulnerabilities, and changes should be communicated to the PSU.
3. Where product functionality permits, PSPs should allow PSUs to disable specific payment functionalities related to the payment services offered by the PSP to the PSU.
4. Where, in accordance with Article 68 paragraph 1 of the Law on Payment Services, a PSP has agreed with the payer spending limits for payment transactions executed through specific payment instruments, the PSP should provide the payer with the option to adjust these limits up to the maximum agreed limit.
5. PSPs should provide PSUs with the option to receive alerts on initiated and/or failed attempts to initiate payment transactions, enabling them to detect fraudulent or malicious use of their accounts.
6. PSPs should keep PSUs informed about updates in security procedures that affect PSUs regarding the provision of payment services.
7. PSPs should provide PSUs with assistance on all questions, requests for support and notifications of anomalies or issues regarding security matters related to payment services. PSUs should be appropriately informed about how such assistance can be obtained. CHAPTER IX FINAL PROVISIONS Article 32 Transitional period Financial institutions subject to this Regulation are required to fully adapt their activities and operations to the provisions herein within 12 months following the date of entry into force as set forth in Article 34 of this regulation. Article 33 Enforcement, Improvement Measures and Penalties Any violation of the provisions of this Regulation shall be subject to corrective measures and administrative penalties and civil fines as set forth in Law No. 03/L-209 on the Central Bank of the Republic of Kosovo, as amended and supplemented by Law No. 05/L-150, Law No. 10/L-026 on Payment Services, and the Law No. 08/L-304 on Banks.

22 of 22 Article 34 Entry into force This Regulation shall enter into force 15 days from the date of its approval. Dr.sc. Bashkim Nurboja Chairperson of the Board of the Central Bank of the Republic of Kosovo