Association of German Banks (Bundesverband deutscher Banken)
We agree with the proposed increase to the absolute amount threshold.
We would, however, like to point out that focussing on relative thresholds makes more sense and is more meaningful (in line with the internal classification of incidents).
We welcome the introduction of the condition “downtime >1 hour” for both criteria.
We believe this also makes sense for the higher impact level.
In addition, the condition “downtime >1 hour” should also be considered for security incidents (except external attacks).
We also suggest adapting the condition “downtime >1 hour” to the criteria “service downtime >2 hours”, thereby providing for a uniform duration of >2 hours.
This would enable identification processes to be standardised and simplified.
In contrast, the condition “or” instead of “and” does not reduce the burden.
We see this more as a tightening of the conditions and as such we believe “and” should remain as before.
Otherwise, we would be in favour of removing the absolute thresholds.
In principle, we are in favour of using/introducing clearly quantifiable values/criteria.
However, the criterion “Breach of security measures” does not meet this requirement since, for us, it is not clear.
This new criterion is also redundant because any breaches of security measures that require reporting are covered by the existing criterion “High level of internal escalation”.
This criterion should therefore not be introduced.
Alternatively, this new criterion needs to be defined more specifically.
We welcome the proposed changes to the guidelines.
We believe they are a sensible way of addressing deficiencies and simplifying the reporting process.
The requirements of the revised guidelines should be taken into account in the DORA proposal, for example, with regard to alignment of criteria, templates and reporting processes.
In addition, given current developments, the application date for the revised guidelines should be postponed until 1 January 2022.
We are in favour of submitting incident reports in a structured file format, such as “xml”. This simplifies integration into internal bank reporting processes and would continue to make it possible to export them into other formats thanks to widely used IT modules.
At the same time, other common formats such as MS Excel or PDF should also be supported.
In addition, existing reporting channels must continue to be supported as they are already being used effectively by both parties (BaFin’s MVP portal).
2.4: No comments
2.7: We are in favour of specifying “from the moment of classification as a major incident” instead of “detection of the incident”.
2.12: No comments (in our opinion, this is not a simplification).
2.14: No comments.
2.18: We welcome the deadline extension.
We don’t think it will always be possible to fill in all the proposed fields in the template for all types of incidents.
It should be possible either to leave a field empty or mark it as “not available”.
Also, the sub-categories for causes of incidents are too granular and it is sometimes difficult to differentiate between them.
With a view to additional future reporting requirements, e.g. from the DORA Regulation, we would welcome more consistent harmonisation of reporting requirements in general.