We believe the definitions included in the draft Guidelines are sufficiently clear, but we would welcome additional clarity regarding the following:
• Scope: paragraph 11 on page 7 notes that these Guidelines cover incidents affecting payment services, while incidents related to non-payment services would fall under the Network and Information Security Directive. Yet paragraph 13 on page 7 and the definition on page 21 suggest that any incidents that also impact payment services (including ‘supporting tasks’) are also covered. We would appreciate greater clarity on what those supporting tasks are, and generally what types of incident affecting payment services are included. Are power outages or natural disasters (for instance) also covered?
• Coherence with other obligations: has the EBA considered other reporting requirements that firms are covered by, such as the General Data Protection Regulation, or existing national rules on incident reporting? In some cases the same incident will need to be reported to different Competent Authorities – such as the Data Protection Regulator, the Financial Services Regulator or the Cyber Security Regulator. Streamlining these different reporting requirements would help reduce the administrative burden on firms and provide a more harmonized supervisory approach.
• Purpose of the reporting: we would welcome greater clarity regarding the purpose of reporting to national authorities. In our view, this reporting should lead to more cooperation and joint efforts between payment service providers and authorities to prevent and mitigate such incidents in the future, and ultimately to protect the financial system. As such it would be useful to have a sense of what the authorities will do with the reports (i.e. how will the data be analysed and used), and what security measures are in place to ensure the confidentiality and integrity of these reports when they are shared with other national regulators. In addition, we would stress the value of a two-way process between payment providers and national authorities, whereby payment providers also receive updates of major incidents that may impact their activities, to enhance the robustness the cyber security landscape.
The proposed methodology generally allows for a clear assessment and classification of major incidents. For specific comments on the suggested thresholds, please refer to our response to question 4.
We would however like to clarify that the outcome of external application testing programs are not within scope of the Guidelines. These external programs – whereby external vendors/individual contributors signal security vulnerabilities in exchange for compensation – are an essential part of any company’s ongoing security monitoring programs.
The proposed methodology will likely result in significantly more incidents being considered as “major”. Given the low values in the proposed thresholds, there is a risk that even minor incidents could be considered as “major”. This is especially true for larger payment service providers, where even one large-value payment failing to process could trigger a threshold. This risks undermining the meaning of “major” and devalues the reporting procedure. It would also affect the adequate treatment of those major incidents that require proper attention from the Competent Authorities.
To mitigate this risk, we would suggest clarifying that the thresholds must actually be exceeded before the incident is classified as “major”, rather than basing the report on the mere potential of exceeding a threshold. Providing further clarifications on the criteria will also contribute to reducing the volume of reported incidents (please see our response to question 4).
In addition, rather than basing the reporting timelines on the moment where the incident is identified, we recommend using the point where the incident is confirmed as “major”, once the forensic analysis / diagnostics are completed. This would lead to more accurate reporting, as well as contribute to mitigating over-escalations of minor incidents.
We would welcome additional clarification on the thresholds referred to in Guideline 1.3:
• Transactions Affected
1. The monetary values are generally quite low and will lead to an increased number of reported incidents. It is possible that an incident concerning one large-value payment failing to process could trigger these thresholds. We would recommend maintaining only the relative values expressed in percentages.
2. We would welcome more clarity on the meaning of affected in this context. For instance, does this only concern the transactions compromised as part of the breach, or also those impacted by the wider service interruption (e.g. loss of access)?
3. The definition should also further define under what circumstances is a transaction considered as affected or compromised (e.g. loss of data/type of data compromised, loss of service/delays in the service, the transaction type, etc.).
4. Regarding the term “regular level of transactions”: does this cover all the transactions performed within the affected Member State(s), or those performed by the payment service provider in the EU, or globally?
• Clients Affected
1. The static values are generally quite low and will lead to an increased number of reported incidents. We would recommend maintaining only the relative values expressed in percentages.
2. We would welcome more clarity on the meaning of affected in this context, and especially under what circumstances is a client considered as affected (e.g. loss of data/type of data compromised, loss of service/delays in the service, the transaction type, etc.).
3. Regarding the term “total number of clients”: does this cover all the clients in the affected Member State(s), or the total number of clients in the EU, or globally?
4. We would also welcome confirmation that individual incidents (such as customer phishing or account takeovers), when bundled into a campaign carried out by the same perpetrators and which may meet some of the thresholds, do not in fact qualify under these Guidelines.
• Service Downtime
1. Does this concern total outages of the payment system, or also situations where the system remains operational but with reduced functionalities (partial outage)?
2. Is a service considered “unavailable” if an alternative channel is not affected? (e.g. only the web browser is affected by the incident but not the mobile application).
3. Planned system outages should be clearly defined within the Guidelines as out of scope.
To illustrate how the definitions of Transactions Affected, Client Affected and Service Downtime can affect how an incident is handled, take a DDOS attack limiting the ability of all customers in one Member State to initiate transactions through web applications. This does not affect the initiation of transactions via mobile applications, nor those transactions that were in-motion or previously scheduled. Once the attack was mitigated, customers were able to log in on the web applications and initiate transactions.
Is this a total or partial outage?
Are all clients in that Member State considered to be affected, or only those that exclusively use the web applications / have not downloaded the mobile applications?
Are all transactions considered to be affected, or only those that would have been initiated through the web applications?
• High Level of Internal Escalation
1. Given that the level of internal escalation is subjective to each payment provider, this does not seem an appropriate criterion for triggering external reporting to regulators. Each payment provider’s internal escalation procedures are notably subject to different risk appetites. This has the potential of creating an inconsistent application of the Guidelines.
2. We would also welcome greater clarity on what the term “crisis mode” refers to in table 1. Each provider may have different definitions and thresholds in their internal procedures to determine a crisis mode; and depending on their risk appetite, not all incidents handled under this crisis mode would constitute a “major” incident as understood under these Guidelines.
• Reputational Impact: we would welcome more clarity on how to measure reputational impact, as this can be a highly subjective area. Given the volume and usage of social media, a significant proportion of incidents carry some degree of reputational impact: at which stage does this impact become reportable?
We do not consider the deadline of two hours for the initial report to be feasible. It often takes a few hours, and sometimes days or weeks, to determine the true impact of an incident. In addition, the proposed initial deadline and the subsequent pace of the intermediary reports place the emphasis on incident reporting, whereby focus should in fact be on incident handling, i.e. identifying and resolving the problem(s). This diverts essential resources away from resolving the incident. We would recommend aligning the initial deadline to the one found in other European legislation, such as the General Data Protection Regulation, where a time frame of 72 hours has been provided. This harmonisation would help companies comply with varying incident reporting obligations, as well as contribute to more accurate and comprehensive reporting.
In addition, we would welcome greater clarity on what is meant by the “incident discovery point”. Rather than basing the reporting timelines on the moment when the incident is identified, we recommend using the point when the incident is confirmed as “major”, once the forensic analysis / diagnostics are completed. This would lead to more accurate reporting, as well as contribute to mitigating over-escalations of minor incidents.
Regarding the final report, which should be sent within two weeks of “back to normal” status, we would recommend more flexibility. It may not always be possible to determine the root causes of the incident within two weeks – for instance if a detailed forensic analysis is needed, or if detailed diagnostics by a third-party are required. Instead, firms could provide the Competent Authorities an indication in the final interim report of when the final report would be available.
We question the added-value of the requirement for the third party to be established in the EU: global corporations have security incident response teams, which may include external vendors, across the world to enable quick and robust responses at any time of the day or night. In many cases, it is these teams that would perform the reporting requirements, as they have first-hand knowledge and experience of the incident and its life cycle.