We see issues regarding the definition on “major operational or security incident”. There are no indications in the definition as to what kind of impact constitutes a major incident. We would recommend that definitions from international organizations are adopted. We would also recommend, that the reference to events that “may have” a material adverse impact should be deleted, since the wording and understanding is ambiguous and in any case may result in an inappropriate amount of “may have” incident reporting’s, where it is at the present not clear, how they will be processed either if they turn into a real incident or do not turn into an incident at all.
We in general consider the criteria and methodology described to be clear but some of them we predict will be hard to manage from a practical viewpoint. A couple of examples (see also question 4):
• We find it unclear how you calculate affected number of customers. Assume more than 25% of the banks customers use net bank. When the net bank is down, does this then automatically trigger reporting in accordance with criteria level 2, since it is unlikely that 25 % of the bank customers are actually effected (that would mean, that all customers are using the net bank at all times).
• We are also unsure which format is expected (if any) for the 2 hours deadline for the initial reporting / notification. If it is the intention, that the reporting template in Annex 1 should be used for the initial reporting, we have reservations regarding its applicability in practice (see also question 7).
• We would also suggest that the same incident will only need to be reported to one national authority, since many of our members are present in more than one member state.
We think that the methodology as described now will include a great number of incidents that are presently not reported to the national authorities, and it is our opinion that the majority of the said incidents would not qualify in international definitions as being a “major incident”. We have completed a small survey within the Danish Community, where we asked them to estimate, how many incidents in 2016 would have qualified as a major incident and needed to be reported if the new guidelines had been effective in 2016. One reported an increase of 400 %. Another reported that 90 incidents in 2016 would have to be reported, while only very few of these have been accessed in the internal risk management procedures as major incidents and handled as such. We had indications from others that these estimates are valid. We fear that this high level of reporting will add risk instead of mitigate risk, since substantially more resources will have to be used on reporting instead of solving the problems. At the same time, the amount of reports will make it difficult for the authorities to single out the “real” major incidents, where authorities need to take an active part in resolving the incident or notify other national authorities.
We would suggest the thresholds for level 1 are changed, since it is our belief, that the fulfillment of either three or more of the criteria’s in their present form will not constitute a major incident. Instead we suggest:
• The thresholds expressed in percentage seem adequate. The thresholds in totals might lead to an over reporting of incidents by the larger institutions as most of the minor incident could reach the thresholds in totals despite affecting a small number of transactions or clients in relative terms.
• “Service downtime” level 1 is changed to “>4 hours or >2 hours within normal business hours” and normal business hours are de-fined by each national community in dialogue with the national authorities.
• “Reputational impact” and “High level of escalation” thresholds are merged; since they are usually coincident (escalations-levels will typically follow the reputational impact scale in the internal risk assessment).
• The definition of “High level of escalation” is changed from “reported to the Chief Information Officer (or similar)” to “Board of Directors (or similar)”, since the practice for reporting to the CIO will be very different at different institutions, while “major” incidents as best practice will be reported to Board of Directors or similar level.
Another approach could be to let the level 1 criteria be used as criteria for “minor incidents” and instead reassess the level 2 criteria as criteria for “major incidents”. In that case we would suggest, that only level 2 incidents needed to be reported within a certain time limit while there for limit 1 incidents only need to be sent in a final report for data collecting purposes. In this way the term “major incident” will be reserved to incident with a serious impact on the individual PSP or with wider impact on the sector as a whole, and it would bring the whole set-up closer to best practice.
Yes in regard the final report if additional information can be provided as an annex. The guidelines now state: ”Initial reports are not expected to provide very detailed information or accurate figures, but rather a high level overview of what has happened and the impact it has had or may have.” It is not clear, if it is the intention, that the template in Annex1 is expected to be used for the initial reporting. It is our estimation that it will only be possible to fill out few fields in Annex 1 within the 2 hour time limit, ex:
1- General details: all information
2 – Incident discovery: all information
3 – Incident classification: few or no information
4 – Incident description: few or no information
5 – Incident impact: few information’s
6 – Incident mitigation: few or no information
7 - Root cause analysis and follow up: no information
8 – Additional information: no information
With the present thresholds we furthermore fear that an inexpedient amount of information needs to be collected on incidents, that we would today categorize as “minor”.
Yes, but we recommend other ways of communication to clarify any doubts that may appear during the completion, ex. via email or phone. In the final version we would suggest a format, which in a better and more intuitive way will assist the quick submitting of information.
Two hours for reporting is extremely short in some cases. Intermediate reporting will have to take these facts into consideration. It can often take days to obtain all the necessary details. This could mean that the first notification will not be based on the criteria but on other indicators such as experience from earlier incidents, and it seems not clear, how this will work in practice. We also fear that this will lead to over-reporting and reporting on a very uneven level from the different communities. We would therefore suggest a differentiation between “major” incidents, that needs to be reported time limit and “minor incidents” where only final reporting is necessary (se also question 4). Also detailed or final reports will not always be possible under the currently proposed thresholds. In the case of major incidents it in some cases requires more than two weeks to establish the root cause.
Yes for smaller PSP’s who use IT-group service center, since in these cases the IT-group service center will have the detailed information on the incident that is needed for the reporting.
Yes, consolidated reporting is essential to make it possible for PSP’s to use an IT-group service center or one common technical service provider offering them the same services / processes / infrastructures in a practical way. In the case where many PSP’s use the same IT-group service, typically for out-of-the-box solutions, and this solution is based on the same it-platform, the incident will typically take place in the it-platform, but the impact will effect more than one PSP. In these cases the PSP for practical reasons will in many cases make use of the consolidated reporting procedure, since they do not themselves have the operational information to fill out the relevant reporting. The practical issue in these cases will be how to quickly assess the impact on each PSP against the thresholds that defines a major incident. This will in some Danish cases have to be done for 30 – 35 PSP’s within 2 hours. We would therefore suggest, that the competent national authority in their implementation of the guidelines will be allowed to make arrangements with the PSP-community and its main IT-group service centers on how to handle the impact evaluation for a specific it-service that take into account these practical issues, as long as the implementation do not affect the thresholds put forward in the final guidelines and the responsibilities of the said parties as described in Guideline 3.