Response to consultation on Guidelines on major incidents reporting under PSD2
Go back
The community would strongly advise that EBA adopts definitions from international organisations such ISO, BIS or ENISA which are already widely used in the industry (e.g. GDPR, NIS Directive, eIDAS) in order to achieve harmonization of definitions.
General remarks – Sharing of information
Sharing information in a timely manner is of uttermost importance so as to detect, contain and/or prevent evolving threats. Anonymized information on reported major incidents should be shared by competent authorities with financial institutions on a confidential basis, and not solely to supervisors and regulators. These early warnings would increase information intelligence and therefore would allow financial institutions to proactively take measures to avoid or prevent those or similar incidents, in order to protect customers and other stakeholders.
General remarks – Harmonization of incident reporting
The Portuguese community understands the need to report incidents to the PSD2 authority, but we observe an increase on demand for the PSPs to report the same type of incidents to the different regulators, thus increasing the burden with reporting. There is definitely a need for harmonisation for incident reporting, and so the guidelines should make clear to the competent authorities in the Member States that these guidelines should replace similar reporting requirements from these authorities.
Distinguishing criteria for unavailability incidents vs integrity and confidentiality incidents
The criteria introduced does not distinguish between incidents leading to unavailability of the service (e.g. a DDoS attack, or an internal failure leading to unavailability of the service) and other types of incidents. We think that an unavailability of the service for a short period (e.g. 5min.) should not be categorised as major incident, even though this (potentially) may affect all customers.
Adequacy of criteria for AISPs
Some of the threshold criteria is not applicable to AISPs (e.g., transactions affected). It might be appropriate to define a special threshold matrix for AISPs (e.g., number of compromised records).
Externally originated incidents reporting
Incidents that derive from incidents of external origin (e.g., communications or electrical blackout) are not contemplated in any special way in these guidelines and may thus lead to unnecessary reporting. On the other hand, other incidents of external origin (e.g., a PISP compromise) may at least require an initial report.
This community believes that the high level criteria will lead to significantly more reporting of incidents compared to what is considered major today, more in particular related to operational incidents. Some thresholds might need to be revisited for large PSPs to result in the reporting of truly major incidents rather than getting involved in “business as usual” incident reporting and investigation.
In our opinion the qualitative criteria are not sufficiently detailed in order to determine the risk. A “yes/no” answer is not sufficient to measure this; for example:
• A “Reputational impact” will, although it may be low, always result in a “yes” answer.
• The criteria “Other payment service providers or relevant infrastructures potentially affected” should be quantified in order to give some guidance on the level.
• The “High level of internal escalation” criteria should be more detailed and granular than indicated by the EBA in the draft Guidelines paragraph 1.2.e. In some financial institutions, all incidents are reported to the Chief Information Officer (or similar) despite its significance/criticality. For instance, the escalation to the Board of Directors or to a risk/audit committee outside of the regular reporting procedures would provide a meaningful indication of the potential significance of the underlying event.
Chief Officers terms harmonization
Consistency between “Chief Information Officer” and “executive officers of the organization” should be managed. Perhaps the term “Chief Information Security Officer” might be considered.
As rightly stated in the consultation paper, data breaches may have a serious impact on payment service users and their PSPs. For that reason, they should be reported in the same way under PSD2 and the GDPR. We would therefore propose to align reporting requirements as it was done for the NIS Directive to avoid duplication and loss of meaningful intelligence.
Report classification
The guidelines do not mention the confidentiality of the report provided to the competent authority. We believe that the information should be considered confidential. No request – for example by a journalist, should potentially lead to the disclosure of any of the information provided to the competent authority.
Clarification on mandatory vs optional nature of information
A clearer distinction should be made between data that is mandatory to be reported and data which is optionally reported.
Yes they are, but some clarifications would be useful:
• In the field “Incident status”, the “repair” and “restoration” choices need more clarification.
• In the field “Economic impact”, “Indirect costs” are several times difficult to be estimated.
• In the field “cause of incident”, in the “type of attack”, the choices “infection of internal systems” and “targeted intrusion” need more clarification and could be overlapping (e.g. What choice should be made of a malware 0-day attack for stealing information).
• The field “Did the PSP had to cancel….” needs more clarification.
• Does the field “Was a civil complaint filed against the PSP” also include legal actions against the PSP before the civilian goes to a court?
• Introduce a box in the template to indicate whether the numbers are estimates or measured values.
We are of the opinion that the requirement for the first report to be issued within 2 hours of identification to be unrealistic and disproportionate, not defending the interests of the stakeholders. The first hours of any incident have as the primal priority containing the attack and preventing eminent danger. The reporting within 72 hours, aligned with the GDPR, would seem more adequate. It should be stressed that this is a maximum time and that participants should respond within this period but at the earliest moment possible.
Incident final report deadline
The experience of our members shows that investigations for major incidents might be very complex (e.g. forensic analyses of major incidents usually require more than two weeks) and numbers for direct and indirect impact may be hard to calculate in a couple of weeks. Therefore, the proposed two weeks for the final report is definitely too short.
The procedure proposed in the draft guideline will certainly provide added value for smaller PSPs.
Yes, it might be appropriate to cover a number of PSPs, e.g., if they share a common infrastructure or are participants in the same payment scheme.
Question 1: Do you consider the definitions included in the draft Guidelines to be sufficiently clear?
Adopting definitions from international organisationsThe community would strongly advise that EBA adopts definitions from international organisations such ISO, BIS or ENISA which are already widely used in the industry (e.g. GDPR, NIS Directive, eIDAS) in order to achieve harmonization of definitions.
General remarks – Sharing of information
Sharing information in a timely manner is of uttermost importance so as to detect, contain and/or prevent evolving threats. Anonymized information on reported major incidents should be shared by competent authorities with financial institutions on a confidential basis, and not solely to supervisors and regulators. These early warnings would increase information intelligence and therefore would allow financial institutions to proactively take measures to avoid or prevent those or similar incidents, in order to protect customers and other stakeholders.
General remarks – Harmonization of incident reporting
The Portuguese community understands the need to report incidents to the PSD2 authority, but we observe an increase on demand for the PSPs to report the same type of incidents to the different regulators, thus increasing the burden with reporting. There is definitely a need for harmonisation for incident reporting, and so the guidelines should make clear to the competent authorities in the Member States that these guidelines should replace similar reporting requirements from these authorities.
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?
No, please see the comments and requests for further clarifications below.Distinguishing criteria for unavailability incidents vs integrity and confidentiality incidents
The criteria introduced does not distinguish between incidents leading to unavailability of the service (e.g. a DDoS attack, or an internal failure leading to unavailability of the service) and other types of incidents. We think that an unavailability of the service for a short period (e.g. 5min.) should not be categorised as major incident, even though this (potentially) may affect all customers.
Adequacy of criteria for AISPs
Some of the threshold criteria is not applicable to AISPs (e.g., transactions affected). It might be appropriate to define a special threshold matrix for AISPs (e.g., number of compromised records).
Externally originated incidents reporting
Incidents that derive from incidents of external origin (e.g., communications or electrical blackout) are not contemplated in any special way in these guidelines and may thus lead to unnecessary reporting. On the other hand, other incidents of external origin (e.g., a PISP compromise) may at least require an initial report.
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.
Potential excessive reportingThis community believes that the high level criteria will lead to significantly more reporting of incidents compared to what is considered major today, more in particular related to operational incidents. Some thresholds might need to be revisited for large PSPs to result in the reporting of truly major incidents rather than getting involved in “business as usual” incident reporting and investigation.
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.
Qualitative thresholds lack more detailIn our opinion the qualitative criteria are not sufficiently detailed in order to determine the risk. A “yes/no” answer is not sufficient to measure this; for example:
• A “Reputational impact” will, although it may be low, always result in a “yes” answer.
• The criteria “Other payment service providers or relevant infrastructures potentially affected” should be quantified in order to give some guidance on the level.
• The “High level of internal escalation” criteria should be more detailed and granular than indicated by the EBA in the draft Guidelines paragraph 1.2.e. In some financial institutions, all incidents are reported to the Chief Information Officer (or similar) despite its significance/criticality. For instance, the escalation to the Board of Directors or to a risk/audit committee outside of the regular reporting procedures would provide a meaningful indication of the potential significance of the underlying event.
Chief Officers terms harmonization
Consistency between “Chief Information Officer” and “executive officers of the organization” should be managed. Perhaps the term “Chief Information Security Officer” might be considered.
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.
PSD2 and GDPR reporting harmonizationAs rightly stated in the consultation paper, data breaches may have a serious impact on payment service users and their PSPs. For that reason, they should be reported in the same way under PSD2 and the GDPR. We would therefore propose to align reporting requirements as it was done for the NIS Directive to avoid duplication and loss of meaningful intelligence.
Report classification
The guidelines do not mention the confidentiality of the report provided to the competent authority. We believe that the information should be considered confidential. No request – for example by a journalist, should potentially lead to the disclosure of any of the information provided to the competent authority.
Clarification on mandatory vs optional nature of information
A clearer distinction should be made between data that is mandatory to be reported and data which is optionally reported.
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.
Field clarificationsYes they are, but some clarifications would be useful:
• In the field “Incident status”, the “repair” and “restoration” choices need more clarification.
• In the field “Economic impact”, “Indirect costs” are several times difficult to be estimated.
• In the field “cause of incident”, in the “type of attack”, the choices “infection of internal systems” and “targeted intrusion” need more clarification and could be overlapping (e.g. What choice should be made of a malware 0-day attack for stealing information).
• The field “Did the PSP had to cancel….” needs more clarification.
• Does the field “Was a civil complaint filed against the PSP” also include legal actions against the PSP before the civilian goes to a court?
• Introduce a box in the template to indicate whether the numbers are estimates or measured values.
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.
Containment as a primal priorityWe are of the opinion that the requirement for the first report to be issued within 2 hours of identification to be unrealistic and disproportionate, not defending the interests of the stakeholders. The first hours of any incident have as the primal priority containing the attack and preventing eminent danger. The reporting within 72 hours, aligned with the GDPR, would seem more adequate. It should be stressed that this is a maximum time and that participants should respond within this period but at the earliest moment possible.
Incident final report deadline
The experience of our members shows that investigations for major incidents might be very complex (e.g. forensic analyses of major incidents usually require more than two weeks) and numbers for direct and indirect impact may be hard to calculate in a couple of weeks. Therefore, the proposed two weeks for the final report is definitely too short.
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.
Contemplating smaller PSPsThe procedure proposed in the draft guideline will certainly provide added value for smaller PSPs.
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.
Contemplating consolidated reportingYes, it might be appropriate to cover a number of PSPs, e.g., if they share a common infrastructure or are participants in the same payment scheme.