Response to consultation on Guidelines on major incidents reporting under PSD2
Go back
The current definitions are not fully clear. An example is a strong link between the terms “availability” and “continuity”. If EBA considers that both definitions are required, they should clarify in more detail the difference. Maybe the term ‘continuity’ could be replaced by ‘recovery’, which is the term more generally used. A quick recovery will lead to a short period of unavailability.
On page 21, the definition of Major Operational or security incident, it is defined as an event or series of events which may have material adverse impact…” we would suggest removing may have from the definition, so that only actual real events are required to be reported on.
PSD2 uses the term Payment service ‘user’ rather than ‘client’. We suggest using the same term here.
There is an issue with the templates here being very detailed in parts, which means that there will be partially overlapping reporting obligations of incidents, e.g. in the case of cyber related incidents also affecting PSPs. Reporting channels and templates need to be harmonized with local/national competent authorities so that PSPs do not need to duplicate similar reports and send to different authorities (or even in some cases different reports to the same competent authority) after such events. There is a concern that these guidelines will constitute yet another requirement to report events. Partially overlapping with requirements from other current and proposed legislation nationally as well as at EU level, targeted at payment services providers, critical infrastructure providers and providers of online services already leads to considerable strain on PSPs, and there is a consern that this will increase the workload even further without PSPs gaining much in the way of benefits. In order to avoid this, templates and reporting channels to competent authorities should be harmonized and structured, so that we make use of the reporting channels as PSPs are currently subjected to, rather than introducing increased reporting in multiple channels.
Also, the value of this to the market depends entirely on the purpose of the reporting. It is unclear to us what exactly these reports will be used for. For PSPs usefulness of reporting would depend on resulting informastion being fed back to them, perhaps as trend reports, updated threat assessments and early warnings when major attacks look likely to spread.
On page 26 point 1.4 states that PSPs should resort to estimations if they do not have data. It is unclear what these estimations should be based on? Should these estimations be based on historical data?
In the template, it should be possible to leave topics uncommented. Confidentiality related incidents can also lead to the requirement to report these to the local privacy authority. Preferably, both authorities should accept the same reporting information (maybe with a different reporting frequency). A more clear distinction should also be made between data that is mandatory to be reported and data which is optionally reported.
In our opinion, the template reflects the current security landscape. It will also need to include potential new threats that may arise following the introduction of new roles and actors as a consequence of PSD2, as part of the template.
We also support the possibility for submitting additional documentation if relevant. In some instances this may provide more clarity and relevant information than some of the fields in the template.
We are equally doubtful whether all competent authorities will be staffed on a 24/7/365 basis and hence equipped to receive and process reports in a timely matter according to time frames outlined in this document. Thus, the value of imposing such stringent timeframes on PSPs is questionable.
Equally, the time limit for the final report should be flexible. Some major events are complex, and gathering all the information may take time. It is surely more important that the final report is accurate and contains complete information than delivered within a 2 week time limit.
Question 1: Do you consider the definitions included in the draft Guidelines to be sufficiently clear?
Guideline 1.1 b states that “Payment service providers should determine the number of clients affected both in absolute terms and as a percentage of the total number of clients”. We consider that there is a need to point out that this should only refer to legal persons who are potential users of payment services. These are usually identifiable by referring to a user agreement. Failure to make this distinction will lead to skewed percentages, particularly where several actors may report on the same incident.The current definitions are not fully clear. An example is a strong link between the terms “availability” and “continuity”. If EBA considers that both definitions are required, they should clarify in more detail the difference. Maybe the term ‘continuity’ could be replaced by ‘recovery’, which is the term more generally used. A quick recovery will lead to a short period of unavailability.
On page 21, the definition of Major Operational or security incident, it is defined as an event or series of events which may have material adverse impact…” we would suggest removing may have from the definition, so that only actual real events are required to be reported on.
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?
We would like to suggest some clarifications.PSD2 uses the term Payment service ‘user’ rather than ‘client’. We suggest using the same term here.
There is an issue with the templates here being very detailed in parts, which means that there will be partially overlapping reporting obligations of incidents, e.g. in the case of cyber related incidents also affecting PSPs. Reporting channels and templates need to be harmonized with local/national competent authorities so that PSPs do not need to duplicate similar reports and send to different authorities (or even in some cases different reports to the same competent authority) after such events. There is a concern that these guidelines will constitute yet another requirement to report events. Partially overlapping with requirements from other current and proposed legislation nationally as well as at EU level, targeted at payment services providers, critical infrastructure providers and providers of online services already leads to considerable strain on PSPs, and there is a consern that this will increase the workload even further without PSPs gaining much in the way of benefits. In order to avoid this, templates and reporting channels to competent authorities should be harmonized and structured, so that we make use of the reporting channels as PSPs are currently subjected to, rather than introducing increased reporting in multiple channels.
Also, the value of this to the market depends entirely on the purpose of the reporting. It is unclear to us what exactly these reports will be used for. For PSPs usefulness of reporting would depend on resulting informastion being fed back to them, perhaps as trend reports, updated threat assessments and early warnings when major attacks look likely to spread.
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 definition of ‘major’ will vary according to the size of the PSP. Catastrophic events to a small PSP may not reach reporting threshold, while even minor events from a large PSP will need reporting.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.
On page 25 under reputational impact PSPs should consider if client data is lost or stolen. Would any single social engineering attack targeting individual customers be sufficient to be classified as reputational risk?On page 26 point 1.4 states that PSPs should resort to estimations if they do not have data. It is unclear what these estimations should be based on? Should these estimations be based on historical data?
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.
Has the EBA taken into account the impact of additional notification requirements for incidents that also meet the criteria of the GDPR in case of a data breach? We would like to prevent overburdening PSPs with different notification requirements.In the template, it should be possible to leave topics uncommented. Confidentiality related incidents can also lead to the requirement to report these to the local privacy authority. Preferably, both authorities should accept the same reporting information (maybe with a different reporting frequency). A more clear distinction should also be made between data that is mandatory to be reported and data which is optionally reported.
In our opinion, the template reflects the current security landscape. It will also need to include potential new threats that may arise following the introduction of new roles and actors as a consequence of PSD2, as part of the template.
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.
It should be possible to leave fields empty. For example for an initial report all details may not be clear when the report is sent. Some things may never become entirely clear, or be relevant.We also support the possibility for submitting additional documentation if relevant. In some instances this may provide more clarity and relevant information than some of the fields in the template.
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.
No. The staff who are tasked with reporting to authorities are not present 24/7/365. The staff members who are on round-the-clock duty need to prioritize handling and recovery from a major incident. Incident handling and reporting functions are often delegated to different organization units. The reporting function is usually only staffed during office hours. A two hour time limit for initial reports would only be feasible during office hours, outside holiday seasons and unless the incident collided with other activities. 24 hours is more feasible, but may also be too short during weekends and public holidays.We are equally doubtful whether all competent authorities will be staffed on a 24/7/365 basis and hence equipped to receive and process reports in a timely matter according to time frames outlined in this document. Thus, the value of imposing such stringent timeframes on PSPs is questionable.
Equally, the time limit for the final report should be flexible. Some major events are complex, and gathering all the information may take time. It is surely more important that the final report is accurate and contains complete information than delivered within a 2 week time limit.