We support the proposed increase of the absolute threshold. Focus on relative thresholds appears to be more sensible and meaningful (analogous to the internal classification of incidents).
The condition "or" instead of "and" in the lower impact level leads to a significant tightening of the reporting situation. A purely percentage-based approach without an absolute lower impact level leads to an increase in the number of reports with low relevance and thus to disproportionate additional work for payment service providers and their IT service providers. Even short-term production restrictions during off-peak hours will become subject to reporting - depending on the number of customers affected. We therefore strongly advise against the proposed change in the criteria for affected customers and affected transactions. Otherwise, we would suggest the deletion of the absolute thresholds.
The inclusion of the criterion "duration of the incident >1h" does not contribute to the relief either. From the point of view of the customers it is not the operational incident time that is important but the “service downtime”. The separation between “duration of the incident” and “service downtime” is therefore not defined or equal in many institutions. We therefore suggest deleting the criterion of "operational downtime" or at least replacing it with "service downtime" and providing for a uniform duration of > 2 hours.
- We support the use/introduction of clearly quantifiable values/criteria. However, the criterion "breach of security measures" does not meet this requirement, as it is not clear for us.
With regard to the impact on "availability", it leads to a redundancy with the criteria "affected transactions" and "affected customers". As a result, the violation of both criteria at the lower thresholds leads to reports whose content does not represent a material incident.
Another redundancy results from the criterion "High level of internal escalation", as the violation of security measures is regularly accompanied by a high internal escalation level.
The target of receiving fewer operational reports is missed with this change. We expect an opposite effect. In addition, the relevant reports get lost in this point. Therefore the criterion should not be applied.
In view of the current draft regulation on cyber resilience (DORA) and the expected transfer of major incident reporting into DORA regulations, the question arises of the goal of revising the Guideline on Incident Reporting at this point of time. At least, it must be ensured that the rules defined in DORA and in the revised guidelines are coordinated with each other or that the requirements defined in the Guidelines are included in DORA.
Note: The reporting credit institutions should receive feedback if a report is incorrect.
Existing national solutions for reporting must be maintained. Otherwise, there will be a high, short-term adaptation effort, which is to be expected again with DORA.
In principle, a standardised format makes sense in order to enable machine processing. Here, service provider independent (XML) formats and formats of standard applications (here: MS-Excel) are to be preferred.
These formats have proven themselves in practice. They allow the necessary flexibility across all reporting institutions.
2.4: No comments.
2.7: We support the specification "after classification as major incident" instead of "after detection".
2.12: In our opinion, this regulation is not a simplification: In our view, an interim report should be provided when:
- the service has been restored (incident resolved, problem still exists)
- a downgrade from higher impact level to lower impact level or an escalation from lower level to higher level took place or
- the supervisor explicitly requests an interim report.
2.14: No comments.
2.18: We welcome the time relief.
Existing templates must be retained, as otherwise there will be an adaptation effort that is to be expected again with DORA (see answer 5).
Many mandatory fields are defined in the new template, but it is not always possible to fill in all the newly proposed items (especially for the initial or interim report). Fields must also be able to be filled in as N/A or left blank.