Guidelines on ICT and security risk management

FINAL REPORT

EBA Guidelines on ICT and security risk management

Contents

1. Executive summary 3 2. Background and rationale 6 3. Guidelines 8 4. Accompanying documents 30 4.1. Draft cost-benefit analysis/impact assessment 30 4.2. Feedback on the public consultation 34

1. Executive summary

The complexity of information and communication technology (ICT) and security risks is increasing and the frequency of ICT and security-related incidents (including cyber incidents) is rising, together with their potential significant adverse impact on financial institutions’ operational functioning. Moreover, due to the interconnectedness of financial institutions, ICT and security-related incidents risk causing potential systemic impacts. The EBA has responded to this by detailing how supervisors should cover ICT and security risks within supervision (EBA/GL/2017/05), by detailing how financial institutions should manage outsourcing (EBA/GL/2019/02) and by describing the expectations for ICT and security risk management for the financial institutions in these guidelines. These guidelines set out how financial institutions should manage the ICT and security risks that they are exposed to. In addition, this guidance aims to provide the financial institutions to which the guidelines apply with a better understanding of supervisory expectations for the management of ICT and security risks. These guidelines integrate and are built on the requirements set out in the ‘Guidelines on security measures for operational and security risks of payment services’ (hereafter ‘Guidelines on security measures’), which were published in December 2017 (EBA/GL/2017/17) and which have applied since January 2018 in fulfilment of the mandate in Article 95(3) of Directive 2015/2366/EU (PSD2). Those guidelines were addressed to payment service providers (PSPs), and only applied to their payment services; however, they were in fact relevant to a broader set of institutions. For that reason, these guidelines have been formulated to be addressed to a broader range of financial institutions under the EBA’s remit (namely to credit institutions which already fell within the scope of the guidelines on security measures for their payment services, but for which these guidelines will now apply for all activities) and to investment firms. These guidelines continue to apply to PSPs for the payment services they provide; they extend to other activities of credit institutions and also apply to investment firms for all activities. Collectively, the guidelines apply to financial institutions as set out in paragraph 9 under the addressees section. The term ‘ICT and security risks’ addresses the operational and security risks mandate of Article 95 of the revised Payments Services Directive (PSD2). This term recognises that the operational risks for payment services refer predominantly to ICT and security risks because of the electronic nature of payment services (over ICT systems). For this reason, these guidelines refer to ‘ICT and security risk’ instead of ‘operational and security risk’ to avoid confusion with wider operational risk issues, such as conduct risk, legal risk and reputational risk. Furthermore, security risks may stem from inadequate or failed internal processes or external events, but ultimately it is their impact on systems and data that is relevant. The definition of ‘ICT and security risk’ is based on the definition in the EBA Guidelines on the revised common procedures and methodologies for the supervisory review and evaluation process and supervisory stress testing (EBA/GL/2018/03); thus, it encompasses data integrity risk but includes additional details to clarify that it covers the impact deriving from security risks. These guidelines provide details on how financial institutions should comply in order to address ICT and security risks, with the following provisions in the Capital Requirements Directive (CRD) and PSD2: (i) Article 74 of Directive 2013/36/EU (CRD), which strengthens the governance requirements for institutions, including the requirements to have robust governance arrangements with a clear organisational structure with well-defined, transparent and consistent lines of responsibility and effective processes to identify, manage, monitor and report the risk they are or might be exposed to; (ii) Article 95 of Directive 2015/2366/EU (PSD2), which contains explicit provisions for the management of operation and security risks that require PSPs to have appropriate mitigation measures and control mechanisms to manage the operational and security risks and includes a mandate for the EBA to develop guidelines on this topic. These guidelines specify the above-mentioned requirements as follows: Section 3.1 sets out the proportionate application of these guidelines, recognising the potential variation in size, complexity, internal organisation, nature, scope and riskiness of the services and products between financial institutions. Section 3.2 of the guidelines focuses on the management and mitigation of ICT and security risks through establishing sound internal governance and an internal control framework that sets clear responsibilities for financial institutions’ staff, including for the management bodies. It requires the establishment of the financial institutions’ ICT strategy, which should be aligned with their overall business strategy. The guidelines also remind financial institutions to ensure the effectiveness of the risk-mitigating measures, as defined by their risk management framework, when outsourcing or using third party providers. This should be set out in contracts and service level agreements. Nevertheless, financial institutions should monitor and seek assurance of the level of compliance. Section 3.3 requires financial institutions to manage and mitigate ICT and security risks through an independent and objective control function, appropriately segregated from ICT operations processes and not responsible for any internal audit, and an independent internal audit function. It requires financial institutions to maintain updated mapping of their business functions, supporting processes and information assets and to classify them in terms of criticality, based on the confidentiality, integrity and availability of data. Based on this, financial institutions should assess the operational risks related to ICT and the security risks that impact them and should determine what measures are required to mitigate the identified risks. Section 3.4 sets out requirements for information security to the extent that the information is held on ICT systems. This section defines requirements to implement effective information security measures, including having an information security policy in place; establishing, implementing and testing information security measures; and establishing a training programme for all staff and contractors. Section 3.5 specifies high-level principles on how ICT operations should be managed, including requirements to improve, when possible, the efficiency of ICT operations; implement logging and monitoring procedures for critical ICT operations; maintain an up -to-date inventory of their ICT assets; monitor and manage the life cycle of ICT assets; and implement data and ICT systems backup and restoration procedures. Financial institutions should also establish and implement incident and problem management processes. Section 3.6 describes requirements for ICT project and change management, including the acquisition, development and maintenance of ICT systems and services. Financial institutions should ensure that changes to production systems are assessed, tested, approved and implemented in a controlled manner, with the aim of ensuring that ICT projects have appropriate governance and oversight and that the development of applications is carefully monitored from the test phase to the production phase. Section 3.7 specifies expectations with regard to business continuity management and developing response and recovery plans, including testing, and their consequent updating based on the test results. Financial institutions should ensure that they have effective crisis communication measures in place so that all relevant internal and external stakeholders can be informed in a timely manner. The ICT business continuity management processes are an integral part of the overall financial institution’s business continuity management process and should not be separated. The last section, Section 3.8, applies only to PSPs for their provision of payment services. It prescribes requirements for payment service users (PSUs) relationship management, including allowing PSUs to disable specific payment functionalities (where product functionality permits), receiving alerts on initiated and/or failed attempts to initiate payment transactions, and providing PSUs with assistance on questions and requests for support. The EBA stresses the importance of ensuring transparency, such that PSUs are always aware of which PSP is responsible for providing them with the payment service. In implementing these guidelines, financial institutions should refer to existing standards and leading best practices. These guidelines intend to be technology and methodology agnostic. The implementation of these guidelines should be done in accordance with the principle of proportionality, taking into account the scale and complexity of operations, the nature of the activity engaged in, the types of services provided and the corresponding ICT and security risks related to financial institutions’ processes and services. These guidelines complement and should be read in conjunction with the supervisory assessment to the applicable institutions in the EBA Guidelines on ICT risk assessment under the Supervisory Review and Evaluation Process (EBA/GL/2017/05), which are addressed to supervisors, as well as other relevant guidelines such as the EBA Guidelines on outsourcing arrangements (EBA/GL/2019/02).

Next steps

The EBA Guidelines on the security measures for operational and security risks of payment services under Directive (EU) 2015/2366 (PSD2) will be repealed after these guidelines come into force.

2.Background and rationale

1. ICT risks can pose significant adverse prudential risks, potentially compromising a financial institution’s viability. For this reason, ICT and security risk management is fundamental for a financial institution to achieve its strategic, corporate, operational and reputational objectives. 2. The scope of application of the guidelines covers PSPs for their payment services (any reference to ‘payment services’ includes ‘issuing of electronic money’), credit institutions for all activities beyond their payment services and also investment firms for all activities. Specifically, these guidelines are addressed to (1) PSPs as defined in Article 4(11) of PSD2; (2) to institutions, meaning credit institutions and investment firms as defined in point 3 of Article 4(1) of Regulation (EU) No 575/2013; and (3) to competent authorities, as defined in point 40 of Article 4(1) of Regulation (EU) No 575/2013, including the European Central Bank with regard to matters relating to the tasks conferred on it by Regulation (EU) No 1024/2013, and to competent authorities under PSD2, as referred to in point (i) of Article 4(2) of Regulation (EU) No 1093/2010. For the purpose of these guidelines, unless specified otherwise, the addressees in points 1 and 2 above are collectively referred to as ‘financial institutions’. 3. These guidelines integrate the ‘Guidelines on security measures for operational and security risks of payment services’ under Article 95 of PSD2, which were published in December 2017 (EBA/GL/2017/17), and elaborate further on certain topics that contribute to mitigating ICT and security risks in financial institutions. These guidelines therefore contribute to a level playing field for all financial institutions. The guidelines also address the European Commission (the Commission) request set out in the Commission’s financial technology (FinTech) action plan published in March 2018, which requests that European Supervisory Authorities develop guidelines on ICT risk management and mitigation requirements in the EU financial sector . 4. The guidelines address ICT and security risks that have increased in recent years. This is due to the increasing digitalisation of the financial sector and the increasing interconnectedness through telecommunications channels (internet, mobile and wireless lines, and wide area networks) and with other financial institutions and third parties. This renders financial institutions’ operations vulnerable to external security attacks, including cyber-attacks; therefore, recognising the need for preparedness for cybersecurity, these guidelines implicitly cover the need for cybersecurity within the financial institution’s information security measures. While these guidelines recognise that cybersecurity should be undertaken as part of a financial institution’s overall information security risk management, it is worthwhile pointing out that cyber-attacks have some specific characteristics that should be taken into account in ensuring that the information security measures are adequate to mitigate cyber risks: i) Unlike most other sources of risk, malicious cyber-attacks are often difficult to identify or fully eradicate, and the breadth of damage is difficult to determine. ii) Some cyber-attacks can render common risk management and business continuity arrangements ineffective (e.g. disaster recovery procedures), and they might in some instances fuel the spread of malware and corrupted data to backup systems. iii) Third party service providers, vendors and vendors’ products may become channels to propagate cyber-attacks; therefore, an interconnected financial institution that has individual low relevance may become vulnerable and a source of risk propagation. Observing the weakest link principle, cybersecurity should not only be a concern for major market participants and critical service providers. 5. The guidelines are compatible with the three lines of defence model, with the ICT operational units being the first line of defence. The guidelines focus in particular on the responsibilities of the management body and the second line of defence (which usually includes the information security function), and, following the public consultation, the structure of the guidelines has been revised to better reflect this focus. It is further clarified that cross-references to the EBA Guidelines on internal governance (EBA/GL/2017/11) are intended to incorporate in these guidelines governance requirements that are (objectively) valid for the purposes of these guidelines. For the avoidance of doubt, references do not change or expand the scope of application of the EBA Guidelines on internal governance. 6. The provisions of the ‘Guidelines on the security measures for operational and security risks of payment services’ (EBA/GL/2017/17) have been transposed and incorporated into these guidelines, with a wording that has been adapted to fit with the wider scope of addressees and with other provisions. As it was the case for the ‘Guidelines on the security measures for operational and security risks of payment services’, these guidelines should be applied in a manner that is proportionate to the nature, scope and complexity of the PSPs’ and institutions’ businesses and the corresponding ICT and security risks. The ‘Guidelines on the security measures for operational and security risks of payment services’ (EBA/GL/2017/17) will therefore be repealed with effect from the date of application of these guidelines, which replace them in their entirety.

3.Guidelines EBA Guidelines on ICT and security risk management Compliance and reporting obligations

Status of these guidelines

1. This document contains guidelines issued pursuant to Article 16 of Regulation (EU) No 1093/2010 . In accordance with Article 16(3) of Regulation (EU) No 1093/2010, competent authorities and financial institutions must make every effort to comply with the guidelines. 2. Guidelines set out the EBA’s view of appropriate supervisory practices within the European System of Financial Supervision or of how European Union law should be applied in a particular area. Competent authorities as defined in Article 4(2) of Regulation (EU) No 1093/2010 and to whom guidelines apply should comply by incorporating them into their practices as appropriate (e.g. by amending their legal framework or their supervisory processes), including where guidelines are directed primarily at institutions.

Reporting requirements

3. According to Article 16(3) of Regulation (EU) No 1093/2010, competent authorities must notify the EBA whether they comply or intend to comply with these guidelines, or otherwise, with reasons for non-compliance, by 04/05/2020. In the absence of any notification by this deadline, competent authorities will be considered by the EBA to be non-compliant. Notifications should be sent by submitting the form available on the EBA website to compliance@eba.europa.eu with the reference ‘EBA/GL/2019/04’. Notifications should be submitted by persons with appropriate authority to report compliance on behalf of their competent authorities. Any change in the status of compliance must also be reported to the EBA.

Subject matter, scope and definitions

Subject matter

5. These guidelines build on the provisions of Article 74 of Directive 2013/36/EU (CRD) regarding internal governance, and derive from the mandate to issue guidelines in Article 95(3) of Directive (EU) 2015/2366 (PSD2). 6. These guidelines specify the risk management measures that financial institutions (as defined in paragraph 9 below) must take in accordance with Article 74 of the CRD to manage their ICT and security risks for all activities and that payment service providers (PSPs as defined in paragraph 9 below) must take, in accordance with Article 95(1) of PSD2, to manage the operational and security risks (intended as ‘ICT and security risks’) relating to the payment services they provide. The guidelines include requirements for information security, including cybersecurity, to the extent that the information is held on ICT systems.

Scope of application

7. These guidelines apply in relation to the management of ICT and security risks within financial institutions (as defined in paragraph 9). For the purposes of these guidelines, the term ICT and security risks addresses the operational and security risks of Article 95 of PSD2 for the provision of payment services. 8. For PSPs (as defined in paragraph 9) these guidelines apply to their provision of payment services, in line with the scope and mandate of Article 95 of PSD2. For institutions (as defined in paragraph 9) these guidelines apply to all the activities that they provide.

Addressees

9. These guidelines are addressed to financial institutions, which for the purposes of these guidelines refers to (1) PSPs as defined in Article 4(11) of PSD2, and (2) to institutions, meaning credit institutions and investment firms as defined in point 3 of Article 4(1) of Regulation (EU) No 575/2013. The guidelines also apply to competent authorities as defined in point 40 of Article 4(1) of Regulation (EU) No 575/2013, including the European Central Bank with regard to matters relating to the tasks conferred on it by Regulation (EU) No 1024/2013, and to competent authorities under PSD2, as referred to in point (i) of Article 4(2) of Regulation (EU) No 1093/2010.

Definitions

10. Unless otherwise specified, terms used and defined in 2013/36/EU (CRD), Regulation (EU) No 575/2013 (CRR) and Directive (EU) 2015/2366 (PSD2) have the same meaning in the guidelines. In addition, for the purposes of these guidelines, the following definitions apply: ICT and security risk 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 technology (IT) 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. Management body (a) For credit institutions and investment firms, this term has the same meaning as the definition in point (7) of Article 3(1) of Directive 2013/36/EU. (b)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. (c) For PSPs referred to in points (c), (e) and (f) of Article 1(1) of Directive (EU) 2015/2366, this term has the meaning conferred on it by the applicable EU or national law. Operational or security A singular event or a series of linked events unplanned by the incident financial institution that has or will probably have an adverse impact on the integrity, availability, confidentiality and/or authenticity of services. Senior management (a) For credit institutions and investment firms, this term has the same meaning as the definition in point (9) of Article 3(1) of Directive 2013/36/EU. (b) For payment institutions and electronic money institutions, this term means natural persons who exercise executive functions within an institution and who are responsible, and accountable to the management body, for the day-to-day management of the institution. (c) For PSPs referred to in points (c), (e) and (f) of Article 1(1) of Directive (EU) 2015/2366, this term has the meaning conferred on it by the applicable EU or national law. Risk appetite The aggregate level and types of risk that the PSPs and institutions are willing to assume within their risk capacity, in line with their business model, to achieve their strategic objectives. Audit function (a) For credit institutions and investment firms, the audit function is as referred to in Section 22 of the EBA guidelines on internal governance (EBA/GL/2017/11). (b)For PSPs other than credit institutions, the audit function must be independent within or from the PSP and may be an internal and/or an external audit function. ICT projects 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. Third party An organisation that has entered into business relationships or contracts with an entity to provide a product or service . Information asset A collection of information, either tangible or intangible, that is worth protecting. ICT asset An asset of either software or hardware that is found in the business environment. ICT systems ICT set-up as part of a mechanism or an interconnecting network that supports the operations of a financial institution. ICT services 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.

Implementation

Date of application

11. These guidelines apply from 30 June 2020.

Repeal

12. The Guidelines on security measures for operational and security risks (EBA/GL/2017/17) issued in 2017 will be repealed by these guidelines at the date that these guidelines become applicable.

Guidelines on ICT and security risk management

3.1. Proportionality

1. All financial institutions should comply with the provisions set out in these guidelines in such a way that is proportionate to, and takes account of, the financial institutions’ size, their internal organisation, and the nature, scope, complexity and riskiness of the services and products that the financial institutions provide or intend to provide.

3.2. Governance and strategy

3.2.1. Governance

2. The management body should ensure that financial institutions have adequate internal governance and internal control framework in place for their ICT and security risks. 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. 3. 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. 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 (see also Section 3.4.7). 4. 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.

3.2.2. Strategy

5. The ICT strategy should be aligned with financial institutions’ overall business strategy and should define: a) 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; b) the planned strategy and evolution of the architecture of ICT, including third party dependencies; c) clear information security objectives, focusing on ICT systems and ICT services, staff and processes. 6. Financial institutions should establish sets of action plans that contain measures to be taken to achieve the objective of the ICT strategy. These should be communicated to all relevant staff (including contractors and third party providers where applicable and relevant). The action plans should be periodically reviewed to ensure their relevance and appropriateness. Financial institutions should also establish processes to monitor and measure the effectiveness of the implementation of their ICT strategy.

3.2.3. Use of third party providers

7. Without prejudice to the EBA Guidelines on outsourcing arrangements (EBA/GL/2019/02) and Article 19 of PSD2, financial institutions should ensure the effectiveness of the risk-mitigating measures as defined by their risk management framework, including the measures set out in these guidelines, 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. 8. To ensure continuity of ICT services and ICT systems, 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 Section 3.7.2) with providers (outsourcing providers, group entities, or third party providers) include the following: a) 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 centres; b) operational and security incident handling procedures including escalation and reporting. 9. 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.

3.3. ICT and security risk management framework

3.3.1. Organisation and objectives

10. 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, analysed, 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. 11. Financial institutions should assign the responsibility for managing and overseeing ICT and security risks to a control function, adhering to the requirements of Section 19 of the EBA Guidelines on internal governance (EBA/GL/2017/11). Financial institutions should ensure the independence and objectivity of this control function by appropriately segregating it from ICT operations processes. 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. It should ensure that ICT and security risks are identified, measured, assessed, managed, monitored and reported. Financial institutions should ensure that this control function is not responsible for any internal audit. 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 securityrelated activities and units of a financial institution with the financial institution’s policies and procedures and with external requirements, adhering to the requirements of Section 22 of the EBA Guidelines on internal governance (EBA/GL/2017/11). 12. 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. 13. The ICT and security risk management framework should include processes in place to: a) determine the risk appetite for ICT and security risks, in accordance with the risk appetite of the financial institution; b) identify and assess the ICT and security risks to which a financial institution is exposed; c) define mitigation measures, including controls, to mitigate ICT and security risks; d) 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 PSD2 affecting the ICT-related activities, and take action to correct the measures where necessary; e) report to the management body on the ICT and security risks and controls; f) 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. 14. 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. The ICT and security risk management framework should be approved and reviewed, at least once a year, by the management body.

3.3.2. Identification of functions, processes and assets

15. 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. 16. 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.

3.3.3. Classification and risk assessment

17. Financial institutions should classify the identified business functions, supporting processes and information assets referred to in paragraphs 15 and 16 in terms of criticality. 18. 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. 19. Financial institutions should review the adequacy of the classification of the information assets and relevant documentation, when risk assessment is performed. 20. 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. This risk assessment should be carried out and documented annually or at shorter intervals if required. 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. 21. 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.

3.3.4. Risk mitigation

22. 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. 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. 23. Financial institutions should define and implement measures to mitigate identified ICT and security risks and to protect information assets in accordance with their classification.

3.3.5. Reporting

24. 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 competent authorities with an updated and comprehensive risk assessment, as laid down in Article 95(2) of Directive (EU) 2015/2366.

3.3.6. Audit

25. 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, skills and expertise in ICT and security risks and in payments (for PSPs) to provide independent assurance of their effectiveness to the management body. The auditors should be independent within or from the financial institution. The frequency and focus of such audits should be commensurate with the relevant ICT and security risks. 26. A financial institution’s management body should approve the audit plan, including any ICT audits and any material modifications thereto. 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. 27. A formal follow-up process including provisions for the timely verification and remediation of critical ICT audit findings should be established.

3.4. Information security

3.4.1. Information security policy

28. 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. For PSPs this policy is identified in the security policy document to be adopted in accordance with Article 5(1)(j) of Directive (EU) 2015/2366. 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. The policy should be approved by the management body. 29. 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 and technology in relation to information security, recognising that staff and contractors at all levels have responsibilities in ensuring financial institutions’ information security. 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. The information security policy should be communicated to all staff and contractors of the financial institution. 30. 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: a) organisation and governance in accordance with paragraphs 10 and 11; b) logical security (Section 3.4.2); c) physical security (Section 3.4.3); d) ICT operations security (Section 3.4.4); e) security monitoring (Section 3.4.5); f) information security reviews, assessment and testing (Section 3.4.6); g) information security training and awareness (Section 3.4.7).

3.4.2. Logical security

31. Financial institutions should define, document and implement procedures for logical access control (identity and access management). These procedures should be implemented, enforced, monitored and periodically reviewed. The procedures should also include controls for monitoring anomalies. These procedures should, at a minimum, implement the following elements, where the term ‘user’ also includes technical users: (a) 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-toknow’ 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’). (b) 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. (c) Privileged access rights: financial institutions should implement strong controls over privileged system access by strictly limiting and closely supervising accounts with 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. (d) Logging of user activities: at a minimum, all activities by privileged users should be logged and monitored. Access logs should be secured to prevent unauthorised 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 Section 3.3.3, without prejudice to the retention requirements set out in EU and national law. 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. (e) 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. (f) 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. (g) 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. 32. Electronic access by applications to data and ICT systems should be limited to a minimum required to provide the relevant service.

3.4.3. Physical security

33. 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. 34. Physical access to ICT systems should be permitted to only authorised individuals. Authorisation should be assigned in accordance with the individual’s tasks and responsibilities and limited to individuals who are appropriately trained and monitored. Physical access should be regularly reviewed to ensure that unnecessary access rights are promptly revoked when not required. 35. 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.

3.4.4. ICT operations security

36. 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: a) 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; b) implementation of secure configuration baselines of all network components; c) implementation of network segmentation, data loss prevention systems and the encryption of network traffic (in accordance with the data classification); d) 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; e) ensuring that mechanisms are in place to verify the integrity of software, firmware and data; f) encryption of data at rest and in transit (in accordance with the data classification). 37. 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. 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.

3.4.5. Security monitoring

38. Financial institutions should establish and implement policies and procedures to detect anomalous activities that may impact financial institutions’ information security and to respond to these events appropriately. 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. The continuous monitoring and detection processes should cover: a) relevant internal and external factors, including business and ICT administrative functions; b) transactions to detect misuse of access by third parties or other entities and internal misuse of access; c) potential internal and external threats. 39. 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. Financial institutions should actively monitor technological developments to ensure that they are aware of security risks. 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. 40. 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.

3.4.6. Information security reviews, assessment and testing

41. 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. For instance, financial institutions may perform gap analysis against information security standards, compliance reviews, internal and external audits of the information systems, or physical security reviews. Furthermore, the institution should consider good practices such as source code reviews, vulnerability assessments, penetration tests and red team exercises. 42. 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. 43. The information security testing framework should ensure that tests: a) 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; b) 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. 44. Financial institutions should perform ongoing and repeated tests of the security measures. For all critical ICT systems (paragraph 17), 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(2) of PSD2. Noncritical systems should be tested regularly using a risk-based approach, but at least every 3 years. 45. 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. 46. 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. 47. For PSPs, the testing framework should also encompass the security measures relevant to (1) payment terminals and devices used for the provision of payment services, (2) payment terminals and devices used for authenticating the payment service users (PSU), and (3) devices and software provided by the PSP to the PSU to generate/receive an authentication code. 48. Based on the security threats observed and the changes made, testing should be performed to incorporate scenarios of relevant and known potential attacks.

3.4.7. Information security training and awareness

49. 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. Financial institutions should ensure that the training programme provides training for all staff members and contractors at least annually.

3.5. ICT operations management

50. 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 Article 5(1)(j) of PSD2) that are approved by the management body. This set of documents 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. 51. Financial institutions should ensure that performance of their ICT operations is aligned to their business requirements. 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. 52. Financial institutions should implement logging and monitoring procedures for critical ICT operations to allow the detection, analysis and correction of errors. 53. Financial institutions should maintain an up-to-date inventory of their ICT assets (including ICT systems, network devices, databases, etc.). 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. 54. 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. 55. 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. 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. The risks stemming from outdated or unsupported ICT assets should be assessed and mitigated. 56. 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. 57. Financial institutions should define and implement data and ICT systems backup and restoration procedures to ensure that they can be recovered as required. 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. Testing of the backup and restoration procedures should be undertaken on a periodic basis. 58. 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.

3.5.1 ICT incident and problem management

59. 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. Financial institutions should determine appropriate criteria and thresholds for classifying events as operational or security incidents, as set out in the ‘Definitions’ section of these guidelines, as well as early warning indicators that should serve as alerts to enable early detection of these incidents. Such criteria and thresholds, for PSPs, are without prejudice to the classification of major incidents in accordance with Article 96 of PSD2 and the Guidelines on major incident reporting under PSD2 (EBA/GL/2017/10). 60. To minimise the impact of adverse events and enable timely recovery, financial institutions should establish appropriate processes and organisational 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: a) the procedures to identify, track, log, categorise and classify incidents according to a priority, based on business criticality; b) the roles and responsibilities for different incident scenarios (e.g. errors, malfunctioning, cyber-attacks); c) problem management procedures to identify, analyse and solve the root cause behind one or more incidents — a financial institution should analyse operational or security incidents likely to affect the financial institution that have been identified or have occurred within and/or outside the organisation and should consider key lessons learned from these analyses and update the security measures accordingly; d) effective internal communication plans, including incident notification and escalation procedures — also covering security-related customer complaints — to ensure that: i) 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; ii) 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. e) 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; f) specific external communication plans for critical business functions and processes in order to: i) collaborate with relevant stakeholders to effectively respond to and recover from the incident; ii) provide timely information to external parties (e.g. customers, other market participants, the supervisory authority) as appropriate and in line with an applicable regulation.

3.6. ICT project and change management

3.6.1. ICT project management

61. 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. 62. 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. 63. A financial institution should establish and implement an ICT project management policy that includes as a minimum: a) project objectives; b) roles and responsibilities; c) a project risk assessment; d) a project plan, timeframe and steps; e) key milestones; f) change management requirements. 64. The ICT project management policy should ensure that information security requirements are analysed and approved by a function that is independent from the development function. 65. 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. 66. 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. Financial institutions should include project risk in their risk management framework.

3.6.2. ICT systems acquisition and development

67. Financial institutions should develop and implement a process governing the acquisition, development and maintenance of ICT systems. This process should be designed using a riskbased approach. 68. 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. 69. 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. 70. Financial institutions should have a methodology in place for testing and approval of ICT systems prior to their first use. This methodology should consider the criticality of business processes and assets. The testing should ensure that new ICT systems perform as intended. They should also use test environments that adequately reflect the production environment. 71. Financial institutions should test ICT systems, ICT services and information security measures to identify potential security weaknesses, violations and incidents. 72. 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. Specifically, a financial institution should ensure the segregation of production environments from development, testing and other non-production environments. 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. 73. Financial institutions should implement measures to protect the integrity of the source codes of ICT systems that are developed in-house. They should also document the development, implementation, operation and/or configuration of the ICT systems comprehensively to reduce any unnecessary dependency on subject matter experts. The documentation of the ICT system should contain, where applicable, at least user documentation, technical system documentation and operating procedures. 74. 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. The financial institution should maintain a register of these applications that support critical business functions or processes.

3.6.3. ICT change management

75. 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. 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. 76. 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 the risks involved. These changes should be in accordance with the financial institutions’ formal change management process.

3.7. Business continuity management

77. Financial institutions should establish a sound business continuity management (BCM) process to maximise their abilities to provide services on an ongoing basis and to limit losses in the event of severe business disruption in line with Article 85(2) of Directive 2013/36/EU and Title VI of the EBA Guidelines on internal governance (EBA/GL/2017/11).

3.7.1. Business impact analysis

78. As part of sound business continuity management, financial institutions should conduct business impact analysis (BIA) by analysing 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. 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 Section 3.3.3. 79. 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.

3.7.2. Business continuity planning

80. Based on their BIAs, financial institutions should establish plans to ensure business continuity (business continuity plans, BCPs), which should be documented and approved by their management bodies. The plans should specifically consider risks that could adversely impact ICT systems and ICT services. 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. Financial institutions should coordinate with relevant internal and external stakeholders, as appropriate, during the establishment of these plans. 81. 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). In cases of severe business disruption that trigger specific business continuity plans, financial institutions should prioritise business continuity actions using riskbased approach, which can be based on the risk assessments carried out under Section 3.3.3. For PSPs this may include, for example, facilitating the further processing of critical transactions while remediation efforts continue. 82. 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. 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.

3.7.3. Response and recovery plans

83. Based on the BIAs (paragraph 78) and plausible scenarios (paragraph 82), financial institutions should develop response and recovery plans. 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. The response and recovery plans should aim to meet the recovery objectives of financial institutions’ operations. 84. The response and recovery plans should consider both short-term and long-term recovery options. The plans should: a) 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; b) be documented and made available to the business and support units and readily accessible in the event of an emergency; c) be updated in line with lessons learned from incidents, tests, new risks identified and threats, and changed recovery objectives and priorities. 85. 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. 86. 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 importance for a financial institution’s ICT service continuity (in line with the provisions of the EBA Guidelines on outsourcing arrangements (EBA/GL/2019/02) regarding business continuity plans).

3.7.4. Testing of plans

87. 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 89. 88. 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. 89. 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: a) 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; b) be designed to challenge the assumptions on which BCPs rest, including governance arrangements and crisis communication plans; and c) include procedures to verify the ability of their staff and contractors, ICT systems and ICT services to respond adequately to the scenarios defined in paragraph 89(a). 90. Test results should be documented and any identified deficiencies resulting from the tests should be analysed, addressed and reported to the management body.

3.7.5. Crisis communications

91. 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 competent authorities when required by national regulations, and also relevant providers (outsourcing providers, group entities, or third party providers) are informed in a timely and appropriate manner.

3.8. Payment service user relationship management

92. 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. 93. 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. 94. 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. 95. Where, in accordance with Article 68(1) of Directive (EU) 2015/2366, 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. 96. 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. 97. PSPs should keep PSUs informed about updates in security procedures that affect PSUs regarding the provision of payment services. 98. 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.

4.Accompanying documents

4.1. Draft cost-benefit analysis/impact assessment

As per Article 16(2) of Regulation (EU) No 1093/2010 (EBA Regulation), any guidelines and recommendations developed by the EBA are to be accompanied by an impact assessment (IA), which analyses ‘the potential related costs and benefits’. This section presents a cost-benefit analysis of adopting the guidelines described in this Consultation Paper by financial institutions. Given the nature and the scope of the guidelines, the IA is high level and qualitative in nature. A. Problem identification The complexity of ICT risks is increasing and the frequency of ICT-related incidents (including cyber incidents) is rising, together with their potential significant adverse impacts on the operational functioning of financial institutions. Moreover, due to the interconnectedness of financial institutions, ICT-related incidents risk causing potential systemic impacts. For PSPs, ICT plays an important role in the efficient functioning of payment systems. A recent risk analysis exercise conducted by the EBA and the European Central Bank (ECB) identified various threats and vulnerabilities that PSPs are currently exposed to when providing their payment services. The most common risks are: i. inadequate protection of communication channels used for payments; ii. inadequately secured ICT systems used for payments; iii. unsafe behaviour of users and PSPs; iv. technological advancements and tools that are available to potential fraudsters or malicious attackers. For institutions, ICT is a key resource in developing and supporting banking services; ICT systems are not only key enablers of institutions’ strategies, forming the backbone of almost all banking processes and distribution channels, but they also support the automated controls environment on which core banking data are based. ICT systems and services also represent material proportions of institutions’ costs, investments and intangible assets. Furthermore, technological innovation plays a crucial role in the banking sector from a strategic standpoint, as a source of competitive advantage, as it is a fundamental tool for competing in the financial market through new products as well as through facilitating the restructuring and optimisation of the value chain. As a result of the increasing importance of ICT in the banking industry, some recent trends include: i. the emergence of cyber risks together with the increased potential for cybercrime; ii. the increasing reliance on third parties for ICT services and products, often in the form of diverse packaged solutions and resulting in manifold dependencies and potential constraints and concentration risks. In view of the growing importance and increasing complexity of ICT and security risks for financial institutions, and based on the mandates set out for the EBA, the EBA has published: a) Guidelines on ICT risk assessment under the supervisory review and evaluation process (SREP), addressed to competent authorities (EBA/GL/2017/05); b) Guidelines on security measures for operational and security risks of payment services, addressed to PSPs (EBA/GL/2017/17). The guidelines above in point (b) set out very important requirements for PSPs for the provision of their payment services, but, for credit institutions that are PSPs the existing guidelines do not address ICT and security risks from their other activities. Furthermore, the guidelines in point (b) do not apply to investment firms. The new Guidelines on ICT and security risk management aim to address the European Commission request for guidelines for all institutions regarding their ICT security and governance. The aim is to ensure sound ICT and security management in the EU financial sector and to ensure a level playing field for all institutions. The new guidelines integrate the existing text of the ‘Guidelines on security measures’ and broaden the scope of addressees, namely covering all activities for credit institutions and investment firms. Furthermore, the new guidelines build on the existing requirements in the ‘Guidelines on security measures’ but are more explicit, clarifying in more detail how institutions can ensure adequate management of their ICT and security. B. Policy objectives The main objective of the guidelines is to establish harmonised requirements for ICT and security across PSPs (for payment services) and institutions (for credit institutions and investment firms, this extends to all activities). In return, this is expected to contribute to better management of risks arising to market integrity, consumers and the viability of institutions and PSPs from ICT. Operationally, the guidelines aim to integrate all provisions on ICT and security management in a single legal text for all financial institutions and for a wider range of activities. C. Baseline scenario The status quo should constitute the baseline scenario. It entails maintaining the current regulatory framework, which includes two pieces of legislation related to ICT and security risk management: i. Guidelines on ICT risk assessment under the supervisory review and evaluation process (SREP) (EBA/GL/2017/05): these guidelines are addressed to competent authorities and are intended to promote common procedures and methodologies for the assessment of the ICT risk under the supervisory review and evaluation process (SREP). The guidelines set out the requirements that competent authorities should apply in their assessment of ICT on the general provisions and application of scoring as part of the SREP assessment of risks to capital, assessment of institutions’ governance and strategies on ICT, and the assessment of institutions’ ICT and security risk exposures and controls. ii. Guidelines on the security measures for operational and security risks of payment services under Directive (EU) 2015/2366 (PSD2) (EBA/GL/2017/17): these guidelines set out the requirements that PSPs should implement to mitigate operational and security risks derived from the provision of payment services, which in practice relate to the impact of the operational and security risks on their ICT systems. D. Options considered

Scope

Option 1a: Develop a separate set of Guidelines on ICT and security risk management addressed only to credit institutions and investment firms, and maintain the Guidelines on the security measures for operational and security risks of payment services under Directive (EU) 2015/2366 (PSD2) for PSPs. Option 1b: Develop a single set of Guidelines on ICT and security management addressed to PSPs for their payment services and to credit institutions and investment firms for all activities, integrating (and consequently repealing) the Guidelines on the security measures for operational and security risks of payment services under Directive (EU) 2015/2366 (PSD2).

Level of detail in prescribed requirements

Option 2a: Set out detailed and prescriptive requirements on ICT and security management. Option 2b: Set out high-level principle-based requirements on ICT and security management. E. Cost-benefit analysis and preferred options

Scope

Option 1a would mean a new set of Guidelines on ICT and security management for credit institutions and investments firms for all activities and services. However, given that most of the requirements that apply to the security of payment services (i.e. those already within the published Guidelines on security measures) are also applicable for security of other services and activities, the two sets of guidelines would have significant overlap and would create confusion for credit institutions which already apply the Guidelines on security measures for their payment services. This then means that the benefits of having two different guidelines are limited. Option 1b would ensure that the same requirements are set across PSPs for payment services (i.e. not extending beyond the PSD2 mandate), and for all institutions for all services, creating a level playing field. The mandate for security measures for operational and security risks in payment services in practice refers to security measures for operational and security risks on ICT systems. Therefore, it would also reduce the compliance burden for institutions, which will then need to refer to a single legal text for their requirements on ICT and security risk management, irrespective of the service they provide. In addition, it can still take into account any specificities in the ICT and security risk management for PSPs, by setting exclusive requirements for payment services. Option 1b is retained.

Level of detail in prescribed requirements

Option 2a to include detailed and prescriptive requirements on ICT and security risk management could increase comparability and create a level playing field across financial institutions. However, this option risks requirements becoming obsolete very quickly due to the ever-changing nature of ICT and security risks. A financial institution would be unable to ensure that its ICT and security risk management properly mitigates ICT and security risks in an ecosystem in which new threats are evolving continuously. Option 2b on the other hand would allow financial institutions to adapt their risk management processes to new challenges and developments. Therefore, this option reflects financial institutions’ needs to anticipate and mitigate unknown types of ICT and security risks. Option 2b is retained.

4.2. Feedback on the public consultation

Summary of responses to the consultation and the EBA’s analysis The EBA’s analysis Amendments to Comments Summary of responses received the proposals

One respondent commented on the implementation of the guidelines, In line with EBA standard practice, the guidelines do not

suggesting to add to Section ‘background and rationale’ , about how the cover implementation aspects in detail. Any practical

supervision of the implementation of the guidelines is envisaged (e.g. questions can be addressed through the EBA Single

possible role for the competent authorities). Rulebook Q&A facility or through bilateral discussions

with competent authorities. One respondent expressed concerns relating to the impact of these

guidelines on third party providers (TPPs), given the open banking

facility in PSD2. Their concerns relate to how each competent authority

will comply with these guidelines, as a possible restrictive interpretation

could introduce barriers to entry, impact the number of TPPs and

negatively affect the growth of open banking. Moreover, it was noted

that the guidelines can be interpreted liberally or restrictively by General competent authorities. This could result in new entrants requesting comment — No change. authorisation and licence from jurisdictions with a less restrictive implementation The EBA guidelines are principle based. Any interpretation of the guidelines for the provision of their cross-border specification of details would create a situation in services. Consequently, consumers may be exposed to different ICT which one size does not fit all institutions. Furthermore, security levels and risks. The need for a more legally binding text (i.e. a the EBA guidelines are technology and methodology level 1 text) was also proposed by the same respondent. The neutral, with an expectation for institutions to focus on respondent noted the possibility of the ‘deceptive’ implementation of their security, based on a robust process (Section 3.3), the guidelines by institutions and therefore called for sanctions to instead of on detailed compliance aspects. enforce the implementation of the guidelines. This is to avoid a situation

where, in a potential fraud case caused by a TPP, consumers may blame

the banks for exposing them to loss of reputation and credibility, as the

banks hold the client relationship. Sanctions could be a useful tool for

supervisors to protect customers and financial services. They also

suggested introducing and applying industry standards (such as an open

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

application programming interface (API)) and industry solutions (such as the PSD2 hub), which can embrace technology and ensure adequate security, while maintaining minimum security standards acceptable to the industry.

The guidelines A few comments were received on the guidelines being principle based The EBA agrees with a principle- based approach, and have been versus being rules based. Some respondents supported and encouraged the guidelines are drafted with this explicit intention. amended. the EBA’s use of the principle-based approach, commenting that this is The EBA intends to ensure that the guidelines are essential and should be maintained as far as possible. Specifically the principle based and flexible enough to facilitate their focus on outcomes that allow firms to demonstrate capabilities was application to all the relevant institutions in the sector. cited as increasing consistency. This approach ensures that the Furthermore, it is important to ensure that the guidelines can be implemented with proportionality in mind. guidelines remain valid in the continuously evolving technological environment. The EBA’s aim is not to be Principle-based guidance also provides the flexibility required for the overly prescriptive but to cover the main important continuously evolving nature of technology risks and avoids prescriptive areas of ICT and security risk management. In several and detailed requirements that may become obsolete over time. This General parts the detailed points are drafted as examples to be would increase consistency and alignment with the Bank for comment — considered. That said, a number of specific points have International Settlements (BIS) Committee on Payments and Market been amended based on the current supervisory principles vs Infrastructures (CPMI) International Organisation of Securities rules in the insights for future developments in ICT and security risk Commissions (IOSCO) guidance ‘Cyber resilience for financial market guidelines management maturity. infrastructures’. Where more detailed guidance is provided, the EBA should consider separating these out as examples or use cases, such as how the three lines of defence could be implemented to provide examples of how the requirements could apply or be interpreted.

Other respondents considered that some requirements in the guidelines are too prescriptive and too detailed and are thereby limiting the risk management options available to financial institutions (such as governance structures, internal controls and other security-related measures). This was considered to put at risk the ability of the guidelines to withstand the rapid nature of changes in the ICT and information security risk landscape in the years to come. It might also ultimately limit

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

financial institutions’ abilities to innovate within the information and The guidelines do not aim to promote one set of No change. cybersecurity domain. standards over another. The EBA agrees with the need to harmonise regulatory requirements and finds that One respondent noted that a departure from the existing recognised these guidelines are sufficiently principle based that standards increases regulatory complexity and requires resources to be they do not contradict existing standards. diverted from other activities, inhibiting firms from focusing their efforts on the identification of and protection against technological risks, thus increasing the amount of firms’ resources that are focusing on compliance rather than on technological security. This respondent recommended the international harmonisation of ICT rules in the EU and globally, as diverging regulatory requirements will significantly increase operating costs and will introduce risks of regulatory arbitrage.

One respondent suggested that a risk-based approach should be General This is taken on a case-by-case basis throughout the adopted in these guidelines, especially where controls are mentioned. Changes made on comment — guidelines; however, in general the guidelines are to be a case-by-case risk-based applied proportionately, taking into account the risks basis. approach that the financial institutions are exposed to.

Standardisation One respondent commented that the guidelines seem to separate the The guidelines cover ICT from a holistic business point of all ICT ‘business’ and ‘IT’ functions within an organisation, thus not taking into of view, using the overall business strategy and guidelines account new configurations, represented particularly by FinTech start- business processes as a starting point. If new entrants ups. It was further commented that new developments in ICT seem to are primarily technology driven, business strategy and be ignored, such as cloud computing and distributed ledger technology ICT strategy will coincide, but this does not change the (DLT), along with the issues of end-to-end data encryption in the course expectations on formulating and approving such of data processing; access to data, which conflicts with banking strategies. No change. confidentiality (General Data Protection Regulation, GDPR), The guidelines are technology agnostic. It is up to an management of ICT security in the form of internal outsourcing, etc. institution to ensure that appropriate security The same respondent understood that the objective of these guidelines measures are implemented, e.g. by using new was to integrate and standardise all ICT guidelines (in force and under technologies or by leveraging more traditional implementation), taking into account relevant national guidelines. technologies. The EBA cannot specify all details or all technologies.

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

The guidelines do not replace any ICT-relevant guidelines from EU law, but they clarify and harmonise the supervisory expectations following from CRD IV, Article 74, and PSD2, Article 95 (1). Some issues are not addressed in these guidelines because there already exist EU-level regulations and guidelines on these topics (e.g. data-related questions are regulated in the GDPR, and cloud security is also handled in the EBA Guidelines on outsourcing).

Reference to Some respondents proposed that the guidelines are linked — where The aim of EBA was to ensure that these guidelines are The guidelines international relevant — to European and international technology and methodology agnostic and do not have been standards practices/requirements/standards/regulations relating to ICT risk prescribe any particular international standards or amended. management that are already in place. Examples include (1) the stand-alone good practices. Financial Stability Board (FSB) Cyber Lexicon, (2) the Basel Committee’s It would not be feasible for the EBA to mention all the ‘Principles for the sound management of operational risk’, (3) the FSB’s existing standards and regulations in the text of the ‘Guidance on arrangements to support operational continuity in guidelines. However, in the executive summary, the resolution, (4) the EBA’s ‘Guidelines on outsourcing’, (5) the ECB’s EBA highlights the two main regulations (PSD2 and ‘Cyber resilience oversight expectations for financial market CRD IV) as these guidelines elaborate how to comply infrastructures’, and (6) International Organization for Standardization with their requirements. Furthermore, the executive (ISO) 27001/2 for controls and ISO 27005 for risk management. Without summary has been amended with references to the an explicit reference or a gap analysis, it is currently not clear how the existing EBA guidelines. guidelines overlap or complement the existing standards in place. In addition, overly general guidelines are open to interpretation both by The ECB cyber resilience oversight expectations for organisations and by supervisors in each Member State, and references financial market infrastructures are aligned with these to existing standards will ease harmonisation across Member States and guidelines, but the main difference is in their scope, as provide assistance in the consistent interpretation of requirements. the ECB cyber resilience oversight expectations specify details for financial market infrastructures, while these One respondent commented that the guidelines do not mention any guidelines apply to institutions. international standard and appear to be a stand-alone best practice for the whole sector. However, much of the guidelines work should be (or The EBA considers that keeping these guidelines should already have been) taken from international standards (e.g. ISO) principle based allows them to be applied by all kinds

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

and tailored to the financial institution environment. This respondent of institutions in the sector. However, this means that considers that this would have allowed a more tailored, thorough, institutions and supervisors need to interpret and tailor consistent, tested and adopted approach to have been defined for the guidelines for a specific case. financial institutions, which would have less difficulty in the adoption and implementation of these guidelines.

Reference to A few respondents requested an explanation of the relationship The EBA has amended the executive summary with The guidelines existing EBA between the Guidelines on ICT risk assessment under the supervisory references to existing EBA guidelines that are relevant have been guidelines review and evaluation process (EBA/GL/2017/05) and these draft to these guidelines. amended. guidelines (preferably with a mapping between the requirements if The Guidelines on ICT risk assessment under the possible). A request was made to reference the existing guidelines in supervisory review and evaluation process these new guidelines. (EBA/GL/2017/05) are addressed to competent authorities, while these guidelines are addressed to financial institutions. For these guidelines to add value it was agreed not to do a direct mapping of the requirements but to word them in a way that makes it easier for the financial institutions to read over and apply them. These guidelines are directed at financial institutions and cover ICT and security risk management from a holistic perspective. In particular, the definition of ICT and security risk details that this covers data confidentiality, integrity and availability. This is also found in other definitions, such as of incidents, and is included in processes such as the classification and risk assessment process. The aspect of data integrity, therefore, is fully integrated into the entire guideline, instead of being dealt with as a specific risk type.

In contrast, the EBA/GL/2017/05 guidelines are directed at supervisors. Since the supervisory

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

assessment depends on information provided by

financial institutions, data integrity has been

highlighted as a specific topic, not because data

integrity is more important or specific as a risk type, but

because of the impact on the subsequent assessment

of all risks (including data confidentiality and data

Another respondent highlighted that these draft guidelines do not availability).

address the data Integrity risk from EBA/GL/2017/05. Even if all financial

institutions are not subject to the Basel Committee on Banking

Supervision’s principles for effective risk data aggregation and risk The EBA agrees with the importance of data integrity The guidelines

reporting (BCBS 239 principles), this is a key risk for financial risks; therefore, the EBA has amended the document to have been

institutions. The respondent requested clarification on why this include the data integrity risk as one of the risks that amended.

theme/risk is not within the scope of the draft guidelines. institutions should manage.

One respondent suggested that this section should be replaced with the Section 1: new regulation, Regulation (EU) 2018/1725 of the European Parliament responding to and of the Council of 23 October 2018 on the protection of natural This comment has been accommodated; however, this The guidelines the persons with regard to the processing of personal data by the Union section has been removed from the final guidelines, as have been consultation — institutions, bodies, offices and agencies and on the free movement of it was used only for the consultation. amended. data protection such data, and repealing Regulation (EC) No 45/2001 and Decision

No 1247/2002/EC.

One respondent proposed that the guidelines should better clarify the Compliance and intent to comply are mentioned in the Compliance and difference between compliance and intent/intention to comply. EBA Regulation, Regulation (EU) No 1093/2010. reporting Intention to comply does not equal compliance. Also, there is a typo: Further information can be found here: obligations — ‘intend’ should be ‘intent’. https://eba.europa.eu/about-us/legalreporting No change. framework/compliance-with-eba-regulatory-products. requirements We expect that competent authorities giving intention

to comply should provide a date by which they will

comply. There is no typo.

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

Subject matter, Paragraphs 6, 7, 8 should be amended to reflect the correct paragraph The guidelines scope of The final guidelines have been updated with the final number that they reference ‘… as defined in paragraph 9 …’ (instead of have been application and accurate references. paragraph 8). amended. definitions

The addressees of the EBA guideline — the subject of

the consultation (EBA/CP/2018/15) — are not only the

institutions related to PSD2, but a broader range of

institutions under the EBA remit (e.g. investment firms

and other activities of the credit institutions). A question was received on the addressees about why these guidelines

(EBA/CP/2018/15) are addressed to institutions related to PSD2, while These guidelines do not repeal the Guidelines on ICT Subject matter, the Guidelines on ICT risk assessment under the supervisory review and risk assessment under the supervisory review and scope and No change. evaluation process (EBA/GL/2017/05) have a broader scope. If an entity evaluation process (EBA/GL/2017/05), so they both definitions — is not related to PSD2, will the EBA/GL/2017/05 guidelines continue to should be applied according to their scope/addressees. addressees apply? If an entity is related to PSD2, are both guidelines going to apply, Note that EBA/GL/2017/05 is intended for supervisors, or only this last one (EBA/CP/2018/15)? not financial institutions. The EBA expects that if

financial institutions implement the Guidelines on ICT

and security risk management, providing supervisors

with the input required for EBA/GL/2017/05 should not

lead to undue burdens.

A few comments were received recommending that the definitions are

aligned as far as possible with the definitions within international The comments regarding each of the definitions have Definitions — publications on technology and cybersecurity risks such as the FSB Cyber been taken on a case-by-case basis and are described See below. general Lexicon and the ECB cyber resilience oversight expectations (CROE) or for each definition below. to use standard definitions (e.g. from control objectives for information

and related technology (COBIT), ISO, etc.) where possible.

The current definition mentions expected loss, which is ICT risk – one respondent recommended applying the concept of Definitions the result of the probability of loss times the expected probability, as there is a likelihood of any kind of impact. impact. Furthermore, this definition brings together

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

the existing definition from the EBA Guidelines on

common procedures and methodologies for SREP and No change. stress testing (EBA/GL/2014/13 consolidated version)

and the definition of security risk from the EBA

Guidelines on the security measures for operational

and security risks of payment services under Directive

(EU) 2015/2366 (PSD2) (EBA/GL/2017/17); therefore,

no change is required. Another respondent asked for clarification of the use of the terms ICT

risk, security risk and cyber risk in the document. In particular, when ICT As specified in the scope of these guidelines

risk is meant to include security/cyber risk. (paragraph 7), for the purposes of these guidelines, the

term ICT and security risk addresses the operational No change.

and security risks of Article 95 of PSD2 (including cyber

risk).

Management body — one respondent commented that the definition

could be supplemented with a reference to paragraph 8 of the

Guidelines on internal governance (EBA/GL/2017/11). Other The definition of ‘management body’ references level 1

Definitions respondents commented that there are different management body legislation and the EBA does not consider that there is No change.

structures and responsibilities in the EU jurisdictions and that the a need to specify this further.

definition should be clarified if this refers to the Board of Directors or

the executive management of the bank.

Operational or security incident — a few respondents suggested using The wording ‘operational or security incident’ is The guidelines just the word ‘incident’, which would allow it to be aligned with the FSB purposefully used to address the requirements of have been Cyber Lexicon definition of ‘incident’. A further comment was received Article 95 of PSD2, and also ‘incident’ has a wider amended. that the current wording describes a risk and not an operational or meaning in the financial sector. The definition describes security incident. Definitions an event not a risk. The terms has been revised to be in Another comment suggested revising the wording, as ‘continuity’ is line with the definition used in the EBA Guidelines on already included in the definition of ‘availability’ and is therefore security measures for operational and security risks of considered redundant. payment services under Directive (EU) 2015/2366 Another respondent suggested deleting the text ‘…systems and…’ from (PSD2) (EBA/GL/2017/17). the definition, as ‘ICT system continuity’ has been covered by

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

‘availability’ mentioned one line above, whereas ‘ICT services The guidelines continuity’ can refer to third party providers’ services outsourced by the have been The EBA concurs that the word continuity is redundant. financial institutions. amended.

Risk tolerance — some respondents suggested using ‘risk appetite’, The EBA agrees to change the definition to ‘risk The guidelines which is more common. The use of ‘risk appetite’ would also be appetite’, to coincide with the use of this in the EBA have been consistent with other EBA guidelines (e.g. SREP, internal governance). Guidelines on internal governance (EBA/GL/2017/11), amended. Furthermore, one respondent explained that risk tolerance is the Guidelines on the revised common procedures and understood as the variability regarding the established risk appetite that methodologies for the supervisory review and the organisation can accept under some circumstances. They evaluation process (SREP) and supervisory stress commented that risk appetite can consider the aggregate level of risk as testing (EBA/GL/2014/13) and the Guidelines on Definitions a medium value of the addition of risks in the organisation, and not only security measures for operational and security risks their addition. One suggestion to overcome this was to add this term (EBA/GL/2017/17). into the text (hence, risk tolerance or risk appetite). Another respondent commented that, in relation to paragraph 13a), ‘risk tolerance’ is a term used in connection with the investments, whereas the whole document is about ICT-related risks, so they suggested providing more details relating to ICT in the definition.

ICT projects — comments suggested that the definition should refer to The EBA considers that shortening the definition would The guidelines ICT projects’ ‘end of life’ or ‘removal’ as part of wider ICT and business adversely impact the intention of the definition; have been transformation programmes, while a suggestion was received to add however, it is reasonable to add the phrase ‘dismissed’ amended. the word ‘dismissed’ to refer to this same notion, as the removal of ICT to the definition. Adding this completes the definition. systems should be treated with the same caution as that given to their Definitions change, replacement or implementation. Another respondent commented that the definition is too wide and suggested shortening it to ‘Any project where ICT systems and services are changed, replaced or implemented. ICT projects can be part of wider ICT or business transformation programmes.’

Definitions Information asset — revised wording was suggested, as it is difficult to know what is worth protecting, so it would be better explained using

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

the following definition: ‘A collection of information, either tangible or

intangible, that is supports the critical business functions and processes in the business environment, and that the entity deems to be characterises as worth protecting following a risk assessment.’ A

further comment was received in which it was suggested that the The definition of ‘information asset’ derives from the wording ‘that is worth protecting’ should be the outcome of the risk definition of ‘asset’ in the FSB Cyber Lexicon, but is analysis, as an information asset may be significantly relevant for the No change. clarified to refer specifically to ‘information assets’, as functioning of the organisation but not worth protecting due to the cost both ‘information’ and ‘ICT assets’ are defined in these of implementing security measures (tangible or intangible costs). guidelines, whereas the FSB Cyber Lexicon was not Another respondent suggested changing the definition to ‘information, specific. data and tools required for the processing thereof, which can either belong to the company or be stored under bailment (e.g. personal data).’ The respondent considers that mentioning ‘tools’ is significant, as all measures taken on the protection of information are tightly related to the tools (e.g. user rights), while leaving the definition only as ‘pure data’ makes things philosophical and removes the connection to reality, where data does not exist by itself but is always under the management of some tools. Another respondent suggested harmonising this definition with the wording in paragraph 17.

ICT asset — a proposal was received to consider the use of the similar See the above explanation regarding ‘information definition of ‘asset’ from the FSB Cyber Lexicon reference. asset’. The guidelines Definitions Another suggestion was received to clarify the wording to ‘an asset have been The explanation has been clarified in accordance with amended.

either of software and or hardware, that is found in the business

the comment received. environment’.

The EBA considers that all definitions used follow New definitions existing legislation and industry standards as suggested appropriate. However the aim of the EBA is to ensure

that these guidelines are technology and methodology

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

agnostic and do not prescribe any particular international standards or stand-alone good practices. In particular: New definitions were suggested for the following: 1) As this phrase is not used anywhere in the guidelines, 1) ‘structured data’ to include in the guideline: ‘Structured data there is no need for the definition. Furthermore, the No change. are information that is structured systematically, which guidelines deal with structured and unstructured data; typically includes information within IT applications and therefore, the EBA considers it inappropriate to single database records structured according to a data model, as for out structured data. example a relational or hierarchical schema’. 2) ‘Project implementation leadership’ is used in the No change. 2) ‘project implementation leadership’ — paragraph 66. text in its general meaning. There is no need to specify its meaning. 3) ‘adequate knowledge’ — paragraph 70. 3) ‘Adequate knowledge’ has no special meaning in this 4) ‘information security function’ to clarify if this means the chief text. The knowledge should be proportionate to what it No change. information security office (CISO) (paragraph 32). relates to. 5) ‘information security standards’ in paragraph 44. 4) ‘Information security function’ has already been 6) ‘business-managed applications’ in paragraph 80. made clear in the text from the context and the 7) ‘urgent or emergency ICT changes’ in paragraph 81(e). responsibility associated with it. The intention is not to The guidelines 8) ‘asset owner’ in paragraph 19, because entities/institutions’ be too prescriptive about the roles and responsibilities have been complexities can be very different. for this function; therefore, the EBA does not want to clarified. explicitly link it to the CISO. After considering all feedback received, paragraphs 32 and 33 have been removed. 5) ‘Information security standards’ refers to any No change. applicable and relevant information security standards. The EBA does not see the need to list specific standards. The guidelines 6) ‘Business-managed applications’ were mentioned in have been paragraph 80 only as an example. The EBA does not amended. want to explain and define the examples that are used

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

to support the understanding of the guidelines; therefore, the EBA deleted this example from the text. The guidelines 7) ‘Urgent or emergency ICT changes’ has been have been removed from the guidelines (paragraph 81); amended. therefore, there is no need to define it in the text.

8) ‘Asset owner’ has been removed from the text. In The guidelines paragraph 18 the text has been amended and updated have been

to ‘There should be clearly assigned accountability and

amended.

responsibility for the information assets.’

One respondent asked that additional wording be added in order to be All EBA guidelines must be applied proportionately by clear on the obligation of all addressees to comply with the new all those to whom these guidelines are addressed (see guidelines. This new wording should set out that proportionality cannot ‘Addressees’). Proportional application is specified in be understood as grounds for exemption and that all addressees should paragraph 1 of the guidelines (see Section 3.1). address and manage their ICT and security risks. One respondent asked Compliance with the provisions will be monitored by that proportionate application or implementation according to the competent authorities. The basis of proportionality is individual risk situation should be made possible. specified in this paragraph.

One respondent commented that, although appropriate, the principle of proportionality may lead to financial institutions excluding the No change. implementation of security controls, based solely on cost factors. The Competent authorities have the responsibility of Proportionality monitoring proportionate application. In line with principle of proportionality must be closely monitored by the paragraph 1 the EBA expects that competent management bodies (or even the regulator) that will issue the relevant guidelines. Hence, the respondent suggested considering the authorities take into account the institution’s risk profile. amendment of Section 4.1 and its association with Section 4.2.1.

Another respondent suggested including a more comprehensive set of principles governing the proportionate application, or a differentiation between minimum requirements and those that could be applied proportionately, in order for institutions to achieve compliance with competent authorities’ needs.

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

Another suggested that ‘proportionality’ is better expressed as ‘a

graded approach’ according to the specific context, objectives, These are principle-based guidelines that, as explained conditions and needs of financial institutions. The respondent in paragraph 1 of the guidelines (see Section 3.1), suggested that it is appropriate to set minimum criteria (factors) to be should be applied by all institutions in a proportionate

taken into account and proposed the following for paragraph 4.1: ‘The

manner. The application of these guidelines is not for

management body should apply the graded approach to comply with

competent authorities’ needs but for institutions to

the provisions set out in these guidelines in such a way that is

ensure that they manage their ICT and security risks

proportionate to, and takes account of, at least the following factors:

proportionately. Furthermore using a graded approach

a) security significance of the financial institution and its parts, b) the

would limit the implementation of principle-based

financial institution’s size and complexity, c) internal organisation, d)

guidelines and it is the right of the management body

the nature, scope, complexity and riskiness of the services and

to establish proportionate application.

products that the financial institutions provide or intend to provide, e) the strategy and the goals. The factors used to grade the development and application of the guidelines shall be documented.’

Another respondent commented that adapting to the requirements in These guidelines will be applied for more services and the guidelines could be a significant problem for organisations operating by more addressees than the Guidelines on security on a small scale, such as cooperative banks, payment services measures for operational and security risk under PSD2 institutions and FinTech start-ups. The application of the principle of (EBA/GL/2017/17). It is important that the guidelines proportionality should be clarified to specify which aspects are are ‘size neutral’ and are applicable to all addressees. important for these organisations and which are not. This applies

particularly to countries where ‘gold-plating’ occurs. This can lead to

other negative outcomes, such as the migration of payment institutions All institutions must apply all the guidelines in a

to more ‘liberal’ countries. proportionate manner based on paragraph 1 (see

Section 3.1).

Some respondents commented on the management body’s roles, The guidelines intend to place the responsibility and

4.2. ICT specifically requesting that it is specified that the executive function of accountability with the management body, in particular No change. the management body deals with the ICT function and strategy but that governance and regarding strategy and governance due, which is in line the accountability of the executive function (the Executive Board) strategy with paragraphs 23(a) and 23(b) of the EBA Guidelines

should focus on risk strategy and risk appetite and should challenge on internal governance (EBA/GL/2017/11).

decisions of the ICT function. Therefore, the Executive Board’s

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

responsibilities should be amended in the guidelines (in paragraph 4) to Paragraph 4 states that the oversight of permit delegation where appropriate, e.g. in implementing processes. implementation is for the management body, which is The need for the management body to approve specific risk-type in line with paragraph 23 of the EBA Guidelines on policies should also be reconsidered. One respondent elaborated internal governance (EBA/GL/2017/11). concerns that the drafting would significantly expand the management body’s obligations to include the day-to-day activities regarding the design and implementation of ICT governance and strategy. This level of In addition, the EBA does not state that the granularity is not considered necessary, given that the management management body should formulate and draft the body discharges its obligation to ensure that an adequate control policies but considers that the general ICT and security framework is in place, as detailed in paragraph 2. risk management framework and information security framework is of such particular importance that it Another respondent proposed replacing ‘management body’ with should be approved periodically at the highest level. ‘senior management body’, making reference to governance and mentioning the activity of ‘ensuring’. The respondent suggested promoting a view of ICT corporate governance and, by definition, that The term management body is used in line with the EBA the responsibility of governance belongs to the Executive Board while Guidelines on internal governance (EBA/GL/2017/11). the responsibility of management belongs to the management body. The guidelines do not prescribe the composition (or Another respondent suggested that the management body should have part of it) of the management body. at least one expert in the information security/ICT risks field in order to The EBA does not see a need to promote and define the properly execute governance. ICT corporate governance into the management body. The guidelines allow for implementation by all institutions (according to their size or mandate).

Paragraph 2 specifies that the management body is required to set roles and responsibilities for information security risk and business Business continuity and information security are 4.2.1. ICT continuity, not only for ICT risks. The question is rather what addressed in the guidelines in the context of ICT. This is No change. governance chapter 4.2.1 covers and should the chapter title reflect this, i.e. is it specified in the wording in Section 3.2. only ICT risk or also information security risk and business continuity?

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

One respondent suggested deleting the requirement for a sustainable The guidelines budget for setting an adequate internal governance and control The comment has been accepted. have been framework (paragraph 3). The respondent fully supported supervisors’ amended. expectations to ensure an appropriate budget for an institution to meet its requirements on ICT governance and also agreed on having an overall sustainable budget, which is, in their understanding, to maintain the ability for an institution to (1) meet its current as well as expected future financial obligations and (2) sustain growth, both primarily through current or past income. Nevertheless, the respondent questioned the requirement for having a sustainable budget for such a limited scope as ICT governance, particularly as the support of operational needs and the implementation of risk management processes is associated with costs and not directly related to income. 4.2.1. The concept of ‘key roles’ in paragraph 3 is considered vague by some Governance The EBA agrees with the need for information security respondents, as it relates to training, and all staff should receive training for all staff members and in particular for key information security training. function holders in the institution. One respondent commented that the wording contradicts the principle The guidelines have been updated to state that training in paragraph 30 of chapter 4.4.1, where it states that the information is necessary for all staff including key function holders. security policy should apply to all employees, and in paragraph 52 of The guidelines chapter 4.4.8, where training applies to all employees. Others wanted Key function holder has a meaning as set out in the EBA have been to receive more detail about what are considered ‘staff members Guidelines on internal governance (EBA/GL/2017/11). amended. occupying key roles’. Furthermore, financial institutions should ensure that One respondent suggested clarifying that the requirement for quantity on an annual basis, or more frequently if required, all and skills of staff specifies that it is for relevant staff, as, in banks, only staff members including key function holders receive part of the staff is responsible for performing the tasks listed. appropriate training on ICT and security risks, including Heightening the awareness of all staff is already addressed in, for on information security. example, paragraph 54. The new wording suggested is ‘ …the quantity

and skills of financial institutions’ relevant staff is adequate …’

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

One respondent suggested drafting changes to paragraph 4, as the The EBA agrees with the suggestion that the The guidelines obligations set out cover a level of activity that would in their view management body is accountable for and not have been reasonably be approved and overseen at a level below the management responsible for ensuring the effective risk management amended. body: ‘The management body has overall accountability responsibility framework. The text has been amended. Other wording for ensuring an effective risk management framework for ICT risks is in this paragraph remains the same in order to remain in place, including ensuring there is an identified individual or forum in line with the EBA Guidelines on internal governance 4.2.1. within the organisation is responsible for setting, approving and (EBA GL/2017/11). overseeing the implementation of that framework. of financial Paragraph 4 institutions’ ICT strategy as part of their overall business strategy as well as for the establishment of an effective risk management framework for ICT risks.

Another respondent suggested after ’management of ICT risks’ adding

the following new text: ‘as the integral part of overall business risk management process.’

One respondent commented that some requirements related to ICT The intention is to stay ‘size neutral’ and allow No change. 4.2.1. security operating models (roles, responsibilities, reporting lines and proportional application; therefore, such a level of Governance mechanisms) could be included. detail is not necessary.

The EBA does not see a need to prescribe the need for No change. One respondent suggested adding ‘compliance with applicable laws and compliance with applicable laws and regulations in regulations’ as a further component of the ICT strategy, as nonthese guidelines, as it is already prescribed in all of the compliance signifies a business risk (and associated provisions in the 4.2.2. Strategy laws and regulations. business strategy). Paragraph 5(a) Another respondent suggested adding in the first line ‘to effectively support and participate in their business strategy’. This reflects the role The EBA agrees that it is important to highlight the importance and functions of ICT on creating and of ICT as an integral part of processes, not only as a support function implementing a company’s business strategy.

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

that is involved in the late stages of already established processes and Therefore the EBA has amended the text according to The guidelines

procedures. the suggestion. have been

amended.

The guidelines do not prohibit the establishment of a

separate information security strategy; they state only One respondent commented that there should be room for a separate that there must be information security objectives in information security strategy as long as there is a clear connection to the company’s ICT strategy. According to this, the No change. the ICT strategy — this relates to paragraph 5(c) where it is specified guidelines do not mention the issue of the separate that the ICT strategy should contain information security objectives. information security strategy, so there is a possibility

for any institution to have a separate information

security strategy, as long as it is in line with the 4.2.2. Strategy Another respondent asked if ICT assets should be added here (i.e. information security objectives of the ICT strategy. software and hardware — for example licences, redundant hardware, Paragraph 5(c) up-to-date software and hardware, etc.) All ICT assets are covered by the current wording; — components therefore, there is no need to specifically mention them No change. of ICT strategy Another respondent suggested adding at the end of the sentence ‘in at this point.

line with general security and governance policies established in

organisation’. The text should also include the alignment of the ICT According to the EBA, it is important that the security

strategy with innovation, to avoid disruption and to support lean digital policies and ICT strategy must be aligned with each

transformation that is based on ICT architecture. It should also include other and with any innovation. This suggestion is No change.

the proper portfolio of changes to align ICT transformation in covered in paragraph 4, which mentions ‘ICT strategy

accordance with business transformation. as part of their overall business strategy’. Therefore,

there is no need to introduce the suggested text in the

guidelines again.

Two comments were received on the concept of ‘action plans’ in The EBA agrees that the previous wording was a little 4.2.2. Strategy paragraph 6, which are said to support the ICT strategy. One respondent inaccurate and that a detailed, clarified text could help Paragraph 6 — said that the term ‘action plans’ seems vague, and there is a request to institutions to implement the guidelines. Therefore the The guidelines

have been action plans to clarify what is meant by ‘action plans’ and the associated expectations. comments regarding action plans have been amended. support the ICT Could they be articulated as either initiatives, projects, programmes or accommodated, to clarify the intention.

strategy an implementation programme supported by an action plan (priorities,

deadlines, resources, etc.)? Another respondent suggested the

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

following wording: ‘Financial institutions should establish a set of

measures to be taken to achieve the objectives of action plans to support the ICT strategy,... The action plans These measures should be

periodically reviewed to ensure their relevance….’. One respondent commented that instead of ‘should be periodically The EBA does not consider this proposal too detailed or No change. reviewed’, the review should be performed and validated on a unnecessary. management committee level to ensure alignment with the overall business strategy.

One respondent commented that addressing requirements across two The guidelines specify some requirements that address different sets of guidelines (these and the EBA Guidelines on the specificities of ICT and security risk when outsourcing arrangements (EBA/GL/2019/02)) could create uncertainty outsourcing and using third parties and complement about the applicable requirements or lead to differences in the the EBA Guidelines on outsourcing arrangements interpretation by different competent authorities about how each (EBA/GL/2019/02); therefore, this section is deemed to document is translated and implemented. Other respondents suggested add value by giving information about security 4.2.3. Use of leaving this section out, partially or completely, to avoid any confusion requirements. third party with the EBA Guidelines on outsourcing arrangements providers (EBA/GL/2019/02) and to avoid fragmentation of requirements and (reference to inconsistencies across the services, activities and functions being No change. the EBA outsourced. Another respondent requested a clear alignment with the Guidelines on requirements set out in the EBA Guidelines on outsourcing outsourcing arrangements, as it remains unclear if it is necessary to differentiate arrangements) between parent entities based in another Member State and parent entities based in a third country. Another respondent requested clarification on the relation (if any) between the concept of ‘appropriate The requirements apply to the addressees of the EBA and proportionate security objectives and measures’ in these guidelines Guidelines for any outsourcing or use of third parties, and the classification of outsourcing (as critical or not critical) proposed regardless of where the parent entity is. by the EBA Guidelines on outsourcing. There is no contradiction or particular relation between these guidelines and the distinction of critical or

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

important functions in the EBA Guidelines on outsourcing arrangements.

To create the necessary requirements for other sectors, One respondent asked for consistency in requirements across the is the responsibility of the other European Supervisory 4.2.3. Use of sectors because ‘intragroup’ would include insurance companies, and in Authorities (ESAs). Therefore, it is not possible for the third party the event that a financial institution’s ICT serves multiple subsidiaries, it EBA to define cross-sectoral requirements that must be No change. providers would be complex to have different security controls on different applied in all of the sectors. However the ESAs liaise subsidiaries. closely on this topic in order to be aligned in their approaches.

A question was received asking if the measures set out in these The EBA considers that the measures in these No change. guidelines should be included in the outsourcing risk assessments guidelines should be included in the outsourcing risk assessments, as these general principles need to be whenever the outsourced service is related to payment services. applied when outsourcing. One respondent proposed the following changes to clarify that the provision of services by third parties should not trigger the EBA The scope of the EBA Guidelines on outsourcing arrangements is clearly specified in those guidelines. Guidelines on outsourcing arrangements: ‘[…] including the measures set out in these guidelines, when important operational functions of The intention of this section is to ensure that ICT and security risks are covered not only when outsourcing No change. payment services and/or ICT services and ICT systems are outsourced, including to group entities, or when using third parties.’. but also when using third parties. The EBA does not support the suggested modification in the wording. The Paragraph 7 With regard to the wording ‘financial institutions should ensure the option of using third parties is an important issue, and effectiveness of the risk-mitigating measures as defined by their risk it is important to keep it in this point. management framework’, one respondent suggested that the risk management framework of each institution could be enhanced through a common risk management framework, such as the one already The intention is not to specify one risk management No change. established by the ECB — i.e. risk assessment questions of the ECB for framework over another. The guidelines are principle outsourcing providers. This common framework will help to ensure based. consistency among all institutions.

There was a request to clarify that group entities are covered only to the extent applicable in line with current vendor risk obligations and

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

intragroup service controls, i.e.: ‘ICT systems, are outsourced, including, The requirements of the guidelines must be applied to

to the extent applicable, to group entities…’) any intragroup outsourcing, without any limitation or No change. lightening; therefore, the EBA considers there is no

need to specify or clarify the text.

Requests for clarification were received for the specific use of the The suggested wording (to add ‘critical or important’

wording ‘critical or important’ in both paragraphs 7 and 8, to align with operational functions) is not necessary, as the

the EBA Guidelines on outsourcing arrangements (EBA/GL/2019/02), guidelines apply for any outsourced service or system,

i.e. ‘when critical or important operational functions…’. and it is the company’s right to determine whether it is No change.

critical or important, based on its proportionality. In particular, one respondent suggested limiting paragraph 8 to (critical

or important) outsourcing of ICT services and ICT systems, as otherwise Paragraphs 7 the principle of proportionality and the draft guidelines’ objective to and 8 The guidelines are risk based and proportionality is focus on risk might be contradicted. This is because they consider that No change. already specified in the guidelines. Furthermore the the minimum contractual content outlined in paragraph 8 is too Guidelines on outsourcing arrangements set out the extensive for the entirety of the potential ICT-related services or guidance for critical and important outsourcing. systems procured from third parties. Rather, the assessment of the

necessity for specific contractual requirements should be within the

responsibility of the institution, whereas, in line with the principle of

proportionality, necessity should be risk based.

The following requests for clarification on paragraph 8 were received:

(i) Paragraph 8: suggested rewording to clarify the sentence ‘…ensure

that contracts and service level agreements with the provider (third

(i) The EBA considers that it is important to keep service No change. party outsourcing provider or group entity, or third party provider)…’ level agreement (SLA) in the text; however, the wording

Paragraph 8 (ii) Paragraph 8(a): ‘appropriate and proportionate information has been clarified.

security-related objectives and measures, including requirements such

as minimum cybersecurity requirements’. The wording ‘information The guidelines security-related objectives’ is not clear, so the respondent suggests (ii) The EBA agrees with the suggestion. have been using ‘measures’ alone. Also ‘appropriate and proportionate amended.

information security objectives, ICT risks and measures […]’

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

(iii) Paragraph 8(a): the terms ‘minimum cybersecurity requirements’ (iii) ‘Minimum cybersecurity requirements’ and ‘data No change. and ‘data life cycle’ are considered to be vague, and there was also a life cycle’ already exist in other ICT standards, so no suggestion that these terms should be removed and that the first part change is needed. of this section is enough: ‘appropriate and proportionate information security objectives and measures...’.

(iv) Paragraph 8(b): one respondent commented that service level (iv) The suggested supplement is not necessary, as the The guidelines agreements are currently only available on continuity, but there should current text covers all of the suggestions on other have been also be agreements on vulnerability management/patching, as well as points: patching and vulnerability management in amended. on release management of system security items such as antivirus paragraph 8(a), key performance indicator (KPI) in patterns/engines. Another proposed redrafting was ‘Service-level paragraph 8(a), and reporting in paragraph 8(c) and

agreements, key performance indicators, reporting or other adequate

paragraph 9. The text has been amended by moving

measures to ensure continuity of business-critical ICT services and ICT

part of paragraph 8(b) into paragraph 8. systems and performance targets under normal circumstances as well

as those provided by business continuity or contingency plans…’.

No change. (v) One respondent suggested including a new paragraph 8(d): ‘The (v) The EBA considers that it is not necessary to add the right to audit the provider to validate compliance of the requirements new paragraph, as this is included in the EBA Guidelines established in the contract.’ on outsourcing.

One respondent suggested that the use of KPIs to monitor compliance of the outsourcing provider to the SLA provisions, as well as key risk indicators (KRIs) for outsourcing provider evaluation purposes could There is no intention to prescribe the use of KPIs and benefit financial institutions. Generic KPIs and KRIs could be provided to ensure consistency among financial institutions, at least to a certain KRIs to monitor compliance, as this would be too Paragraph 8 degree, since other laws and regulations may impose diverse detailed. Therefore, the EBA aims to keep the text as it No change. is and retain the opportunity for institutions to decide requirements. Such generic KRIs could include certifications of the how they want to fulfil the guidelines. outsourcing provider against ISO 27001:2013, the Cloud Security Alliance (CSA) Cloud Control Matrix (CCM) and/or STAR certification (for cloud providers). This will also assist the implementation of paragraph 9 below (‘Financial institutions should monitor and seek assurance on the

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

level of compliance of these providers with their security objectives, measures and performance targets.’).

One respondent provided a second sentence to clarify the wording in The suggestion is considered too prescriptive. The No change. paragraph 9: ‘For the avoidance of doubt, contractual obligations addition of the suggested new sentence would limit the concerning intragroup service relationships can be satisfied by binding regulation, and it would be necessary to apply this group information security policies applicable to the servicing group provision also to intragroup service relationships.

entity covering such requirements.’

Another respondent commented that the particular assurance is better to be specified. For the security measures, a system and organisation Paragraph 9 controls (SOC)2 type II security attestation by an independent assessor The EBA does not consider that there is a need to No change. could be provided. Without explicitly stating compliance assurance, specify such standards (e.g. SOC2), as the guidelines are service providers can never move in the right direction. Similarly, principle based. another respondent suggested mentioning some examples of internationally accepted standards and certifications (e.g. certifications to standards in the ISO/International Electrotechnical Commission (IEC) 27000 family and the International Standard on Assurance Engagements (ISAE) 3402 type II certification).

One respondent suggested limiting the applicability of paragraph 9 to ‘where considered appropriate in terms of related risks’, i.e. in the case of (material) outsourcings, as it considered the requirement to ‘seek assurance on the level of compliance of ICT service or system providers with their security objectives, measures and performance targets’ too The EBA considers that the guidelines follow a risk- Paragraph 9 prescriptive and inexpedient. Monitoring and potential assurance of based approach and therefore consider that this is No change. compliance should be appropriate to the service or system’s relevance already included. and the risk it poses, whereas the assessment of associated risks is conducted by means of various mandatory risk assessments, e.g. outsourcing risk assessments, vendor risk assessments and information security risk assessments. The costs associated with a mandatory assurance of compliance of the entirety of ICT service or system

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

providers, irrespective of their relevance and risk, are excessive, compared with the potential associated benefits of such mandatory assurance of compliance.

The EBA expects that monitoring is done on a regular One respondent suggested at the end of the sentence to add ‘on a No change. basis. The general concept is already in the text, so it is Paragraph 9 regular basis with remediation plans created and implemented based already expected that an institution would act based on

on findings obtained by monitoring and testing’.

its findings.

The use cloud services and related specific governance (CSA, etc.), 4.2.3. Use of taking into account the different implementation models (SaaS, PaaS, This is already included and regulated in the EBA third party public cloud, hybrid, etc.) and assurance mechanisms, should be Guidelines on outsourcing, so there is no need to have No change. providers highlighted in this chapter as being increasingly important third party this specification here also. service providers.

One respondent suggested that data centres supporting financial institution operations should possess or adhere to internationally recognised certifications, controlled by independent auditors. There are a number of standards that greatly contribute to data centre security and that could be included in the text: a minimum tier 3 level of redundancy of the data centre infrastructure ensures the continuity of 4.2.3. Third operations; the ISO 27001 standard certifies the quality of an The EBA agrees with the concept and points that were party providers information security management system, guaranteeing the suggested, but these would be too detailed for the No change. — data centres confidentiality and availability of data; the ISO 14001 standard specifies general purpose of these guidelines. requirements for an effective environmental management system; the ISO 9001 standard ensures effective quality management, providing a systematic approach to maintaining and improving customer experience; ISAE 3000 type 2 and ISAE 3402 type 2 reports ensure adequate risk management, quality and reliability of internal processes; ISAE 3000 focuses on operational management; and ISAE 3402 focuses on financial reporting.

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

Furthermore, the respondent recommended applying the following

criteria to enhance the physical security of data centres: a safe location;

the use of a minimum of two data centres, connected to different power

grids to diversify risks; data servers to be stored separately from any

other customers; and a controlled access system to the data centre

needs to be in force that requires identity verification.

The adoption of a well-recognised security 4.3.1. No change. One respondent suggested the adoption of a well-recognised security management framework is too limiting with regard to Organisation management framework. the ICT and security risk management of financial and objectives institutions.

Comments were received on the specification in the text of the three Financial institutions have to manage their ICT and

lines of defence (3LoD) model, with a request that the model for security risks according to their general obligations on The guidelines implementation should not be specified, particularly as this is risk management set forth in EBA/GL/2017/11 have been considered to move away from the guidelines being ‘principle based’. Guidelines on internal governance under amended. The focus should be on ensuring an effective internal risk management Directive 2013/36/EU.

and control model. This would be, for example, just a clear description Based on the feedback received, the guidelines have 4.3.1. of what duties and responsibilities reside with the respective lines of been amended to follow the ‘principle-based’ defence, on an overall level. This description should be in line with Organisation approach. Paragraphs 10 and 11 have been revised to EBA/GL/2017/11 Guidelines on internal governance under and objectives ensure appropriate segregation of ICT operations, relating to ICT Directive 2013/36/EU. One respondent also highlighted that there is no control, and internal audit functions, while consistent industry standard for the 3LoD model, whereby the model is risk paragraphs 32 and 33 have been removed. The revised implemented by institutions in accordance with their size, structure and management guidelines do not explicitly refer to the 3LoD model and framework complexity. This has resulted in the allocation of information security do not prescribe to financial institutions how to roles to the first or second line of defence not being consistent in implement the 3LoD model for ICT and security risk industry. The view was also that the objectives of the guidelines are met management purposes. These guidelines do not assign without the need to disrupt the existing enterprise risk management specific roles to each of the three lines of defence, but practices. One respondent said that banks should not be forced to describe the responsibilities of each. manage ICT risks differently from the rest of their risks. Others said that

this guidance may be deemed useful for smaller, less mature institutions The EBA considers that these guidelines are now

but not for well-established institutions that already meet existing compatible with the 3LoD model, with the ICT

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

regulations. Meanwhile another respondent commented that the 3LoD operational units being the first line of defence. The

requirement can be difficult for smaller companies to meet, as they may guidelines now focus in particular on the

not have enough people with adequate technical skills or the responsibilities of the management body and the

information security background outside ICT support teams (second second line of defence control function (which usually

line). includes the information security function). Cross-

references to the EBA Guidelines on internal

One of these respondents suggested the following wording in

governance (EBA/GL/2017/11) added to paragraphs 10 paragraph 10: ‘Financial institutions should identify and manage their and 11 are intended to incorporate in these guidelines

ICT risks according to the three lines of defence model an effective

governance requirements that are (objectively) valid

internal risk management and control model, including an

for the purposes of these guidelines. For the avoidance

independent risk control function, to identify and manage these risks.’

of doubt, references do not change or expand the

One respondent proposed changes in paragraph 11: ‘… in charge of ICT scope of the application of the EBA Guidelines on

systems, processes and security operations, which could be acting as internal governance.

the first line of defence, should operate under the supervision of an Based on the feedback received, reference to the 3LoD The guidelines internal control function, which could be acting as a second line of model has been removed. Instead paragraphs 10 and have been defence. This internal control function should take responsibility for the 11 have been revised to ensure the appropriate amended.

management of ICT risks. The internal audit function, which could be

segregation of ICT operations, control, and internal acting as the third line of defence should have the capacity to audit functions. independently review and provide assurance of the respective roles the

above-mentioned functions (see Section 4.3.6)

One respondent suggested consistently using the term ‘financial Based on the feedback received, the guidelines have

institutions’ throughout these guidelines, instead of mentioning the been amended to follow the ‘principle-based’

appropriate department or level (including the 3LoD) where the approach. The text has been amended for clarification The guidelines responsibility for a specific requirement lies. In addition, the respondent and alignment with the EBA/GL/2017/11 Guidelines on have been suggested adjusting the wording for the three lines of defence in internal governance under Directive 2013/36/EU — amended. paragraphs 11, 13, 27, 32 and 33, as the three lines of defence are not paragraphs 10 and 11 have been revised to ensure the

described clearly and consistently. appropriate segregation of ICT operations, control, and

internal audit functions. The revised guidelines do not

explicitly refer to the 3LoD model — they do not assign

specific roles to each of the three lines of defence, but

describe the responsibilities of each.

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

One respondent commented that the distinction in the requirements The EBA considers that financial institutions have to between financial institutions and PSPs is incomprehensible. PSPs manage their ICT and security risks according to their should also follow the 3LoD model and an appropriate internal control general obligations on risk management set forth in function. Another respondent requested clarification of paragraph 11, EBA/GL/2017/11 Guidelines on internal governance as in paragraph 10 the use of the 3LoD model is a mandatory under Directive 2013/36/EU. requirement, while paragraph 11 seems to leave it optional to manage the ICT risks under this model, using the term ‘where the three lines of Based on the feedback received, the guidelines have The guidelines been amended to follow the ‘principle-based’ Paragraph 10 defence is applied’. However, the respondent requested wording that have been approach, and paragraphs 10 and 11 have been revised suggests that the 3LoD model is used but, for reasons of proportionality amended. in small financial institutions, risk management can be done as to ensure appropriate segregation of ICT operations, control and internal audit functions. The revised effectively as necessary under a different approach. It should be more guidelines do not explicitly refer to the 3LoD model and important to create a robust ICT risk management with an independent internal control function than to formally stick to a model. This approach do not prescribe to financial institutions how to would be especially valuable in situations where, due to head count, the implement the 3LoD model for ICT and security risk management purposes. implementation of all three lines of defence would prove to be difficult.

The guidelines One respondent suggested changing the wording in paragraph 11 to Based on the feedback received, the text has been have been ‘internal control function should take responsibility of the control of ICT revised and aligned with the wording of the amended. risks’. Currently, according to paragraph 11, an internal control function EBA/GL/2017/11 Guidelines on internal governance in the second line of defence should ‘take responsibility for the under Directive 2013/36/EU. The control function management of ICT risks’, but this was considered unclear. The should adhere to the requirements of Section 19 of the suggestion is to ensure that it is the same as the requirements defined EBA Guidelines on internal governance in EBA/GL/2017/11 Guidelines on internal governance under Paragraph 11 (EBA/GL/2017/11). Directive 2013/36/EU, paragraphs 174 to 180 on the risk management function’s role in identifying, measuring, assessing, managing, mitigating, monitoring and reporting on risks. The EBA considers that such change would not be in line No change.

Another respondent suggested that where it is mentioned that the with the EBA/GL/2017/11 Guidelines on internal second line of defence should take ‘responsibility’ for the management governance under Directive 2013/36/EU.

of ICT risks, this should be replaced with ‘accountability’, since the responsibility of managing ICT risks during the daily tasks is the first line

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

of defence. The second line would have an internal control function, but The EBA considers that one single department does not The guidelines

not the responsibility for the daily risk management. have to manage ICT and security risks alone. Following have been

the feedback received, the wording of these guidelines amended. Another respondent commented that the internal control function has been revised to clarify that the assignment of the should be in the information security and operational risk management responsibilities for managing and overseeing ICT and departments, as it is not clear how one single department can manage security risks should adhere to the requirements of ICT risks alone. Section 19 of the EBA/GL/2017/11 Guidelines on

Another respondent commented that the internal control function internal governance under Directive 2013/36/EU.

should be allowed to be organisationally situated outside the ICT No change. The EBA considers that the independence of the control department in order to ensure independence and to avoid conflicts of function as the second line of defence is ensured. interests.

Another respondent suggested moving this paragraph to an annex as

an example of a potential model framework for certain institutions with Following the feedback received, these guidelines have The guidelines

less mature risk management functions. Some rewording was been revised and the wording of paragraphs 10 and 11 have been

suggested here for this purpose: ‘…acting as the first line of defence, aligned with the wording of the EBA/GL/2017/11 amended.

should operate under the supervision oversight of an internal control Guidelines on internal governance under

function acting as a second line of defence. This internal control Directive 2013/36/EU.

function should take responsibility for the independently challenge the first line of defence’s management of ICT risks’.

One respondent commented that there may be room to add a fourth

level that is provided by a regular external audit — both passive (e.g.

SOC2) and active (e.g. red teaming). No change. The EBA does not recognise a fourth level of defence.

To ensure consistency when referring to the ICT organisational As the guidelines already mention ‘fully integrated’, this

structure, one respondent suggested that the wording in this paragraph should also include the interdependencies between

be amended to align with Section 4.2.1 and Section 4.3.2, to include any areas of risk. Paragraph 12 No change. interdependencies to ICT risks within the organisation. The following The ICT and security risk management framework wording was suggested: ‘this framework should be fully integrated into, should be fully integrated into the financial institutions’ and aligned with, financial institutions’ overall risk management overall risk management processes.

processes, including any interdependencies related to the ICT risk’. A

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

request was received to clarify what kind of integrations are expected (e.g. advanced measures approaches — capital reserve, risk appetite framework, etc.).

One respondent recommended that paragraphs 13 and 14 regarding Paragraph 14 specifies documentation requirements in risk management should follow the identification of functions, the area of the ICT and security risk management Paragraph 13 processes and assets (Section 4.3.2), as business requirements drive risk framework. As these requirements are normally No change. management actions, and to be in line with Section 4.3.3 paragraphs 21 specified at the end of the relevant subsection, a and 22. change of order is not deemed appropriate

A question was received about what details/criteria are required to Risk appetite is already further defined (see section on No change. determine the risk tolerance to ICT risks. One respondent also suggested definitions, page 13). providing a list of common risks that should be considered in risk assessment/risk mitigation processes, for instance the unavailability of key staff of financial institutions; the unavailability of data centre ICT and security risk is defined in the section on No change. facilities (fire, power outage, power from city grid unavailable for 4, 8 or definitions. Further guidance is not deemed necessary 24 hours); cyber-attack (distributed denial-of-service (DdoS), due to the principle-based approach embedded in the ransomware); and data leakage (inside job, external attack). (Some of guidelines. In addition, factors for risk tolerance can the risks are listed in paragraph 39 in Section 3.2.1, review of the depend on business process particulars; therefore, the institutions’ ICT risk profile in EBA/GL/2017/05). EBA does not intend to provide such details. Paragraph 13(a ) Another respondent suggested switching paragraphs 13(a) and 13(b) to first identify and assess, and then determine, risk tolerance. Another respondent suggested considering rephrasing paragraph 13(a) as follows: ‘a) enable the management to determine an appropriate risk The EBA agrees that further clarification is appropriate Paragraph 13(a) tolerance for ICT risks, […]’. The respondent stated that paragraph 13 regarding the requirement in paragraph 13(a). Please has been provided a non-exhaustive list of processes to be implemented as part see also comments above and below. amended to of the ICT risk management framework, including processes for replace determining the risk tolerance for ICT risk. The respondent noted that ‘tolerance’ with the institution’s risk management framework contains processes to ‘appetite’. determine the institution’s risk-bearing capacity, based on which the institution’s management has to decide on its risk tolerance. The

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

respondent argued that the risk framework as such cannot determine the actual risk tolerance.

Another respondent commented that the level of risk tolerance or risk threshold defined by the institution could be difficult to determine at this early phase, before measuring the residual (or net) risk level for the institution’s ICT risks. It is advisable to define it at the risk mitigation See comment above. phase (Section 4.3.4) with the pertaining risk acceptance announcement, signed by senior management, on tolerating the residual risk items below the risk tolerance threshold.

One respondent requested the definition of controls compared with Further guidance is not deemed necessary due to the No change. Paragraph 13(c) mitigation measures, i.e. of the mitigation measures, which ones are principle-based approach embedded in the regulations. considered controls.

New paragraph 13(f) added: One respondent suggested that in order to account for a timely ‘identify and assess whether there are any ICT and The guidelines mitigation of the risks identified, as well as to track the implementation Paragraph 13(f) have been of mitigating measures, the guidelines should include an additional item security risks resulting from any major change in ICT system or ICT services, processes or procedures, and/or amended. (i.e. paragraph 13(f)) to address the aforementioned aspects.

after any significant operational or security incident.’

One respondent commented that the need for firms to update their ICT risk management framework with ‘lessons learned’ is fully appreciated. However, the way firms decide to do this may vary. The respondent sought clarification on the implementation of a continuous The EBA sees no need for further clarification on No change. Paragraph 14 improvement process. The respondent considered that this is subject to ‘lessons learned’ and its documentation, due to the different interpretations, as ‘lessons learned’ documentation could be overall proportionality principle. inferred as being part of the project closure documentation or being the lessons learned from ICT incidents and outages. In addition, they request clarification on the level of documentation and the level of criticality of the incidents that should be captured in the ‘lessons

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

learned’ documentation. Another respondent questioned if the lessons learned should be gathered explicitly in a specific document for that purpose, or if it is enough to add them to the different appropriate documents in an implicit way. Another respondent requested a definition of ‘lessons learned’ in the ICT risk management framework background.

One respondent considered that the second sentence in paragraph 15 As this is indeed a role of the ICT and security risk The guidelines belongs to the list of activities in the ICT risk management framework in management framework; the guidelines have been have been paragraph 13. amended to include a new paragraph 13 (f). amended. Furthermore, one respondent commented that the ‘ICT risk The first sentence moved under paragraph 14 but with management framework’ contains requirements that are more of an no changes: The guidelines operational nature and do not require approval by the management ‘The ICT and security risk management framework have been body. The respondent suggested the revised wording: ‘The ICT risk should be approved and reviewed, at least once a year, amended. management framework should be approved and reviewed, at least

by the management body.’

once a year, by the management body.’ This would be in line with EBA Guidelines on internal governance (see Section 17). Another suggested No change.

‘The management body should ensure that the ICT risk management

The EBA sees no inconsistency with the current text. Paragraph 15 framework should be is approved and reviewed, at least once a year, by

the individual or forum with delegated responsibility for ICT risks. appropriate management body.’ Another respondent stated that an

approval is only necessary if there are changes to the ICT risk No change. management framework, as an approval of an unchanged ICT risk The EBA sees no inconsistency with the current text. management framework is inexpedient.

Some respondents commented on the wording ‘major change’, with one asking for clarification and another asking whether the intention is No change. that the risk evaluation of major changes/information security incidents Clarification on ‘major changes’ is not deemed has to be done formally in the general risk management process and necessary. reported to those owners, or whether risk evaluation in the change or information security incident management process is sufficient?

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

One respondent suggested that the second sentence be separated out The EBA would like to clarify that the first No change. and moved to Section 4.6.3 on ICT change management: ‘Financial example/option described is in line with the institutions should …. from this change or incident’. requirement in this guideline.

One respondent asked if the ICT risk management framework is one Risks resulting from these changes are being single framework, as there are separate information security and addressed, therefore it should not be moved to No change. operational risk management frameworks and consolidating the two Section 4.6.3. could create operational inconsistencies. The EBA considers that the term is used as an No change. ‘umbrella’ term, and that financial institutions can have a few frameworks.

One respondent commented that the guidelines could refer to the As the work of the Basel Committee on Banking No change. topic of operational resilience to make it consistent with Basel work. Supervision has not yet been finalised, the EBA prefers not to use this term at the current time. Another respondent suggested that guidance for risk tolerance No change. (thresholds) be specified for mapping business functions, roles and Further guidance is not deemed necessary due to the processes, which would lead to a critical or significant ICT risk based on principle-based approach embedded in these acceptable risk thresholds. However, regarding such thresholds, they guidelines. 4.3.2. recommend that in paragraph 17 only information assets that, when Identification of not available, would cause a significant client or sector impact should be functions required to be mapped. The principle of proportionality and guidance processes and for risk tolerance should be followed. assets Another respondent suggested mentioning the holistic view of an Further guidance is not deemed necessary due to the Paragraphs 16 No change. organisation detailed on an appropriate enterprise architecture to principle-based approach embedded in the regulations. and 17 control changes and impacts. They also suggested mentioning data governance to capture and control metadata information in a corporate view that explains and describes organisation data and related risk. All risk management activities need to be reviewed on Another respondent commented that the provision on the minimum a regular basis then only make specific time references The guidelines and maximum frequency of the review of processes, functions and when there is a specific reason to do so. Paragraph 14 have been resources should be elaborated, or a new provision should be added, to makes the general statement that this applies to the amended. actual implementation of these procedures. The

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

the effect that such a review is necessary if there are significant changes guidelines have been updated to require financial in resources, infrastructure, systems or processes. institutions to ‘identify, establish and maintain

updated mapping’.

One respondent asked whether instead of ‘roles’, ‘information assets’ No change. ‘Information assets’ was not meant to be used. See also Paragraph 16 was meant to be used. In addition, it requested a more detailed comment below. explanation of the mapping referred to.

There was a suggestion to add that a risk-based approach should be used for the mapping, and that it should leverage language in existing regulations with a potential focus on materiality: ‘Financial institutions The mapping should include all of a financial No change. should identify, establish and regularly update a mapping of their institution’s business functions, roles, etc. and not use business functions, roles and supporting processes — using a risk-based a risk-based approach.

approach — to identify...’. The requirement as it stands would be a

Paragraph 16 challenge and probably not sustainable. One respondent suggested that financial institutions should also make statements concerning the importance of the identification of ICT risks The mapping of the ICT infrastructures is a part of the No change. in their organisations. The institutions should then do the mapping of next step (as in information asset), see paragraph 18. business functions, roles and supporting processes and ICT infrastructures and link these to the ICT risks.

One respondent suggested that the mapping is done every 3 years. The No change. mapping requirements in the EBA’s current drafting seem to indicate The current wording about the regular update of the that it would be expected of firms to complete a mapping of all mapping is sufficient and provides the proportionality needed. In regard to the information assets there is no functions, across all jurisdictions and legal entities. The respondent therefore also recommends that the EBA clarifies the scope and differentiation between inter-group or other Paragraph 17 expectation of firms, to ensure that this is realistically completed, in line outsourcing arrangements. with business criticality and firms’ risk appetites. With regard to third parties, it is not clear to the respondent if the requirements are in addition to the EBA Guidelines on outsourcing These guidelines and the EBA Guidelines on No change. outsourcing arrangements coexist (see paragraph 7 of arrangements, in particular relating to inter-group arrangements or these guidelines). fourth parties.

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

Another respondent suggested that ICT assets (software and hardware) No change. and physical necessities (such as buildings, workplaces), both internally The ICT assets are included in the ICT systems. provided/owned and from third parties, should be included.

The guidelines One respondent suggested that the word ‘people’ should be replaced Based on the suggestion and according to have been by ‘organisational function’. EBA/GL/2017/11, ‘people’ will be replaced by ‘staff’. amended.

One respondent commented that paragraph 41 of the EBA Guidelines Each financial institution needs to define their own on ICT risk assessment under the supervisory review and evaluation level of criticality; therefore, the definition depends on process (EBA/GL/2017/05) outlines conditions for identifying critical ICT the financial institution. systems and services, whereas currently no reference to those guidelines is made. Clarification on this point is also relevant for further paragraphs where criticality is mentioned, such as paragraph 49. The EBA considers that the result of the classification is Furthermore, the respondent was of the opinion that the costs to know different levels of criticality; therefore, the 4.3.3. associated with the classification of supporting processes and lower levels should not be excluded upfront. Classification information assets in addition to the business functions clearly exceed No change. and risk the potential benefits. It therefore suggested limiting the classification assessment - in terms of criticality to business functions only and, if considered Paragraph 18 necessary, to major supporting processes related to critical business functions. Another respondent requested clarification on the classification of criticality of business functions with reference to areas such as their key roles in the financial statement, the decision-making process, 24/7 customer service (e.g. e-channels), cash withdrawal, money transfer and payment services, risk or compliance-related areas and strategic planning.

4.3.3. Adding that the regulation requirements is to be No change. Some respondents suggested that criticality is defined by Classification considered is too generic. Next to that, regulatory and risk regulations/standards, e.g. the payment card industry, the Society for requirements can place expectations/burdens but be Worldwide Interbank Financial Telecommunication (SWIFT) system and assessment not at the same level.

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

Paragraph 19 GDPR, and therefore suggested the wording ‘consider the

confidentiality, integrity, and availability and regulation requirements’.

The EBA does not consider this addition necessary. No change. One respondent commented that this section should focus on structured data, with the proposed wording ‘...consider the confidentiality, integrity and availability requirements on structured data’. The respondent also proposed that a definition of ‘structured data’ should be included in the guidelines (see comments for definitions).

One respondent did not consider that a review of the classification of the information assets and relevant documentation should be done every time a risk assessment is performed, as this task should be Such a review needs to be done while the risk Paragraph 20 included in other activities. In their view, when a risk assessment takes No change. assessment is performed. place, the classification already assigned by the owner of the asset or documentation should be considered to directly determine the possible impact that a risk event could produce.

One respondent was of the opinion that carrying out risk assessments, See also the comment on paragraph 18. The criticality i.e. classification in terms of criticality, on supporting processes and assessment is done by the financial institution and No change. information assets is generally inappropriate and in particular is too needs to include the supporting processes and prescriptive. Consequently, the respondent asked that the guidelines information assets. The work needs to be done limit the applicability of paragraph 21, in particular in the case of the extensively for each process. However, if the risk classification of supporting processes and information assets and also assessment of a particular process shows that the for business functions where risk assessments of the aforementioned process is not vital/critical, then the supporting Paragraph 21 subjects should be reviewed using a risk-based approach. In line with information assets can be evaluated in a risk-based this, major changes as listed in the second sentence in paragraph 21 or process as well. A more extensive risk assessment changes in the underlying ICT risks and related ICT systems should needs to be done for more important information trigger a reassessment of risks. assets. One respondent requested that ‘business function’ is defined. It also suggested that this point should be less restrictive so that different risk management methodologies can be implemented depending on the

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

characteristics of the organisation. For a very complex and big The current wording is more general. Defining ‘business organisation, determining the ICT risks to every business function or function’ is too restricting in terms of using different No change. information asset could be difficult to maintain and is not practical. risk management methodologies Two respondents asked for the requirement for updates to be more frequent than 1 year to be deleted, i.e. ‘This risk assessment should be If there is a major change, the risk assessment needs be carried out and documented, annually or at shorter intervals if carried out sooner. No change. required’. The view was that assessments of ICT risks once a year are sufficient, since a new assessment takes place anyway during the course of the year if there are major changes. Further assessments during the year are not appropriate. The risk assessment for periods of less than a year No change. Another respondent asked for clarification of or confirmation that this should be risk based (see also paragraph 1). paragraph covers a risk-based approach, referring to ‘annually or at shorter intervals, if required’.

A request was received to clarify how financial institutions are expected It is not intended to limit financial institutions in their No change. to monitor threats, as there are many different ways to assess ICT risks, approaches; therefore, no further clarification is including scenario analysis and the evaluation of threats and controls needed. against information assets. This request was complemented with a Paragraph 22 suggestion to replace ‘risk scenarios impacting them’ with ‘the ICT risk

framework’.

No change. Another respondent suggested additional wording at the end: ‘and The EBA sees no inconsistencies. The mentioned establish actions and activities in relation to newly discovered risk scenarios should be reviewed.

vectors’.

Two respondents suggested that in addition to providing guidance on No further guidance is needed; this depends on the risk No change. risk mitigation in the form of a risk mitigation plan the guidelines should appetites of the different financial institutions. 4.3.4. Risk clarify the three other ‘T’s of risk mitigation: transfer (by insurance), mitigation tolerate (risk acceptance) and terminate (stop doing the business or ICT process altogether).

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

One respondent proposed mentioning the role of business process No further guidance is deemed necessary, since in the No change. controls to risk mitigation. guidelines the business strategy and processes drive the ICT strategy and processes (see paragraph 4).

Some respondents asked that reporting should be done on an The level of reporting is not specified and depends on No change. aggregated level on the total ICT risk picture for the financial institution the financial institution. to the management body. The view was that requiring individual risk assessments to be reported to the management body is in many cases irrelevant (the information is too detailed) and would demand disproportionate resources, compared with the outcome. Another respondent said that the management body should have the ability to delegate to an individual or forum, to ensure that its time is No change. not dedicated to reading individual risk reports: ‘Risk assessment This is not to be delegated.

results should be reported to the management body individual or forum with the delegated responsibility for ICT risks in a timely

4.3.5. Reporting manner.’ Paragraph 25 One respondent said that ICT risk reporting should take place as part of a broader risk report to the management body and should not be No change. Paragraph 24 does not require a separated ICT and separated out, as, if it is a top risk, it will be identified. security risk report. The timely reporting was commented on and it was suggested that it should be set to a specific threshold, as otherwise it leads to subjective implementation (e.g. quarterly or semi-annually), and the reporting to The requirement to document risk assessment is set in No change. competent authorities should be set to annually. One respondent paragraph 20.

suggested adding the word ‘documented’ before ‘reported’.

Furthermore, two comments were received about deleting the second sentence, as the requirement is already dealt with comprehensively by Because of the scope of these guidelines (PSPs and No change. Article 95(2) of Directive (EU) 2015/2366. Double regulation should be credit institutions), there is no double regulation. avoided.

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

One respondent suggested that quantitative requirements concerning The frequency of such audits is not specified and No change. the minimum and maximum audit frequency should be imposed, depends on the financial institution (see paragraph 26). provided that the bracket is sufficiently wide (for example, from once a year to once every 3 years), in order to accommodate the specific nature of the operations of any given organisation. One respondent requested clarification of whether the requirement that ‘The auditors should be independent within or from the institution’ The requirement is based upon the internal audit No change. excludes the internal audit function. The respondent commented that requirements of the relevant regulations and is internal audit is considered as being independent in financial deemed sufficient. institutions (by any applicable corporate governance model) and should be part of the audit. An external auditor will provide an unbiased opinion; nevertheless, this must also be part of the internal audit responsibilities. 4.3.6. Audit One respondent considered that the methodology should be Paragraph 26 periodically updated, to guarantee that it covers requirements related to new trends and changes in the payment ecosystem (cloud platforms, big data, new technologies, new actors in the payment ecosystem, etc.). Therefore, the respondent proposed adding the The requirement is based upon the internal audit No change. following sentence: ‘The methodology should be periodically requirements of the relevant regulations. Therefore, an updated, to guarantee it considers requirements related to new amendment is not deemed necessary.

trends and changes in the payment ecosystem’.

One respondent asked for the final sentence (‘The frequency and focus of such audits should be commensurate with the relevant ICT risks.) to

be replaced by: ‘The scope and frequency of the audits should be

Due to the principle-based approach of the guidelines,

based on a risk assessment that takes into account the ICT assets

a rewording of the last sentence does not seem No change.

supporting the critical business processes, the identified ICT risks,

necessary. It would actually be limiting, since it focuses

and the prior outcome of ICT and security audits or management

only on the critical business processes, whereas the

reviews.’

audit universe should be more holistic.

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

The financial institution’s management body’s overall

One respondent asked to substitute ‘approve the audit plan’ by ‘be responsibility requires an approval of the audit plan.

Paragraph 27 informed on the audit plan’, as the audit committee is an independent Please refer in this regard also to the EBA Guidelines on No change.

body within the organisation. internal governance under Directive 2013/36/EU

(EBA/GL/2017/11), paragraph 206.

Two respondents asked that the wording ‘security-related’ be deleted The guidelines and stated that the remediation extends to all critical ICT findings, not ‘…remediation of critical ICT security-related audit Paragraph 28 have been just to those that are security related, i.e. ‘..remediation of critical ICT findings should be established.’ amended. security related audit findings should be established’.

One respondent commented that it is unclear on what level in the The guidelines have been clarified and changed to: ‘The The guidelines

organisation the information security policy should be ratified. This policy should be approved by the management body.’ have been

should be clarified in the requirement. amended.

Some respondents said that the wording ‘and based on the relevant The EBA considers that the mentioned sentence is results of the risk assessment process’ should be deleted, since the essential in order to highlight the interconnectedness No change. information security policy establishes the information security of ICT and security risk management and information objectives and the security framework of the financial institution. These security. objectives will determine the risk tolerance and how to manage the 4.4.1. results of the risk assessment. However, the information security policy Information security policy is not based on the relevant results of the risk assessment process, as

stated in these guidelines. One respondent considered that the wording Paragraph 29 in paragraph 29 should be changed by adding at the end: ‘It shall take

into account regulatory and legal requirements for financial

As these guidelines are within the scope of the relevant

institutions and other legal provisions that affect ICT in general.’

regulations (see section on ‘subject matter, scope and No change.

Another respondent suggested removing this paragraph, as this is definitions’), such a clarification is not deemed

already covered by Article 5 of Directive 2015/2366 (PSD2), which necessary.

prescribes the conditions to obtain a licence. One of which is the

development of an information and security policy. It further noted that No change. the responsibility for fraud scenarios lies with fraud operations. The EBA does not see any inconsistencies.

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

A few respondents requested that the information security policy is not Based on the suggestion, the guidelines have been

communicated to third parties, with the suggested rewording: ‘The revised in the following manner: ‘The information The guidelines information security policy should be communicated within financial security policy should be communicated to all staff and have been

institutions, and while to third parties used by financial institutions a contractors of the financial institution within of the

amended. legal document reflecting the necessary parts of the policy will be financial institutions and to third parties used by

communicated. as applicable, and.The information security policy financial institutions, as applicable, and should apply to

should apply to all employees of the financial institutions.’ all employees.’ Paragraph 30

A suggestion was made to clarify that the components of the policy

should be in accordance with the risk tolerance of the financial The EBA considers that components of the policy institution: ‘[…]The policy should ensure the confidentiality, integrity should be in accordance with the risk appetite and that and availability of financial institutions’ critical logical and physical the proposed rewording is not deemed necessary. No change. assets, resources and sensitive data whether at rest, in transit or in use,

according to the risk tolerance of the financial institutions[…].’

The EBA considers that the incident

response/management process is part of the ICT One respondent suggested adding an incident response/management operations management and is, therefore, covered in No change. process (see Section 4.5.1) these guidelines by Section 3.5.1 ICT incident and

Similarly a comment was received that change and configuration problem management. Paragraph 31 management is one of the major factors affecting information security. The EBA considers that the ICT change management is It was recommended that change management becomes a separate part of ICT project and change management and is, No change. point in Section 4.4.1, paragraph 31 and that it is linked to Section 4.6. therefore, covered in these guidelines by Section 3.6.3

‘ICT change management’.

The order of the last two subsections should be reversed and their The guidelines Paragraph 31(f) section numbers should be adjusted in accordance with the section The references have been revised. have been and 31(g) numbering on pages 22 and 23. amended.

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

Further to the comments on Section 4.3.1 (paragraph 11), a number of Based on the feedback received, the guidelines have The guidelines comments were received on the three lines of defence referenced here been amended to follow a ‘principle-based’ approach have been and called for less prescription in the text, citing examples where the by removing paragraphs 32 and 33, and revising amended. current wording would not be appropriate. Respondents suggested that paragraphs 10 and 11. The revised guidelines do not the idea of clearly segregated lines of defence should remain but prescribe to financial institutions how to implement the without assigning specific roles to each one of them. Specifically the 3LoD model for ICT and security risk management guidelines could include a clear description (in line with purposes. The EBA considers that these guidelines are EBA/GL/2017/11 Guidelines on internal governance) of what duties and now compatible with the 3LoD model, with the ICT responsibilities reside with the respective lines of defence, on an overall operational units being the first line of defence. The level. Some examples were given by respondents to illustrate their guidelines now focus in particular on the concerns: there are cases where an information security function/unit responsibilities of the management body and the also includes security operations that are independent from the rest of second line of defence (which usually includes the 4.4.2. ICT operations (e.g. firewall administration vs network administration). information security function) and, following the public Information This segregation ensures that information security is fully independent consultation, the structure of the guidelines has been security (in terms of governance, organisation and technology) and cooperates revised to better reflect this focus. The cross-references function very closely with ICT, but, as an operating model, it effectively creates to the EBA Guidelines on internal governance an overlap between the first and second lines as regards the information (EBA/GL/2017/11) added to paragraphs 10 and 11 are Paragraphs 32 security role in this context. In addition, it would be more efficient to intended to incorporate in these guidelines governance and 33 only list the requirements regarding the security and risk management requirements that are (objectively) valid for the control objectives. Paragraph 32 refers to the information security purposes of these guidelines. function also as a function of the second line of defence and also The guidelines have been revised and now do not mentions that this function is responsible for the security policy and for assign specific roles to each of the three lines of monitoring its implementation and reporting to the management defence but describe the responsibilities of each. independently. This would imply that the CISO function would be part Furthermore, the revised guidelines do not explicitly of the second line of defence. It is not clear how this is related to the require the establishment of an information security internal control function described in paragraphs 10 and 11. A revised function, with the responsibilities assigned to a wording for paragraph 32 was put forward: ‘Financial institutions should designated person, but a reference to the information

establish an information security function, with the responsibilitiesy for

security function is made in the background section. it assigned to a designated person. Financial institutions should ensure the independence and objectivity of the information security function Based on the feedback received, paragraphs 32 and 33 by appropriately segregating it from ICT operations processes (where have been removed. Paragraphs 10 and 11 have been

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

the three lines of defence model is applied, this function should be the revised to ensure the appropriate segregation of ICT second line of defence function — see Section 4.3.1).’ The first change operations, and control and internal audit functions. reflects the fact that the accountability of the security function can be assigned to a single person but not all the responsibilities under the security function (some require a role/team). The second change is because it is considered to be too prescriptive to impose a specific operational or organisational model, given that these may vary significantly across financial institutions. The respondents then proposed that if the phrase ‘where the three lines of defence model is applied, this function should be the second line of defence function — see Section 4.3.1’ is not deleted, clarification should be made of the new role of the information security function in relation to the other second level of defence roles. Reference to the information security function in the Another respondent requested that the requirements in the guidelines The guidelines guidelines has been removed. It is only included in the (and specifically paragraph 32), for an information security function have been background section. should focus on its required level of independence rather than on the amended. organisational structure of the financial institution. One respondent requested clarification of the reference to ‘… this function should be the second line of defence function’. The respondent commented that the information security function, in the best case, could be part of the second line of defence but is not the only component of the second line of defence. The respondent also asked if the operational day-to-day activities related to information security would be part of the first line of defence. In addition, the respondent requested clarification of what Based on the feedback received, paragraphs 32 and 33 person (the CISO?) was referenced in ‘…with the responsibilities The guidelines have been removed. Paragraphs 10 and 11 have been assigned to a designated person’? have been revised to ensure the appropriate segregation of ICT amended. Another respondent proposed that the control function should monitor operations, and control and internal audit functions. and control the information security function and hence that this person The guidelines Based on the feedback received, paragraphs 32 and 33 must be located independently of the control function. have been have been removed. Paragraphs 10 and 11 have been amended.

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

One respondent suggested clarifying that internal audits may be carried revised to ensure the appropriate segregation of ICT

out by the second line of defence (information security management operations and of control and internal audit functions.

system (ISMS) audits) but that they are separate from the internal audit The EBA considers that the control function should not function: ‘In accordance with financial institutions’ internal governance No change. carry out any internal audit, whereas different kinds of structure, financial institutions should ensure that the information security reviews (penetration testing, etc.) are not

security function is not part of the internal audit function. is not

meant here. responsible for any internal audit..’

One respondent was of the view that the tasks listed in paragraph 33

should be performed by the first line of defence and that the second

line should independently control and report on the effective Based on the feedback received, paragraphs 32 and 33 implementation of those tasks. For instance, awareness and training, The guidelines have been removed. Paragraphs 10 and 11 have been risk monitoring controls and reporting are first-line tasks. The second have been revised to ensure the appropriate segregation of ICT line can complement these through independent monitoring, control amended. operations, control and internal audit functions. and assurance reviews, but it should not diffuse the responsibility of the

first line in these areas. Another way to put this is that the second line

of defence should perform its required activities also in the risk area of

ICT and security risk.

Based on the feedback received, paragraphs 32 and 33 The guidelines One respondent commented that having an information security officer have been removed. Paragraphs 10 and 11 have been have been as a measure to secure robust ICT risk management is interpreted more revised to ensure the appropriate segregation of ICT amended. as a function that can be carried out by a team representing the operations, control and internal audit functions. information security function as the second line of defence; it should

not necessarily mean the appointment of an information security 4.4.2. Security individual. It should be clarified that, with the appointment of an function information security officer, the information security function is Paragraph 32 established. According to proportionality it may be necessary for the

information security officer to have a team, but this should be a

question of size and the level of risk exposure of the individual financial

institution. Another comment suggested that the word ‘person’ is

replaced by ‘role, that can be performed by a team or person’.

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

One respondent commented that the first line (operational) and second Based on the feedback received, paragraphs 32 and 33 The guidelines line (information security function) of defence are not described have been removed. The EBA considers that the have been separately and are unclear. For example, in their view, the activity in requirement set in paragraph 33(d) to adhere to the amended. paragraph 33(d) belongs to the first line of defence (operational information security requirements when using third management) and is not the responsibility of the information security parties is covered by Section 3.2.3 ‘Use of third party function. The respondent suggested adjusting the wording of this providers’, paragraph 7. paragraph to ensure that third party adherence to security Paragraph 33 requirements is not difficult/infeasible to enforce. Based on the feedback received, paragraphs 32 and 33 The guidelines

Another respondent suggested adding a new paragraph 33(f) ‘Be

have been removed. However, the EBA considers that have been

involved in all ICT initiatives and projects from their early stages’. It

adding such a general task for the information security amended. should also mention software security controls and data masking in the function might cause conflicts of interest with respect non-production environment. to the monitoring task of the information security functions and its control function.

A comment was received to amend paragraph 34 to include that the Logical access controls have to be implemented, No change. procedures can be designed according to the criticality of data/systems: including the elements stated in paragraph 34(a) to (g).

‘Financial institutions should define, document and implement procedures for logical access control (identity and access management),

according to the criticality of the information assets and systems. ….These procedures should, in principle at a minimum, implement the

4.4.3. Logical No change. following elements …’. security The example is intended to provide clarity but is not Paragraph 34(c): Privileged access rights: A suggestion was received to Paragraph 34 obligatory. delete the example, as granting privileged access rights depends on protection needs ‘with elevated system access entitlements (e.g. The guidelines administrator accounts)’. The EBA considers that all privileged user activities have been should be logged and monitored. Proposed Paragraph 34(d): Logging of user activities: one respondent asked that amended.

clarification: ‘at a minimum, all activities by privileged

this paragraph specify what type of privileged user activities should be

users […]’

logged. The objective should be logging of exceptional activities (e.g.

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

failed logins, reconciliation breaks) and should distinguish between interactive and non-interactive privileged activities.

In paragraph 34(d) there is a reference to retention requirements set The EBA considers that no change is needed because No change. out in EU and national law with regard to the period of time for retaining retention requirements are set out in EU and national access logs. One respondent suggested that this should be clarified and laws. that the data safeguard requirements should be in line with other regulations that give guidance on retention periods at EU level, e.g. GDPR.

Paragraph 34(d): Change to ‘Ffinancial institutions’.

Paragraph 34(e): Access management: new wording was suggested, as The guidelines access rights are withdrawn, not removed: ‘access rights should be The comment has been accommodated. have been

granted, removed withdrawn or modified in a timely manner’.

amended. Paragraph 34(e): one respondent asked for clarification of the definition The comment has been accommodated. of ‘information asset owner’. Depending on circumstances, an ‘information asset owner’ could be a person, a tool or a system. The The guidelines question was raised whether any of these definitions can be accepted. have been In addition, the respondent asked if the definition in the guidelines was amended. consistent with the definition used in the GDPR. In order to make it The EBA would like to clarify that these guidelines easier to understand and create relationships and controls at scale, the specify requirements for financial institutions, based on respondent suggested using the standardised terminology across the CRD and PSD2. On the contrary, the GDPR concerns legislation (e.g. the GDPR and PSD2). the protections of personal data. Consequently, the No change. EBA does not see the necessity for a standardisation of 34 (e) One respondent suggested additional the wording: ‘Access terms in this respect. management: access rights should be granted, removed or modified in a timely manner, according to predefined approval workflows involving

either the applicant’s immediate leader (subject-based approach) and/or the business owner of the information being accessed (information asset owner in an object-based approach).’

Paragraph 34(f): with regard to ‘access rights should be periodically Adding this wording would be too detailed and reviewed’ one respondent suggested that the security function can only therefore not in line with the principle-based approach

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

oversee this process, as this will be the responsibility of each business of these guidelines. The current wording was deemed

owner. sufficient. No change.

Para 34 (g): Authentication methods: new wording was suggested to

avoid multiple interpretations: ‘[…] This may should at a minimum

include password complexity requirements and/or other authentication

methods, based on relevant risk’.

Paragraph 34(g): mandatory two-factor authentication to access critical See comment above.

systems is too burdensome and it was suggested to remove it. The

respondent agreed that it is more secure, but argued that it should not No change.

be mandatory if an adequate privileged access management process is

implemented, e.g. New York Department of Financial Services

(NYDFS) 23 and New York Codes, Rules and Regulations (NYCRR) 500:

‘Based on its risk assessment, each covered entity shall use effective Following feedback received, the guidelines have been

controls, which may include multifactor authentication’. It also amended to reflect a risk-based approach, and two-

questioned whether the two controls for network access are needed for factor authentication is used as an example: ‘This

the server and especially with a check against policy. A question was should, at a minimum include complex passwords or The guidelines raised about whether the server will lose network connectivity if it is not stronger authentication methods (such as two-factor have been compliant any more. The respondent suggested that this control should authentication), based on relevant risk.’ ‘Stronger amended. only be applicable for systems in non-secured areas, e.g. clients. authentication methods’ are not to be confused with

‘strong customer authentication (SCA) under PSD2’ to Another respondent commented that the provision for password be applied by PSPs when carrying out remote electronic complexity is vague, which could lead to multiple interpretations and transactions. SCA is defined as ‘authentication based on therefore that this should be clearer in the text. One respondent the use of two or more elements categorised as

suggested the additional wording: ‘This may include password length,

knowledge (something only the user knows),

complexity, password lockout (both time-based and failed attempts-

possession (something only the user possesses) and

based) policy and expiration period requirements and/or other

inherence (something the user is) that are

authentication methods, based on relevant risk […]’

independent, in that the breach of one does not

compromise the reliability of the others, and is

designed in such a way as to protect the confidentiality

of the authentication data.’

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

The EBA considers that further description would be No change.

unduly burdensome and would not be principle based.

One respondent appreciated that the requirements on logical security,

physical security and ICT operational security follow the content of

4.4.3. Logical generally accepted standards such as ISO 27001/02 or the National These guidelines are explicitly intended to be security, 4.4.4. Institute of Standards and Technology (NIST) cybersecurity framework, technology and methodology agnostic to allow Physical as this contributes to harmonising applicable requirements. However, institutions to leverage on various industry practices. No change. security, 4.4.5. the respondent commented that the draft guidelines deviate from the The EBA considers that reference to specific standards ICT operations structure of the aforementioned standards and therefore is not appropriate. security recommended further alignment to the standards mentioned and

structuring them according to security domains or functions to enhance

readability.

4.4.4. Physical Physical security encompasses protective measures

One respondent suggested a change in title: ‘4.4.4. Physical and

security against environmental hazards; therefore, a change is No change.

environmental security’

not deemed necessary.

There was a suggestion from one respondent to clarify that access to

non-public ICT systems should be permitted only for authorised 4.4.4. Physical The EBA considers the proposed differentiation not

individuals: ‘Physical access to non-public ICT systems should be

security necessary, as it would be an additional source of No change. permitted only for authorised individuals.’ Users of public ICT systems Paragraph 37 complexity. (e.g. automated teller machines (ATMs), information terminals and

account statement printers) have physical access to these.

One respondent suggested that data centres that support financial These are interesting security points for data centres, Data centres institution operations should possess or adhere to internationally

but the EBA considers that such requirements would be No change. recognised certifications, controlled by independent auditors. These too detailed for the purpose of these guidelines. were listed in a comment on Section 4.2.3.

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

The goal of these measures is the prevention of security No change. One respondent commented that this paragraph should encompass a issues in ICT systems and ICT services and minimising risk-based approach. Furthermore, it recommend prescribing the goals their impact on ICT serve delivery. Therefore, a change as suggested is not deemed necessary. instead of the activities in this paragraph. One respondent noted that the chapter starts with an ambition to The EBA would like to highlight that this paragraph ‘identify potential vulnerabilities’ but then continues to describe a set describes measures for implementing procedures to No change. prevent the occurrence of security issues in ICT systems of best practices for ICT security. It recommended that there must be a 4.4.5. ICT clearer connection between the identification of the potential and ICT services. Therefore, the EBA sees the listed operations vulnerabilities and the actions that must be taken as a consequence of measures as appropriate to accomplish these security requirements. the identified potential vulnerabilities. Paragraph 39 Another respondent found the list too prescriptive and suggested the

revised wording: ‘These procedures, following a risk-based approach,

The EBA does not consider the list as examples but as should could include, for example, the following measures’. Another necessary measures. No change. respondent provided suggested wording for paragraph 39, specifically: ‘Financial institutions should implement procedures to prevent the

occurrence of security issues, particularly in critical ICT systems and ICT

Due to the interconnectedness of all ICT systems and services and should minimise their impact on ICT service delivery.’ ICT services, there is a need to observe all security No change. issues.

Vulnerabilities have to be identified before they can be One respondent asked that the wording in paragraph 39(a) is revised evaluated and remediated; therefore, the EBA and suggested splitting what should be achieved (the outcome) and No change. considers that no change is needed. how it should be achieved (the measures). Suggested wording: ‘a)

evaluate and remediate vulnerabilities by ensuring software and firmware are up to date, including the software provided by financial institutions to its internal and external users, by deploying critical security patches or by implementing compensating controls’. Their

view was that currently the wording in paragraph 39(a) on the desired outcome to ‘identify potential vulnerabilities’ that starts this section is

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

not addressed in the text that follows. Instead it addresses the remediation of known vulnerabilities. The EBA considers that the timing of the security Another said that the critical security patches should be deployed by no patches’ deployment depends on their criticality; No change. later than 1 month. therefore, no specific time should be prescribed.

From a network security perspective, one respondent said that it might be counterproductive to only require security baselines for certain ‘critical network components’. Instead, there should be a framework in place that defines the level or type of security baseline for any given The EBA agrees with the comment and that platform network device, in a risk-based manner. Suggested wording: ‘b) secure aspects (such as operating systems and databases) configuration baselines of all network components such as core routers should be included. For clarification, the guidelines are The guidelines Paragraph 39(b or switches should be implemented in a risk-based manner;’ have been ) revised to include: ‘implementation of secure amended. Another respondent considered that secure configuration baselines configuration baselines of all network components’. should be established not only for critical network components, but also for system components (servers, databases, etc.). Therefore, they proposed adding the following reference: ‘Secure configuration

baselines of critical network components […] and system components, such as servers and databases’.

Rewording was suggested to replace ‘leakage’ with ‘loss’, as this derives In line with the suggestion ‘leakage’ has been replaced The guidelines from ‘data loss prevention’ (DLP) not ‘leakage’, and to add ‘detection with ‘loss’. have been and response’ to ‘data leakage prevention systems’. In addition, a amended. comment was received to say that this requirement seems to indicate that it would be expected of firms to complete this blanket control This requirement has to be implemented in a across all activities and therefore a request was received for clarification proportional manner. Therefore no change is No change. Paragraph 39(c) of the scope and what was expected of firms. necessary. Another respondent commented that this point contains a mixture of different security measures with different purposes. To make this paragraph clearer, they suggest an outcome-based approach, e.g. what The goal of the measures is the prevention of security is it that should be achieved with network segmentation, DLP and issues in ICT systems and ICT services and minimising encryption, respectively?

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

Another suggested that, because of its utmost importance as being the their impact on ICT serve delivery. Therefore, a change No change. basis of network defence, ‘network encryption’ should come first in the as suggested is not deemed necessary. list and the ‘or’ should be changed to ‘and’, because the combination of all these elements are necessary for an in-depth and multilayer defence The guidelines mechanism. The wording suggested is ‘the encryption of network Based on the suggestion, the wording has been have been traffic, network segmentation and data leakage prevention systems changed from ‘or’ to ‘and’. amended.

should be implemented;’

One respondent asked if the encryption referred to in paragraphs 39(c) It has been clarified that the encryption of network and 39(f) refers to sensitive data only, or if all data had to be encrypted. traffic and data should be ‘in accordance with the data The guidelines classification’. have been amended.

One respondent asked for this to be explicitly risk based, with the The EBA considers that no change is needed, as the No change. suggested wording: ‘protection of endpoints …should be implemented, guidelines follow a principle-based approach.

according to risk-based principles’.

The EBA considers that financial institutions are Paragraph 39(d One respondent asked if the evaluation of whether an endpoint meets responsible for all their endpoints, including their security standards before being granted access to a corporate network outsourcing to the cloud, i.e. to ensure that these also No change. ) includes servers. They asked how this would work in the cloud: will meet the security standards of the institution. servers lose connectivity, if they are non-compliant? Nevertheless, institutions have flexibility, which comes from the ‘risk-based’ approach that the EBA expects institutions to formulate for themselves.

One respondent proposed an amendment that aims to define the scope of this provision, which in their view could be burdensome and could These guidelines should be applied in a manner that is No change.

also have a strong impact on costs: ‘to verify the integrity of critical

proportionate to the nature, scope and complexity of software, firmware, and information’. Paragraph 39(e the financial institution’s business and the ) One respondent asked what integrity checking for information would corresponding ICT and security risks. be. Another respondent asked that the requirements should be risk In line with the suggestion, reference to ‘integrity- The guidelines based, as integrity checking is not possible in every ICT system (e.g. checking mechanisms’ is removed and they are not have been appliances): ‘financial institutions should ensure that integrity checking specified, in order to ensure that these guidelines are amended.

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

mechanisms are in place to verify the integrity of software, firmware, principle based. Moreover, ‘information’ was replaced and information, where applicable;’ by ‘data’.

One respondent proposed additional wording regarding a risk-based The EBA agrees with the arguments expressed. The The guidelines approach, as it is not possible to encrypt all data at rest and in transit: guidelines have been amended to clarify this: have been ‘encryption of data at rest and in transit. The choice of cryptographic ‘encryption of data at rest and in transit (in accordance amended.

controls should be based on the security objectives (confidentiality, with the data classification).’ integrity/authenticity, authentication, non-repudiation) and be a result of a risk-based approach.’

These guidelines have been amended to clarify this: Others asked for details on which level of encryption will be necessary. The guidelines

‘encryption of data at rest and in transit (in accordance

In transit, is every file, or only the channel (i.e.(TLS) necessary? At rest, have been

with the data classification).’

Paragraph 39(f) is every file necessary? amended. These guidelines have been amended to clarify this: Another respondent suggested clarifying that the requirement should

‘encryption of data at rest and in transit (in accordance

only be on critical or sensitive data, as not all the data needs to be with the data classification).’ The guidelines

encrypted, i.e. ‘encryption of critical or sensitive data at rest and in

have been transit.’ (i.e. either use critical or sensitive). One respondent highlighted The EBA considers that implementing these amended. the importance of applying non-obsolete encryption methods and suggestions would be unduly burdensome and not be sufficient key length. New wording suggested: ‘only non-obsolete principle based.

encryption methods and sufficient key length should be used for

No change.

encrypting data at rest and in transit.’

A comment was received that this paragraph seems very generic and that this should be clarified. In the respondent’s view it is not clear if the The EBA considers that there is no need to further No change. Paragraph 40 control refers to manual processes or if it focuses on automated explain ‘changes’, as it refers to both. processes (i.e. static and dynamic code analysis before going live).

One respondent suggested adding cross-references here to The EBA considers that cross-references between No change. Paragraph 40 Section 4.6.2 ‘ICT acquisition and development’ and Section 4.6.3 sections are not deemed necessary to ensure that these ‘Change management’. guidelines remain concise.

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

Further specification was requested from one respondent on the 4.4.6. Security Further specification is requested on Section 5.2 of the monitoring connection between business/administrative functions Guidelines on security measures for operational and No change. (paragraph 41(a)) and relevant ‘internal and external factors’ security risks (EBA/GL/2017/17). Paragraph 41 (paragraph 41(c))

One respondent recommended that the requirement to ‘constantly The EBA considers that there is no need for rephrasing, No change.

monitor security threats’ should be rephrased to state that ‘financial referring to the principle-based wording.

institutions establish a threat intelligence gathering and assessment

process to identify, triage and counter targeted threats, and that this is

embedded into its log correlation and orchestration processes’. Firms

should know what they are monitoring for. This was reiterated by a

comment on the intention of the wording ‘actively monitoring

technological developments’ and how this should be understood.

Another respondent suggested deleting the following wording ‘.. their The EBA considers that a financial institution should ability to provide services. Financial institutions should actively monitor No change. have the necessary capabilities to actively monitor Paragraph 42 technological developments to ensure that they are aware of security technological developments and should be aware of risks.’, as it was deemed unclear how an institution can do this. Another the associated security risks. respondent commented that there seems to be no consideration of

proactive measures in this paragraph, e.g. threat hunting.

One respondent suggested wording to clarify that proportionality

aspects should be taken into account: ‘Financial institutions should The EBA agrees with the comment and suggestion implement detective measures, for instance to identify possible The guidelines made. The guidelines have been reworded as follows: information leakages, malicious code and other security threats, and have been

‘Financial institutions should implement detective, for

publicly known vulnerabilities of software and hardware, and to check amended.

instance to identify possible information leakages […].’

for corresponding new security updates.’

The intention of this requirement is for the security One respondent commented that it is not clear how the security monitoring process to assist a financial institution to No change. Paragraph 43 monitoring process will help a financial institution identify an have a better understanding of its own systems and operational incident that will be a security incident. risks.

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

A general comment on Section 4.4.7 was received for the guidelines to The EBA considers that a financial institution itself is No change. consider activities carried out by firms to assess and mitigate responsible for their risk assessment and needs to have operational and ICT risks (e.g. operational risk self-assessment) that an understanding of what is useful for their situation. could align with the requirements in these guidelines. Another general The guidelines do not consider that penetration tests comment was on the fact that the guidelines do not include minimum and red team exercises should be mandatory, as testing The guidelines KPIs for ISMSs, the Federal Financial Institutions Examination Council should be proportionate, commensurate to the risk have been (FFIEC) principles for outsourcing and more specific requirements for 4.4.7. exposure of the institution and to the maturity of ICT amended. Information adequate vulnerability/patch management and network segmentation. and security risk management within the organisation. As a consequence, institutions do not know what is useful and what the security The guidelines are clarified by replacing ‘foster’ with auditor will demand. In contrast to this, the number of penetration tests reviews, ‘consider good practices such as’. assessment and is deemed too high. If tests for the effectiveness of the security measures are required after major changes, information security testing incidents and the installation of new internet-facing systems and once per year for critical and every 3 years for other applications, the information security organisation will spend most of its budget on penetration tests and will lose the support of the company in following up. The respondent recommends that it would be better to use the FFIEC wording in the ICT Examination Handbook: ‘frequency and scope of a penetration test should be … determined by the risk assessment process.’

One comment was received that the institution should foster source The guidelines are clarified by replacing ‘foster’ with The guidelines code reviews, penetration tests and/or red team exercises. Another ‘consider good practices such as’. have been respondent proposed new wording to ensure that the selection and amended. intensity of the control measures should be made dependent on the needs or threat situation and that proportionality is taken into account: Paragraph 44 ‘Financial institutions should perform a variety of different information security reviews, assessments and testing, so as to ensure effective identification of vulnerabilities in its ICT systems and ICT services. Specifically, financial institutions may perform gap analysis against No change. information security standards, compliance reviews, internal and

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

external audits of the information systems, or physical security reviews. The EBA considers that the suggested wording is part The guidelines The selection and intensity should be appropriate, depending on the of the proportionality principle: therefore, no change have been needs or threat situation. Furthermore, the institution should foster is needed. amended.

source code reviews, penetration tests, or red team exercises. Other

The guidelines are amended as suggested: ‘or’

instruments to consider include source code reviews, penetration replaced with ‘and’. testing, and red team exercises.’

One respondent suggested that some of the terms in this section should The suggestion is partly accommodated to include be defined in the ‘Definitions’ section (e.g. red team) and some other ‘vulnerability assessment’: ‘Furthermore, the related terms should be also used here for the sake of inclusiveness, for The guidelines institution should consider good practices such as Paragraph 44 example ‘vulnerability assessment’ and ‘blue teaming’ (together with source code reviews, vulnerability assessments, have been ‘purple teaming’). Additional wording proposed: ‘Furthermore, the amended. penetration test and red team exercises.’

institution should foster source code reviews, vulnerability assessments, penetration tests, or blue team - red team (or purple team) exercises.’

One respondent suggested deleting the word ‘new’: ‘and ensure that Based on the suggestions, the guidelines have been The guidelines this framework considers new threats and vulnerabilities’, while amended to replace ‘new’ with ‘identified’. have been Paragraph 45 another suggested substituting ‘new threats’ with ‘identified threats’. amended. Another respondent asked for clarification of whether this paragraph introduces a separate framework.

Paragraphs 45 One respondent asked if a specific security testing environment was The EBA considers that a specific security testing No change. and 46 required. environment is not required. A request was received to specify ‘testing framework’, as in the The testing framework is more than drafting a test plan; respondent’s view it seems that ‘testing framework’ refers to a concept No change. Paragraph 46 therefore, it is necessary to keep the wording. that goes beyond the simple drafting of a test plan to the merits of how the tests are performed.

No change. With regard to the reference to ‘independent testers’, some The reference to ‘independent testers’ includes Paragraph 46(a respondents requested that the guidelines consider a firm’s ability to internal as well as external testers. ) perform tests by internal or external providers, as long as those tests are performed by resources having the necessary level of independence

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

and expertise. This would also highlight that in certain cases, and according to the risk involved, it is more advisable that independent testing is done by internal employees with the necessary separation of duties. Additional wording proposed: ‘are carried out by independent

(external or internal) testers.’

One comment was received to add the word ‘critical’ to better reflect the proportionality principle, i.e. that minor or low-risk changes to non- The proportionality principle is already sufficiently No change. critical or low-risk processes, infrastructure or systems might not need Paragraph 47 included in the wording of ‘tests of security measures security testing, depending on the type of risks associated with the are conducted’. change (risk-based approach): ‘Financial institutions … in the event of

changes to critical infrastructure, processes ….’

One respondent suggested that paragraph 49 should be placed before The guidelines Paragraphs 47 paragraph 47, as the tests conducted on an ongoing basis should be The EBA agrees with the proposal. The guidelines have have been and 49 mentioned before the tests conducted in the event of changes to been amended accordingly. amended. infrastructure, processes or procedures.

One respondent proposed changes to allow flexibility in handling weaknesses that are exposed by security tests and should have the The EBA considers that the obligation to patch cannot No change. flexibility to decide to defer updating a critical system to its next release, be removed in the case of a critical system. There is a timing aspect of ‘when do you patch’, but if this causes as an update might introduce more risk than does the risk of not fixing the weakness. Furthermore, management could be willing to accept the a big delay, the institution should have more robust risk of not implementing a security measure …: ‘Financial institutions systems or methods of patch deployment. Paragraph 48

should continuously monitor and evaluate results of the security tests, and update their security measures on a risk-based approach

accordingly. without undue delays in case of critical ICT systems. A risk The EBA considers that risk-based approach is included by the word ‘accordingly’. No change.

treatment plan should be established including necessary compensative controls, in order to reduce risk, when patching is not an option.’

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

A comment was received on how to define criticality of systems and for See comment on paragraph 18 above the EBA to clarify that the expectation is for firms to demonstrate having No change.

adequate processes for determining criticality and an appropriate

process for action on this basis.

A number of comments were received regarding the testing frequency

of 3 years. Some respondents suggested that the timing of ‘every

3 years’ should be deleted since this paragraph already provides for a

risk-based approach, so there is no need to be more prescriptive. The EBA considers that conducting tests on a risk-based Another respondent considered that testing all the critical security approach but at least every 3 years is critical to ensure measures on an annual basis and all non-critical systems every 3 years No change. effective ICT and security risk management. Testing can be too much for complex organisations and that these requirements systems less frequently than every 3 years may result in should be adapted to the kind of organisation we are talking about. security measures being obsolete. Other respondents considered that the period of 3 years is a long span

of time and that tests for all critical ICT systems should be performed at

least on an annual basis, i.e. based on the asset classification process Paragraph 49 previously mentioned. In 3 years, technology revolutions happen and

attack vectors evolve in impressive ways.

A third view was that new wording should be added to ensure that the The EBA considers that a financial institution has to No change. timing for testing is risk based and the responsibility of the institution: conduct its own risk assessment and conduct the tests

‘Financial institutions should perform on-going and repeated tests of accordingly. However, it is important to ensure that

the security measures, commensurate with the criticality of the ICT tests are conducted repeatedly, but not less frequently

systems.’ For all critical ICT systems (paragraph 18), these tests shall be than every 3 years.

performed at least on an annual basis. Non-critical systems should be

tested regularly on a risk-based approach, but at least every three

years.’

One respondent also suggested that the scope be deleted (i.e. not to

specify ‘non-critical systems’). This respondent commented that No change. The EBA considers that implementing these penetration testing is conducted on all external-facing applications suggestions would be unduly burdensome and not be before going live, annually, and when there are material changes to principle based. As suggested in the example provided, these applications. They test external-facing applications because these

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

are viewed as having a high risk exposure to threat actor operations. an external-facing application should be a critical

Therefore the respondent considered that external-facing applications system.

rather than the criticality of the application would be more reasonable

for taking a targeted approach to penetration testing.

One respondent suggested that this paragraph should be rephrased to The EBA considers the current wording of the guideline

Paragraph 50 prescribe that only certified payment terminals have access to the to be sufficient, as it is in line with the relevant No change.

network. regulation.

One respondent suggested that it seems that the requirement does not

take into account the current trends in payment services technology. The EBA is of the view that, as a rule, PSPs should enter Paragraph 50 requires all PSPs to test security measures implemented into contracts with their outsourcing providers for the in payment terminals and devices used to provide payment services, provision of payment services. Any form of contract payment terminals and devices used to authenticate the user of should be concluded between the PSP and its payment services and devices and software supplied by the payment outsourcer, not with the PSU. The EBA is aware that in service provider to the user of the payment service to enable the user some cases PSPs may not have a close relationship with Paragraph 50 to generate/receive an authentication code. In the case of mobile No change. sub-outsourcing providers because the whole process devices, such as smartphones and tablets, the requirement to test each is under the control of the primary outsourcing device model is not unrealistic, but it may be considered excessively provider. The EBA is also aware that PSPs might not burdensome. Therefore, testing could be restricted to a limited range of enter into contracts with suppliers of end user devices, models, reducing the potential choice of compliant mobile devices. It is such as tablets or smartphones, or providers of suggested that the requirement to test mobile devices (smartphones, operating systems. tablets, etc.) be limited to the testing of the operating system only (e.g.

Android, iOS, Windows Mobile).

4.4.8. The guidelines have been revised to clarify that training The guidelines A comment was received that training should be required for staff with Information programme includes periodic security awareness have been relevant functions and that heightening the awareness of all staff is

security addressed in paragraph 54. ‘… training programme for relevant all staff programmes. They were also amended to clarify that a amended.

training and training programme should be established for all staff, …’ awareness including the management body and contractors. To

ensure that they are well informed, all staff should Paragraph 52 undergo training (including security awareness

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

programmes), as appropriate, at least annually.

Paragraphs 53 and 54 were removed and the guidelines

amended accordingly:

‘Financial institutions should establish 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 trained to address

information security-related risks. Financial institutions should ensure that the training programme

provides training for all staff members and contractors

at least annually.’

The EBA merged a few paragraphs in Section 3.4.8 and The guidelines redrafted the guidelines to require that institutions have been

should ‘establish a training programme, including

A few comments were received on the training and who it is addressed amended.

periodic security awareness programmes, for all staff

to. In particular one respondent questioned whether a security

and contractors to ensure that they are trained to

awareness programme can be considered a targeted information

perform their duties and responsibilities consistent with

security training for staff members occupying key roles. Another

the relevant security policies and procedures to reduce

suggested removing ‘occupying key roles’, as this should apply to all

human error, theft, fraud, misuse or loss and trained to

Paragraph 53 staff. One respondent made the proposal for the additional wording:

address information security-related risks. This

‘Financial institutions should ensure that staff members occupying key ensures that the guidelines can be applied in a

roles and main ICT risk-handling functions (e.g. ICT operations staff,

proportionate manner.

ICT in-house development staff and ICT security management staff)

receive targeted information security training at least annually with The EBA considers that a security awareness

mandatory examinations.’ programme is not considered a targeted information

security training and that applying the requirement to

all staff would be unduly burdensome and would not be

principle based. The EBA considers that examples

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

provided are the examples of roles, but no change is needed to the guidelines in order to keep them principle based. On the last point, the EBA considers that to specify an examination requirement in the No change. guidelines would be too specific.

One respondent proposed the additional wording: ‘Financial institutions should establish and implement periodic security awareness The EBA considers ‘management assistance personnel’ Paragraph 54 programmes to educate their staff, including the management body as part of the financial institution’s staff; therefore, the No change. (together with management assistance personnel), on how to address suggested clarification is not deemed necessary.

information security-related risks.’

The word ‘programmes’ was selected in order to speak A suggestion was made to replace awareness programmes with about the whole awareness training, which may Paragraph 54 No change ‘awareness sessions’, as ‘sessions’ is deemed more flexible. encompass sessions but also other things such as manuals.

One respondent proposed adding the designation ‘appropriate’, in Section 4.5. ICT The terms ‘management body in its management No change. order to cater for different internal organisation structures: ‘[…]based operations function’ and ‘management body in its supervisory on processes and procedures that are documented, implemented and management function’ should be interpreted throughout the

approved by the appropriate management body’.

guidelines in accordance with the applicable law within Paragraph 55 Another requested clarification that only material changes in the overall each Member State. ICT risk management documentation should be approved by the management body, since not every tiny change and adaption needs The terms ‘management body in its management management approval, as long as the overall concept is not changed. function’ and ‘management body in its supervisory function’ are used throughout these guidelines without referring to any specific governance structure and should be interpreted throughout the guidelines in accordance with the applicable law within each Member State. This definition is consistent with the EBA Guidelines on internal governance EBA/GL/2017/11. The term ‘management body’ by

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

definition is an appropriate management body and is

already defined in the definitions section of the

guidelines.

The intention of the guidelines is that the initial

development, documentation and implementation of

operational processes and procedures should be

approved by the management body. The management

of changes to ICT and security risk management

processes and documentation is defined in

Section 3.3.1, paragraph 14.

Two respondents emphasised that the way financial institutions decide Paragraph 55 The guidelines require institutions to develop No change. to complete the documentation for their ICT operations and maintain processes and procedures that should consider the their ICT asset inventories may vary and suggested keeping the maintenance of their ICT assets inventories; however, guidelines principle based with regard to how firms decide to do this to they do not specify how these should be achieved, avoid this activity increasing resource requirements and becoming which provides institutions with sufficient flexibility. compliance driven.

Two respondents suggested that the documentation of processes and Paragraph 55 The management body should approve the processes The guidelines procedures need not be performed and approved by the members of and procedures; however, the EBA anticipates the have been the management body but by executive/senior management structures. delegation of the documentation and implementation. amended. Management body approval of the main features of the operations and The guidelines have been amended to reflect this: a corresponding mandate to a responsible member of staff are

‘Financial institutions should manage their ICT

sufficient. Certain management body responsibilities outlined in the

operations based on documented and implemented

guidelines should be amended to permit delegation where deemed

processes and procedures (which, for PSPs, include the

adequate. The proposed wording is ‘Financial institutions should

security policy document in accordance with manage their ICT operations based on documented processes and Article 5(1)(j) of PSD2) that are documented, procedures.’

implemented and approved by the management body. Another commented that it is not possible that the management body

would ‘implement’ any policy that it would approve, as this extends

beyond its strategic role in the governance of the organisation. The

proposed wording is ‘Financial institutions should manage their ICT

operations based on processes and procedures that are documented,

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

implemented and approved by the management body individual or forum with delegated responsibility for ICT risks.’

A few respondents commented on the use of automation in ICT Paragraph 56 The guidelines intend to show that manual tasks may The guidelines operations. Some said that the guidelines should remain principle based cause errors. However, it is also clear that automation have been Automation and suggested removing any reference to the automation of ICT may indeed be one of a number of ways of increasing amended. operations, as firms may achieve operational efficiency through means effectiveness; therefore, the wording is amended to other than automation. These respondents recognised the benefits of

reflect this: ‘Financial institutions should maintain and

automation but also highlighted a number of potential risks, so in

improve, when possible, the efficiency of their ICT

certain processes it still makes sense to include expertise in decisions. A

operations, including but not limited to the need to

change in wording was proposed: ‘To increase the efficiency of financial

consider how to minimise potential errors arising from

institutions’ ICT operations, fFinancial institutions are encouraged to

the execution of manual tasks’.

automise as far as possible, automate ICT operations (e.g. job

scheduling processes, monitoring of ICT systems, maintenance and ‘To increase the efficiency of financial institutions’ ICT

repair of financial institutions’ assets, shift handover) to minimise operations, financial institutions should, as far as

potential errors arising from the execution of manual tasks. Financial possible, automate ICT operations (e.g. job scheduling

institutions should ensure that the performance of their ICT operations processes, monitoring of ICT systems, maintenance and

is aligned with the business requirements.’ Another respondent repair of financial institutions’ assets, shift handover) to

suggested removing the requirement for automation and to add minimise potential errors arising from the execution of

‘consider where automation of ICT operations may provide material manual tasks. Financial institutions should ensure that

benefit in the minimisation of potential errors arising from the the performance of their ICT operations is aligned with

execution of manual tasks.’ the business requirements.’

One respondent commented that, given the relevance of security, this Paragraph 56 ICT security is given sufficient attention in other parts No change. should be taken into account by ICT operations when performing their of the guidelines, specifically in Section 3.4. To avoid duties, at least with the same attention as is given to the other duplication of messages, no further changes are requirements that ICT operations are subject to. Addition of ‘and required in paragraph 53.

security’ is proposed: ‘[…] is aligned with the business and security

requirements’.

One respondent requested clarification on how the requirement ‘as far Paragraph 56 The paragraph has been revised in line with comments The guidelines as possible’ can be measured by competent authorities for compliance. received, and the reference to ‘as far as possible’ has have been

been removed. The EBA considers that, for the amended.

assessment of principle-based requirements,

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

competent authorities are expected to use an approach

that takes into account each institution on a case-by-

case basis.

One respondent recommended that the guidelines remain principle Paragraphs 56 The comment has been accommodated in revised The guidelines based on how firms decide to increase ICT operational efficiencies and and 57 paragraph 53 (see comment above), and examples have been suggested removing the prescriptive requirements on how firms have been removed. amended. achieve this outcome. The respondent recognised the benefits of ICT

operations capacity monitoring and performance management; With regard to paragraph 57 (revised paragraph 54),

however, the implementation of such programmes for financial service the EBA considers that logging and monitoring No change. firms operating globally is often costly, complex and may not deliver requirements are important and need to be in place.

immediately the benefits expected. For example, the logging and However, the manner and extent to which they are

monitoring of procedures for critical ICT operations may not increase implemented is decided upon by institutions

operational efficiency if not implemented appropriately. proportionately.

One respondent suggested that this requirement should also depend on Paragraph 58 The inventory should contain all assets, which then No change. protection needs and the business criticality of the process and/or asset need to be classified for criticality. Maintaining an — only for the critical assets of the bank and only for the key inventory of only critical assets risks omitting assets components. The additional wording suggested is ‘Financial institutions that were not correctly classified. should maintain an updated inventory of their critical ICT assets

(including the core ICT systems, network devices, databases). Another respondent suggested identifying assets that are ‘critical’ in

providing service capability.

One respondent requested clarification of the objective behind a Paragraph 58 Paragraph 58 (revised paragraph 53) does not require a No change. requirement to have a single system to carry this information, as the financial institution to keep the inventory in a single goal of enabling a proper configuration and change management system. The way the inventory is maintained is up to process can be achieved in other ways, including by using a suite of the institution; these guidelines specify only what tools. The respondent acknowledged and agreed that financial should be maintained. institutions should maintain up-to-date inventories of ICT assets.

However, it considered that the requirement in this section should

specify desired outcomes rather than specific features of an asset

management system. Financial institutions that maintain very large

systems may choose to keep asset, configuration, change and

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

dependency information in systems specifically optimised for each use,

rather than in single monolithic asset inventory systems.

One respondent suggested substituting ‘document the configuration’

Paragraph 58 The comment has been accommodated by replacing The guidelines

with ‘contain the configuration’.

‘document’ with ‘store’. have been

amended.

One respondent suggested that clarification was needed on the extent Paragraphs 58 The EBA considers that providing more detailed No change. to which financial institutions have to document interdependencies and 59 recommendations on the level of details or specific between the different ICT assets. solutions would make the guidelines less practical and One respondent suggested specifying the desired outcomes in asset, more burdensome. The intention is to remain principle configuration or change management, to which ICT professionals can based, to allow their proportionate implementation. adhere using verifiable and commercially reasonable means. The

respondent argued that, while it is reasonable to require ICT

professionals to understand the components and/or systems on which

an application or system depends, this is not true in the opposite

direction. For example, while the operating system version on which a

particular application relies is an important dependency to understand,

it would not be practical for an operating system vendor to know all of

the software packages that may at some point run on that operating

system.

One respondent suggested identifying the ‘legal, regulatory or The EBA considers that these legal, regulatory or No change. Paragraph 59

contractual requirements’ that need to be addressed when managing contractual requirements do not need to be captured

the asset. in the inventory of assets on such a granular level.

One respondent suggested replacing ‘ICT assets’ with ‘software assets’

Paragraph 60 The focus of the paragraph is to ensure that relevant No change. because this provision is limited to software assets, as hardware can be ICT assets continue to meet and support business and managed in a different way, following a specific hardware technology risk management requirements. The EBA does not

life cycle. Moreover, the respondent proposed adding ‘or other external

intend to limit the scope to software only, as hardware

ICT experts’ to reflect that it is also possible to have support from third

also needs to be taken into consideration. parties (e.g. for open source solutions) that are not the vendor of the

software. The comment on external experts has been

The revised wording proposed was: ‘Financial institutions should accommodated: ‘ICT assets are supported by their

monitor and manage life cycle of ICT software assets to ensure that they

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

continue to meet and support business and risk management external or internal vendors and or in-house The guidelines

requirements. Financial institutions should monitor that the ICT developers’ have been

software assets are supported by their vendors, or in-house developers amended.

or other external ICT experts and that all relevant patches and upgrades

are applied based on a documented process. The risks stemming from

outdated or unsupported ICT software assets should be assessed and

mitigated.’

One respondent suggested substituting ‘restoration’ with ‘recovery’.

Paragraph 62 The process is a restoration, as backups are performed No change.

for the recovery of a system’s functionality. The EBA

considers that the paragraph’s text is logical and

sequential.

Two respondents recommended that the guidelines remain principle Paragraphs 62 These guidelines requires financial institutions to No change. based in how firms decide to implement data and ICT systems backups and 63 define their backup and recovery processes and restoration procedures and to remove prescriptive requirements requirements, in line with business recovery on how firms achieve this outcome. requirements and the criticality of the data and the ICT One respondent suggested that backup requirements should be aligned systems. However, the EBA does not specify how this to the business recovery requirements. System criticality is more should be achieved. Hence, the EBA has defined aligned to the BIA for technology in business continuity management. principles rather than specific requirements. Another respondent recognised the benefits of ICT systems and data

backups and restoration. However, it suggested that further The EBA specifically mentioned that backup

considerations may be required (e.g. impact tolerance levels, firms risk requirements are defined in line with business recovery

appetite). requirements and the criticality of the data and the ICT

systems.

Some respondents requested further specification of supervisory Paragraph 63 The comment has been accommodated in order to The guidelines expectations for what is meant by ‘sufficiently remote’, in order to avoid remain more principle based regarding the location of have been discrepancies in implementation. One respondent asked for clarification backups. With regard to the remote location, it should amended. on whether it is acceptable that the remote location or locations are in be in such a location that it is not exposed to the same the same city as the primary site but far away in distance. risks as the primary site. The guidelines have been

amended as follows: ‘Financial institutions should ensure that data and ICT system backups are stored

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

securely in one or more locations out of the primary

site, which are secure and are sufficiently remote from

the primary site so they are not so as to avoid being

exposed to the same risks.’

The desired outcome is to recover systems to meet Another respondent asked what was the desired outcome, an RPO or business recovery requirements. As part of setting an RTO? No change. these requirements, firms can consider defining RPOs

and RTOs that are relevant to specific processes,

systems and data.

4.5.1. ICT One respondent commented that the implementation of requirements The EBA considers that the objectives of loss data No change.

incident and in paragraphs 64 and 65 seems to align with the requirements detailed collection and incident and problem management are

problem in the BIS BCBS’s ‘Principles for the sound management of operational different.

management risk’ regarding ‘loss data collection’ (page 11), and recommend

considering adding a reference to this document, as it would help clarify

and trace requirements to their potential source.

One respondent commented that this description was primarily focused Paragraph 64 The EBA considers that the primary objective is to No change. on the aim of incident management. Since Section 4.5.1 was meant for enable financial institutions to continue or resume incident and problem management, the respondent suggested critical business functions and processes when

providing additional wording: ‘The primary objectives of problem

disruptions occur. Problem management processes are

management are to prevent incidents […] (proactive problem

one of the means to achieve this. The EBA describes

management).’

problem management processes in paragraph 60(c).

Several respondents noted that the word ‘financial institutions’ was

Paragraph 64 Drafting change accepted. The guidelines missing. have been

amended.

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

One respondent suggested the additional wording ‘timely resume’, to

Paragraph 64 Suggestion accepted and the guidelines amended as The guidelines emphasise the time criticality issue. follows: ‘[..] continue or resume, in a timely manner[..]’. have been

amended.

One respondent asked for the guidelines to specify and provide Paragraph 64 The guidelines focus on operational and security No change. examples of which incidents are considered security incidents and incidents that are described in the definitions section of which are considered another type of ICT incident. these guidelines.

One respondent expected financial institutions to have criteria in place Early warning indicators are part of the problem

for (1) operational incidents, (2) security incidents, and (3) early warning identification process and the way in which the No change.

indicators. problem identification process is implemented may

vary between institutions; therefore, any further

details would be disproportionate and burdensome.

One respondent welcomed the principle-based guidance on resumption Paragraph 65 As the guidelines follow a principle-based approach, No change. of service in the event of a disruption but recommended considering providing more specific requirements would not be separating out the list of activities that firms should consider in their practical and proportionate. incident and problem management as examples of how the

requirements could apply or be interpreted.

One respondent suggested that, for internal products/services, there is Paragraph 65(a The comment has been accommodated. Service level The guidelines sometimes no SLA available, so this cannot be used as a benchmark. The ) agreements are not the driver to decide the priority of have been criticality rating is present in every case. The change in wording an incident, as this priority should be based on business amended. suggested is ‘business criticality and or service agreements’ criticality assessments. Reference to ‘service

agreements’ is removed.

Two respondents commented that security incidents outside the Paragraph 65(c) The EBA considers that it is important to take account The guidelines organisation are not part of an institution’s own incident management. of incidents affecting a financial institution that have have been A financial institution is unlikely to be able to act to ‘identify, consider occurred outside, for example at a service provider. The amended. and resolve’ problems external to its organisation. The present wording ways in which to avoid recurrence of incidents, could be misunderstood to mean that incidents within other however, are in the control of an institution. The text of organisations would also have to be considered. the guidelines has been revised to provide more clarity:

‘should analyse operational or security incidents likely

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

The suggested changes in wording are ‘within and/or outside the to affect the financial institution that have been

organisation’ and ‘financial institutions should analyse operational or identified or have occurred within and/or outside the

security incidents that have been identified or have occurred within organisation[…]’.

and/or outside the organisation.’

One respondent suggested further considering the impact on firms Paragraph 65(f) The EBA is aware of the need for multiple submissions No change. operating across multiple jurisdictions of having to comply with multiple across jurisdictions; however, such a proposal is outside requirements or reporting obligations. There is an increasing risk of the the scope of the guidelines. Moreover, the EBA has proliferation of incident reporting requirements for firms, which may flagged this issue to the European Commission in its increase the reporting burden on firms, as well as divert resources from Joint ESA advice on the need for legislative actual risk mitigation. The respondent suggested that the EBA should improvements on ICT risk management requirements consider how to support efficient reporting mechanisms, such as (JC 2019 26). ‘provide once, satisfy many’, or how reporting information could be

aggregated by authorities and shared with industry to support

preparedness and response. The respondent was supportive of an

effective and coordinated incident response plan that would support

the industry in the event of a large-scale disruption, which may require

input and testing with the public sector’s response (e.g. an EU

blueprint).

One respondent proposed adding the words ‘and internal’. The Paragraph 65(f) The suggested change would overlap with No change.

suggested wording is ‘specific external and internal communication

paragraph 60(d), which covers internal communication plans’. plans.

One respondent proposed the addition of ‘(e.g. customers, other market Paragraph 65(f) As the guidelines follow a principle-based approach and No change.

participants, the supervisory authority, any existing sectoral

(ii) the list of examples cannot be exhaustive, the EBA

CERT/CSIRT), as appropriate’ to ensure maximum involvement of sector

considers that providing more specific examples would structures dedicated to cybersecurity in order to facilitate crisis not be practical or proportionate. management coordination and sectoral response in case of systemic

events.

As the guidelines follow a principle-based approach and Another respondent suggested that there may be clashes with other the list of examples cannot be exhaustive, the EBA legal provisions here, as potentially confidential (e.g. personal) data that No change.

may be protected by law and for which the guidelines are unlikely to be

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

an adequate basis for encroachment in every case can be affected. The considers that providing specific examples would not suggested additional wording is ‘to provide timely information to be practical or proportionate. external parties (e.g. customers, other market participants, the supervisory authority), as appropriate and in line with the applicable

regulation and legislation (e.g. GDPR).’

4.6. ICT project Many respondents suggested that Section 4.6, ‘ICT project and change The EBA has updated all of Section 3.6 to make it more The guidelines and change management’, should be redesigned to allow modern project principle based and technology neutral. have been management management practices to be used for system/application development amended. The EBA defined the desired outcomes of these (e.g. Agile, Tribes). Agile principle guidelines and the principles that institutions can apply It was suggested to focus more on what is to be achieved (control to achieve these outcomes. The guidelines do not seek The guidelines principles) and less on how this should be achieved. Draft requirements to define specific ways in which the outcomes can be have been could be perceived to dictate that project management and system achieved, and it is up to institutions to decide how best amended. development methodologies should follow the waterfall model, i.e. a to apply these principles. The EBA applied the principle linear sequential design approach for software development. Most of proportionality throughout the text and focused on financial institutions have already or are in the process of adopting agile creating technology agnostic and future proof software development. This is another example of these guidelines guidance. Hence, the EBA does not specify what limiting the options available for financial institutions, in this case not software development methodology is to be used nor only related to risk management but also to business development. what specific standards or technology are to be applied. The executive summary has been amended to include One respondent proposed amending this section in such a way that it

the following sentence: ‘These guidelines intend to be

facilitates agile working in ICT development projects. Financial

technology and methodology agnostic.’

institutions have increasingly adopted agile ways of working in the development of software. This means that the requirements described Based on the suggestion, the paragraph has been in paragraph 73, which envisage that the process of the development of revised and prescriptive elements removed. Instead, ICT systems should include a), b), c) and d), cannot be met by the the guidelines now require that ‘This process should be financial institutions that use agile methods. In competitive designed using a risk-based approach. Include: environments, the need for flexibility, especially with the limited a) setting objectives during the development phase; separation of duties and new ways of organising projects, is seen as b) technical implementation (including secure The guidelines mandatory. coding/programming guidelines); have been c) quality assurance standards; and amended. The iterative approach of ‘agile’ methods supports a product rather than a project mindset. This provides greater flexibility throughout the

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

development process, whereas in projects the requirements are d) testing, approval and release, irrespective of whether

defined and locked down from the very beginning, making it difficult to the development is done in house or externally by a

change them later. Iterative product development allows the software third party’

to evolve in response to changes in business environment or market

requirements.

One respondent suggested that the guidelines should rather focus on References to the phases of each project have been The guidelines

providing clarification of supervisory expectations regarding adequate removed in order to ensure that these guidelines are have been

governance and control related to (material) changes. The respondent software development methodology agnostic: ‘[…]ICT amended.

considered that some requirements of the draft guidelines are project management policy that defines the phases of

expendable and not fit for purpose. In particular, where the guidelines each project and includes as a minimum’.

outline the implementation of ICT-related changes primarily through a

project setup, there is a lack of insight on state-of-the-art ICT challenges.

The respondent considered that the draft guidelines focused too

strongly on project setup, which did not fit the actual practice in, among

other things, software development. Software is increasingly being

developed continuously or in agile project setups (e.g. Scrum) rather

than in so-called ‘waterfall’ project setups (as particularly indicated in

paragraph 68 of the draft guidelines). No change. Logical access controls have to be implemented, Another respondent advised adding a provision in Section 4.6 on the use including the elements stated in paragraph 31(a) to (g). of control mechanisms, regardless of the methodology employed.

The revised Section 3.6 defines principles relevant to One respondent suggested the possibility of including the draft project and change management processes that guidelines on ICT project management (i.e. Section 4.6.1) as general The guidelines financial institutions can apply to ensure that changes requirements for, for example, project and change management, into have been to production systems are recorded, tested, assessed, the Guidelines on internal governance under Directive 2013/36/EU amended. approved, implemented and verified in a controlled (EBA/GL/2017/11). It argued that the draft Guidelines on ICT project manner, with the aim of ensuring that ICT projects have management, as specified under Section 4.6.1 of the draft guidelines, appropriate governance and oversight and that the do not contain any ICT-related specifications but constitute general development of applications is carefully monitored requirements on project management that are applicable to a multitude from the test phase to the production phase.

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

of fields and should therefore be incorporated (including agile project The executive summary has been amended to explain No change. setups) in guidelines that focus on institutions’ organisational duties. that these guidelines are technology agnostic. Furthermore, the EBA considers that changing the Guidelines on internal governance would be counterproductive.

General 4.6 One respondent acknowledged the importance of ICT project The executive summary has been amended to explain management and promoting adequate standards to ensure the safe and that these guidelines are technology and methodology secure implementation or change of ICT systems, but recommended agnostic and hence the EBA does not specify what that the guidelines remain principle based regarding how firms standards or methodology should be used to achieve No change. implement adequate standards for ICT project and change the requirements of the guidelines. management, and rather focus on firms being able to demonstrate adequate capabilities and outcomes.

General 4.6 One respondent suggested including provisions associated with risk In these guidelines, Section 3.4.4 on ICT operations management, since it must be an inherent part of changes, acquisitions, security requires institutions on an ongoing basis to new developments, projects, etc., to enable the ‘security by design and determine whether changes in the existing operational by default’ paradigm. environment influence the existing security measures or require the adoption of additional measures to mitigate related risks appropriately. These changes should be part of the financial institutions’ formal No change. change management processes, which should ensure that changes are properly planned, tested, documented, authorised and deployed.

A combination of requirements in Section 3.4.4 and Section 3.6 will ensure that information security requirements are considered.

4.6. ICT project One respondent suggested that the implementation of this requirement Financial institutions should ensure that changes to and change seemed to indicate that it would be expected of firms to complete this production systems are recorded, tested, assessed, No change. management blanket control across all activities regardless of criticality; it approved, implemented and verified in a controlled

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

Paragraphs 66 recommended clarification of the scope and of what would be expected manner. An institution should decide how to 82 of firms and that it would be performed using a risk-based approach to requirements in Section 3.6 apply, considering the ensure that it is realistically completed, in line with best practices. scale and complexity of the project or change, the nature of the change or project and related activities, the types of services affected and the corresponding ICT and security risks related to the financial institution’s processes and services affected by the change or project.

4.6.1. ICT One respondent suggested that Section 4.6.1 on ICT project Section 3.6.1 defines important principles related to project management should be removed, as it is too high level and, to a large project management. Although there are some management extent, is a repetition of more specific and concrete requirements references to this process in other sections of the covered elsewhere. The guidelines already required institutions to guidelines, it is important to keep this section to ensure No change. assess risks in major ICT changes (Section 4.6.3: ICT change that a holistic set of principles is defined. management; Section 4.3.1, item 15: identify and assess ICT risks resulting from major change; Section 4.3.3, item 21: ICT risk assessment to be performed annually or on any major changes).

The reference to procurement management has been One respondent suggested that as these guidelines contained ICT and removed to ensure better consistency with a principle- The guidelines security risk management provisions, procurement management is not based approach. Furthermore, procurement have been within the scope of these guidelines. management-related principles are sufficiently defined amended. in the EBA Guidelines on outsourcing arrangements.

One respondent commented that the guidelines particularly Paragraph 66 To accommodate the comment, the EBA has amended The guidelines emphasised the implementation of the ICT strategy through ICT projects paragraph 6 in Section 3.2.2 on ICT strategy: ‘Financial have been but that the objectives of the ICT strategy could be implemented by institutions should establish sets of action plans that amended. various equivalent means. The respondent commented that the

contain measures to be taken to achieve the objective

implementation of an institution’s strategy should be effectively

of to support the ICT strategy. These should be

supported through adequate governance processes and therefore

communicated to all relevant staff (including

considered the requirements in the guidelines misleading, as they might be interpreted by institutions as supervisory expectation to

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

implement ICT-related strategic objectives exclusively through projects. contractors and third party providers where applicable

The respondent suggested that instead of focusing on project setups, and relevant).’

clarification of supervisory expectations should focus on an adequate

Section 3.6. paragraph 61 has also been revised: ‘A

control or change management framework (see Chapter 4.6.3.).

financial institution should implement a programme

and/or project governance process that defines roles, responsibilities and accountabilities e adequate

project implementation leadership to effectively support the implementation of the ICT strategy through ICT projects.’

Paragraph 71 has also been deleted.

Three respondents requested a clear definition or clarification of ‘an Paragraph 66 The EBA defined key principles of the project The guidelines adequate project implementation leadership’. governance process to include roles, responsibilities have been

and accountabilities. However, how this project amended.

governance is implemented is up to each institution.

One respondent suggested that financial institutions should also Paragraph 67 The EBA considers that the requirements related to monitor and mitigate risks regarding the involvement of external No change. relationships with third party providers are sufficiently solution providers during the project (e.g. transfer of confidential data covered in Section 3.2.2 –—Strategy, Section 3.2.3 — during development or development environments in the cloud). Use of third parties and Section 3.6.2 — ICT systems

acquisition and development.

One respondent suggested that the requirements of this paragraph are Paragraph 68 The EBA has removed ‘phases of each project’ to depart The guidelines too prescriptive, as they do not allow strategy implementation through from the waterfall approach, but the EBA considers that have been non-project activities, e.g. agile/lean methods. The respondent the underlying principles still remain even if using agile amended. suggested deleting and includes at a

methodology: ‘ICT project management policy that

minimum: and the points (a)-(g).’. Another respondent suggested

defines the phases of each project and includes as a

making them examples and not minimum requirements. Furthermore, minimum’. in order to allow agile project development methods, additional

wording at the end of paragraph 68 was proposed: ‘For agile development, corresponding methods can be used.’

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

One respondent suggested that the requirements of this paragraph are Paragraph 69 The guidelines have been amended in line with the The guidelines too prescriptive, as they do not allow strategy implementation through suggestion. have been non-project activities, e.g. agile/lean methods. The following changes

amended.

were suggested:

‘The policy should ensure that information security requirements are

analysed and approved by a function that is independent from the

development function. through all phases of an ICT project.’.

Two respondents asked which function that was independent from Paragraph 69 Paragraph 61 defines project governance process, The guidelines development had enough authority to analyse and approve the security which will be relevant for defining the independent have been requirements. One respondent asked for clarification of the desired function responsible for ensuring that information amended. outcome, and pointed out that in a DevOps development scenario, this security requirements are considered. method may slow down the delivery of security fixes, which seems

contradictory to the requirement to push security patches as fast as

possible.

Some respondents requested a clear definition of ‘adequate knowledge’ Paragraph 70 The aim of the guidelines is to ensure that project and in particular whether it means that the project team’s member participants have knowledge that is both sufficient and should have knowledge about business, if the scope requires it (e.g. a No change. relevant to the project and the related business payment expert), or it means that work stream leads should have processes and systems being developed. project management knowledge, or both.

One respondent suggested that the requirements of this paragraph are Paragraphs 71 See comments on paragraph 66 above. Based on the The guidelines too prescriptive, as they do not allow strategy implementation through and 72 amended text in paragraph 66, paragraph 71 has been have been non-project activities, e.g. agile/lean methods. The following change removed. amended. was suggested: ‘The responsibilities of the project team members should

be defined and documented in the project plan. and approved by the project implementation leader. ‘

It also suggests the following change in the ensuing paragraph:

‘Establishment and progress of ICT projects and their associated risks Risks stemming from projects need to be considered in No change.

should be reported to the management body, individually or institutions’ wider risk management frameworks.

aggregated, depending on the importance and size of the ICT projects,

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

regularly and on an ad hoc basis as appropriate. Financial institutions should include project risk in their risk management framework. ‘

4.6.2. ICT One respondent suggested adding a reference to ISO 27001 A.14 on The guidelines are technology agnostic; therefore, they

systems system/software development life cycle, as ISO 27001 can be do not refer to specific standards or technologies.

acquisition and considered an appropriate software solution. Another respondent Although having a secure software development life No change.

development asked that the principles of secure software development life cycles cycle is good practice, the EBA is not mandating it, but

should be discussed in more detail. rather specifies principles to achieve similar outcomes.

One respondent suggested deleting the minimum requirements for the Paragraph 73 The guidelines aim to provide the facility for a risk- The guidelines acquisition, development and maintenance of ICT systems to allow agile based approach; therefore, the comments have been have been

software development. Another respondent commented that the

accommodated by removing the specific requirements amended. development/maintenance process requirements apply to all ICT set out in items (a) to (d). systems. As these may be highly complex, high-risk systems or simple,

low-risk systems, a risk-based process design should be possible. The

respondent proposed using a risk-based approach and specifying that

the points listed should be included in principle.

One respondent commented that not specifying applications for testing, Paragraph 73(d The guidelines do not intend to be prescriptive. The approval and release would make the rollout of critical security patches ) intention of this requirement was for the security The guidelines for, for example, operating systems, unduly formal and therefore risky. monitoring process to assist a financial institution to have been The respondent proposed clarifying that ‘for financial applications, amended. have a better understanding of its own systems and

additionally testing, approval and release….’

risks. As indicated in the previous comment, items (a)

to (d) have now been removed.

Two respondents suggested revising the wording to allow agile software Paragraph 74 The guidelines have been amended to ensure that The guidelines development. They specifically suggested that the second sentence financial institutions clearly define requirements for ICT have been should be removed. One respondent commented that the proposed systems, and that the guidelines are technology amended. methodology suggests following a one-solution model; however, the agnostic and would apply to agile software respondent expressed a view that in DevOps product development development. scenarios, other methods should be considered. The risk can be

mitigated by breaking the changes into classes of risk and automating

testing batteries for defined risk levels. For example, lower risk issue

testing can then be automated, thereby focusing development

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

resources on critical issues. This method serves to focus attention on Financial institutions should consider the results of

the critical levels and meets the requirement of patching security fixes their risk assessments when deciding what

as fast as possible. methodologies best suit them.

One respondent suggested the additional wording: ‘Financial

These guidelines are technology agnostic and do not institutions should ensure that before any acquisition or development of specify what specific standards or technology should be No change.

ICT systems takes place (e.g. at the request for information phase), […].’

used to comply with the guidelines. The EBA amended

the executive summary to explain that these guidelines

are technology agnostic and hence the EBA does not

specify what software development methodology and

standards should be used.

Two respondents suggested a change in wording to allow more Paragraph 75 The comment has been accommodated. The guidelines flexibility: ‘Financial institutions should ensure that measures are in have been

place to prevent mitigate the risk of unintentional alteration or

amended. intentional manipulation of the ICT systems during development.’

Another respondent commented that only precautions can be taken, as The guidelines

‘prevention’ cannot be fully ensured; therefore, a change of wording The EBA has updated the text to focus the outcome on have been

was suggested: ‘Financial institutions should take precautions ensure mitigating the risk. amended.

that measures are in place to prevent unintentional alteration ….’

The guidelines Another respondent commented that the word ‘development’ creates have been confusion and sought clarification on what these measures should be. The EBA has amended the text to refer to ‘development amended. and implementation in the production environment’.

One respondent proposed adding a reference to business criticality: Paragraph 76 The EBA amended the text to make it more

‘Financial institutions should have a …. their first use. This methodology

proportional and principle based: ‘Financial institutions

should take into account the criticality of business processes and

should have methodology in place for testing and The guidelines

assets.’ Another respondent suggested an amendment to allow agile

approval of ICT systems prior to their first use. This have been

software development: When applicable, regression testing should be

methodology should consider the criticality of amended.

performed to ensure that new ICT systems perform in the same way as business processes and assets. The testing should previously developed and tested systems. They should also use test ensure that new ICT systems perform as intended. environments that adequately reflect the production environment so

When applicable, regression testing should be performed to ensure that new ICT systems perform in

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

that the behaviour of the ICT systems in the production environment the same way as previously developed and tested

can be predicted and sufficiently tested.’ systems. They should also use test environments that

adequately reflect the production environment so that the behaviour of the ICT systems in the production environment can be predicted and sufficiently tested.’

These amendments also ensure that the guidelines are

technology agnostic and do not specify what software

development methodology and standards should be

used.

One respondent suggested mentioning other equally important test Paragraph 76 These guidelines are technology agnostic and do not No change. types apart from regression testing (i.e. unit testing, integration testing, specify what specific types of tests should be used to user acceptance testing). They also suggested using test environments comply with the guidelines. Financial institutions that adequately reflect the production environment so that the should decide what test types are best to ensure that behaviour of the ICT systems in the production environment can be new ICT systems perform as intended, depending on predicted and sufficiently tested. It proposed additional wording in the criticality of business processes and assets that are paragraph 76: affected by a change. They should also use test ‘a) they should use test environments that adequately reflect the environments that adequately reflect the production production environment so that the behaviour of the ICT systems in the environment. The reference to regression testing is production environment can be predicted and sufficiently tested, removed. b) they should use various testing methods, like integration testing, user

acceptance testing and performance testing, align risk-based approach

to ensure that ICT system has the acceptable characteristics, and

c) if applicable, regression testing should be performed to ensure that

new ICT systems perform in the same way as the previously developed

and tested system(s) of the same function or the original system

One respondent requested a definition of ‘errant coding practices.’ Paragraph 77 The text of the guidelines has been revised to provide The guidelines

more clarity on expected processes: ‘Financial have been

institutions should test ICT systems, ICT services and amended.

information security measures to identify potential

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

errant coding practices and systems vulnerabilities that could lead to security weaknesses, violations and

incidents’.

One respondent suggested using the term ‘penetration testing’ in this Paragraph 77 The guidelines are sufficiently clear and principle based section, similar to paragraph 76, which uses ‘regression testing’. The No change. to require testing without specifying exactly what type

suggested additional wording is ‘When applicable, penetration testing

is required.

should be performed to identify system vulnerabilities….’ In addition,

the respondent suggested mentioning ‘technical testing’ and ‘functional

testing’, instead of ‘testing’.

Some respondents suggested replacing ‘unverified’ with ‘unauthorised

Paragraph 78 The word ‘unverified’ encompasses both unauthorised or unaccepted’. No change. and unaccepted.

Some respondents highlighted a wide practice across the industry of Paragraph 78 The EBA amended the text to highlight the objective of copying production data to testing systems, and to ensure adequate protecting the confidentiality and integrity of segregation proposed the additional wording ‘[…] and other nonproduction data in non-production environments. But production environments. Copying of production data to other The guidelines the guidelines remain technology and methodology environments shall not take place. Only scrambled data can reside in have been

agnostic: ‘A financial institution should ensure the

non-production environments.’ amended.

integrity and confidentiality of production data in nonproduction environments. Access to production data is restricted to authorised users.’

One respondent suggested replacing ‘in a comprehensive manner’ with Paragraph 79 The EBA considers that use of the words ‘best practices’ No change.

‘according to best practices’, as reference to best practices avoids the

would create more ambiguity, while ‘in a lack of clarity in the term ‘comprehensive manner’ and caters for future comprehensive manner’ is in line with the principledevelopments in the protection of source code. based and proportionate approach of the guidelines.

Another respondent commented that user documentation does not The guidelines

make sense for all systems, e.g. infrastructure systems, and proposed have been The comment has been accommodated. the following addition: ‘should contain (where applicable) at least user amended.

documentation...’

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

One respondent requested clarity surrounding the desired outcome of Paragraph 79 The EBA considers that the main purpose of this this requirement — i.e. to assist in knowledge transfer from departing paragraph is to ensure the transfer of knowledge from employees or to give existing employees an easier path to information departing employees. discovery. The respondent agreed and acknowledged that source code No change. integrity was critical to the success of any ICT system, but noted that many of the system components require specialised knowledge and may be intellectual property.

One respondent expressed a view that this requirement was partially The requirements in this paragraph are specific to Paragraph 79 No change. the same as paragraph 75. source code management.

Paragraph 80 One respondent requested adding the definition of ‘business-managed In the context of this paragraph, business managed applications’ and using standard definitions (e.g. COBIT, ISO, etc.) where applications are merely an example of ‘ICT systems possible. developed or managed by the business function’s end No change.

users outside the ICT organisation’. The EBA considers

the current wording of the guidelines to be sufficient, as it is in line with the relevant regulation.

Paragraph 80 One respondent requested clarity on the desired outcome of this The desired outcome of this paragraph is to ensure that measure. The respondent said that financial institutions’ processes for ICT systems managed outside the ICT organisation are acquisition and development of ICT systems should not necessarily subject to the same controls as those managed by the apply to systems developed outside the organisations. For instance, if ICT organisation. telephone systems are outsourced to a provider, the ICT function should The EBA is of the view that, as a rule, PSPs should enter manage the performance of the outsourced telecommunications into a contract with their outsourcing providers for the service through an SLA and understand the risks and controls provision of payment services. Any form of contract surrounding this outsourcing. should be concluded between the PSP and its outsourcer, not with the PSU. The EBA is aware that in some cases PSPs may not have close a relation with sub-outsourcing providers because the whole process is under the control of the primary outsourcing providers. The EBA is also aware that PSPs might not enter into contracts with suppliers of end user devices,

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

such as tablets or smartphones, or with providers of operating systems.

Paragraph 80 One respondent requested clarity on the term ‘risk-based manner’. The term risk-based manner is the same as risk-based The guidelines approach, which has been used in other places have been throughout the text. This means that it is up to an amended. institution to define the process applicable for the management of the business-managed applications based on the risk and criticality of these systems. The wording has been amended to be consistent with other parts of the guidelines.

4.6.3. ICT One respondent suggested adding a comment regarding the ‘post- The EBA has updated the text in this paragraph to be change implementation review’, which should give assurance that the change more principle based, removing specific requirements The guidelines management implementation has been done successfully without unexpected of certain elements of the change management process have been impacts. Based on a risk assessment, a ‘post-implementation review’ to ensure that financial institutions focus on outcomes may be required for new implementations as well as for changes to of the change management process and have sufficient amended.

implementations. The suggestion was also made for this section to flexibility to achieves these outcomes. mention proper change documentation, control and approval. Furthermore, the incident and problem management process will provide additional assurance if the implementation is not successful.

The EBA confirms that paragraph 75 considers a risk- Paragraph 81 One respondent requested clarification or confirmation that this No change. based approach and that financial institutions should paragraph covers a risk-based approach. The respondent agreed that an consider the impact of the proposed changes and the ICT change management process should be in place, but suggested that potential implementation risks. not all ICT systems are equally qualified/sensitive.

Two respondents suggested that the requirements in this paragraph Paragraph 81 The EBA has updated the text in this paragraph to be The guidelines were too prescriptive. more principle based, removing specific requirements have been One respondent proposed the following changes: of certain elements of the change management process amended. ‘Financial institutions should establish and implement an ICT change to ensure that financial institutions focus on outcomes management process to ensure that all changes to ICT systems are

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

assessed, tested, approved and implemented in a controlled manner. of the change management process and have sufficient The ICT change management process should contain at least the flexibility to achieves these outcomes by removing the following elements: prescriptive items (a) to (f).

a) a process for recording all change requests to ICT systems; b) an evaluation, testing, and approval process for all change requests to ICT systems - specifically financial institutions should evaluate the impact of the proposed changes and the potential implementation risks. Following approval, and based on the outcome of the evaluation, the process should include a formal acceptance of any new residual risks; c) testing and independent validation processes of ICT systems’ changes for possible compatibility and security implications prior to deployment to production environment; d) an authorisation process, only after which ICT changes move to production. This authorisation process should be undertaken by responsible personnel in such a way so that a rollback can be performed in case of a malfunction; e) a process for urgent or emergency ICT changes. Financial institutions should handle changes in case of emergency (i.e. changes that must be introduced as soon as possible) following procedures that provide adequate safeguards. Such changes should be traceable and notified ex-post to the relevant asset owner for ex-post analysis; and f) a process to update ICT systems’ documentation to reflect the changes carried out, where necessary. ‘

Another respondent requested outcome-based requirements that allow organisations to demonstrably meet the goals set in the guidelines without necessarily imposing a specific deployment process. They provided an example that some recurring changes deemed to be lowrisk changes may be undertaken by automated systems. Under such a The guidelines model, a risk assessment is performed for the class of changes, and have been automated procedures are developed and tested, but each individual amended. change is not independently authorised or formally accepted (although

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

each change would be independently logged for traceability). Such a mechanism allows a repetitive activity to be undertaken over time in a consistent and scalable manner. General One respondent commented that the implementation of the The EBA agrees that ICT and security risk management No change. comment requirement in paragraph 81(c) seems to align with the requirements is a subset of operational risk; however, there is no detailed in the BIS BCBS’s ‘Principles for the sound management of benefit to adding a reference to it in the guidelines. operational risk’ regarding ‘Principle 7: Senior management should ensure that there is an approval process for all new products, activities, processes and systems that fully assesses operational risk.’ The respondent recommended considering referring to this document, as it would help clarify and trace requirements to their potential source.

Paragraph 81(c) One respondent commented that not all changes can be tested The EBA has updated the text in this paragraph to be The guidelines absolutely (e.g. keys), and proposed the following addition: ‘testing and more principle based, removing specific requirements have been independent validation processes of ICT systems’ changes for possible of certain elements of the change management process amended. compatibility and security implications prior to deployment to to ensure that financial institutions focus on outcomes production environment, if technically possible’. of the change management process and have sufficient flexibility to achieves these outcomes, by removing the prescriptive items (a) to (f), including item (c) on testing.

Paragraph 81(d One respondent proposed additional wording: ‘an authorisation As per comment above, item (d) has been removed. The guidelines ) process, only after which ICT changes are permitted to move to have been production.’ amended.

Paragraph 81(e Two respondents requested the clarification of the term ‘asset owners’. As per comment above, item (e) has been removed. The guidelines ) In paragraph 19 there is reference to ‘asset owners’ who are have been accountable for the classification of the information assets. In amended. paragraph 81(e), the reference to the ‘asset owner’ seems to be different, and it is unclear whether it refers to the business owner or the ICT person responsible for the application.

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

Paragraph 81(e One respondent requested a definition of ‘urgent or emergency ICT The EBA has updated the text to provide more clarity The guidelines ) changes’, using standard definitions (e.g. COBIT, ISO, etc.) where on how these changes need to be managed: ‘Financial have been possible. institutions should handle the changes during amended.

emergencies (i.e. changes that must be introduced as soon as possible) following procedures that provide adequate safeguards.’

One respondent suggested that the requirements in this paragraph Paragraph 82 The comment has been accommodated. The guidelines were too prescriptive and proposed the following changes: have been ‘Financial institutions should determine whether changes in the existing amended. operational environment influence the existing security measures or require adoption of additional measures to mitigate the risk involved.

These changes should be in accordance with the financial institutions formal change management process. part of financial institutions’ formal change management process, which should ensure that changes are properly planned, tested, documented and authorised.

4.7. Business One respondent suggested that the guidelines should remain focused The EBA considers that ICT is an essential part of The guidelines continuity on minimum standards for ICT and security risk management and that business continuity management and that it would be have been management the requirements in the guidelines that relate to areas that are not counterproductive not to include business continuity amended. directly related to technology resilience, such as references to business management in the context of the overall objectives of continuity management, are identified and removed. This would ensure these guidelines. Furthermore, this is necessary for that the guidelines are focused on ICT risks and would avoid inconsistent institutions within the scope of PSD2 that are not within or duplicative requirements. the scope of the EBA Guidelines on internal governance (EBA/GL/2017/11).

General One respondent welcomed a risk-based approach for business ICT and security risk management is a part of No change. comment continuity management of ICT systems and services and encouraged the operational resilience. The UK approach is not yet alignment, where relevant, with key concepts developed by the UK finalised and any alignment efforts at this stage would authorities in their proposed approach to operational resilience. not be useful due to the different stages of progress.

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

General One respondent made a general comment that most of the guidelines The EBA considers that the level of detail in the No change. comment regarding business continuity are acceptable. In some cases, however, guidelines is sufficiently practical to achieve the desired the complexity of a financial institution is taken into account and at outcomes while providing institutions with the other times the requirements for the content of plans (BCP and recovery flexibility to do so. plans) are much too detailed. This will lead to plans that are unmanageable, unmaintainable and practically not usable.

General One respondent suggested that the implementation of requirements in The EBA agrees that ICT and security risk management No change. clarification paragraphs 83 to 97 seems to align with the requirements detailed in is a subset of operational risk; however, adding BIS BCBS’s ‘Principles for the sound management of operational risk’ reference to it in the guidelines would create confusion. regarding ‘business resiliency and continuity: Principle 10’, and recommended referring to this document, as it would help clarify and trace requirements to their potential source.

BCM is treated Two respondents stated that it was unclear why BCM is treated as a BCM is not a subset of ICT and security risk. However, as a subset of subset of ICT risk. One respondent commented that this may lead to a in the context of these guidelines, BCM is an important ICT The guidelines new layer of requirements as opposed to business continuity planning concept for the mitigation of ICT and security risks. have been for business as a whole, and risks confusion, mixed control standards On completely separating BCP from business, the EBA’s amended. and the potential duplication of effort with no material benefit. view is that it would be counterproductive to separate The approach in the guidelines diverges from the emerging approaches ICT from the rest of the business process; thus, these and supervisory focus on end-to-end service availability and are considered where relevant (see comment on accountability at the service level. Section 3.7). Another respondent recommended reconsidering the inclusion of the The EBA updated the executive summary with the BCM elements outlined in this section to avoid introducing unnecessary following clarification with regard to Section 3.7: complexity to institutions and a potentially siloed approach to BCM. By ‘Section 3.7 specifies expectations with regard to setting specific requirements for one function (i.e. ICT), at the expense business continuity management and developing of all other functions, the guidelines would undermine this emerging response and recovery plans, including testing, and approach. They would create a discrete and additional layer of BCM their consequent updating based on the testing results. requirements specifically for ICT, as opposed to the business as a whole. Financial institutions should ensure that they have

effective crisis communication measures in place so

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

It argued that this section of the guidelines varies from providing very that all relevant internal and external stakeholders can specific guidance for ICT functions to providing more strategic be informed in a timely manner. ‘The ICT business requirements for an institution’s overall BCM. continuity management processes are an integral part

of the overall institution’s business continuity

The respondent said that the guidance applies a narrow lens to BCM,

management process and should not be separated.’

which may deflect focus from other, equally important, impact types and that effective assurance for large global banks relies on an approach that can be consistently applied across all business divisions and jurisdictions.

Paragraph 83 One respondent suggested that this could refer to the preparation The EBA considers that this paragraph is relevant to No change. phase of BCM when high-availability solutions (e.g. redundancy, data BCM, whereas the processes defined in the other parts mirroring) can minimise the probability of an ICT system and/or service of the guidelines (e.g. risk management, change outage. This ‘going concern’ approach should be given at least as much management, information security and vendor emphasis in the BCM process as is given to those preparations that management) ultimately support a financial activate after the ICT disaster happens (‘gone concern’), where truly the institution’s operational resilience, including ICT. main concerns are limiting losses, disaster containment and making the systems operable again.

One respondent proposed that, although financial market 4.7. (including The EBA considers that it is the financial institution’s No change. infrastructures (FMIs) are a subset of the bank’s interdependencies, paragraphs 93 responsibility to assess risks to its business processes, Section 4.7 (including paragraphs 93 to 95) should caveat the guidelines to 95) including risks from FMIs and to design measures to with an appropriate qualifying statement to exempt banks from the recover affected business processes. Institutions responsibility of FMIs’ business continuity planning and ongoing BCM should consider alternative processes if there is a governance. The respondent explained that financial institutions are failure of an FMI. reliant on third party service providers, including FMIs as payment, clearing and settlement operators, to ensure continuity of services to the customer. FMIs are subject to regulatory requirements for their resilience framework (such as the ECB’s cyber resilience oversight guidance for FMIs or the principles for FMIs issued by the BIS and IOSCO). However, it is not always within the control of an individual bank or financial institution to mandate or ensure compliance of an

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

FMI’s business continuity planning or to test its response and recovery capabilities.

4.7.1. Business One respondent noted that the principle of proportionality applies to all The EBA confirms that the principle of proportionality No change. impact analysis requirements included in the draft guidelines. A system for business applies throughout these guidelines. continuity management is built on a BIA, which enables the identification of critical processes, for which appropriate mechanisms should be in place to ensure business continuity. Depending on the scale of operations and the size of the enterprise, in accordance with the principle of proportionality, the analysis should provide information on the requirements for business continuity management.

Paragraph 84 One respondent requested clarification on whether paragraph 84 Paragraph 17 covers the identification of functions, No change. resembles paragraph 17. processes and assets, whereas paragraph 78 defines BIAs. However, the outcomes of the analysis performed in paragraph 17 can be used for the BIA in paragraph 78.

Paragraph 84 One respondent suggested amending paragraph 84 in such a way that a The EBA considers that scenario planning is an No change. scenario analysis is not expected to be a mandatory part of a BIA. They effective way to assess the impact of severe business commented that, as part of sound business continuity management, disruptions. However, the guidelines do not limit the financial institutions should conduct a BIA by means of, among other BIA to scenario testing only, as its main aim is to assess things, scenario analysis. They pointed out that, according to their exposure to severe business disruptions and their understanding, the scope of the BIA is to analyse a financial institution’s potential impact. exposure to severe business disruptions. The impact derived from such disruptions does not change depending on the underlying scenario (the root cause triggering the disruption). Consequently, scenario analyses do not provide added value within this context. In contrast to this, scenario analyses can add value in other areas of business continuity management, such as business continuity planning, response planning and testing.

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

Paragraph 84 Two respondents requested clarification of which criticality dimension The criticality assessment is defined in Section 3.3.2 as No change.

paragraph 84 refers to, as the guidelines consider criticality in an referred to in this paragraph; also integrity and in

extended sense, assessing the dimensions of confidentiality, integrity particular availability as described in paragraph 78 are

and availability as well as continuity. roughly equal to the term ‘continuity’).

Two respondents requested clarification of what ‘external data’ refers Paragraph 84 This has been clarified by adding that external data can The guidelines to. include third party provider data relevant to a business have been

process or publicly available data that can be relevant amended.

to the BIA.

One respondent requested clarification of whether BCP requirements Paragraph 84 The outcomes of the BIA are used in designing the BCP No change. need to be included in the BIA. as explained in paragraph 80.

One respondent suggested that this section could discuss in more detail Paragraph 85 The EBA does not refer to specific technologies, to No change. other high-availability solutions relevant to different disaster scenarios ensure that the guidelines are technology agnostic and (e.g. disaster recovery as a service (DRaaS), cloud solutions, activefuture proof. active geo-redundant data centres, asymmetrical data mirroring

methods against software errors replicating real-time online, etc.).

One respondent suggested that the reference to disruption of business 4.7.2. Business As noted in earlier comments, adding references to No change. services in paragraphs 86 to 88 (e.g. ‘severe business disruption that’) continuity other documents within the guidelines would create appears highly aligned with the overall approach currently taken by the planning confusion. UK authorities, and potentially the Basel Committee, on operational

resilience, and recommended considering a reference to operational

resilience, to avoid potential inconsistencies or divergent approaches

being developed.

One respondent suggested that, due to financial institutions These provisions are sufficiently covered in the EBA No change. outsourcing ICT functions, BCM provisions must be included in the Guidelines on outsourcing and should not be replicated respective SLAs. It recommended that such a requirement is included in here. Section 4.7.2. They noted that paragraph 92 discussed only the

outsourcing parties’ responsibilities in the recovery plans.

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

Some respondents suggested removing any reference to prescriptive Paragraphs 86 The EBA considers that the approval of the business No change. activities expected from the management body, such as the and 96 continuity plans and the review of the results of tests documentation and approval of business continuity plans are consistent with the management body’s (paragraph 86) or the requirement that identified deficiencies resulting management and supervisory functions as defined in from tests should be analysed, addressed and reported to the the EBA Guidelines on internal governance under management body (paragraph 96). The respondent also suggested Directive 2013/36/EU (EBA/GL/2017/11). reconsidering the need for the management body to approve specific

risk-type policies. Another respondent commented that the The management body in its supervisory function

management body should approve the strategy but not the specific oversees and challenges the management function and

BCPs of all functions; therefore, approval of BCPs should be done by the provides appropriate advice. The management body

executive management. One respondent proposed adding the should monitor, periodically review, and address any

designation ‘documented and approved by appropriate management weaknesses identified regarding the implementation of

body or responsible management’, in order to cater for different processes, strategies and policies.

internal organisation structures. Also the term ‘management body’

refers to board level and BCPs are usually described at a much more

technical level than the board is used to.

Two respondents proposed adding the wording ‘Besides other risks, the

Paragraph 86 The risks are considered in the previous sentence, so No change. plans should support […]’, as BCPs cover all risks, not only ICT risks. there is no need to repeat them.

Two respondents proposed deleting ‘the confidentiality, integrity and

Paragraph 86 Incidents and disruptions can affect confidentiality, No change.

availability of’. One respondent argued that the continuity plans are

integrity and availability, so this should be addressed by intended to respond to unplanned interruptions of critical processes, the BCPs. Continuity is covered by availability. not to incidents of confidentiality or integrity of information (the latter

could cause problems of continuity but not necessarily).

One respondent commented that disaster recovery (the ICT service Paragraph 86 The EBA considers BCPs and disaster recovery No change. continuity) should/can be treated separately in accordance with ISO processes as separate but complimenting each other. standards. The BCP is aimed at ensuring that an institution can

continue operating, while the disaster recovery process

is aimed at recovery activities. The EBA does not specify

which standards should be used.

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

One respondent suggested that financial institutions need to assess Paragraph 86 Section 3.7.1 refers to the necessary considerations for The guidelines their dependencies from third parties and, where necessary, analyse the BIA, which should consider third parties as per have been whether the business continuity and disaster recovery measures put in Section 3.3.2. Furthermore, more guidance on BCM amended. place by third parties satisfies/aligns with the requirements of the related to third party providers relationships is financial institutions. provided in the EBA Guidelines on outsourcing. One respondent requested that Section 4.7.2 should reflect more the BCP process and its connection with third party vendors — BCPs must For clarification, paragraph 78 has been revised to cover this area — than the continuity related to services provided by include a reference to ‘third parties’: ‘[…]The BIAs external parties. 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 Section 3.3.3.’

One respondent commented that the RTO is an objective. If a maximum Paragraph 87 RTO is an objective, since meeting the envisaged time The guidelines time was required, it suggested using the term maximum tolerable is never guaranteed. In addition, the term MTO is much have been outage (MTO). less known, and, in practice, RTO covers MTO. amended. The EBA has updated the text of paragraph 81 to make it clearer that the objective of the BCPs is to recover processes within RTO:

‘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 and

maintain the operations of their critical business activities after a disruption 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).’

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

One respondent viewed imposing a sector critical standard that Paragraph 87 The guidelines do not set a specific RTO value, but the No change. required entities to establish a specific RTO for their sector critical guidelines do require that one is established by the systems as impractical, technically infeasible and potentially a risk to institution in order to have a proportionate and financial stability and a contagion risk. A more practical and feasible applicable objective for recovery that would involve approach is one that focuses more broadly on resumption of service, planning for the necessary efforts for meeting measured by the entity’s best efforts to ensure the ability to safely meet contractual and regulatory service obligations. contractual and regulatory service obligations.

One respondent suggested that application would be facilitated and Paragraph 87 These guidelines are technology agnostic and do not No change. confusion avoided by re-using established and well-known definitions specify what specific standards or technology should be RTO and RPO from international standards when available, e.g. the ISO 22301 used to comply with the guidelines. definition standard definitions for RTO and RPO. It proposed to (1) align the

definition of the RTO with ISO 22301: ‘The period of time following an RTO and RPO were sufficiently defined in the Guidelines

incident within which a product or service must be resumed, or activity on ICT risk assessment under SREP. As there were no

must be resumed, or resources must be recovered.’; and changes introduced, the EBA does not see it necessary

(2) align the definition of the RPO with ISO 22301: ‘The point to which to repeat definitions provided there.

information used by an activity must be restored to enable the activity to operate on resumption.’ One respondent suggested to add ‘timely maintain or restore’ and

Paragraph 87 The guidelines are sufficiently proportionate to allow No change.

‘minimum operation requirements’, in order to add a critical

institutions to decide the best way to comply with these characteristic of what BCM should ensure, which is ensuring the requirements without setting minimum requirements minimum operation requirements for time-critical business functions if and allowing institutions to set those timely there is a major disruption/crisis. The suggested revised wording is ‘and operational requirements through their RTOs and

that they are able to timely maintain or restore the minimum operation

RPOs.

requirements of their critical business activities after a disruption within

a recovery time objective’.

One respondent requested more explanation and examples of how Paragraph 87 The prioritisation requirements will define how the No change. ‘financial institutions should prioritise business continuity actions using recovery of business processes or systems should be a risk-based approach’. It asked if a previous risk assessment is needed prioritised depending on their criticality, for example by to decide which BCP to choose if several BCPs exist depending on the giving restoration priority to the most critical and timescenario, and if a business disruption implies the use several of them. sensitive processes. If separate BCPs are created for

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

scenarios, the term BCP in this document points to the collection of these plans.

One respondent commented that this mix of disaster recovery and ICT Paragraph 87 Paragraph 81 refers to failure and disruption, with the No change. security incidents is not the best practice in the industry, given the fact objective of ensuring business continuity and disaster that these are two different processes that have different recovery, irrespective of the source of failure or characteristics. disruption.

Paragraph 88 One respondent requested clarification of this paragraph, as it implies Paragraph 82 refers to extreme but plausible scenarios, No change. that ICT is responsible for certain fraud scenarios, e.g. phishing. The including cyber-attacks. Institutions need to consider responsibility for fraud scenarios lies with fraud operations. scenarios that affect their ability to provide services. Phishing and fraud may result in disruption (e.g. phishing can spread ransomware). Institutions need to consider how they would recover from the results of these activities.

4.7.3. Response One respondent suggested that regarding the BCM measures, it should Each institution should consider how BCM is No change. and recovery be sufficient from a host competent authority perspective that BCM implemented in their particular entity. If support and plans measures could also be implemented by the parent entity of a cross- services are provided from another legal entity, this border group if the parent entity is situated in an EU Member State. needs to be considered as part of the requirements in Furthermore, guidance is needed with regard to BCM measures Sections 3.3.2, 3.7.1 and 3.7.2. provided by parent entities in third countries. The respondent suggested aligning this with the supervisory equivalence decisions, which allow countries recognised as equivalent to be treated in a similar way to Member States. There were two comments to review the cross-references, e.g. Paragraph 89 The guidelines have been updated. The guidelines paragraph 87 should be paragraph 88. have been amended.

Two respondents requested that the meaning of ‘short-term’ and ‘long- Paragraph 90 The EBA considers that providing a more detailed No change. term’ are clarified. description will not be proportionate, as it is up to the

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

institution to define the length of short- and long-term periods, based on a relevant BIA. However, as a general practice, short term refers to hours or days, whereas long term refers to days and months.

Paragraph 91 One respondent suggested that paragraph 91 should be deleted, as it The objective is to address the fact that sometimes No change. was unnecessary. It argued that to require a second plan with recovery is not possible, for example if a main system alternative options undermines the requirement to have solid response and backups are deleted. Thus, alternative workaround and recovery plans in the first place. Paragraph 90 already requires considerations are required. short- and long-term recovery options, which covers alternative options.

Paragraph 91 Two respondents suggested deleting the reference to ‘unforeseen The proposal would be limiting and the guidelines No change. circumstances’, as it makes the perimeter of the BCP extremely broad. intend to capture a broad range of circumstances that The suggested wording is ‘The plans should also consider alternative may lead to the need for alternative options. options where recovery may not be feasible in the short term because of

cost, risks or logistics, or unforeseen circumstances.’

4.7.4. Testing One respondent recommended considering how mutual recognition of Each legal entity should consider how BCM is No change. of plans tests could be achieved in order to satisfy cross-jurisdictional implemented in their particular entity. If support and requirements where firms operate across jurisdictions. services are provided from another legal entity, this needs to be considered as part of Sections 3.3.2, 3.7.1 and 3.7.2

One respondent suggested that testing activities could be broken down The EBA considers that it is appropriate to avoid No change. into two categories: ‘table top exercises’ and ‘simulation scenarios’. referring to table top exercises, in order to maintain a Although the latter provides a clear view of a plan’s effectiveness, table principle-based approach. top exercises assist in optimising the plans (prior to the simulation tests) without any disruption to business operations.

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

Paragraph 93 One respondent generally agreed that testing of operations was an The comment has been accommodated. The guidelines important aspect of risk management in general, and of BCPs in have been particular, and was of the opinion that testing of services provided by amended. third parties should be limited to ‘where applicable’. This follows widely applicable standards on outsourcing and is in line with paragraph 95(a), according to which financial institutions’ testing of BCPs should include ‘testing of services provided by third parties, where applicable’. An additional wording was proposed: ‘Financial institutions should test their BCPs, and ensure that the operation of their business functions, supporting processes, information assets and their interdependencies (including those provided by third

parties, where applicable) are tested at least annually.[…].’

Paragraph 93 One respondent suggested considering reviewing the expectation of The guidelines aim to harmonise requirements for The guidelines annual testing of critical business functions. It suggested that testing critical business functions and to test plans periodically. have been could be required when relevant changes occur or at least every 3 years, The guidelines do not require everything to be tested amended. rather than on an annual basis. annually, only the critical aspects. Another respondent suggested that a general requirement to test BCPs annually is unreasonable, as testing should be geared to risk/protection

needs. A change of wording was proposed: ‘are tested at least annually regularly.’

Paragraph 94 One respondent suggested considering reviewing the expectation of See comment above. No change. annual updates of BCPs. It suggested that updates could be required when relevant changes occur or at least every 3 years, rather than on an annual basis.

Another respondent suggested that a general requirement to update BCPs annually is unreasonable, as updating should be geared to

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

risk/protection needs. Change in wording proposed: ‘BCPs should be

updated at least annually on given occasions, based on testing results.’

Paragraph 94 One respondent commented on ‘BCPs should be updated at least No changes are required, as paragraph 88 defines what No change.

annually, based on testing results, current threat intelligence and needs to be considered to update the BCP, and

lessons learned from previous events’ and suggested that in business introducing a new term may create more confusion.

continuity this should be called horizon scanning.

One respondent suggested aligning the terms and concepts related to Paragraph 95 Please refer to previous general comment on No change. operational resilience (e.g. ‘adequate set of severe but plausible testing Section 3.7. scenarios’, ‘demonstrate ability to sustain the viability of the business

until critical operations are re-established’) with terminology proposed

by the UK authorities in their approach to operational resilience.

One respondent requested a clarification in the case of including ‘an Paragraph 95(a An institution’s BCP planning and testing should be No change. adequate set of severe but plausible testing scenarios’. It raised a ) based on a BIA and the respective criticality assessment question of whether if the critical functions are tested independently, of business processes. The recovery order should be that is first a critical function is recovered and then another, and so on, defined in the plan and subsequently tested to ensure it can it be considered to be a severe testing scenario. that assumptions made during planning can be

implemented in practice.

One respondent suggested that there should be flexibility in the Paragraph 95(a The guidelines need to set out requirements and could No change. execution of the disaster recovery tests and suggested replacing ) not provide the necessary requirement for such a test.

‘should’ with ‘could’. The proposed change in wording is ‘This should

The EBA considers that testing the switch-over of

could include the switch-over of critical business functions […]’.

critical business functions is necessary for all Another respondent suggested removing the second sentence, as the institutions, but the requirement provides sufficient switch-over called for under paragraph 95(a) is impracticable and flexibility, as it guides institutions to perform tests in a harbours additional risks — no backup system is available for the certain way, but also allows them to use different

duration of testing. ‘This should include the switch-over of critical

methods to achieve the same outcome.

business functions, supporting processes and information assets to the disaster recovery environment and demonstrating that it can run them for a sufficiently representative period of time, and that it can restore normal functioning afterwards.’

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

One respondent commented that this paragraph suggests that use of Paragraph 95(a The guidelines allow that individual systems No change. redundant infrastructure (e.g. servers, data centres) must be ) redundancy is a mechanism to ensure ongoing implemented, but the requirement to have such infrastructure at those resilience, whereas paragraph 89(a) refers to testing levels should be a result of a BIA, risk assessment analysis and the RTO disaster recovery. Also, please note that paragraph 89 parameters defined and the ability of the financial institution to recover mentions ‘until critical operations are re-established’. services within the RTO time. If the RTO time does not exceed the This highlights that this is not a blanket requirement for maximum time and the financial institution is able to recover its services everything. The EBA considers that financial institutions to normal operations in their primary location, then an extra recovery should test existing infrastructure and not create environment may not be required. additional structures.

One respondent suggested that reporting to the management body Paragraph 96 The comment limits the assessment, remediation and No change. should be confined to key aspects. The change in wording proposed is reporting of identified issues to the main ones that may

‘Test results should be documented and any identified main findings or

lead to an institution’s inability to recover if less serious deficiencies…..’. issues are not addressed but in combination can

contribute to a wider failure.

There was a suggestion to add an acronym: ‘4.8. Payment service user 4.8. Payment The acronym if already defined. No change.

(PSU) relationship management’ service user relationship management

One respondent commented that while the term ‘PSP’ is used 4.8. Payment The EBA considers that all guidelines should apply to all No change. throughout the guidelines, certain requirements in this section seem to service user PSPs so as not to favour specific business models and to be only applicable to either a credit institution or a TPP. The guidelines relationship ensure technological neutrality. Therefore, the should therefore specify when a requirement applies to all types of PSPs management guidelines require all security measures to be complied and when they are directed specifically at an account servicing payment with by each addressee in relation to the payment service provider (ASPSP), a payment initiation service provider (PISP) services they provide, regardless of the size of the PSP and/or an account information service provider (AISP). Specific and the business model followed. reference was made to paragraphs 101 to 103, that in their view should

only apply to ASPSPs. Establishing or disabling specific payment However, the guidelines are subject to the principle of

functionalities should be initiated and processed only by these entities, proportionality, set out in Section 3.1, which means

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

as this is the level at which the decision is made, i.e. that the steps that PSPs are required to take to be

Directive 2015/2366/EU (PSD2) does not allow for establishing or compliant may differ between PSPs, depending on their

disabling specific payment functionalities through a TPP. size and the nature, scope, complexity and riskiness of

the particular service(s) they provide or intend to

provide.

One respondent suggested that to make the relationship between the Relationship The EBA agrees with the comment that the PSU should The guidelines TPPs and the ASPSPs transparent for PSUs, the PSU should always be between the always be aware of which PSP is responsible for the have been made aware by TPPs that they are not acting on behalf of the ASPSP. TPPs and the service in question. This concern has been reflected in amended. This will help ensure stronger consumer protection, as it will allow PSUs ASPSPs the executive summary section of the guidelines: ‘The to make more informed decisions and maintain consumers’ trust in the EBA stresses the importance of ensuring transparency, developing payments system. In order to prevent the trust that the PSUs

such that PSUs are always aware of which PSP is

have in the ASPSPs from being misused, the respondent suggested that

responsible for providing them with the payment

Section 4.8 require the TPPs to clearly articulate to the PSUs whether or

service.’

not it is acting on behalf of the ASPSP. To make such a statement

obvious to the PSU, it could be provided in a disclaimer when an

instruction is initiated or added to the TPP’s documentation or guidance

for the PSU.

One respondent suggested that Section 4.8 covers responsibilities that Section 4.8 — These guidelines focus on ICT and security risks as well No change. are outside the scope of ICT; these are covered by operations. This lies General as on security risks, which can be of an operational outside the mandate of the chief information officer. comment nature. Proper communication with the PSU is to be

seen as an important element of an integrated risk

management approach in this context.

One respondent questioned whether the consent of a PSU was required Paragraph 98 The EBA assumes that such consent is already included No change. to send such awareness information (campaigns, bulletins, etc.). — Consent of a in the general contractual agreements related to the

PSU corresponding payment service. It is not in the scope of

these guidelines to define any contractual

requirements in this context.

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

One respondent commented that the wording ‘where product Paragraph 100 As it is a requirement under these guidelines, it is not No change. functionality permits’ creates an ambiguity about whether this is to be seen as optional. However, it should only be optional or not. provided if product functionality permits such an Another respondent suggested that this requirement appeared to be approach. A possible use could be disabling the ability onerous from a merchant’s point of view and requested a clarification to make foreign payments if the user wishes to. In this of the desired outcome for this approach. For example, in many context the proportionality principle set out in payment instances a PSP was integrated into the merchant application Section 3.1 should also be considered. via an API call (white label service), to facilitate a simple integration into

the business. The respondent noted that requirements in

paragraph 100 will require many businesses to rewrite applications.

One respondent recommended informing the PSU about other security- Paragraph 102 The EBA agrees in principle with the respondent. No change. related events as well, for example master data changes (e.g. However, the focus of these guidelines should be on customer’s phone numbers, passwords) and other non-transactiontransactions. This does not exclude the fact that PSPs based events that could help prevent fraudulent activities. might offer additional functionalities if considered

useful.

One respondent commented that there is no differentiation made Paragraphs 103 The EBA agrees in principle with the respondent but No change. between PSUs that are consumers and PSUs that are corporate clients. and 104 would like to point out that, even if there is no explicit With regard to corporate clients, PSPs could expect a more elaborate differentiation in the wording of these guidelines, this knowledge and understanding of risks and threats related to payment does not exclude a differentiation being made in services than PSUs that are consumers. It should be appropriate to practice. In this context the proportionality principle set amend a risk-based approach to these provisions to enable differential out in Section 3.1 should also be considered. treatment of PSUs with regard to the scope of information needed.

One respondent acknowledged the role of PSPs in keeping PSUs Paragraph 103 These guidelines derive from the mandate to issue No change. informed of security updates but suggested that there is a potential risk guidelines in Article 95 of Directive (EU) 2015/2366 to the level playing field and to financial stability if further consideration (PSD2). That means that they are developed under of a horizontal data sharing framework is not developed under PSD2. PSD2 and fulfil the requirements of PSD2 to establish a

level playing field.

One respondent recommended in Section 5.1A adding a new point iii. 5.1. Draft cost- The EBA considers that this is covered by reliance on No change. The suggested wording is ‘ii. the increasing reliance on third parties for benefit third parties (item ii). ICT services and products, often in the form of diverse packaged

The EBA’s analysis Amendments to Comments Summary of responses received the proposals

analysis: impact solutions resulting in manifold dependencies and potential constraints assessment and concentration risks.

iii. increased dependencies between the actors of the financial sector and the ICT infrastructures supporting the sector.’