Response to consultation on Guidelines on major incidents reporting under PSD2
Go back
Specifically:
1. The definition of “major operational or security incident” includes a reference to an event (or series of linked events) that “may have” an adverse impact on the delivery of payment services. Under this definition, PSPs are required to make an assessment on the observed and future impact of an incident as part of their incident reporting process. We feel that this places a very significant burden on PSPs and will likely lead to over-reporting. We would suggest that only incidents that have already breached the relevant Criteria thresholds detailed in Section 4 (Guideline 1) should be classified as major.
2. The definitions of “Availability” and “Continuity” that are provided appear to be largely overlapping. The concept of service resilience or recoverability after an incident occurs is covered under the standard information security definition of availability as listed in the (ISO/IEC 27000:2016 Information technology — Security techniques — Information security management systems - Overview and vocabulary: 2016 edition). We would suggest that the standard Availability definition that appears in this ISO standard is adopted and the definition of Continuity is removed.
The Transactions affected and the Clients affected criteria use the term “affected” in a generic manner. It is not clear whether the term is meant to cover lack of access (non availability), or compromise (exposed transaction or customer data), or lack of integrity (data corruption or unauthorized alterations).
We believe that the severity of the impact to a payment service – and therefore the classification- of an incident will be different depending on the nature of the incident. We recommend that the definition of these criteria is further limited to incidents that impact the confidentiality and integrity of transactions and customer accounts rather than incidents of service unavailability.
The provision for Economic impact requires PSPs “to determine the monetary costs associated to the incident holistically”. Guideline 1.2 references both direct and indirect costs connected to an incident. We believe that the scope of this definition is too wide, at present. It is also likely to be under-used as an incident notification trigger since the full economic impact of an incident is usually unclear for some time after it is first detected. It is worth considering whether this criterion is needed at all; the Transactions affected and Clients affected criteria can be used to capture economic impact for a PSP.
The thresholds of the 3 qualitative criteria (High Level of internal escalation, Other payment service providers or relevant infrastructures potentially affected and Reputational impact) are themselves not clear.
For the criterion “Other payment service providers or relevant infrastructures potentially affected”, the PSP is expected to make industry/systemic-risk assessments even though it may have limited visibility of the impact of an incident beyond its own infrastructure. We believe that NCAs are much better placed to complete such assessments.
For the criterion “Reputational impact”, the PSP is required to consider the visibility of an incident in the marketplace and the media coverage it has received. We consider this a subjective and inconsistent criterion to use to classify an incident since it is not uncommon for minor incidents to receive wide media coverage while higher-impact incidents are often not reported at all.
We therefore recommend that:
a. The Other payment service providers or… potentially affected and Reputational impact criteria are removed altogether,
b. The High Level of internal escalation criterion is only assigned a Level 2 Threshold that is triggered when the PSP Disaster Recovery Plan (DRP) is activated.
We would additionally welcome more clarity on the application of the Level 2 thresholds for the Transactions affected and Clients affected criteria:
• Does the use of the term OR suggest that breaching EITHER of the two Level 2 thresholds listed in Table 1 would trigger a notification? The static thresholds listed for these 2 criteria are quite low even for medium-size PSPs.
We believe that the assignment of static (monetary) criteria thresholds will lead to inconsistent reporting of growing numbers of incidents across PSPs of different size. We therefore suggest revising these to make them proportionate to the size or turnover of the business.
The continued mis-classification of incidents will add white noise to this process and make it more difficult for NCAs to identify genuine major incidents that should be shared with domestic authorities, the EBA/ECB and other EU NCAs. We would advise that the static (amount-based) Level 2 thresholds of all quantitative criteria are replaced by relative thresholds that reference the size/scope of the business of the reporting PSP.
On a related topic, we would welcome the establishment of a standardized, 2-way incident notification process between PSPs and the relevant NCAs whereby PSPs both submit and receive updates of major incidents that may impact their services. Such a notification mechanism could supplement mechanisms established by national CERTs and help PSPs prepare to address major incidents. The establishment of such a notification process will deliver real security benefits to PSPs and increase the appreciation of this incident reporting framework among the PSP community.
Finally, we want to highlight the multiple incident reporting requirements introduced by a number of regulatory frameworks (GDPR, eIDAS, NIS etc.) that PSPs need to satisfy. Our members would urge the EBA to align reporting frequencies and reporting data formats under these Guidelines with existing regulatory frameworks.
1. The Qualitative criterion “Other payment service providers or relevant infrastructures potentially affected” is removed. We do not feel that individual PSPs are best placed to assess whether a particular incident can be replicated at other payment service providers.
2. The qualitative criterion “Reputational impact” is removed. This is an entirely subjective criterion that is largely dependent on the likelihood of exposure of the effects of an incident to the public/press, and to consequent public perception. We do not perceive this to be a dependable, consistent criterion for assigning a major classification to an incident.
3. Assign only a Level 2 threshold to the criterion “High Level of internal escalation” that should be tied to the activation of a PSP’s Disaster Recovery Plan. We perceive such an arrangement will provide a more accurate reflection of the impact of an incident rather than an “escalation” to the Information Security Officer (or CIO). Especially, in smaller PSPs where C-level executives fulfil many roles, the report of an incident to the CISO or CIO is not necessarily indicative of major incident. On the other hand, the Activation of a DRP identifies a major emergency.
4. Remove the “Economic Impact” criterion since it is almost impossible to assess with any accuracy at the time an incident is detected. Instead, the combination of the “Transactions affected” and “Clients affected” criteria can provide a good proxy of the scope of the financial impact of an incident to a PSP.
5. Remove all static criteria thresholds from Table 1. Instead, thresholds should be stated in relation to the size/scope of the business of the reporting PSP. The current static thresholds will cause most medium/large PSPs to generate significantly more reports for incidents that may not prove to be major. Thus, they will lead to inconsistent reporting of incidents across PSPs of different sizes.
However, we are concerned that the proposed Report Template introduces yet another Report format that PSPs must use to interact with competent authorities on a range of subjects. We would ask that the EBA confirms that the proposed report template aligns with similar report templates introduced by the EU Network & Information Systems Security Directive (2016/1148) and the General Data Protection Regulation (EU 2016/679).
We are also concerned that the attempted differentiation between Operational and Security incident types under the Incident Classification section of the template is not helpful; some incidents may be both. At the time of filing the Initial Incident Report, it can be very difficult for a PSP to make this distinction. Therefore, we would question the value-add of the attempted differentiation of operational vs. security incidents.
Additionally, we note that the PSP is expected to provide very sensitive information under the Incident Mitigation section of the Report Template. This information comprises BCP/DRP details, descriptions of the measures taken to address the incident, description of security controls that have been impacted etc. Our members are keen to understand the security controls that will apply to the channel used to pass such Incident Reports to the NCA and the confidentiality undertakings of the relevant competent authorities for receiving/storing/processing and transmitting such information. For example, could such information be released by the NCAs if it became the subject of Freedom of Information Act requests? The subsequent release of such information by an NCA without the explicit approval of the PSP may have a significant impact on the financial position of a PSP.
In view of the risks outlined above, we would ask the EBA to clarify the rationale behind the process of the NCA collecting the sensitive information listed under the Incident Mitigation section of the Report Template.
1. In the General Details section, under Report details, provide space for a PSP-generated Report ID that can then be referenced in Intermediate Reports and the Final report. This will limit the likelihood of duplication and miscounting of incidents.
2. Confirm how the PSP receives the “unique code issued by the competent authority at the first data record” that is to be introduced under Report Details.
3. Clarify the difference between “Repair” and “Recovery” Status stages in the Incident Discovery section of the Template. Consider removing one of the 2 stages to avoid confusion and mis-reporting of the status of the efforts of the PSP to address the incident.
4. In the Incident Description section of the Template, under Cause of Incident -> Type of attack, the labels “infection of internal systems” and “targeted intrusion” are often overlapping (e.g. zero-day OS/system bugs or malware introduced by an attacker that is then exploited to carry out a targeted intrusion). It is useful to inform PSPs that multiple attack vectors may be present in a single incident and should be reported.
5. In the Incident Impact section of the template, under “Payment Services affected”, replace “Cash placement & withdrawal from a payment account” with the more generic “Fund transfer into & from a payment account”. The latter term offers a more accurate description of the payment services offered by E-Money Issuers and Payment Institutions to their account holders.
6. Finally, in the Incident Impact section of the template, under “Functional areas affected”, introduce a standalone “Customer service” choice and a sub-listing of separate customer service channels (e-mail, phone, IRC chat, social media etc.). Since customer service systems are the primary means of PSP<-> customer communication, it is appropriate to allow PSPs to highlight incidents that impact such communication.
We believe that time interval for the submission of Intermediate Reports should be fixed to 5 working days. PSPs should be encouraged to submit more frequent Intermediate Reports to inform NCAs of any material change to the scope/impact of a previously-reported incident. The current expectation to submit a new Intermediate Report “every time there is a relevant status update” (Guideline 2, Clause 2.11) and in any case every 3 business days (Clause 2.13) will force PSPs to submit Intermediate Reports with limited new incident information; in return, this will create additional report processing overheads at the relevant NCAs for limited value-add.
The current expectation that a Final Report is submitted 2 weeks after business is deemed back to normal (Guideline 2, Clause 2.17) underestimates the time/effort involved in carrying out forensic and root cause analysis activities. The PSP should be afforded flexibility for the submission of the Final Report; weekly Intermediate Reports can continue to be used to provide more incident information to the relevant NCA before the Final Report is submitted.
Overall, we would propose that incident reporting deadlines become variable to reflect the systemic risk posed by attacks that impact the systems and operations of PSPs that underpin the ongoing operation of domestic and EU-wide financial services systems. Indeed, the NIS directive had already identified such PSPs and assigned specific incident reporting requirements to them. As a result, such PSPs have already initiated a process to establish security incident reporting processes and resources that align with the requirements of the NIS Directive; these processes typically complement security engineering resources that are tasked with addressing the impact of incidents. It is in the interest of NCAs to be quickly informed of major incidents that impact the operations of PSPs of such size/scope. However, we would suggest that it may not be helpful to apply the same incident reporting deadlines to all PSPs that are regulated by any Home Member NCA.
Question 1: Do you consider the definitions included in the draft Guidelines to be sufficiently clear?
A. A number of definitions would benefit from further clarity.Specifically:
1. The definition of “major operational or security incident” includes a reference to an event (or series of linked events) that “may have” an adverse impact on the delivery of payment services. Under this definition, PSPs are required to make an assessment on the observed and future impact of an incident as part of their incident reporting process. We feel that this places a very significant burden on PSPs and will likely lead to over-reporting. We would suggest that only incidents that have already breached the relevant Criteria thresholds detailed in Section 4 (Guideline 1) should be classified as major.
2. The definitions of “Availability” and “Continuity” that are provided appear to be largely overlapping. The concept of service resilience or recoverability after an incident occurs is covered under the standard information security definition of availability as listed in the (ISO/IEC 27000:2016 Information technology — Security techniques — Information security management systems - Overview and vocabulary: 2016 edition). We would suggest that the standard Availability definition that appears in this ISO standard is adopted and the definition of Continuity is removed.
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?
A. We would recommend that the incident assessment criteria are further clarified to avoid misinterpretation and to facilitate consistent, accurate reporting of major operational or security incidents.The Transactions affected and the Clients affected criteria use the term “affected” in a generic manner. It is not clear whether the term is meant to cover lack of access (non availability), or compromise (exposed transaction or customer data), or lack of integrity (data corruption or unauthorized alterations).
We believe that the severity of the impact to a payment service – and therefore the classification- of an incident will be different depending on the nature of the incident. We recommend that the definition of these criteria is further limited to incidents that impact the confidentiality and integrity of transactions and customer accounts rather than incidents of service unavailability.
The provision for Economic impact requires PSPs “to determine the monetary costs associated to the incident holistically”. Guideline 1.2 references both direct and indirect costs connected to an incident. We believe that the scope of this definition is too wide, at present. It is also likely to be under-used as an incident notification trigger since the full economic impact of an incident is usually unclear for some time after it is first detected. It is worth considering whether this criterion is needed at all; the Transactions affected and Clients affected criteria can be used to capture economic impact for a PSP.
The thresholds of the 3 qualitative criteria (High Level of internal escalation, Other payment service providers or relevant infrastructures potentially affected and Reputational impact) are themselves not clear.
For the criterion “Other payment service providers or relevant infrastructures potentially affected”, the PSP is expected to make industry/systemic-risk assessments even though it may have limited visibility of the impact of an incident beyond its own infrastructure. We believe that NCAs are much better placed to complete such assessments.
For the criterion “Reputational impact”, the PSP is required to consider the visibility of an incident in the marketplace and the media coverage it has received. We consider this a subjective and inconsistent criterion to use to classify an incident since it is not uncommon for minor incidents to receive wide media coverage while higher-impact incidents are often not reported at all.
We therefore recommend that:
a. The Other payment service providers or… potentially affected and Reputational impact criteria are removed altogether,
b. The High Level of internal escalation criterion is only assigned a Level 2 Threshold that is triggered when the PSP Disaster Recovery Plan (DRP) is activated.
We would additionally welcome more clarity on the application of the Level 2 thresholds for the Transactions affected and Clients affected criteria:
• Does the use of the term OR suggest that breaching EITHER of the two Level 2 thresholds listed in Table 1 would trigger a notification? The static thresholds listed for these 2 criteria are quite low even for medium-size PSPs.
We believe that the assignment of static (monetary) criteria thresholds will lead to inconsistent reporting of growing numbers of incidents across PSPs of different size. We therefore suggest revising these to make them proportionate to the size or turnover of the business.
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.
A. We believe that the reporting methodology will lead to over-reporting of incidents regarded as “major” that will subsequently prove to be less significant.The continued mis-classification of incidents will add white noise to this process and make it more difficult for NCAs to identify genuine major incidents that should be shared with domestic authorities, the EBA/ECB and other EU NCAs. We would advise that the static (amount-based) Level 2 thresholds of all quantitative criteria are replaced by relative thresholds that reference the size/scope of the business of the reporting PSP.
On a related topic, we would welcome the establishment of a standardized, 2-way incident notification process between PSPs and the relevant NCAs whereby PSPs both submit and receive updates of major incidents that may impact their services. Such a notification mechanism could supplement mechanisms established by national CERTs and help PSPs prepare to address major incidents. The establishment of such a notification process will deliver real security benefits to PSPs and increase the appreciation of this incident reporting framework among the PSP community.
Finally, we want to highlight the multiple incident reporting requirements introduced by a number of regulatory frameworks (GDPR, eIDAS, NIS etc.) that PSPs need to satisfy. Our members would urge the EBA to align reporting frequencies and reporting data formats under these Guidelines with existing regulatory frameworks.
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.
A. As outlined in the response we provided to Q.2 above, we propose that:1. The Qualitative criterion “Other payment service providers or relevant infrastructures potentially affected” is removed. We do not feel that individual PSPs are best placed to assess whether a particular incident can be replicated at other payment service providers.
2. The qualitative criterion “Reputational impact” is removed. This is an entirely subjective criterion that is largely dependent on the likelihood of exposure of the effects of an incident to the public/press, and to consequent public perception. We do not perceive this to be a dependable, consistent criterion for assigning a major classification to an incident.
3. Assign only a Level 2 threshold to the criterion “High Level of internal escalation” that should be tied to the activation of a PSP’s Disaster Recovery Plan. We perceive such an arrangement will provide a more accurate reflection of the impact of an incident rather than an “escalation” to the Information Security Officer (or CIO). Especially, in smaller PSPs where C-level executives fulfil many roles, the report of an incident to the CISO or CIO is not necessarily indicative of major incident. On the other hand, the Activation of a DRP identifies a major emergency.
4. Remove the “Economic Impact” criterion since it is almost impossible to assess with any accuracy at the time an incident is detected. Instead, the combination of the “Transactions affected” and “Clients affected” criteria can provide a good proxy of the scope of the financial impact of an incident to a PSP.
5. Remove all static criteria thresholds from Table 1. Instead, thresholds should be stated in relation to the size/scope of the business of the reporting PSP. The current static thresholds will cause most medium/large PSPs to generate significantly more reports for incidents that may not prove to be major. Thus, they will lead to inconsistent reporting of incidents across PSPs of different sizes.
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.
A. The information that the reporting PSP is asked to provide in the Major Incident Report template in Annex 1 is quite comprehensive and could allow the relevant NCA to understand the scope/type of the incident being reported.However, we are concerned that the proposed Report Template introduces yet another Report format that PSPs must use to interact with competent authorities on a range of subjects. We would ask that the EBA confirms that the proposed report template aligns with similar report templates introduced by the EU Network & Information Systems Security Directive (2016/1148) and the General Data Protection Regulation (EU 2016/679).
We are also concerned that the attempted differentiation between Operational and Security incident types under the Incident Classification section of the template is not helpful; some incidents may be both. At the time of filing the Initial Incident Report, it can be very difficult for a PSP to make this distinction. Therefore, we would question the value-add of the attempted differentiation of operational vs. security incidents.
Additionally, we note that the PSP is expected to provide very sensitive information under the Incident Mitigation section of the Report Template. This information comprises BCP/DRP details, descriptions of the measures taken to address the incident, description of security controls that have been impacted etc. Our members are keen to understand the security controls that will apply to the channel used to pass such Incident Reports to the NCA and the confidentiality undertakings of the relevant competent authorities for receiving/storing/processing and transmitting such information. For example, could such information be released by the NCAs if it became the subject of Freedom of Information Act requests? The subsequent release of such information by an NCA without the explicit approval of the PSP may have a significant impact on the financial position of a PSP.
In view of the risks outlined above, we would ask the EBA to clarify the rationale behind the process of the NCA collecting the sensitive information listed under the Incident Mitigation section of the Report 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.
A. We find the Incident Report completion instructions provided in the Consultation Paper to be clear and useful. We would recommend that the following changes are carried out to the Incident Report Template to allow reporting PSPs to complete it more efficiently:1. In the General Details section, under Report details, provide space for a PSP-generated Report ID that can then be referenced in Intermediate Reports and the Final report. This will limit the likelihood of duplication and miscounting of incidents.
2. Confirm how the PSP receives the “unique code issued by the competent authority at the first data record” that is to be introduced under Report Details.
3. Clarify the difference between “Repair” and “Recovery” Status stages in the Incident Discovery section of the Template. Consider removing one of the 2 stages to avoid confusion and mis-reporting of the status of the efforts of the PSP to address the incident.
4. In the Incident Description section of the Template, under Cause of Incident -> Type of attack, the labels “infection of internal systems” and “targeted intrusion” are often overlapping (e.g. zero-day OS/system bugs or malware introduced by an attacker that is then exploited to carry out a targeted intrusion). It is useful to inform PSPs that multiple attack vectors may be present in a single incident and should be reported.
5. In the Incident Impact section of the template, under “Payment Services affected”, replace “Cash placement & withdrawal from a payment account” with the more generic “Fund transfer into & from a payment account”. The latter term offers a more accurate description of the payment services offered by E-Money Issuers and Payment Institutions to their account holders.
6. Finally, in the Incident Impact section of the template, under “Functional areas affected”, introduce a standalone “Customer service” choice and a sub-listing of separate customer service channels (e-mail, phone, IRC chat, social media etc.). Since customer service systems are the primary means of PSP<-> customer communication, it is appropriate to allow PSPs to highlight incidents that impact such communication.
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.
A. We consider the deadline for submission of the Initial Report to (a maximum of 2 hours after first detection of an incident) to be unattainable. The main focus of a PSP’s efforts when they first detect a major incident will be to understand its scope and mitigate its impact through a Triage process rather than fill in a detailed Incident Report Form. A requirement to submit a major incident report within 2 hours after an incident is detected may actually impede the efforts of a PSP Incident Response team by forcing the diversion of limited resources away from incident control activities. To allow PSPs to gather meaningful information on an Incident that can be used to populate/submit the Incident Report Form, a minimum of 24 hours after detection would be much more realistic.We believe that time interval for the submission of Intermediate Reports should be fixed to 5 working days. PSPs should be encouraged to submit more frequent Intermediate Reports to inform NCAs of any material change to the scope/impact of a previously-reported incident. The current expectation to submit a new Intermediate Report “every time there is a relevant status update” (Guideline 2, Clause 2.11) and in any case every 3 business days (Clause 2.13) will force PSPs to submit Intermediate Reports with limited new incident information; in return, this will create additional report processing overheads at the relevant NCAs for limited value-add.
The current expectation that a Final Report is submitted 2 weeks after business is deemed back to normal (Guideline 2, Clause 2.17) underestimates the time/effort involved in carrying out forensic and root cause analysis activities. The PSP should be afforded flexibility for the submission of the Final Report; weekly Intermediate Reports can continue to be used to provide more incident information to the relevant NCA before the Final Report is submitted.
Overall, we would propose that incident reporting deadlines become variable to reflect the systemic risk posed by attacks that impact the systems and operations of PSPs that underpin the ongoing operation of domestic and EU-wide financial services systems. Indeed, the NIS directive had already identified such PSPs and assigned specific incident reporting requirements to them. As a result, such PSPs have already initiated a process to establish security incident reporting processes and resources that align with the requirements of the NIS Directive; these processes typically complement security engineering resources that are tasked with addressing the impact of incidents. It is in the interest of NCAs to be quickly informed of major incidents that impact the operations of PSPs of such size/scope. However, we would suggest that it may not be helpful to apply the same incident reporting deadlines to all PSPs that are regulated by any Home Member NCA.