6. Erroneous paragraph reference numbers in paragraphs 6, 7 and 8 should be corrected (see specific textual suggestions referred to in this document together with minor typo corrections in the attached document with version control: EBA+BS+2018+431+(Draft+CP+on+Guidelines+on+ICT+and+security+risk+management)_OTP.docx)
10. Definition
definition of ‘ICT Risk’
The definition explains the impacts (breach of confidentiality, failure of integrity systems and data, etc.). We recommend to apply the concept of probability, considering that any kind of impact has a likelihood.
definition of ‘Information asset’
This definition might be harmonised with that given in the ’Guidelines’ section at paragraph 17.
definition of ‘Operational or security incident’
Argument for deleting the text ‘…systems and…’ from the definition: we presume that ’ICT system continuity’ has been covered by ’availability’ mentioned one line above, whereas ’ICT services continuity’ can refer to third party providers’ services outsourced by the financial institutions.
‘Guidelines’ section
1.
A more comprehensive set of principles governing proportionate application of these dimensions and possible examples for their exact values (on a domestic and international level) or a differentiation between minimum requirements and those that could be applied proportionately could be more useful for FIs in order to achieve compliance with competent Supervisory Authorities’ needs.
9.
For the sake of clear reference, it could be useful if some examples for internationally accepted standards and certifications were mentioned here as examples (e.g. certifications to standards in the ISO/IEC 27000 family, ISAE 3402 Type II certification among others).
13.a
The level of risk tolerance or risk threshold defined by the FI could be difficult to determine at this early phase, before measuring the residual (or net) risk level for the FI’s ICT risks, therefore it could be more advisable to define it at the Risk Mitigation (Section 4.3.4) phase with the pertaining Risk Acceptance Announcement signed by senior management on tolerating the residual risk items below the risk tolerance threshold.
18.
We would like to have additional clarification on the classification of criticality of business functions perhaps with reference to areas like their key role in the financial statement, the decision making process, 7/24 customer service (e.g. e-channels), cash withdrawal, money transfer and payment services, risk or compliance related areas and strategic planning.
23.
Apart from ’treating’ the risks in the form of a Risk Mitigation Plan, perhaps the 3 other ’T’-s of risk mitigation could also be mentioned: transfer (by insurance), tolerate (risk acceptance) and terminate (stop doing the business or ICT process altogether).
31.f and 31.g
The order of the last two subsections should be reversed and their section numbers should be adjusted in accordance with the section numbering on page 22 and 23.
39.c
Because of its utmost importance as being the basis of network defence, ‘network encryption’ should come first in the 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 mechanism.
39.f
Highlighting the importance of applying non-obsoleted encryption methods and sufficient key length should be also necessary to mention here.
40.
It would be welcome to have cross-references here for Section 4.6.2 - ’ICT acquisition and development’ and Section 4.6.3 – ’Change management’.
44.
In our view some of the terms in this section should be defined in the ’Definitions’ part (e.g. red team) and some other related terms should be also used here for sake of all-inclusiveness, for example ‘vulnerability assessment’ or ‘blue teaming’ (together with ‘purple teaming’).
46.
We would like to specify two types of independent testers internal and external within the text, in order to 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.
73-80. (4.6.2. ICT systems and acquisition and development) and 73.b
Principles of Secure Software Development Life-cycle should be discussed perhaps in more details, furthermore Agile software development model could be also more highlighted or taken into consideration when discussing security requirements as opposed to the classical Waterfall software development model, the risk management controls of which is covered in full detail within this section.
76.
We suggest mentioning other equally important test types apart from regression testing (unit, integration, user acceptance testing).
79.
This requirement is partially the same as paragraph 75.
83.
This could refer to the preparation phase of BCM when High Availability solutions (e.g. redundancy, data mirroring) can minimize the probability of an ICT system and/or service outage. This ’going concern’ approach should be given at least as much highlight in the BCM process as is given to those preparations that activate after the ICT disaster happens (’gone concern’), where truly the main concern is limiting losses, disaster containment and making the systems operable again.
85.
This section could discuss in more detail other High Availability solutions relevant to different disaster scenarios (e.g. Disaster recovery-as-a-Service – aka DRaaS – cloud solutions, active-active geo-redundant Data Centers; asymmetrical data mirroring methods against software errors replicating real-time online, etc.).
102.
We recommend informing the PSU about other security related events as well, for example master data changes (e.g. customer’s phone number, password) and other non-transaction based events that could help preventing fraudulent activities.
