Prokopieva, Troyanov, Russenov & Partners Law Firm 

Comments on the EBA Guidelines on ICT and security risk management

EBA/GL/2019/04

The EBA has recently updated its Guidelines on ICT and security risk management by adopting new rules in its EBA/GL/2019/04.

The new guidelines apply to Payment service providers (“PSPs”), credit institutions for all activities beyond their payment services and also investment firms.

The “Background and rationale” part of the document gives us an insight into the EBA’s decision-making process in revising its EBA/GL/2017. Not only are the Guidelines designed to elaborate further on certain topics that are crucial to the development of better ICT and security risk management in financial institutions, the guidelines also address the EU Commission’s FinTech action plan, which was issued in March 2018. The FinTech Action plan aims to facilitate the emergence of innovative business models across the EU through innovation facilitators that are scalable on an EU-level, while also increasing competition between the market players. The EU has steadily been falling behind of the curve of the state-of-innovation financial services, because of its fragmented and highly-regulated market, in contrast of China and the USA, which have been the spawning grounds for FinTech giants like WeChat (China) and Robinhood (USA).

1. Legal background

The Guidelines are based on the provisions of art. 74 of Directive 2014/36/EU (the “CRD”) and art. 95 of Directive (EU) 2015/2366 (the “PSD2”).

Therefore, the Guidelines will be imperative for:

(1) PSPs as defined in Article 4(11) of PSD2, and

(2) 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 that are supervising the two groups of entities. Competent authorities have the right to notify the EBA for their intent to not comply with the Guidelines in accordance with art. 16(3) of Regulation (EU) No 1093/2010.

The definition of a ICT and security risk as per the Guidelines is:

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

Or in other words ICT and security risks are such circumstances that may lead to the leaking of confidential information, the corruption or unavailability of the institution’s software or hardware systems and other similar, including unintended system lockouts.

Financial institutions are responsible for coming up with their own, risk-based approach on the ICT and security risks, which they are exposed to, based on their size, internal organisation and the nature, scope, complexity and the particular inherent risks that the services they provide are exposed to.

ICT and security risks can lead to Operational or security incidents, which are defined as:

A singular event or a series of linked events unplanned by the financial institution that has or will probably have an adverse impact on the integrity, availability, confidentiality and/or authenticity of services

While there may be some similarities to article 96 of PSD2, this definition seems to be broader.

1. Governance and strategy.

The guidelines establish that the Management body[1] of the institution is responsible for ensuring that the institution has adequate internal governance and control framework in place in order to mitigate ICT and security risks. This would usually mean that the Management body is responsible for enacting appropriate policies and procedures, as well as providing the staff with the adequate resources in order to ensure the abovementioned goals.

The management body is also tasked with the ensuring of the quantity and skills of financial institutions’ staff in order to maintain an adequate level of ICT operational needs and security risk management. This translates into an obligation to allocate enough budget for the fulfillment of this goal, the organization of appropriate training of key staff on an annual basis or more often, and ensuring that there are enough employees in order to handle the risks appropriately.

The ICT strategy should be aligned with the institutions’ overall business strategy and the Guidelines prescribe that there should be three key points addressed:

1. A plan concerning the institution’s ICT “evolution” in order to effectively support and participate in the business strategy
2. A plan concerning the institution’s evolution of the architecture of ICT, including an overview of the use of third-party dependencies
3. Definition of clear security objectives, focusing on ICT systems and ICT services, staff and processes.

Some institutions already are either certified under PCI DSS or appropriate ISO standards, or plan to meet these criteria in the near future. For these institutions, it could be beneficial to incorporate the respective standard’s requirements into the general IT Security policy or similar document in order to ensure compliance with the present guideline.

The Guidelines also establish the obligation of establishing detailed action plans that contain measures to be taken in order to achieve the goals under pt. 1-3 above. This means that ICT strategy should basically follow the same planning as normal development cycles.

Third-party providers are also discussed in this part of the Guidelines. Notwithstanding the obligations of financial institutions under the guidelines on outsourcing arrangements, institutions should also ensure that their use of any group entities of third parties are not hampering their risk management framework. In order to ensure the continuity of ICT services and systems, financial institutions are required that their contracts and service level agreements with such providers include at least the following:

1. Appropriate and proportionate information security-related objectives and measures including requirements such as minimum cybersecurity requirements, specifications of data life cycle; encryptions standards; network security and security monitoring processes, location of data centers;
2. Operational and security incident handling procedures including escalation and reporting.

In order to comply with these requirements, we suggest that financial institutions develop template contractual clauses to be included in their contracts with third-parties and include specific obligations of key stakeholders in their IT security policies regarding the monitoring of the objectives and standards, imposed via the contracts to these third parties.

• ICT and security risk management framework

Obviously, the first step for financial institutions is to identify the ICT and security risks and based on the findings – to develop a strategy for managing the latter.  The Risk management function or a similar role should be the role responsible to ensure that appropriate processes and controls are developed in order to ensure that this goal is met. This stakeholder should meet the internal control function criteria in accordance with the requirements of Section 19[2] of the EBA Guidelines on internal governance (EBA/GL/2017/11). The control function cannot be the internal audit function, since it has specific obligations under the Guidelines, mainly related to the capacity to independently review and provide objective assurance of the compliance with ICT and security-related activities.

At minimum, the ICT and security risk management policies should include the following processes:

1. determine the risk appetite for ICT and security risks, in accordance with the risk appetite of the financial institution;
2. identify and assess the ICT and security risks to which a financial institution is exposed;
3. define mitigation measures, including controls, to mitigate ICT and security risks;
4. monitor the effectiveness of these measures as well as the number of reported incidents, including for PSPs the incidents reported in accordance with Article 96 of PSD2 affecting the ICT-related activities, and take action to correct the measures where necessary;
5. report to the management body on the ICT and security risks and controls;
6. identify and assess whether there are any ICT and security risks resulting from any major change in ICT system or ICT services, processes or procedures, and/or after any significant operational or security incident.

Most of these requirements are quite self-explanatory. The last two points though would mean that institutions should develop a reporting process and also a process of auditing any material changes to the ICT infrastructure for security risks. Institutions would be wise to meticulously document the steps undertaken in compliance with these points.

A good practice in order to evidence the commitment of an institution to the adherence to the Guidelines is to create a “lessons learned” document whenever a security or ICT risk has materialized or been exposed.

The guidelines prescribe that financial institutions identify, establish and maintain a mapping of their business functions, roles and supporting processes and a mapping of their information assets, supporting the business functions and supporting processes. The institutions should clearly assign accountability and responsibility for the information assets.

For example, a financial institution operates service centers (kiosks) at certain public locations, such as a mall. Therefore, there should be a separate business function – Mall kiosks, for example, which is included in the mapping. Generally speaking, the ICT and security risks related to such a business function include the installation of malware on the terminals, the malicious tampering with the hardware at the kiosk, the risk of theft of the hard drives or other similar equipment, and so on. The responsible person for the information assets should be the location’s manager for the on-site accessible equipment, but said manager should not be responsible, for example, for any cloud service, cash-desk software or other similar asset that the kiosk utilizes.

The mapping should also classify the identified business functions in terms of criticality. In order to assess the criticality, at minimum, institutions should consider how a materialization of an ICT/security risk may hamper the confidentiality, integrity and availability of these functions.

The Guidelines stipulate that the mapping and the risk assessment, made in relation to the latter, should be regularly updated. The risk assessment should be carried out and documented at least annually, or in case of major changes.

Based on the identified risks during the assessment, financial institutions are obliged to determine measures in order to mitigate them. The measures should be adequately documented and the documentation should include timelines for their introduction.

The Guidelines create an additional audit obligation for financial institutions, as stated in point 25 – institutions should be audited on a periodic basis by auditors with sufficient knowledge, skills and expertise in ICT and security risks. Institutions are therefore obligated to approve an audit plan for ICT and security risks.  It is explicitly stated that the auditors can be internal, but nevertheless should be independent (i.e. they should not be directly “managed” or instructed by anyone during their audit).

A special remediation/follow-up process must be created for the findings of the audit plan.

1. Information security

In this part, the EBA directly instructs what the Information Security Policy should include.

The most important takeout from the first part of this part is that the high-level principles and rules incorporated into the Information security policy should be based on the information security objectives and the audit results which we talked about beforehand.

The Information security policy should include requirements for staff and third-party contractors, including an obligation for the latter to be informed about the stipulations of the policy.

Specific points which the Information security policy should include are:

1. organisation and governance rules
2. logical security rules
3. physical security rules
4. ICT operations security rules
5. security monitoring rules
6. information security reviews, assessment and testing rules
7. information security training and awareness rules

Regarding point a), we already commented on the requirements for the organisational and governance rules of the financial institutions. Financial institutions should therefore review the policies in place and adapt them by introducing the new requirements of the Guidelines

Regarding point b), financial institutions should improve or implement policies and procedures for logical access control. Many institutions already apply the “need-to-know” principle in their Access control policy/procedures, which is now explicitly addressed in the Guidelines.  Alongside this principle, the Guidelines also stipulate that institutions should introduce:

• User accountability controls – in practice this means that each employee should have its user account settings individually set and that their actions should be easily identifiable in the ICT ecosystems of the financial institution.
• Privileged access rights – in practice this means that in first place, financial institutions should identify which accounts have elevated system access rights, whether the additional privileges are required by the user, and then introduce stricter controls and monitoring over the use of such accounts.
• Logging – all activities of privileged users must be logged and monitored. Access logs should not be modifiable. Financial institutions should analyse the logs and identify and investigate any anomalies.
• Access management – in practice this requirement is related to introducing a procedure for granting, withdrawing or modifying access rights of users in the ICT systems in a timely manner.
• Access rectification – this requirement basically means that financial institutions should periodically revise the user rights of its employees.
• Authentication – financial institutions should introduce mechanisms such as 2FA for access to their ICT systems, based on their criticality. At minimum, password complexity rules should be introduced in the procedures.

Regarding point c), physical security measures should be introduced, defined, documented and implemented. Such rules may include the definition of high-security areas on premises of the financial institution, fire, earthquake, flood and other counter-measures, etc.

Regarding point d), the procedures for ICT operations security should include in their IT security policy rules regarding:

• Vulnerability testing and remediation;
• Configuration settings for all network components;
• Network segmentation, data loss prevention and encryption in transit;
• Protection of endpoints;
• Integrity verification of software, firmware and data
• Encryption at rest

In relation to point e), the Guidelines stipulate the implementation of policies and procedures to detect anomalous activities or in other words, ongoing monitoring of ICT and security risks. Such monitoring program should include at minimum:

• Internal and external factor defining;
• Specific tests to detect misuse of internal access or access by third parties or other entities;
• Potential internal and external threats defining.

In relation to point f), financial institutions are required to define a program for information security reviews, assessment and testing to ensure that the governance framework related to ICT and security risks is reasonably effective. Such tests and assessments may be pen-tests, compliance reviews, gap analysis, external reviews and similar. At minimum, such activities must:

• Be carried out by independent testers with relevant expertise;
• Include vulnerability scans and pen-tests.

Such reviews must be made at least once a year for critical systems. Non-critical systems may be tested using a risk-based approach, but at least every 3 years.

Specific requirements are introduced for PSPs: the reviews should include payment terminals and devices that are used for the provision of payment services (POS, ATMs, similar); payment terminals and devices used for authenticating the payment service users (tokens and similar); devices and software provided by the PSP to the users to generate/receive an authentication code (such as OTP-generation devices or apps).

In relation to point g), financial institutions should implement a training programme, including periodic security awareness programmes, for all staff and contractors. Such programmes should include trainings to reduce human error, theft, fraud, misuse or loss, for example financial institutions could include a training addressing specifically phishing attacks, social engineering attacks, malware attacks and other similar.

1. ICT Operations management

The Guidelines require financial institutions to document the processes of operating, monitoring and controlling the ICT systems and services, including the documentation of critical ICT operations and up-to-date inventory.

A specific requirement for the critical ICT operations is to include enhanced logging and monitoring procedures in order to facilitate the detection, analysis and correction of errors related to these systems.

Some specific requirements are introduced for the inventory of ICT assetss:

• the inventory should describe the configuration of the assets and the links and interdependencies between them.
• The inventory should be sufficiently detailed – it should include the location, security classification and ownership of the ICT asset.

Lifestyle management should be introduced for ICT assets, as well as patch management rules.

Scalability of ICT assets should also be addressed in the financial institution’s policies.

Backup and restoration procedures should be specifically introduced as a supplementary document to the general IT security policy. Such procedures should at the minimum outline the scope and frequency of backups and periodic testing rules, as well as rules related to the mitigation of the general ICT and security risks by ensuring that the backup/restore points are sufficiently remote from the main ICT systems.

Incident and problem management/disaster recovery policies and procedures are not something new for financial institutions. Such policies and procedures should outline the steps which the employees must undertake in order to continue or resume, in a timely manner, critical business functions and processes when such events occur.

The Guidelines require institutions to create and implement policies related to incident monitoring, handling and follow-up. At minimum, they should establish:

• Identification, tracking, logging, categorisation and classification of incidents;
• Roles and responsibilities for different incident scenarios
• Rules for identification, analyzation and solving of root causes behind incidents. A “key lessons” or “lessons learned” procedure should be enacted;
• Internal communication plans which should outline the relevant persons which should be notified, as well as escalation procedures;
• Incident response procedures (although these should be introduced by virtue of other EBA Guidelines)
• External communication plans for critical business functions, which should outline how to collaborate with third-parties to effectively respond and recover from the incident (i.e. specific instructions on how to communicate with critical SLA suppliers, such as cloud service providers or software providers), as well as specific rules for communicating to customers, market participants and supervisory authorities (also see the EBA Guidelines on Major incident reporting EBA/GL/2017/10).

1. ICT project and change management

A specific part of the Guidelines addresses the rules regarding changes in the ICT infrastructure.

The Guidelines stipulate that financial institutions should appropriately monitor and mitigate risks deriving from the ICT projects. In essence, this would require from financial institutions to introduce a ICT Programme management policy.

Therefore, the Guidelines state that at minimum, such a procedure at minimum should introduce rules for documenting:

• Each new project’s objective;
• The roles and responsibilities related to the project;
• A risk assessment of the project;
• A project plan, timeframe and steps;
• Key milestones;
• Change management rules

A similar approach should be developed and implemented in relation to the acquisition, development and maintenance of ICT systems.

• Before institutions acquire or develop new ICT systems, specific information security objectives and requirements should be defined and approved by the relevant manager.
• A methodology should be introduced for testing and approval of such new ICT systems prior to their first use.
• A specific requirement to introduce modern software development practices is introduced – separation of ICT environments (production and non-production environments). Production environment should be restricted to authorized users.
• A specific point is made for in-house developments. Documentation of the development, implementation, operation and/or configuration of the ICT systems is now a must for financial institutions, with a specific rule regarding dependency on subject matter experts.

• Business continuity management

The Guidelines require financial institutions to introduce a Business continuity policy in order to establish clear rules for the mitigation of risks which may otherwise adversely affect the institutions’ day to day operations. This part of the Guidelines supplements Title VI of EBA/GL/2017/11.

Based on a business impact analysis, which should take into account the exposure to severe business disruptons and potential impacts, including scenario analysis, institutions are required to develop such business continuity procedures that would enable them to recover operations of their critical business activities within a reasonable time, called a recovery time objective (RTO), based on a risk-based approach.

Based on analysis explained hereinabove, institutions should develop response and recovery plans, which explain in detail the actions that should be taken to ensure the availability, continuity and recovery of the critical ICT systems and services, in the RTO timeframes.

The plans, should be easily available and should document the plans for the recovery of critical business functions, processes, assets, including the execution of pending payment transactions. The plans should be updated whenever a “lessons learned” procedure is carried out.

Specific rules should be introduced for third-party providers of key importance. It would be wise for financial institutions to consider intertwining their Outsourcing arrangements policy based on EBA/GL/2019/02 with the plans under the present point.

Specific testing plans for the continuity plans should be introduced, at least annually, and the plans should be updated based on their findings. Such test should include:

• Testing of severe but plausible scenarios;
• Challenging of the assumptions on which the continuity of the institution’s business rests (i.e. third-party availability or adequate response from such third-parties);
• Verification of the ability of the staff and third-parties to adequately respond to incidents.

Crisis communication measures are also something new in this Guideline. Internal, external and authority stakeholders should be informed in a timely and appropriate manner.

• Client relationship management

The Guidelines require that institutions implement a process to provide their Clients with sufficient awareness of the security risks, related to the services of the institutions.

Such communications should be updated regularly in light of new identified threats and vulnerabilities.

Specifically, PSPs are required to allow their clients to disable specific payment functionalities, whenever this is possible based on the backend of the offered product.

Whenever maximum spending limits for transactions made through a specific instrument are agreed between the client and the PSP, the PSP is required to provide the client with the option to adjust these limits by him/herself, up to the agreed maximum limit.

Another requirement is to add the possibility for the client to receive alerts/notifications for initiated or failed attempts to carry out payment transactions, using the client’s payment instruments.

A new requirement for PSPs is to regularly update clients for amendments in the security procedures, that may affect their use of the offered payment services and to provide information on how clients may obtain assistance on their questions, requests and other similar, related to security matters of the payment service.

Conclusion

The Guidelines introduce a sweeping plethora of requirements for financial institutions.

Financial institutions should analyse their existing Global IT security policy, including and supplementing policies and procedures to it. Policies and procedures that may be affected from the new guidelines may include:

• Disaster recovery procedures/policies
• Encryption procedures/policies
• User rights management procedures/policies
• Business continuity and/or recovery procedures/policies
• Incident response and Major incident response procedures/policies
• IT Monitoring procedures/policies
• Outsourcing arrangements procedures/policies
• Internal Control procedures/policies
• Network security procedures/policies
• Servers/cloud storage procedures/policies
• Patch Management procedures/policies
• Third Party security procedures/policies
• Log Management procedures/policies
• Backup procedures/policies

Our team at PTRP is ready to assist you in any matter, related to EBA Guidance, PSD2, 4AMLD and compliance. You may reach out to us using the contact form on our website or at office@eu-bg.com

[1] Which means the persons responsible for the management of the institution, or in other words the Board of Directors or similar governance bodies. Check Definitions section of the guidelines

[2] Citation of par. 153: The internal control functions should include a risk management function (see Section 20), a compliance function (see Section 21) and an internal audit function (see Section 22). The risk management and compliance functions should be subject to review by the internal audit function.