Response to consultation on Guidelines on major incidents reporting under PSD2
Go back
- The notion of “operational incident” should be clarified, as we would expect it to be different from other operational risk guidelines.
- Availability: the notion of “authorized clients” should be defined narrowly.
- Confidentiality: a more refined definition is needed. The reference should include privacy.
- Furthermore, incidents that impact, or have the potential to impact the image, perception, credibility of the payment service user or account servicing payment service provider should be in scope of these Guidelines too.
- Major operational incidents: the term “material adverse impact” should be clarified, and the expression “or may have” should be eliminated, due to the difficulty of assessing a potential major impact prior to its materialization.
- A distinction should be proposed between objective criteria and intangible criteria (e.g. im-age …).
- a) transactions affected: the regular level of transactions should take into account seasonality and/or business development, and hence be determined by either the daily average of transac-tions for the same day/week the previous year, and/or the average daily transactions over each of the past 3 months. Note: the same remark applies to section 1.2.a; transactions affected, page 24 of the consultation document.
- b) clients affected: a typology (segmentation of clients affected should be provided (e.g. corpo-rate accounts, etc,…).
- c) service downtime: the period of time when the service may be unavailable can only be pro-vided as a best effort.
- Equally, the economic impact (section 1.2 d) page 24) can only be provided as a best effort.
- Moreover, it must be taken into account when defining these criteria and methodology that the exchange of information on incidents with other financial institutions should be enhanced. Currently, entities do not have the appropriate safeguards (e.g. confidentiality assurances) to share information with other entities. But sharing could bring many benefits to the industry, and its stability as a whole: it would increase available information on cyber-attacks, allow companies to take proactive measures, and deny or harden the systemic propagation of attacks.
As stated in our response to the previous question, the proposed methodology to capture incidents does not change fundamentally enhance the current status. A genuine change would require regula-tory convergence in terms of incident reporting, based on the principle “one incident, one report, one authority”. What is really needed in cybersecurity grounds is that all regulations are harmo-nized, specifically those relating to reporting of incidents, following the principle stated above, and creating thereby a sort of “one-stop-shop” mechanism. The steps taken in this regard in the data protection field could actually serve as a reference and example for cybersecurity aspects.
In particular, the approach “is sufficient to provide competent authorities…” should be reconsid-ered based on the fact that the reporting lines should be extended to other financial institutions. Therefore, the information on the template should be directed to both competent authorities and financial entities, as well as it should provide appropriate confidentiality safeguards.
And again we stress the necessity to adopt the “one incident, one report, one authority” principle, due to the overburdening of financial entities with the large amount and diversity of reporting re-quirements.
Regarding the final report, a distinction should be made between reporting the root cause and re-porting final figures. In the sense of the remark made immediately above, it is more worth to communicate about the root cause – as soon as it has been identified – than to communicate about final figures. A distinction between both should be encouraged, in order once again to prevent if still possible any further propagation of an attack.
Question 1: Do you consider the definitions included in the draft Guidelines to be sufficiently clear?
Overall the definitions are reasonably clear. The following would however deserve amendment and/or a more narrow definition:- The notion of “operational incident” should be clarified, as we would expect it to be different from other operational risk guidelines.
- Availability: the notion of “authorized clients” should be defined narrowly.
- Confidentiality: a more refined definition is needed. The reference should include privacy.
- Furthermore, incidents that impact, or have the potential to impact the image, perception, credibility of the payment service user or account servicing payment service provider should be in scope of these Guidelines too.
- Major operational incidents: the term “material adverse impact” should be clarified, and the expression “or may have” should be eliminated, due to the difficulty of assessing a potential major impact prior to its materialization.
Question 2: Do you consider the criteria and methodology applicable for the assessment and classification of an incident as major to be sufficiently clear? If not, what should be further clarified?
Whilst overall the criteria and methodology applicable for the assessment and classification of an incident as major are reasonably clear, the following amendments should be made:- A distinction should be proposed between objective criteria and intangible criteria (e.g. im-age …).
- a) transactions affected: the regular level of transactions should take into account seasonality and/or business development, and hence be determined by either the daily average of transac-tions for the same day/week the previous year, and/or the average daily transactions over each of the past 3 months. Note: the same remark applies to section 1.2.a; transactions affected, page 24 of the consultation document.
- b) clients affected: a typology (segmentation of clients affected should be provided (e.g. corpo-rate accounts, etc,…).
- c) service downtime: the period of time when the service may be unavailable can only be pro-vided as a best effort.
- Equally, the economic impact (section 1.2 d) page 24) can only be provided as a best effort.
- Moreover, it must be taken into account when defining these criteria and methodology that the exchange of information on incidents with other financial institutions should be enhanced. Currently, entities do not have the appropriate safeguards (e.g. confidentiality assurances) to share information with other entities. But sharing could bring many benefits to the industry, and its stability as a whole: it would increase available information on cyber-attacks, allow companies to take proactive measures, and deny or harden the systemic propagation of attacks.
Question 3: Do you consider that the methodology will capture all of / more than / less than those incidents that are currently considered major? Please explain your reasoning.
It is impossible to reply to this question without performing a historical comparative analysis. The value of such analysis would remain rather hypothetical, given the constant change in the nature of the attacks, the technology employed, the scale...As stated in our response to the previous question, the proposed methodology to capture incidents does not change fundamentally enhance the current status. A genuine change would require regula-tory convergence in terms of incident reporting, based on the principle “one incident, one report, one authority”. What is really needed in cybersecurity grounds is that all regulations are harmo-nized, specifically those relating to reporting of incidents, following the principle stated above, and creating thereby a sort of “one-stop-shop” mechanism. The steps taken in this regard in the data protection field could actually serve as a reference and example for cybersecurity aspects.
Question 4: In particular, do you propose to add, amend and/or remove any of the thresholds referred to in Guideline 1.3? If so, please explain your reasoning.
As already highlighted above, a distinction should be made between objective and intangible crite-ria, which would allow to take account of the relative size of the institutions and the typology of clients affected, in order to arrive at a more proportionate assessment.Question 5: Do you think that the information depicted in the template in Annex 1 is sufficient to provide competent authorities in the home Member State with a suitable picture of the incident? If not, which changes would you introduce? Please explain your reasoning.
The information depicted in the Annex 1 template – which largely echoes the ECB reporting framework for cyber incidents (June 2015) – should be enhanced taking into account the remarks made in response to Questions 1 and 2 above.In particular, the approach “is sufficient to provide competent authorities…” should be reconsid-ered based on the fact that the reporting lines should be extended to other financial institutions. Therefore, the information on the template should be directed to both competent authorities and financial entities, as well as it should provide appropriate confidentiality safeguards.
And again we stress the necessity to adopt the “one incident, one report, one authority” principle, due to the overburdening of financial entities with the large amount and diversity of reporting re-quirements.
Question 6: Are the instructions provided along with the template sufficiently clear and helpful to remove any doubts that could arise when completing the required fields? If not, please explain your reasoning.
The instructions provided are sufficiently clear.Question 7: As a general rule, do you consider the deadlines and circumstances that should trigger the submission of each type of report (i.e. initial, intermediate and final) feasible? If not, please provide a reasoning and justify any alternative proposal.
The matter of report submission should not only be considered from the perspective of the report-ing institution, but also from the perspective of the competent authority receiving the report, and more precisely the actions that the latter may undertake, in order notably to prevent a contagion of an attack. This would suggest that the Guidelines should also contain deadlines for competent authorities to act on such reports without a given (short) deadline.Regarding the final report, a distinction should be made between reporting the root cause and re-porting final figures. In the sense of the remark made immediately above, it is more worth to communicate about the root cause – as soon as it has been identified – than to communicate about final figures. A distinction between both should be encouraged, in order once again to prevent if still possible any further propagation of an attack.