Response to consultation paper on the draft revised Guidelines on major incident reporting under PSD2
Go back
The 'reputational impact' (GL 1.3, viii) is mentioned as one of the factors that in combination with others ('high internal escalation level') acts as trigger for esca-lation of the incident as major. Although, the update to the definition helps, there should be a more tangible value association so as to when reputational impact plays a role in ruling an incident as major. A binary value continues to be too subjective.
The existing threshold criteria detailed in Guidelines 1.2, 1.3 and 1.4 relate to the assessment of the impact or result of an incident, whereas the new criterion 'Breach of security measures' is more closely related to the cause of the incident.
The effect of this is that incidents involving the violation of one or more security measures will require fewer of the other impact related thresholds to be classi-fied as a major incident (considering three or more criteria at the 'lower impact level' classifies a major incident). Is this the desired outcome? Are incidents involving the violation of security measures considered to be inherently more im-pactful as a result of the violation of security measures? It is not necessarily clear if this change would capture the security incidents that appear not to be captured by the current criteria and thresholds.
In paragraph 10 of the consultations paper the EBA states, that the majority of submitted incidents are categorized as operational, while very few are categorized as security incidents. If some relevant security incidents are not captured, it raises the question if this would be better addressed in an update to the incident cause taxonomy rather than through the threshold criteria for relating to the impact levels.
There is a need for clear definitions for breaches of security measures. As an example, should it be understood as this breach of security measures is caused by one of the eight subcategories (‘Malicious code’ etc.) of the broader ‘Malicious actions’ category?
In addition, the intermediate template calls out overall impact. Overall impact cites 'availability, integrity, confidentiality, authenticity' - the link between the 'breach of security measures' and the overall impact criteria should be more clearly coming through as a means to aid the identification process.
However, local regulators have currently introduced the templates with tweaks and minor discrepancies. These discrepancies have major effect on the ability to introduce a standardized escalating and reporting process cross border. In proposing the changes, it should be ensured that the local regulators avoid tweaks and changes to the extent possible, so that uniformity can be applied cross bor-ders.
In addition, there is more overlap observed between PSD2 and NIS reporting especially in relation to security incidents. We therefor welcome, that the EBA takes note of the proposal for an EU regulatory framework on digital operational resilience (DORA).
There are a number of considerations regarding the template and the definitions that support the template:
The intermediate report references 'describe how the security policy was violat-ed' - this definition is not apparent under the 'breach of security measures' definition in the guidelines. If this is the intention, this piece should be referenced in the definition.
The economic impact cites 'potentially missed business opportunities, potential legal fines'. This is not in line with the reporting requirements of operational risk events, where financial impact should be considered in actual terms and should not include opportunity costs (except near miss events).
The reputational impact cites '...incident could affect the reputation of the PSP (e.g. media coverage, potential legal or regulatory infringement...)...' Mixing rep-utational and regulatory impact of an event could prove to be difficult in the internal classification of incidents, as well as in the reporting process and record keeping.
The overall impact cites 'availability, integrity, confidentiality, authenticity' - the link between the 'breach of security measures' and the overall impact criteria should be more clearly coming through.
Lessons learnt references seem to have been removed from the Final Report. There are benefits to keep lesson learnt as an optional information within the template.
Q1. Do you agree with the change proposed in Guideline 1.4 to the absolute amount threshold of the criteria ‘Transactions affected’ in the higher impact level?
We generally welcome the increased threshold. Since these are figures that are required to be reported on to the regulator, it makes sense to reduce the volume of output as well as the required review major incidents. We do however think that the threshold is still quite low and should as a minimum be increased to 25 million EUR. What the bank wishes to record for itself internally should not neces-sarily be affected by thisQ2. Do you agree with the changes proposed in Guideline 1.4 to the assessment of the criteria ‘Transactions affected’ and ‘Payment service users affected’ in the lower impact level, including the introduction of the condition that the operational incidents must have a duration longer than one hour?
Yes, we agree. Since these are figures that are required to be reported on to the regulator, it makes sense to reduce the volume of output as well as the required review major incidents.The 'reputational impact' (GL 1.3, viii) is mentioned as one of the factors that in combination with others ('high internal escalation level') acts as trigger for esca-lation of the incident as major. Although, the update to the definition helps, there should be a more tangible value association so as to when reputational impact plays a role in ruling an incident as major. A binary value continues to be too subjective.
Q3. Do you agree with the inclusion of the new criterion ‘Breach of security measures’ in Guidelines 1.2, 1.3 and 1.4?
While Finance Denmark generally understands and supports the EBA’s wish to capture additional relevant security incidents with the proposed criteria, we think that some clarification is needed.The existing threshold criteria detailed in Guidelines 1.2, 1.3 and 1.4 relate to the assessment of the impact or result of an incident, whereas the new criterion 'Breach of security measures' is more closely related to the cause of the incident.
The effect of this is that incidents involving the violation of one or more security measures will require fewer of the other impact related thresholds to be classi-fied as a major incident (considering three or more criteria at the 'lower impact level' classifies a major incident). Is this the desired outcome? Are incidents involving the violation of security measures considered to be inherently more im-pactful as a result of the violation of security measures? It is not necessarily clear if this change would capture the security incidents that appear not to be captured by the current criteria and thresholds.
In paragraph 10 of the consultations paper the EBA states, that the majority of submitted incidents are categorized as operational, while very few are categorized as security incidents. If some relevant security incidents are not captured, it raises the question if this would be better addressed in an update to the incident cause taxonomy rather than through the threshold criteria for relating to the impact levels.
There is a need for clear definitions for breaches of security measures. As an example, should it be understood as this breach of security measures is caused by one of the eight subcategories (‘Malicious code’ etc.) of the broader ‘Malicious actions’ category?
In addition, the intermediate template calls out overall impact. Overall impact cites 'availability, integrity, confidentiality, authenticity' - the link between the 'breach of security measures' and the overall impact criteria should be more clearly coming through as a means to aid the identification process.
Q4. Do you agree with the proposed changes to the Guidelines aimed at addressing the deficiencies in the reporting process?
Yes, we agree with the proposed changes for the reporting process.However, local regulators have currently introduced the templates with tweaks and minor discrepancies. These discrepancies have major effect on the ability to introduce a standardized escalating and reporting process cross border. In proposing the changes, it should be ensured that the local regulators avoid tweaks and changes to the extent possible, so that uniformity can be applied cross bor-ders.
In addition, there is more overlap observed between PSD2 and NIS reporting especially in relation to security incidents. We therefor welcome, that the EBA takes note of the proposal for an EU regulatory framework on digital operational resilience (DORA).
Q5. Do you support the introduction of a standardised file for submission of incident reports from payment service providers to national competent authorities? If so, what type of structured file format would you support (e.g. “MS Excel”, “xbrl”, “xml”) and why?
We support the introduction of a standardized file for submission of reports. We would support the use of the Excel format. But in the longer run a less manual way of reporting should be identified. This need for more uniform means and tools to report will only increase with DORA-proposal, where the draft version seems to reference the same timeline and incident reporting approach.Q6. Do you agree with the proposed changes to Guidelines 2.4, 2.7, 2.12, 2.14, and 2.18 that are aimed at simplifying the process of reporting major incidents under PSD2?
Yes, this will likely contribute to simplifying the process.Q7. Do you agree with the proposed changes to the templates in the Annex to the Guidelines?
We generally support the wish to simplify the notification process and improve the meaningfulness of the reports received. We would however welcome some clarifications.There are a number of considerations regarding the template and the definitions that support the template:
The intermediate report references 'describe how the security policy was violat-ed' - this definition is not apparent under the 'breach of security measures' definition in the guidelines. If this is the intention, this piece should be referenced in the definition.
The economic impact cites 'potentially missed business opportunities, potential legal fines'. This is not in line with the reporting requirements of operational risk events, where financial impact should be considered in actual terms and should not include opportunity costs (except near miss events).
The reputational impact cites '...incident could affect the reputation of the PSP (e.g. media coverage, potential legal or regulatory infringement...)...' Mixing rep-utational and regulatory impact of an event could prove to be difficult in the internal classification of incidents, as well as in the reporting process and record keeping.
The overall impact cites 'availability, integrity, confidentiality, authenticity' - the link between the 'breach of security measures' and the overall impact criteria should be more clearly coming through.
Lessons learnt references seem to have been removed from the Final Report. There are benefits to keep lesson learnt as an optional information within the template.