Response to consultation on Guidelines on major incidents reporting under PSD2
Go back
For the sake of consistency we recommend that the Definitions in point 13 on page 21 of the consultation paper describing the term Major Operational or Security Incident is aligned to the Type of Incident described in the Instructions to fill out the Template.
There is considerable potential for confusion between Major and Lesser (not Non-Major) incidents. The two point scale has been reversed in that Level 2 incidents are higher than Level 1 incidents. This is counterintuitive to most incident management practices that refer to Priority 1 (P1) incidents as being the highest priority.
It may be helpful to readers to refer to good practice as it relates to Incident Management (IS0 27035) and Crisis Management (BS11200).
A more scaled impact assessment rating should be considered as it will provide a feedback loop enhancing lesson learnt and response, into organisation’s Enterprise Risk Management Processes.
Reporting parties may not comprehend the Thresholds criterion - Table 1: Thresholds page 25 - as some criteria and the impact levels are not defined. It is recommended that threshold definitions for all criteria are documented.
An expansion of incident levels to a wider scale e.g. 1 – 5 is recommended.
We suggest adherence to Incident Management good practice (especially ISO27035) and Crisis Management good practice (BS11200).
It is recommended that the criteria definitions, currently set to ‘Yes’, for the incident descriptions below is more explicit:
• High level of internal escalation
• Other payment service providers or relevant infrastructures potentially affected
• Reputational impact
It is recommended that consideration be given the form layout in order to highlight the main message, such as landscape format to make details easier to find, the top of the report to contain a synopsis of the incident, the centre of the report to contain key messages and the usage of radio buttons and bold font will further help to assist comprehension.
It is recommended that a knowledge pack is provided to include a briefing on Incident Reporting and some illustrative worked examples.
Initial reporting within two hours of detection may require ‘policing’ to ensure uniformity of responses. The risk of late reporting is that, the Competent Authorities will have no view of when the incident escalated and consequently vital information may be lost.
Moreover in order to prevent as much possible the occurrence of an incident which escalates and reaches the Payments Scheme Operator (PSO) without, or late, knowledge of the Competent National Authorities, we suggest requiring intermediate reporting as the incident moves between incident management stages/states i.e. diagnostic, repair, recovery, restoration and closure, instead of allowing the frequency of the reporting under consideration by the PSP’s.
Ideally these reporting requirements will be aligned with the GDPR incident reporting obligations and with the Competent National Authorities requirements in this area e.g. the Senior Managers Regime in the UK.
CGI considers that the proposals for delegated and consolidated reporting, by their separation, are more complex than necessary and omit key considerations. The present definitions seem indistinct from one another e.g. can a PSO be delegated by a PSP to report incidents? Would an outsourced IT Provider be regarded as delegated to or is it responsible for consolidated reporting or can it be both?
Question 1: Do you consider the definitions included in the draft Guidelines to be sufficiently clear?
We consider the definitions in the Guidelines are partially clear. From our experience as a provider of payments and cyber security services we recognise that security incidents are by default Major and that they have operational consequences. Conversely not all operational incidents are security related and they may still be Major for the PSPs.For the sake of consistency we recommend that the Definitions in point 13 on page 21 of the consultation paper describing the term Major Operational or Security Incident is aligned to the Type of Incident described in the Instructions to fill out the Template.
There is considerable potential for confusion between Major and Lesser (not Non-Major) incidents. The two point scale has been reversed in that Level 2 incidents are higher than Level 1 incidents. This is counterintuitive to most incident management practices that refer to Priority 1 (P1) incidents as being the highest priority.
It may be helpful to readers to refer to good practice as it relates to Incident Management (IS0 27035) and Crisis Management (BS11200).
Question 2: Do you consider the criteria and methodology applicable for the assessment and classification of an incident as major to be sufficiently clear? If not, what should be further clarified?
No. Further clarity is needed to effectively report the changing nature of an incident over time. Tracking an incident at level 1 or 2 does not support granularity of a wider scale e.g. 1 to 5. This will prevent the National Authorities to recognise when the severity of an incident is increasing as there is scarce information available.A more scaled impact assessment rating should be considered as it will provide a feedback loop enhancing lesson learnt and response, into organisation’s Enterprise Risk Management Processes.
Question 3: Do you consider that the methodology will capture all of / more than / less than those incidents that are currently considered major? Please explain your reasoning.
No. We consider it likely that a lower level of major incidents will be reported due to the incorrect identification of the impact level by the reporting parties.Reporting parties may not comprehend the Thresholds criterion - Table 1: Thresholds page 25 - as some criteria and the impact levels are not defined. It is recommended that threshold definitions for all criteria are documented.
An expansion of incident levels to a wider scale e.g. 1 – 5 is recommended.
We suggest adherence to Incident Management good practice (especially ISO27035) and Crisis Management good practice (BS11200).
Question 4: In particular, do you propose to add, amend and/or remove any of the thresholds referred to in Guideline 1.3? If so, please explain your reasoning.
Yes. We propose to add the definitions for all thresholds. If the two tier approach for the Thresholds in Table 1 is maintained it is recommended that the threshold definitions for both levels are documented for all criteria e.g. Service Downtime, Economic Impact, Other PSPs, and Reputational Impact for completeness.It is recommended that the criteria definitions, currently set to ‘Yes’, for the incident descriptions below is more explicit:
• High level of internal escalation
• Other payment service providers or relevant infrastructures potentially affected
• Reputational impact
Question 5: Do you think that the information depicted in the template in Annex 1 is sufficient to provide competent authorities in the home Member State with a suitable picture of the incident? If not, which changes would you introduce? Please explain your reasoning.
Yes the template provides sufficient information and background to understand the incident.It is recommended that consideration be given the form layout in order to highlight the main message, such as landscape format to make details easier to find, the top of the report to contain a synopsis of the incident, the centre of the report to contain key messages and the usage of radio buttons and bold font will further help to assist comprehension.
Question 6: Are the instructions provided along with the template sufficiently clear and helpful to remove any doubts that could arise when completing the required fields? If not, please explain your reasoning.
Yes.It is recommended that a knowledge pack is provided to include a briefing on Incident Reporting and some illustrative worked examples.
Question 7: As a general rule, do you consider the deadlines and circumstances that should trigger the submission of each type of report (i.e. initial, intermediate and final) feasible? If not, please provide a reasoning and justify any alternative proposal.
The requirements laid out are feasible and encourage more effective detection via monitoring solutions, but may not be sufficient overall.Initial reporting within two hours of detection may require ‘policing’ to ensure uniformity of responses. The risk of late reporting is that, the Competent Authorities will have no view of when the incident escalated and consequently vital information may be lost.
Moreover in order to prevent as much possible the occurrence of an incident which escalates and reaches the Payments Scheme Operator (PSO) without, or late, knowledge of the Competent National Authorities, we suggest requiring intermediate reporting as the incident moves between incident management stages/states i.e. diagnostic, repair, recovery, restoration and closure, instead of allowing the frequency of the reporting under consideration by the PSP’s.
Ideally these reporting requirements will be aligned with the GDPR incident reporting obligations and with the Competent National Authorities requirements in this area e.g. the Senior Managers Regime in the UK.
Question 8: Do you consider I that the delegated reporting procedure proposed in the draft Guidelines will provide added value to the market? Please explain your reasoning.
Yes and more added value can be created. The delegated procedure will help clarify content to be included in the contracts between the PSPs and the service providers. We believe the market can benefit from having more clarity on what the procedure should be when the delegated entity is located in a different country, within and outside the European Union.Question 9: Do you consider that the consolidated reporting procedure proposed in the draft Guidelines will provide added value to the market? Please explain your reasoning.
Probably, but more added value can be created.CGI considers that the proposals for delegated and consolidated reporting, by their separation, are more complex than necessary and omit key considerations. The present definitions seem indistinct from one another e.g. can a PSO be delegated by a PSP to report incidents? Would an outsourced IT Provider be regarded as delegated to or is it responsible for consolidated reporting or can it be both?