3.3 Assessment of the controls to mitigate material ICT risks

To assess the institution’s residual ICT risk exposure, competent authorities should review how the institution identifies, monitors, assesses and mitigates the material risks identified by the competent authorities in the assessment above.

To this end, for the identified material ICT risks, competent authorities should review the applicable:

• a. ICT risk management policy, processes and risk tolerance thresholds;
• b. Organisational management and oversight framework;
• c. Internal audit coverage and findings; and
• d. ICT risk controls that are specific for the identified material ICT risk.

The assessment should take into account the outcome of the analysis of the overall risk management and internal control framework as referred to in Title 5 of the EBA SREP Guidelines, as well as the institution’s governance and strategy addressed in Title 2 of these Guidelines, as significant deficiencies identified in these areas may influence the ability of the institution to manage and mitigate its ICT risk exposures. Where relevant, competent authorities should also make use of information sources in paragraph 37 of these Guidelines.

Competent authorities should perform the following assessment steps in a manner that is proportionate to the nature, scale and complexity of the institution’s activities and by applying a supervisory review that is appropriate to the institution’s ICT risk profile.

3.3.1 ICT risk management policy, processes and tolerance thresholds

Competent authorities should review whether the institution has appropriate risk management policies, processes and tolerance thresholds in place for the identified material ICT risks. These can be a part of the operational risk management framework or a separate document. For this assessment competent authorities should take into account whether:

• a. the risk management policy is formalised and approved by the management body and contains sufficient guidance on the institution’s ICT risk appetite, and on the main pursued ICT risk management objectives and/or applied ICT risk tolerance thresholds. The relevant ICT risk management policy should also be communicated to all relevant stakeholders;
• b. the applicable policy covers all significant elements for the risk management of the identified material ICT risks;
• c. the institution has implemented a process and underlying procedures for the identification (e.g. ‘risk control self-assessments’ (RCSA), risk scenario analysis) and monitoring of the involved material ICT risks; and
• d. the institution has an ICT risk management reporting in place that provides timely information to senior management and the management body, and which allows senior management and/or the management body to assess and monitor whether the institution´s ICT risk mitigation plans and measures are consistent with the approved risk appetite and/or tolerance thresholds (where relevant) and to monitor changes of material ICT risks.

3.3.2 Organisational management and oversight framework

Competent authorities should assess how the applicable risk management roles and responsibilities are embedded and integrated in the internal organisation to manage and oversee the identified material ICT risks. In this regard competent authorities should assess whether the institution demonstrates:

• a. clear roles and responsibilities for the identification, assessment, monitoring, mitigation, reporting and oversight of the involved material ICT risk;
• b. that the risk responsibilities and roles are clearly communicated, allocated and embedded in all relevant parts (e.g. business lines, IT) and processes of the organisation, including the roles and responsibilities for gathering and aggregating the risk information and reporting it to senior management and/or the management body;
• c. that the ICT risk management activities are performed with sufficient and qualitatively appropriate human and technical resources. To assess the credibility of the applicable risk mitigation plans, competent authorities should also assess whether the institution has allocated sufficient financial budgets and/or other required resources for their implementation;
• d. an adequate follow-up and response of the management body regarding important findings from the independent control functions regarding the ICT risk(s), taking into account the possible delegation of some aspects to a committee, where this exists; and
• e. that exceptions from applicable ICT regulations and policies are recorded and subject to a documented review and reporting by the independent control function with a focus on the related risks.

3.3.3 Internal audit coverage and findings

Competent authorities should consider whether the Internal Audit Function is effective with regards to auditing the applicable ICT risk control framework, by reviewing whether:

• a. the ICT risk control framework is audited with the required quality, depth and frequency and commensurate with the size, activities and the ICT risk profile of the institution;
• b. the audit plan includes audits on the critical ICT risks identified by the institution;
• c. the important ICT audit findings, including agreed actions, are reported to the management body; and
• d. ICT audit findings, including agreed actions, are followed up and progress reports periodically reviewed by the senior management and/or the audit committee.

3.3.4 ICT risk controls that are specific for the identified material ICT risks

For the identified material ICT risks, competent authorities should assess whether the institution has specific controls in place to address these risks. The following sections provide a non-exhaustive list of the specific controls to be considered when assessing the material risks identified under point 3.2.3 that were mapped to the following ICT risk categories:

• a. ICT availability and continuity risks;
• b. ICT security risks;
• c. ICT change risks;
• d. ICT data integrity risks;
• e. ICT outsourcing risks.
• (a) Controls for managing material ICT availability and continuity risks

In addition to the requirements in the EBA SREP Guidelines (para 279 - 281) competent authorities should assess whether the institution has an appropriate framework in place for identifying, understanding, measuring and mitigating ICT availability and continuity risks.

For this assessment, competent authorities should, in particular, take into account whether the framework:

• a. identifies the critical ICT processes and the relevant supporting ICT systems that should be part of the business resilience and continuity plans with:
• i. a comprehensive analysis of dependencies between the critical business processes and supporting systems;
• ii. determination of recovery objectives for the supporting ICT systems (e.g. typically determined by the business and/or regulations in terms of RTO and RPO);
• iii. appropriate contingency planning to enable the availability, continuity, and recovery of critical ICT systems and services to minimize disruption to an institution’s operations within acceptable limits.
• b. has business resilience, continuity control environment policies and standards and operational controls which include:
• i. Measures to avoid that a single scenario, incident or disaster might impact both ICT production and recovery systems;
• ii. ICT system backup and recovery procedures for critical software and data, that ensure that these backups are stored in a secure and sufficiently remote location, so that an incident or disaster cannot destroy or corrupt these critical data;
• iii. monitoring solutions for the timely detection of ICT availability or continuity incidents;
• iv. a documented incident management and escalation process, that also provides guidance on the different incident management and escalation roles and responsibilities, the members of the crisis committee(s) and the chain of command in case of emergency;
• v. physical measures to both protect the institution’s critical ICT infrastructure (e.g. data centres) from environmental risks (e.g. flooding and other natural disasters) and ensure an appropriate operating environment for ICT systems (e.g. air conditioning);
• vi. processes, roles and responsibilities to ensure that also outsourced ICT systems and services are covered by adequate business resilience and continuity solutions and plans;
• vii. ICT performance and capacity planning and monitoring solutions for critical ICT systems and services with defined availability requirements, to detect important performance and capacity constraints in a timely manner;
• viii. solutions to protect critical internet activities or services (e.g. e-banking services), where necessary and appropriate, against denial of service and other cyber-attacks from the internet, aimed at preventing or disturbing access to these activities and services.
• c. tests ICT availability and continuity solutions, against a range of realistic scenarios including cyber-attacks, fail-over tests and tests of back-ups for critical software and data which:
• i. are planned, formalised and documented, and the test results used to strengthen the effectiveness of the ICT availability and continuity solutions;
• ii. include stakeholders and functions within the organisation, such as business line management including business continuity, incident and crisis response teams, as well as relevant external stakeholders in the ecosystem;
• iii. management body and senior management are appropriately involved in (e.g. as part of crisis management teams) and are informed of test results.
• (b) Controls for managing material ICT security risks

Competent authorities should assess whether the institution has an effective framework in place for identifying, understanding, measuring and mitigating ICT security risk. For this assessment competent authorities should, in particular, take into account whether the framework considers:

• a. clearly defined roles and responsibilities regarding:
• i. the person(s) and/or committees that are responsible and/or accountable for the day to day ICT security management and the elaboration of the overarching ICT security policies, with attention for their needed independence;
• ii. the design, implementation, management and monitoring of ICT security controls;
• iii. the protection of critical ICT systems and services by adopting for example a vulnerability assessment process, software patch management, end point protection (e.g. malware virus), Intrusion detection and prevention tools;
• iv. the monitoring, classification and handling of external or internal ICT security incidents; including incident response and the resumption and recovery of the ICT systems and services;
• v. regular and proactive threat assessments to maintain appropriate security controls.
• b. an ICT security policy that takes into consideration and, where appropriate, adheres to internationally recognised ICT security standards and security principles (e.g. the ‘principle of least privilege’ i.e. limiting access to the minimal level that will allow normal functioning for access right management and the principle of “defence in depth” i.e. layered security mechanisms increase security of the system as a whole for designing a security architecture);
• c. a process to identify ICT systems, services and commensurate security requirements reflecting potential fraud risk and/or possible misuses and/or abuses of confidential data along with documented security expectations to be adhered to for these identified ICT systems, services and data, aligned with the institution’s risk tolerance and monitored for their correct implementation;
• d. a documented security incident management and escalation process, that provides guidance on the different incident management and escalation roles and responsibilities, the members of the crisis committee(s) and the chain of command in case of security emergencies;
• e. user and administrative activity logging to enable effective monitoring and the timely detection and response to unauthorised activity; to assist in or to conduct forensic investigations of security incidents. The institution should have in place logging policies that define appropriate types of logs to be maintained and their retention period;
• f. awareness and information campaigns or initiatives to inform all levels in the institution on the safe use and protection of the institution’s ICT systems and the main ICT security (and other) risks they should be aware of, in particular regarding the existing and evolving cyber threats (e.g. computer viruses, possible internal or external abuses or attacks, cyber-attacks) and their role in mitigating security breaches;
• g. adequate physical security measures (e.g. CCTV, burglar alarm, security doors) to prevent unauthorised physical access to critical and sensitive ICT systems (e.g. data centres);
• h. measures to protect the ICT systems from attacks from the Internet (i.e. cyber-attacks) or other external networks (e.g. traditional telecom connections or connections with trusted partners). Competent authorities should review whether the institution’s framework considers:
• i. a process and solutions to maintain a complete and up to date inventory and overview of all the outward facing network connection points (e.g. websites, internet applications, WIFI, remote access) through which third parties could break into the internal ICT systems.
• ii. closely managed and monitored security measures (e.g. firewalls, proxy servers, mail relays, antivirus and content scanners) to secure the incoming and outgoing network traffic (e.g. e-mail) and the outward facing network connections through which third parties could break into the internal ICT systems;
• iii. processes and solutions to secure websites and applications that can be directly attacked from the internet and/or the outside, that can serve as an entry point into the internal ICT systems. In general these include a combination of recognised secure development practices, ICT system hardening and vulnerability scanning practices, and/or the implementation of additional security solutions like for example application firewalls and/or intrusion detection (IDS) and/or intrusion prevention (IPS) systems;
• iv. periodic security penetration testing to assess the effectiveness of implemented cyber and internal ICT security measures and processes. These tests should be performed by staff and/or external experts with the necessary expertise, with documented test results and conclusions reported to senior management and/or the management body. Where needed and applicable, the institution should learn from these tests where to further improve the security controls and processes and/or to obtain better assurance on their effectiveness.
• (c) Controls for managing material ICT change risks

Competent authorities should assess whether the institution has an effective framework in place for identifying, understanding, measuring and mitigating ICT change risk commensurate with the nature, scale and complexity of the institution’s activities and the ICT risk profile of the institution. The institution’s framework should cover the risks associated with the development, testing and approval of ICT systems changes, including the development or change of software, before they are migrated to the production environment and ensure an adequate ICT lifecycle management. For this assessment competent authorities should, in particular, take into account whether the framework considers:

• a. documented processes for managing and controlling changes to ICT systems (e.g. configuration and patch management) and data (e.g. bug fixing or data corrections), ensuring the adequate involvement of ICT risk management for important ICT changes that may significantly impact the institution’s risk profile or exposure;
• b. specifications regarding the required segregation of duties during the different phases of the implemented ICT change processes (e.g. solution design and development, testing and approval of new software and/or changes, migration and implementation in the production environment, and bug fixing), with a focus on the implemented solutions and segregation of duties to manage and control changes to the production ICT systems and data by ICT staff (e.g. developers, ICT system administrators, data base administrators) or any other party (e.g. business users, service providers);
• c. test environments that adequately reflect production environments;
• d. an asset inventory of the existing applications and ICT systems in the production environment, as well as the test and development environment, so that required changes (e.g. version updates or upgrades, systems patching, configuration changes) can be properly managed, implemented and monitored for the involved ICT systems.
• e. a process to monitor and manage the life cycle of the used ICT systems, to ensure that they continue to meet and support the actual business and risk management requirements and to make sure that the used ICT solutions and systems are still supported by their vendors; and that this is accompanied by adequate software development life cycle (SDLC) procedures.
• f. a software source code control system and appropriate procedures to prevent unauthorised changes in the source code of software that is developed in-house;
• g. a process to conduct a security and vulnerability screening of new or materially modified ICT systems and software, before releasing them into production and exposing them to possible cyber-attacks;
• h. a process and solutions to prevent the unauthorised or unintended disclosure of confidential data, when replacing, archiving, discarding or destroying ICT systems;
• i. an independent review and validation processes to reduce the risks for human errors when performing changes to the ICT systems that may have an important adverse effect on the availability, continuity or security of the institution (e.g. important changes to the firewall configuration), or security of the institution (e.g. changes to the firewalls).
• (d) Controls for managing material ICT data integrity risks

Competent authorities should assess whether the institution has an effective framework in place for identifying understanding, measuring and mitigating ICT data integrity risk commensurate with the nature, scale and complexity of the institution’s activities and the ICT risk profile of the institution. The institution’s framework should consider the risks associated with preserving the integrity of the data stored and processed by the ICT systems. For this assessment, competent authorities should, in particular take into account whether the framework considers:

• a. a policy that defines the roles and responsibilities for managing the integrity of the data in the ICT systems (e.g. data architect, data officers⁹ , data custodians¹⁰ , data owners/stewards¹¹ ) and provides guidance on which data are critical from a data integrity perspective and should be subject to specific ICT controls (e.g. automated input validation controls, data transfer controls, reconciliations, etc.) or reviews (e.g. a compatibility check with the data architecture) in the different phases of ICT data life cycle;
• b. a documented data architecture, data model and/or dictionary, that is validated with relevant business and IT stakeholders to support the needed data consistency across the ICT systems and to make sure that the data architecture, data model and/or dictionary remain aligned with business and risk management needs;
• c. a policy regarding the allowed usage of and reliance on End User Computing, in particular regarding the identification, registration and documentation of important end user computing solutions (e.g. when processing important data) and the expected security levels to prevent unauthorised modifications, both in the tool itself, as well as data stored in it;
• d. documented exception handling processes to resolve identified ICT data integrity issues in line with their criticality and sensitivity.

9 A data officer is responsible for data processing and usage. 10 A data custodian is responsible for the safe custody, transport and storage of data. 11 A data steward is responsible for the management and fitness of data elements – both the content and metadata.

For supervised institutions that fall under the scope of the BCBS 239 principles for effective risk data aggregation and risk reporting¹² , competent authorities should review the institution’s risk analysis of its risk reporting and data aggregation capabilities compared to the principles and the prepared documentation thereon, taking into consideration the implementation timeline and transitional arrangements in these principles.

• (e) Controls for managing material ICT outsourcing risks

Competent authorities should assess whether the institution’s outsourcing strategy, in line with the requirements of the CEBS outsourcing Guidelines (2006) and further to the requirement in paragraph 85

• (d) of the EBA SREP Guidelines, adequately applies to ICT outsourcing, including intra-group outsourcing providing ICT services within the group. When assessing the ICT outsourcing risks, competent authorities should take into consideration that the ICT outsourcing risks can also be covered as part of the assessment of inherent operational risks under paragraph 240 (j) of the EBA SREP Guidelines, to avoid any duplication of work or double counting.

In particular competent authorities should assess whether the institution has an effective framework in place for identifying, understanding and measuring ICT outsourcing risk, and in particular, controls and a control environment in place for mitigating risks related to material outsourced ICT services that are commensurate with the size, activities and the ICT risk profile of the institution and include:

• a. an assessment of the impact of the ICT outsourcing on the risk management of the institution related to the use of service providers (e.g. cloud service providers) and their services during the procurement process that is documented and is taken into account by senior management or the management body for the decision to outsource the services or not. The institution should review the ICT risk management policies and the ICT controls and control environment of the service provider to ensure that they meet the institution’s internal risk management objectives and risk appetite. This review should be periodically updated during the contractual outsourcing period, taking into account the characteristics of the outsourced services ;
• b. a monitoring of the ICT risks of the outsourced services during the contractual outsourcing period as part of the institution’s risk management, that feeds into the institution’s ICT risk management reporting (e.g. business continuity reporting, security reporting);
• c. a monitoring and comparison of the received service levels with the contractually agreed upon service levels which should form part of the outsourcing contract or service level agreement (SLA); and
• d. adequate staff, resources and competences to monitor and manage the ICT risks from the outsourced services.

12 Basel Committee on Banking Supervision, Principles for effective risk data aggregation and risk reporting, January 2013, available online: http://www.bis.org/publ/bcbs239.pdf.