Our beloved European Union guidelines to assess risk management for financial institutions:
thanks @sge and company for the lovely reading you sent over … i’m enjoying the reading a lot…not. the important piece here is that they tell you quite clearly how they want you to do risk management , is not “generic guidelines” as put by ISO and other standards.
General Provisions Chapter
This document contains Guidelines issued pursuant to Article 16 of Regulation (EU) No 1093/20104. 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
These Guidelines build on existing references to ICT risk in the SREP Guidelines and also feed into the SREP methodology more generally
Competent authorities should perform the assessment of ICT risk and the governance arrangement and ICT strategy as part of the SREP process following the minimum engagement model and proportionality criteria specified in Title 2 of the EBA SREP Guidelines … the depth, detail and intensity of the ICT assessment should be proportionate to the size … the frequency of the ICT risk assessment would depend on the minimum engagement model
These Guidelines are aimed at addressing risks arising to market integrity and the viability of institutions from ICT. The Guidelines do not therefore explicitly address ICT risks arising to consumers, although the EBA would expect that beneficial effects will materialise indirectly, as a result of the comprehensive assessment of ICT risks as set out in the Guidelines.
Like the EBA SREP Guidelines, these Guidelines do not specify whether onsite or offsite inspections are most appropriate to conduct the assessments contained within these Guidelines
According to Article 16(3) of Regulation (EU) No 1093/2010, competent authorities must notify the EBA as to whether they comply or intend to comply with these Guidelines, or otherwise with reasons for non-compliance, Notifications will be published on the EBA website, in line with Article 16(3)
2.4 ICT Risk […]
With specific regard to b), competent authorities should assess whether the independent control and internal audit functions, as detailed in paragraphs 104 (a), 104 (d), 105 (a) and 105 (c) of the EBA SREP Guidelines, are appropriate to ensure a sufficient level of independence between the ICT and the control and audit functions, given the size and ICT risk profile of the institution
In assessing the institution’s institution-wide risk management and internal controls, as provided by Title 5 of the EBA SREP Guidelines, competent authorities should consider whether the institution’s risk management and internal control framework adequately safeguards the institution’s ICT systems […] the risk appetite and the ICAAP cover the ICT risks, as part of the broader operational risk category, for the definition of the overall risk strategy and determination of internal capital;
Title 3 Assessment of institutions’ ICT risks exposures and controls
Competent authorities should first identify the material inherent ICT risks to which the institution is or might be exposed, followed by an assessment of the effectiveness of the institution’s ICT risks’ management framework, procedures and controls to mitigate these risks.
As part of the process to identify the ICT risks with a potential significant prudential impact on the institution, competent authorities should review documentation from the institution and form an opinion on which ICT systems and services are critical for the adequate functioning, availability, continuity and security of the institution’s essential activities
To this end, competent authorities should review the methodology and processes applied by the institution to identify the ICT systems and services that are critical, taking into consideration that some ICT systems and services may be considered critical by the institution from a business continuity and availability perspective, a security (e.g. fraud prevention) and/or a confidentiality perspective (e.g. confidential data).
- they support the core business operations and distribution channels (e.g. ATMs, internet and mobile banking) of the institution
- they support essential governance processes and corporate functions, including risk management (e.g. risk management and treasury management systems);
- they fall under special legal or regulatory requirements (if any) that impose heightened availability, resilience, confidentiality or security requirements (e.g. data protection legislation
- they process or store confidential or sensitive data to which unauthorised access could significantly impact the institution’s reputation, financial results or the soundness and continuity of its business
- they provide base line functionalities that are vital for the adequate functioning of the institution
Taking into account the performed reviews of the institution’s ICT risk profile and critical ICT systems and services above, competent authorities should form an opinion on the material ICT risks that, in their supervisory judgement, can have a significant prudential impact on the institution’s critical ICT system and services
When assessing the potential impact of ICT risks on the critical ICT systems and services of an institution,
competent authorities should consider
- The financial impact, including (but not limited to) loss of funds or assets, potential customer compensation, legal and remediation costs, contractual damages, lost revenue
- The potential for business disruption, considering (but not limited to) the criticality of the financial services affected; the number of customers and/or branches and employees potentially affected;
- The potential reputational impact on the institution based on the criticality of the banking service or operational activity affected (e.g. theft of customer data); the external profile/visibility of the ICT systems and services affected (e.g. mobile or on-line banking systems, point of sale, ATMs or payment systems);
- The regulatory impact, including the potential for public censure by the regulator, fines or even variation of permissions
- The strategic impact on the institution, for example if strategic product or business plans are compromised or stolen
Competent authorities should then map the identified ICT risks that are considered material into the
following ICT risk categories for which additional risk descriptions and examples are provided in the
Annex. Competent authorities should reflect on the ICT risks in the Annex as part of the assessment
under Title 3
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
- Internal audit coverage and findings; and
- ICT risk controls that are specific for the identified material ICT risk
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; the audit plan includes audits on the critical ICT risks identified by the institution; the important ICT audit findings, including agreed actions, are reported to the
management body; and ICT audit findings, including agreed actions, are followed up and progress reports periodically reviewed by the senior management and/or the audit committee
For this assessment, competent authorities should, in particular, take into account whether the framework […] a comprehensive analysis of dependencies between the critical business processes and supporting systems […] tests ICT availability and continuity solutions, against a range of realistic scenarios including cyberattacks, fail-over tests and tests of back-ups for critical software and data which […]
The information provided shows that all Member States have, for the assessment of ICT risk, mechanisms and measures in certain forms. However, there are also variations in the current level of practices across Member States in relation to future implementation of the Guidelines. 0 (not implemented), 1 (partially implemented), 2 (mostly implemented), 3 (fully implemented).
