The definitions do not include enough specifics, more detailed explanations would be necessary for accurate interpretations.
We recommend that an incident list should be published in the RTS and also available in a dropdown menu on the template. It also needs to be clarified what constitutes a separate incident (that needs to be reported as one incident) as an example: same root cause, same attack vector in a given timeframe. When determining the criteria it should also be considered that in case of subsidiaries due to their size limitations the outlined criteria and methodology cannot be interpreted correctly.
We consider incident related information sharing as a useful tool, however:
- It is necessary to define in advance what kind of information will be part of the real-time information sharing scheme,
- In general, screening/assessment of the information to be shared beforehand is a must. Without the approval of the reporting ASPSP, the information should not be distributed, except perhaps in case of events of international significance.
As a significant part of the Level 1 criteria is not clearly defined, incident handling will be vastly dependent on custom interpretation. Therefore we suggest developing more objective thresholds, metrics and clarifying the conditions that will have to be applied.
We believe that in addition to objective criteria a subjective, discretionary option should also be guaranteed for the PSPs. During the evaluation of the event, the PSPs should be able to decide whether the event is an incident even if based on the thresholds outlined in the RTS it shall be reported as a major incident. Therefore it should be taken into consideration whether the PSP itself classifies the given incident as a major incident or does not, regardless the conditions applicable from the RTS.
As an example: based on “transactions affected” – according to the current practice – special, individual cases occur where the amount could reach the LEVEL 2 threshold but due to the special parameters of the transaction, the event will not be considered as an incident.
Due to the subjective nature of the criteria mentioned below, in practice every incident may be considered as major, for that reason we recommend treating these as one criterion all together or taking them into account on a less significant level:
- High level of internal escalation: it should not be considered as an adequate indicator of the severity of the incident as it is entirely based on an internal process. The Chief Information Officer (or equivalent position) will be notified according to the internal processes of the PSPs, therefore the implementation of this criterion could differ significantly. We recommend the removal or further clarification of the criterion.
- Reputational risk: it is also not an objectively measurable criterion, any incident that gets press attention, causes some kind of failure, et cetera, will inherently carry reputational risk. In our view, this point needs further clarification.
- Potential to affect other payment service providers or relevant infrastructures: from our perspective, potential effect on other PSPs may not be straightforward; also initially it cannot be identified, assessed. The “potential to affect” phrase should be further explained; also level of effect which should be positively considered is not clearly defined.
We recommend taking into account whether the negative impact of the incident can be eliminated in the short run (such as the customer changing the leaked password) or will have a lingering effect (such as the home addresses of the customers were leaked).
We recommend employing a Web-based interface to enable PSPs to fulfil the outlined reporting obligation; also the reporting PSPs need to be properly identified before submitting documentation. It is not necessary to further expand the template, if the PSPs will have an easy option to upload additional documents, information during the reporting process. There is a need for a scorecard system which could be utilised as a starting point for estimates if quantitative data will have to be produced. Also having practical examples for this purpose might prove to be useful.
In case of a data breach, based on the regulation of the GDPR the incident will also have to be reported, so it would be advisable to bring the different reporting obligations in line in order to avoid duplications.
The instructions provided are almost sufficiently clear. Please provide more details what the expected content of the following field: 8-Additional information Was a civil complaint filled against the PSP? If so, please provide details.
In regards to the reporting time limit, in practice, taking into account the fact that analysis of the mentioned criteria belongs to different organisational units therefor the accumulation of the data meanwhile adhering to the official, organisational channels is time-consuming, it might prove to be impossible to keep the 2-hour time-limit. We recommend “as soon as possible but within 4-6 hours” as the deadline for the initial report.
Yes, we welcome the opportunity presented by the delegated reporting procedure.
In general, we welcome the idea of the consolidated reporting, but based on the draft regulation, it can only be employed within the same Member State. We recommend modification as to be able to use consolidated reporting even if the institutions were not established in the same Member State but belong together based on ownership rights, such as mother bank – subsidiary established in another Member State.
László Király, Director, Information Security Department