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).
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.
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).
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
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.
It is recommended that a knowledge pack is provided to include a briefing on Incident Reporting and some illustrative worked examples.
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.
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.
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?