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 this
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.
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.
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).
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.
Yes, this will likely contribute to simplifying the process.
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.