Response to consultation on Guidelines on major incidents reporting under PSD2
Go back
The Italian Banking Association (ABI) welcomes the opportunity to make its observations and comments on the Consultation Paper (CP) containing the “Draft Guidelines on major Incidents under the Payment Services Directive 2” which has been prepared by the EBA in close collaboration with the European Central Bank and the Eurosystem and published for consultation.
Standardising the parameters to define the relevance of operational and security incidents using common classification criteria and the notification of predetermined sets of information to the authorities avoids the negative impact of differences in evaluation between the Member States, enables a coordinated, timely response and helps increasing users’ confidence in e-payment services.
With the objective of further increasing the efficiency of the major incident response of individual payment services providers (PSPs) and of the system as a whole, in general we note that:
• Incidents such as attacks on security could be countered more effectively if the information about those events notified by the PSP is worked out by the Authorities and by specialized centres (as the financial CERT - CERTFin – in Italy) and then spread, under a confidentiality obligation, also to other PSPs for analysis and prevention purposes. The sharing of information about events of this kind, and the underlying mechanisms, would enable the other PSPs to prepare defences and limit the effects on users. This would overcome the barriers that currently exist between PSPs when exchanging information about incidents, also by involving sectorial centres for the analysis, management of emergencies and sharing of information (such as CERTFin in Italy) within the various countries. This, in our opinion, would respond more fully to the indication contained in Recital 91 of PSD2, as the purpose of the report is to ensure that “damage to users, other payment service providers or payment systems, such as a substantial disruption of a payment system, is kept to a minimum”;
• At a time when the urgency of the circumstances would recommend the adoption of simple, rapid procedures, the inconsistencies in processing methods (different reports, deadlines and timeframes) due to a number of different regulatory requirements (the Single Supervisory Mechanism - SSM, the Network and Information Security Directive - NIS, and the General Data Protection Regulation - GDPR) leads to duplication and increases the possibility of confusion and errors by the PSPs. A single template and unique reporting method for all incident types, for all applicable legislations, would be highly appreciated by the market. It is also important for the major incident reporting process relating to payment systems to be harmonised with regard to the management of processes for all incident types already existing in banks, and to the escalation and crisis management processes already set out in the business continuity plans.
• We consider that it would be helpful for the EBA to clarify the legal framework of the Guidelines with respect to the current prudential regulations in force in the Member States related to the classification and reporting of incidents and to the EBA Guidelines on the security of internet payments. It should therefore be specified that the communications governed by the final version of the Guidelines under consultation will replace those already in force for incidents within the scope of PSD2, in order to avoid redundancy and duplications.
In preparing this document, ABI has obtained comments from its members, the ABI Lab Consortium (banking research and innovation centre), the Bancomat® Consortium (owner of the national debit card scheme) and the CBI Consortium (manager of a technological infrastructure for corporate banking). While we refer to the specific replies to each of the questions raised in the CP, we highlight in each answer the most important considerations as well as provide evidence to support the views expressed and propose alternative choices.
Reply to question 1
Point 12. asks PSPs within a banking group operating in multiple Member States to report the incident to the Competent Authority in the Member State in which it is authorised. This obligation is not in line with the reporting of an incident to the ECB in the case of a group that is subject to the SSM.
This approach is also inappropriate with regard to the widespread rationalisation and centralisation strategies of common group functions, and in particular, with regard to the organisation of hierarchical cross-country incident management lines (see the reporting criterion in point 17(e)). For this reason we ask that banking groups be given the option of reporting a major incident to the Competent Authority of the PSP where the incident took place, from the business unit (if present), which has the power to exercise that function on behalf of the entire group. The possibility of allocating reporting activities to one unit, and centralising them, is also provided for in the “consolidated” procedure referred to in point 28. and in Guideline 3.2.
With regard to the definitions, we suggest the following amendments:
• It would be preferable to define operational or security incidents separately from incidents classified as major. The definition of “operational or security incident” should be the one given in point 13, page 21, while the “major incident” should contain the contents of Guideline 1.5;
• The definition of “Major operational or security incident” includes events that “may have” an impact. The incidents are, however, real events, which are identified because they have material, concrete repercussions, and not because they may have repercussions in the future. Therefore we ask that the wording “or may have” be deleted from the definition, thereby excluding events with potential impact, from the assessment;
• As the “reputational impact” (for example, following press news) falls within – as for ENISA and ECB/SSM – the criteria for classification and reporting (Guidelines 1.1 and 1.2(g)), in Point 13. Of the Guidelines it would be necessary to include this dimension in the definition of “major operational or security incident”, by giving a precise, specific definition;
• The generic term ‘client’ should be replaced with “payment service user” (PSU) as in Art. 4(10) PSD2.
• After the consultation, the definitive version of the Guidelines does not duplicate the requirements in this regard for PSPs subject to the ECB’s Single Supervisory Mechanism.
• The reasons that led to the choice of the minimum number of exceeded thresholds (three) for Level 1 and one for Level 2 for the classification of a major incident, should be provided for the sake of clarity in Guideline 1.5 and in Point 20 of Chapter 3.2 of the Consultation Paper;
• It should be expressly stated (for example in Guideline 1.3) that for the purposes of assessing incidents against the thresholds, the PSPs can refer to the available data (real, or estimated with reasonable certainty) by the deadline by which the report needs to be sent.
As to individual criteria, we specifically observe that:
• “Clients affected”:
o Assuming that the word “client” refers to the “payment service user” (PSU), the fixed threshold of the number of PSUs (especially that of 50,000, for Level 2) is not suitable to provide an understanding of the impact of the incident considering that the size of a PSP in terms of the number of PSUs, may vary widely;
o It would be helpful to clarify whether the PSP should consider the number of PSUs generically, or differentiate according to the nature of the PSU involved (i.e., an individual, a SME, or a large corporate);
o In Guidelines 1.1 and 1.2(b) it is not clear whether the basis for the calculation is the total number of users of the PSP or the number of users of the specific payment service;
o In the case of a PSP (‘Level 2 PSP’) offering operational services shared by aggregations and groups of other PSPs (‘Level 1 PSP’) which provides payment services directly to the PSUs, the ‘Level 2’ PSPs have difficulty in retrieving the required information, as they do not have direct access to it because it is in the hands of the ‘Level 1 PSP’; in this context there is a need to clarify whether the ‘Level 2 PSP’ should refer to the number of PSUs of the specific Level 1 PSP, or to the total number of PSUs of all the Level 1 PSPs;
• “Transaction affected”: as with the principle of PSUs affected, setting an absolute threshold amount as a principle for the value of transactions does not allow any weighting of the various types of PSUs, and their average transaction values. For example, the €1,000,000 amount indicated in Level 2 could be exceeded due to error on even a single transaction, in the case of businesses. We also suggest using the specific payment service as a basis for the calculation. The phrase “the daily annual average of payment transactions for all the payment services executed” should be replaced by “the daily annual average of payment transactions for the affected payment service”
• Economic impact: it is very hard to calculate or estimate the economic value of the incident within just two hours from the event. We therefore suggest eliminating this from the assessment criteria or requesting a qualitative valuation on a scale or as a percentage of certain representative variables of the PSP. Another option is that the evaluation of the economic impact takes into account direct costs and indirect costs only if they are certain, excluding potential indirect costs which could lead to overestimate the economic impact. The real economic value can be indicated in the final report. However, even in this case two weeks may not be enough if there are indirect costs (such as insurance payouts or claims) which normally require more time. Only the direct costs of an incident (for example technical intervention to replace hardware) can be established by the deadline and may be included in the final report.
• “Service Downtime” – We suggest explaining the definition of Service so that the principle is interpreted correctly and consistently. For example, an online banking service comprises multiple services, and incidents may only relate to some of them (which may also be available in different ways – through call centres, in-branch, …);
• “High level of internal escalation” – The quantitative criteria identified above already fall within the internal escalation processes at the moment, and therefore the ‘high level of internal escalation’ principle is a duplication of the other criteria and is redundant. The criterion should also be specified further on the basis of the PSP’s size, to avoid to include practices consolidated within some organisational models in small and medium PSPs where information of various types of incidents, and not only the “major” ones, are always reported to top management. With regard to the “crisis mode” in the initial classification of the incident, we consider that this must be eliminated, as the “crisis” is declared in the escalation procedure after the initial recognition of the incident.
• Other payment service providers or relevant infrastructure potentially affected – The PSP must assess, among other things, whether the incident may impact other PSPs or other payment services. If the incident involves a TPP, its Competent Authority should advise the ASPSPs with whom it is working, especially if the nature of the incident involves the compromising of credentials or fraud by the PSU. The information to be shared could include stolen credentials, PSU who behaved fraudulently, customer data violation and so on.
• Reputational impact – This criterion, which is qualitative by nature, appears to be excessively discretionary. The resulting uncertainty in the application of this criterion would lead to an inconsistency in the classification of incidents, which conflicts with the objectives of the Guidelines. For this reason we ask that it be removed, while simultaneously setting at 2 the number of Level 1 criteria for the classification of major incidents, or further specifying the Level 1 so that the assessment is made more objective.
We ask to clarify if the amounts in “Table 1: Thresholds” refer to actual losses or if they include also returned transactions or where funds were recovered.
• Minor reputational damage due to a two-hour interruption of activity, leading to a “high” level of internal escalation because internal policy requires incidents to be reported even if they are of minimal relevance.
• A “Distributed Denial-of-Service” (DDoS) attack lasting three hours, with high escalation, but low impact on transactions and customers because it took place at night.
On the basis of these considerations we consider that:
• The quantitative criteria should be defined and described in detail. The internal escalation level should be clearly delineated, as it may be redundant compared to the other criteria. If the PSP’s internal policies always require information/escalation to the security managers even though the incident is not critical, this principle would always be applied and would distort the evaluation of the incident’s seriousness.
• As with other similar cases, a pilot phase should be included, so that the appropriateness can be evaluated, and the criteria can be finetuned.
We therefore ask that the following criteria be modified:
• Transactions affected
• Clients affected
• Economic impact
eliminating the absolute values and considering only parameters and/or percentage thresholds.
With regard to the “Service Downtime” threshold, this should be increased to four hours. While two hours is the limit set for the recovery of critical infrastructure, it is not appropriate to set the same limit for all PSPs.
In any case, it should be clarified that downtime does not include the carrying out of ordinary and extraordinary maintenance.
Finally, we note the greater complexity of assessments of thresholds in the case of delegated or consolidated reporting, for example in relation to the number of PSUs to be taken into consideration when evaluating the thresholds. We ask the EBA to provide further explanations in this regard.
With reference to the information contained in the template, we consider that it would be enough to provide an accurate representation of the incident. However, we note that two hours are not enough to determine whether the impact is actual or estimated. See Reply 7.
With regard to the confidentiality and integrity requirements in the exchange of information with the Authorities, we suggest providing several examples of communication methods through which these requirements can be met.
We note that certain fields of the report are mandatory, but accompanied by the wording ‘if applicable’ or ‘if known’. This indication may be contradictory, and we therefore ask to make the information optional .
We note that “infection of internal systems” and “targeted intrusion” in the “types of attack” in the “cause of incident” Field could overlap, as it would be the case in the event of theft of information using malware. To avoid confusion, it would be possible to refer to or use an already known taxonomy.
Finally, we propose an amendment to page 38 of the Consultation Paper. The description of the affected countries states “countries where the incident has materialized”. However, we cannot understand which country should be indicated if the IT systems affected were located in the country other than the one of the branch or office at which the event materialised.
In the item “Economic impact – indirect costs” (page 41 CP) the inclusion of what is sometimes known as lost profits, or “revenues lost due to missed business opportunities” is not consistent with indirect costs.
With regard to section 8 (“Additional information”), it is not clear what type of information should be provided in the report regarding possible informal communications with other PSPs.
• Initial report. The period of two hours appears first of all to be disproportionate, if the goal of the report is not the prompt circulation of information for prevention purposes, within the market as a whole. We also note that the reporting deadlines stated in the Guidelines are not the same as those in the GDPR (“without undue delay and, where feasible, not later than 72 hours”) or in the NIS Directive (“without undue delay”). In order to standardise the deadlines to avoid error and confusion we suggest using the wording in the GDPR, which, while allowing for flexibility of application in line with the concept of “undue delay” in Article 96(1) of the Directive, also, where possible, sets a maximum period of time.
o As already indicated in Reply 6, in the case of incidents occurring when the PSP is not operational, for example at night or at weekends, it can only report the incident on the next working day. In these cases the moment that triggers the period for the submission of the initial report should be the time when the PSP is once again operational, is aware of the incident and is therefore fully able to make the report.
o Also, the time allowed for production of the initial report should start from the time when the incident was classified as major, and not from the time it was detected (see paragraph 2.8 of the Guidelines). Similarly, in the case of delegated and consolidated reporting (Guidelines 3 and 4) the interaction between the PSP and delegated party is governed by the agreements between the parties. However, as the PSP has full responsibility for reporting, the delegated party will only send a report after obtaining the consent of the PSP. As the working hours of the PSP may not coincide with those of delegated party, it is important to clarify that the initial time from which the period for the sending of the initial report starts to run is the time when the PSP validates the severity of the incident indicated by delegated party.
o Considering the quantity of information and the difficulties in obtaining or producing reliable estimates, two hours are not enough in any case. It must be remembered that in order to obtain information about the incident and its impact, specialised staff and different teams need to be involved. In the case of a delegated reporting procedure, the time required to draw up the report could be extended due to the necessary interaction between the PSP and the delegated party. On expiry of two hours, there are alternative solutions, which we consider to be compatible with the provisions of Article 96(1):
A. Postponing the deadline until the next working day;
B. Sending an initial notification within two hours, without the full content of the report, and giving an indication of when the full report will be sent.
• Intermediate report: We propose to complement the information provided in the initial report (Case B) so as to eliminate the need for an intermediate report: if the PSP states the deadline by which it will provide the full report, including all the measures requested in Annex 1 (including whether the incident should be considered ‘crisis mode’), the intermediate report could be eliminated as it would become superfluous. If that proposal were not accepted, we would, as a second best, propose to postpone the submission deadline, as three days is too narrow a period. A derogation of the deadline would then have to be made, by sending an intermediate report in advance only in exceptional cases, i.e. only if highly significant discrepancies emerge subsequently, compared to the initial assessment of the incident.
• Final report: the period of two weeks appears to be insufficient as the PSP, as indicated in Reply 2, may not have the requested economic data. As to claims, Article 101(2) PSD2 sets a limit of 15 working days from receipt of a claim for PSPs to reply (and therefore it is assumed that this is a minimum limit for effective quantification). We suggest extending the deadline to four weeks.
We note that if the incident is produced by infrastructures or services which are completely external to the PSP (as an example: telecommunication networks) the PSP could not be in a position to fill the information in the reports (especially the intermediate and the final reports) within the deadline, because the reason and the management of the incident is completely outside the PSP’s responsibility.
Finally, there is a need to clarify whether, in the consolidated reporting procedure, the basis for calculation should be the number of PSUs of the individual service from the individual PSP, or the total PSUs of all PSPs considered in the “consolidated” report.
In addition to the requested answers in the CP, we highlight the importance of clarifying, at EU level and specifically during the national implementation phase the means for transmission of incident reports which have not been defined (Point 31 “Rationale”), also in view of the fact that the information to be reported is strictly confidential. We consider that it would be helpful to clarify which function/office/division of the Competent Authority and which means of transmission to use. We suggest that in addition to the certified e-mail address, a specific telephone number and contact person should also be added.
Question 1: Do you consider the definitions included in the draft Guidelines to be sufficiently clear?
IntroductionThe Italian Banking Association (ABI) welcomes the opportunity to make its observations and comments on the Consultation Paper (CP) containing the “Draft Guidelines on major Incidents under the Payment Services Directive 2” which has been prepared by the EBA in close collaboration with the European Central Bank and the Eurosystem and published for consultation.
Standardising the parameters to define the relevance of operational and security incidents using common classification criteria and the notification of predetermined sets of information to the authorities avoids the negative impact of differences in evaluation between the Member States, enables a coordinated, timely response and helps increasing users’ confidence in e-payment services.
With the objective of further increasing the efficiency of the major incident response of individual payment services providers (PSPs) and of the system as a whole, in general we note that:
• Incidents such as attacks on security could be countered more effectively if the information about those events notified by the PSP is worked out by the Authorities and by specialized centres (as the financial CERT - CERTFin – in Italy) and then spread, under a confidentiality obligation, also to other PSPs for analysis and prevention purposes. The sharing of information about events of this kind, and the underlying mechanisms, would enable the other PSPs to prepare defences and limit the effects on users. This would overcome the barriers that currently exist between PSPs when exchanging information about incidents, also by involving sectorial centres for the analysis, management of emergencies and sharing of information (such as CERTFin in Italy) within the various countries. This, in our opinion, would respond more fully to the indication contained in Recital 91 of PSD2, as the purpose of the report is to ensure that “damage to users, other payment service providers or payment systems, such as a substantial disruption of a payment system, is kept to a minimum”;
• At a time when the urgency of the circumstances would recommend the adoption of simple, rapid procedures, the inconsistencies in processing methods (different reports, deadlines and timeframes) due to a number of different regulatory requirements (the Single Supervisory Mechanism - SSM, the Network and Information Security Directive - NIS, and the General Data Protection Regulation - GDPR) leads to duplication and increases the possibility of confusion and errors by the PSPs. A single template and unique reporting method for all incident types, for all applicable legislations, would be highly appreciated by the market. It is also important for the major incident reporting process relating to payment systems to be harmonised with regard to the management of processes for all incident types already existing in banks, and to the escalation and crisis management processes already set out in the business continuity plans.
• We consider that it would be helpful for the EBA to clarify the legal framework of the Guidelines with respect to the current prudential regulations in force in the Member States related to the classification and reporting of incidents and to the EBA Guidelines on the security of internet payments. It should therefore be specified that the communications governed by the final version of the Guidelines under consultation will replace those already in force for incidents within the scope of PSD2, in order to avoid redundancy and duplications.
In preparing this document, ABI has obtained comments from its members, the ABI Lab Consortium (banking research and innovation centre), the Bancomat® Consortium (owner of the national debit card scheme) and the CBI Consortium (manager of a technological infrastructure for corporate banking). While we refer to the specific replies to each of the questions raised in the CP, we highlight in each answer the most important considerations as well as provide evidence to support the views expressed and propose alternative choices.
Reply to question 1
Point 12. asks PSPs within a banking group operating in multiple Member States to report the incident to the Competent Authority in the Member State in which it is authorised. This obligation is not in line with the reporting of an incident to the ECB in the case of a group that is subject to the SSM.
This approach is also inappropriate with regard to the widespread rationalisation and centralisation strategies of common group functions, and in particular, with regard to the organisation of hierarchical cross-country incident management lines (see the reporting criterion in point 17(e)). For this reason we ask that banking groups be given the option of reporting a major incident to the Competent Authority of the PSP where the incident took place, from the business unit (if present), which has the power to exercise that function on behalf of the entire group. The possibility of allocating reporting activities to one unit, and centralising them, is also provided for in the “consolidated” procedure referred to in point 28. and in Guideline 3.2.
With regard to the definitions, we suggest the following amendments:
• It would be preferable to define operational or security incidents separately from incidents classified as major. The definition of “operational or security incident” should be the one given in point 13, page 21, while the “major incident” should contain the contents of Guideline 1.5;
• The definition of “Major operational or security incident” includes events that “may have” an impact. The incidents are, however, real events, which are identified because they have material, concrete repercussions, and not because they may have repercussions in the future. Therefore we ask that the wording “or may have” be deleted from the definition, thereby excluding events with potential impact, from the assessment;
• As the “reputational impact” (for example, following press news) falls within – as for ENISA and ECB/SSM – the criteria for classification and reporting (Guidelines 1.1 and 1.2(g)), in Point 13. Of the Guidelines it would be necessary to include this dimension in the definition of “major operational or security incident”, by giving a precise, specific definition;
• The generic term ‘client’ should be replaced with “payment service user” (PSU) as in Art. 4(10) PSD2.
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?
With reference to the method of identifying the major incidents, we ask that:• After the consultation, the definitive version of the Guidelines does not duplicate the requirements in this regard for PSPs subject to the ECB’s Single Supervisory Mechanism.
• The reasons that led to the choice of the minimum number of exceeded thresholds (three) for Level 1 and one for Level 2 for the classification of a major incident, should be provided for the sake of clarity in Guideline 1.5 and in Point 20 of Chapter 3.2 of the Consultation Paper;
• It should be expressly stated (for example in Guideline 1.3) that for the purposes of assessing incidents against the thresholds, the PSPs can refer to the available data (real, or estimated with reasonable certainty) by the deadline by which the report needs to be sent.
As to individual criteria, we specifically observe that:
• “Clients affected”:
o Assuming that the word “client” refers to the “payment service user” (PSU), the fixed threshold of the number of PSUs (especially that of 50,000, for Level 2) is not suitable to provide an understanding of the impact of the incident considering that the size of a PSP in terms of the number of PSUs, may vary widely;
o It would be helpful to clarify whether the PSP should consider the number of PSUs generically, or differentiate according to the nature of the PSU involved (i.e., an individual, a SME, or a large corporate);
o In Guidelines 1.1 and 1.2(b) it is not clear whether the basis for the calculation is the total number of users of the PSP or the number of users of the specific payment service;
o In the case of a PSP (‘Level 2 PSP’) offering operational services shared by aggregations and groups of other PSPs (‘Level 1 PSP’) which provides payment services directly to the PSUs, the ‘Level 2’ PSPs have difficulty in retrieving the required information, as they do not have direct access to it because it is in the hands of the ‘Level 1 PSP’; in this context there is a need to clarify whether the ‘Level 2 PSP’ should refer to the number of PSUs of the specific Level 1 PSP, or to the total number of PSUs of all the Level 1 PSPs;
• “Transaction affected”: as with the principle of PSUs affected, setting an absolute threshold amount as a principle for the value of transactions does not allow any weighting of the various types of PSUs, and their average transaction values. For example, the €1,000,000 amount indicated in Level 2 could be exceeded due to error on even a single transaction, in the case of businesses. We also suggest using the specific payment service as a basis for the calculation. The phrase “the daily annual average of payment transactions for all the payment services executed” should be replaced by “the daily annual average of payment transactions for the affected payment service”
• Economic impact: it is very hard to calculate or estimate the economic value of the incident within just two hours from the event. We therefore suggest eliminating this from the assessment criteria or requesting a qualitative valuation on a scale or as a percentage of certain representative variables of the PSP. Another option is that the evaluation of the economic impact takes into account direct costs and indirect costs only if they are certain, excluding potential indirect costs which could lead to overestimate the economic impact. The real economic value can be indicated in the final report. However, even in this case two weeks may not be enough if there are indirect costs (such as insurance payouts or claims) which normally require more time. Only the direct costs of an incident (for example technical intervention to replace hardware) can be established by the deadline and may be included in the final report.
• “Service Downtime” – We suggest explaining the definition of Service so that the principle is interpreted correctly and consistently. For example, an online banking service comprises multiple services, and incidents may only relate to some of them (which may also be available in different ways – through call centres, in-branch, …);
• “High level of internal escalation” – The quantitative criteria identified above already fall within the internal escalation processes at the moment, and therefore the ‘high level of internal escalation’ principle is a duplication of the other criteria and is redundant. The criterion should also be specified further on the basis of the PSP’s size, to avoid to include practices consolidated within some organisational models in small and medium PSPs where information of various types of incidents, and not only the “major” ones, are always reported to top management. With regard to the “crisis mode” in the initial classification of the incident, we consider that this must be eliminated, as the “crisis” is declared in the escalation procedure after the initial recognition of the incident.
• Other payment service providers or relevant infrastructure potentially affected – The PSP must assess, among other things, whether the incident may impact other PSPs or other payment services. If the incident involves a TPP, its Competent Authority should advise the ASPSPs with whom it is working, especially if the nature of the incident involves the compromising of credentials or fraud by the PSU. The information to be shared could include stolen credentials, PSU who behaved fraudulently, customer data violation and so on.
• Reputational impact – This criterion, which is qualitative by nature, appears to be excessively discretionary. The resulting uncertainty in the application of this criterion would lead to an inconsistency in the classification of incidents, which conflicts with the objectives of the Guidelines. For this reason we ask that it be removed, while simultaneously setting at 2 the number of Level 1 criteria for the classification of major incidents, or further specifying the Level 1 so that the assessment is made more objective.
We ask to clarify if the amounts in “Table 1: Thresholds” refer to actual losses or if they include also returned transactions or where funds were recovered.
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.
The experience from the pilot phase of the ECB/SSM reports made with some banks shows that some of the incidents initially declared to be major, according to the criteria, were then downgraded to “non-major” by the Authorities, as they did not show any high relevance, exposure to risk and so on. We therefore consider that the methodology proposed in these Guidelines will cover a spectrum of incidents broader than those that are in fact “major”, and therefore risks increasing the volume and type of events to be reported to the Competent Authority. Examples of incidents that would be classified as “major” by applying this methodology:• Minor reputational damage due to a two-hour interruption of activity, leading to a “high” level of internal escalation because internal policy requires incidents to be reported even if they are of minimal relevance.
• A “Distributed Denial-of-Service” (DDoS) attack lasting three hours, with high escalation, but low impact on transactions and customers because it took place at night.
On the basis of these considerations we consider that:
• The quantitative criteria should be defined and described in detail. The internal escalation level should be clearly delineated, as it may be redundant compared to the other criteria. If the PSP’s internal policies always require information/escalation to the security managers even though the incident is not critical, this principle would always be applied and would distort the evaluation of the incident’s seriousness.
• As with other similar cases, a pilot phase should be included, so that the appropriateness can be evaluated, and the criteria can be finetuned.
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 mentioned in Reply 2, the absolute values in Table 1 do not capture the severity of the incident as they do not reflect the specific context in which it occurs. Just as an absolute value for “transactions affected” does not take into account the variations in the usual transaction values among the various PSU types (consumers, SMEs, large companies), the number of PSUs in absolute terms (which is excessively low especially for the large PSPs) does not enable the weighting of the effects of the negative events nor does it take into account the size of the PSP or the market segment of the PSUs.We therefore ask that the following criteria be modified:
• Transactions affected
• Clients affected
• Economic impact
eliminating the absolute values and considering only parameters and/or percentage thresholds.
With regard to the “Service Downtime” threshold, this should be increased to four hours. While two hours is the limit set for the recovery of critical infrastructure, it is not appropriate to set the same limit for all PSPs.
In any case, it should be clarified that downtime does not include the carrying out of ordinary and extraordinary maintenance.
Finally, we note the greater complexity of assessments of thresholds in the case of delegated or consolidated reporting, for example in relation to the number of PSUs to be taken into consideration when evaluating the thresholds. We ask the EBA to provide further explanations in this regard.
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.
At a time when the urgency of circumstances would recommend the adoption of simple, rapid procedures, the inconsistencies in the treatment of incidents (different reports, deadlines and timeframes) stemming from the requirements of different regulations (PSD2, Single Supervisory Mechanism - SSM, Network security and Information Systems directive - NIS, General Data Protection Regulation - GDPR) lead to duplication and increase the possibility of confusion and errors on the part of the PSPs. Using various templates and producing multiple reports for the same incident depending on the regulations to be applied is neither efficient nor functional. A single template and unique reporting method for all incident types, in all applicable legislations, would be highly appreciated by the market.With reference to the information contained in the template, we consider that it would be enough to provide an accurate representation of the incident. However, we note that two hours are not enough to determine whether the impact is actual or estimated. See Reply 7.
With regard to the confidentiality and integrity requirements in the exchange of information with the Authorities, we suggest providing several examples of communication methods through which these requirements can be met.
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 PSPs are not operational at certain times due to contractual obligations deriving from employment laws. Therefore, if the event occurs during non-operational hours (for example at night), the detection of the incident that triggers the period for the sending of the initial report (Point 23 and Guideline 2.8) should coincide with the time when the PSP is operational, becomes aware of the incident and is able to make the notification. This is also in line with the provisions of Guideline 2.8, which expressly provides that the competent Authorities are not operational at a certain time. The Guidelines should therefore be supplemented in this regard.We note that certain fields of the report are mandatory, but accompanied by the wording ‘if applicable’ or ‘if known’. This indication may be contradictory, and we therefore ask to make the information optional .
We note that “infection of internal systems” and “targeted intrusion” in the “types of attack” in the “cause of incident” Field could overlap, as it would be the case in the event of theft of information using malware. To avoid confusion, it would be possible to refer to or use an already known taxonomy.
Finally, we propose an amendment to page 38 of the Consultation Paper. The description of the affected countries states “countries where the incident has materialized”. However, we cannot understand which country should be indicated if the IT systems affected were located in the country other than the one of the branch or office at which the event materialised.
In the item “Economic impact – indirect costs” (page 41 CP) the inclusion of what is sometimes known as lost profits, or “revenues lost due to missed business opportunities” is not consistent with indirect costs.
With regard to section 8 (“Additional information”), it is not clear what type of information should be provided in the report regarding possible informal communications with other PSPs.
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.
With regard to the report deadlines, we note that:• Initial report. The period of two hours appears first of all to be disproportionate, if the goal of the report is not the prompt circulation of information for prevention purposes, within the market as a whole. We also note that the reporting deadlines stated in the Guidelines are not the same as those in the GDPR (“without undue delay and, where feasible, not later than 72 hours”) or in the NIS Directive (“without undue delay”). In order to standardise the deadlines to avoid error and confusion we suggest using the wording in the GDPR, which, while allowing for flexibility of application in line with the concept of “undue delay” in Article 96(1) of the Directive, also, where possible, sets a maximum period of time.
o As already indicated in Reply 6, in the case of incidents occurring when the PSP is not operational, for example at night or at weekends, it can only report the incident on the next working day. In these cases the moment that triggers the period for the submission of the initial report should be the time when the PSP is once again operational, is aware of the incident and is therefore fully able to make the report.
o Also, the time allowed for production of the initial report should start from the time when the incident was classified as major, and not from the time it was detected (see paragraph 2.8 of the Guidelines). Similarly, in the case of delegated and consolidated reporting (Guidelines 3 and 4) the interaction between the PSP and delegated party is governed by the agreements between the parties. However, as the PSP has full responsibility for reporting, the delegated party will only send a report after obtaining the consent of the PSP. As the working hours of the PSP may not coincide with those of delegated party, it is important to clarify that the initial time from which the period for the sending of the initial report starts to run is the time when the PSP validates the severity of the incident indicated by delegated party.
o Considering the quantity of information and the difficulties in obtaining or producing reliable estimates, two hours are not enough in any case. It must be remembered that in order to obtain information about the incident and its impact, specialised staff and different teams need to be involved. In the case of a delegated reporting procedure, the time required to draw up the report could be extended due to the necessary interaction between the PSP and the delegated party. On expiry of two hours, there are alternative solutions, which we consider to be compatible with the provisions of Article 96(1):
A. Postponing the deadline until the next working day;
B. Sending an initial notification within two hours, without the full content of the report, and giving an indication of when the full report will be sent.
• Intermediate report: We propose to complement the information provided in the initial report (Case B) so as to eliminate the need for an intermediate report: if the PSP states the deadline by which it will provide the full report, including all the measures requested in Annex 1 (including whether the incident should be considered ‘crisis mode’), the intermediate report could be eliminated as it would become superfluous. If that proposal were not accepted, we would, as a second best, propose to postpone the submission deadline, as three days is too narrow a period. A derogation of the deadline would then have to be made, by sending an intermediate report in advance only in exceptional cases, i.e. only if highly significant discrepancies emerge subsequently, compared to the initial assessment of the incident.
• Final report: the period of two weeks appears to be insufficient as the PSP, as indicated in Reply 2, may not have the requested economic data. As to claims, Article 101(2) PSD2 sets a limit of 15 working days from receipt of a claim for PSPs to reply (and therefore it is assumed that this is a minimum limit for effective quantification). We suggest extending the deadline to four weeks.
We note that if the incident is produced by infrastructures or services which are completely external to the PSP (as an example: telecommunication networks) the PSP could not be in a position to fill the information in the reports (especially the intermediate and the final reports) within the deadline, because the reason and the management of the incident is completely outside the PSP’s responsibility.
Question 8: Do you consider I that the delegated reporting procedure proposed in the draft Guidelines will provide added value to the market? Please explain your reasoning.
This proposal is useful especially for PSPs who have chosen full outsourcing to a third party.Question 9: Do you consider that the consolidated reporting procedure proposed in the draft Guidelines will provide added value to the market? Please explain your reasoning.
The consolidated reporting procedure is useful when various PSPs are involved in the same incident. However, we note that Guideline 3.3 requires that PSPs should not delegate the reporting activities unless they have first informed the Competent Authority in the Member State, of that delegation. We consider that this restriction is not justified, as the PSPs remain fully responsible for fulfilling the reporting obligations, and in their contracts all the PSPs will require full compliance, by the delegated party, with the obligations indicated in the Guidelines.Finally, there is a need to clarify whether, in the consolidated reporting procedure, the basis for calculation should be the number of PSUs of the individual service from the individual PSP, or the total PSUs of all PSPs considered in the “consolidated” report.
In addition to the requested answers in the CP, we highlight the importance of clarifying, at EU level and specifically during the national implementation phase the means for transmission of incident reports which have not been defined (Point 31 “Rationale”), also in view of the fact that the information to be reported is strictly confidential. We consider that it would be helpful to clarify which function/office/division of the Competent Authority and which means of transmission to use. We suggest that in addition to the certified e-mail address, a specific telephone number and contact person should also be added.