Response to consultation on Guidelines on major incidents reporting under PSD2
Go back
We generally think the definitions included are clear and welcome the general clarity in the draft Guidelines. However, there are certain areas which we would appreciate clarification or have suggestions. Specifically, we would like to make some comments on the following points:
• Availability – The term “upon demand by authorised clients” implies that all payment-related services are automatically available all of the time (24 x 7 x 365). We do not think that this necessarily applies in all situations. The ability to access and use some payment-related services may be subject to certain restrictions e.g. processing cut-off times, use of particular delivery channels, branch opening times, bank holidays, and scheduled system/service maintenance.
• Definition of incident: There appears to be a mismatch in the definition of incident. In the Guidelines (page 21, paragraph 13) it specifies “Payment Related services” but in the Rationale (page 7, paragraph 13) it states incidents affecting transactions, processes, data or funds". We would welcome clarification from the EBA as to whether any incident impacting a non-payment service would need to be reported. Our assumption is that non-payment related incidents are deemed out of scope of PSD2 reporting to competent authorities. Planned system outages should be clearly defined within the Guidelines as out of scope. Additionally, we would welcome clarity on whether an impact to customer payments in the event of an external incident (i.e. security, national disaster), would be classed as a ‘reportable’ incident.
• Incident classification: In terms of reporting major incidents that could impact payment services provided to Payment Initiation Service Providers (PISPs), Account Information Service Providers (AISPs) or Card-Based Payment Instrument Issuers by firms and in absence of any contractual obligations (as stated under the Directive), we suggest that the incident classification section within the template (Annex 1) could somehow reference this, if needed.
• Scope of incident and wider reporting: We would welcome clarity on whether there is any cross-over with the scope and reporting timelines of many other regulatory/legislative reporting requirements, such as the GDPR requirements (as a limited example). Firms are often required to report to a large number of regulators and competent authorities. We would therefore welcome more specificity on the scope of reporting (i.e. simply payment services) and also which competent authorities should be notified (i.e. just those with authority for PSD2 or competent authorities more widely). Furthermore, more clarity would be welcomed on who to notify in the event an incident affects more than one Member State, would this be the home or host competent authority, or both?
• Definition of authenticity: We are unclear what authenticity specifically refers to in the context of the incident management process. Further clarification would be welcome e.g. does this refer to verification and confidence in data received from third parties during the course of an incident, or does it refer to something else?
• Definition of reputation: We would welcome further clarity on reputational impact, which could be more clearly defined.
• Clarity: If at all applicable it would be useful for the EBA (or the national competent authority) to confirm if these Guidelines supersede any other reporting requirements."
We think the criteria are generally clear in the draft Guidelines; however we have some general and specific commentary as follows:
As a general comment, it is implied in the Guidelines that an incident is ranked as major when a certain number of the thresholds are reached or exceeded. It is not clear from the definitions as to whether the thresholds must actually be exceeded before the incident is classified as a major incident, or whether incidents should be classified as major if there is a potential that thresholds may be exceeded. For example, a payments system incident has the potential impact that a significant volume of same day payments may not be processed if the incident is not resolved before payment cut off times, however the impact may not materialise if the system is recovered ahead of payment cut-off times.
We would also like to make some comments on the following specific points:
• Clients affected: The guidance in this area would benefit from different wording to ensure greater clarity for PSPs. Depending on the individual interpretation of the guidance this could result in very different numbers which could make comparison across different organisations/incidents meaningless. We would welcome the EBA’s clarification on clients affected. We assume that those within scope would be all clients within the scope of PSD2 under ‘payment service user’, with other financial institutions out of scope.
• Service downtime: The threshold for service downtime is less than two hours. At what point is the service downtime deemed to have started? Is this at the point that an initial alert is received or at the point when investigation has determined that there is a system issue? More clarity on this point would be welcomed.
Do the same criteria apply for a partial outage to a payments system - for example if the system is operational but with reduced functionality? We would welcome further clarification around service downtime and what constitutes “service not available”. In particular, where there are multiple channels and services. Would a service be considered not available where there are alternative services that can be used to process a payment? This would be considered sensibly with customer segments in mind (e.g. a service for a retail customer would likely not be considered as an alternative for a service provided to a corporate customer), but we would like to clarify more specifically when a service is not available.
• High level of internal escalation: We feel that using, high level of incident escalation" is not an appropriate indicator for triggering external reporting for regulators. The guidance provided may not provide consistent returns from different PSPs. There are certain challenges to using this as an indicator or priority, as it is an outcome following assessment of a PSP internally to ensure that the right stakeholders are made aware as necessary and in the appropriate timescales. We also feel that internal escalation is subject to different risk appetites within individual PSPs. We would therefore encourage an alternative indicator or at least more clarity could be included to make the classifications less open to interpretation, for example the seniority of the CIO may vary per firm therefore should be clearer on the level of visibility of escalation expected to be reached within the organisation? As under question 4, we recommend that the criteria is changed to 'exceptional level of incident escalation’.
• Transactions/Clients impacted: Further clarity may be required by firms as to whether this is 10% or 25% of:
o The total client base;
o Total number of payment transactions;
o The client base using the specific payment service that is impacted, or;
o The transactions processed by the impacted payment service;
• Thresholds: It would generally be assumed by firms that level 1 incidents are the highest priority incidents and therefore it would be helpful if the level 1/level 2 indicators are swapped. We would recommend that higher thresholds be used for a near miss of the threshold (where there is a potential for thresholds to be breached) if these are indeed required to be reported.
• Incident Notification: It would be helpful for the guidance to stipulate that notification should take place when an incident deemed to be ‘major’ is first detected. It would also be helpful to clarify that if incidents are reclassified, do the same criteria apply (e.g. impact figures and timing)."
All of our members agree that the thresholds as currently set would result in significantly more incidents being considered ‘major’. This would be especially true for large PSPs. Some of the thresholds for reporting could be triggered by just one large-value payment failing to be processed.
In our view this may undermine the meaning of ‘major’. We feel the low thresholds as currently drafted would devalue the reporting procedure and would have consequences for adequate treatment of those major incidents which require proper attention from the authorities. We also have questions as to whether competent authorities are geared up to deal with a possibly significant increase in notifications of major incidents.
As a further point, firms would typically rate impact based on actual or potential financial impact, not on transaction value. For example, if a EUR 1 billion payment is late, then the financial impact of the incident would be related to a more limited scope (for example, the interest, fees or compensation associated with the late payment), not the actual value of the payment. It would be helpful for values to be completed for both levels of each threshold.
We encourage the EBA to give more consideration and to bolster the Guidelines around reputational impacts. A significant proportion of incidents carry some degree of potential reputational impact, especially with the volume/usage of social media. We recommend that additional Guidelines are included as to when reputational impact would become reportable.
We propose the following amendments to the thresholds referred to in Guideline 1.3:
• Value: The value threshold for transactions to trigger a level 2 major incident seems very low. One large-value trade or corporate payment can easily be in excess of this amount and this could lead to an increased number of incidents being reported if a single payment incident can trigger the major incident classification. We also noticed a difference on the definition of the thresholds as level 1 are defined with ‘and’, with level 2 defined as ‘or’, is this intentional by the EBA?
• Internal Escalations: Firms will provide internal escalations in line with their internal guidelines, which will differ between firms and may also lead to an increased volume of incidents being reported if a senior escalation triggers the major incident criteria. We recommend that the criteria are changed to 'exceptional level of incident escalation’.
• Crisis mode: We would like to see greater clarity regarding the term crisis mode" as referred to in the "High level of internal escalation". Providers may utilise a "crisis mode" structure with various tiers of severity, relatively minor incidents may be handled via such a process but would not constitute a major incident.
• Service downtime: The two hour threshold is a short period of time for an outage and we feel this should be longer with the time of day also taken into consideration. There should also be recognition that different services/systems present different levels of impact if taken out of service. For example, a four hour outage of a system that processes direct debits has a lower impact on customers than a four hour outage to debit card or instant payment systems."
We feel the requested information is generally sufficient; however we have additional comments below:
First notification: In the event of a major incident, primary focus in an organisation will be given to fixing the incident. Whilst the notification is of upmost importance, we feel more consideration should be given to the timeline. Two hours for first notification could result in inaccurate reporting.
We also feel that having a two hour notification can also have major impacts on the competent authority’s resources as they would likely need to build a 24 hour capability.
We recognise that a short timescale will be valuable in the context of a competent authority sharing early notification with PSPs to help prevent wider incidents. Should the competent authority not be geared up to achieve this, the benefits of a short notification window are mitigated and reduced.
In the past we have seen other bodies implement a similar outage notification requirement and with it, there was a need to implement a 24 hour and 7 day a week hotline to receive the notifications.
If it is not possible for a lengthened timeline, shorter details should be given as a first notification in the two hour time window, with further detail to follow on in the next stage of communication. The EBA could achieve this by using only the “1 – General Details” section of the major incident report under Annex 1. Firms would remain free to provide further detail in the first notification should they wish.
Furthermore, the EBA should ask whether the incident is historic/has been reclassified. The EBA should also include provision to withdraw a notification should it be discovered that an incident is in fact not major.
Incident Impact: There should be a measure of staff impact as this may affect the ability to maintain services, for example, security incidents such as a terrorist attack where staff are unable to travel or are directly at risk.
Incident Classification: For 'reputational' - this appears to be very subjective and response will be dependent on author and organisation. Explicit questions should be included. As an example some firms may state that the incident could impact the PSP's share price.
Incident discovery: The EBA should ask ‘how was the incident discovered’ to understand whether learnings could be made from the incident and also to understand if there may be an incident affecting more than one firm.
Cause of Incident: The list under ‘attack type’ does not seem to be a complete list. For example, malware attack is missing (e.g. external system infected as in most attacks against online banking systems).
System failure: This section should be split into separate categories, for example, software or hardware failure, to allow for a greater level of understanding across PSPs.
Suggested additional Information: Further consideration should be given to the wider security incident and firm’s activities, for example, in the context of payment service impact such as a DDOS attack, this may have been reported to law enforcement/other agencies and this may be useful for a competent authority to understand in the event of a large-scale attack impacting more than one provider and for working collaboratively in the event with other government authorities.
Further guidance in terms of reporting economic impact would be welcomed. The economic impact is typically dependent upon and determined on the nature of an incident. Dependent upon the incident, firms will not necessarily notify on direct or indirect costs to competent authorities. However, the overall economic impact of a major incident would be dependent on the nature of those costs. For example, firms would advise the financial impacts to its customers and any direct/indirect costs associated with the remediation and redress activity, including a total value and average amount of redress paid. We would welcome further clarity from the EBA on this.
It would be useful for the EBA to include a currency drop down box in the form for non-euro currencies. The reportable currency within the template should also allow for the host currency of the Member State i.e. UK = GBP Ireland = EUR to be reported.
Overall, we welcome the instructions level of clarity but have the following specific suggestions:
Some of the very specific requests e.g. start of incident" may be difficult for firms to confirm. The EBA should accept reasonable estimated times, based on investigation and internal/external intelligence, where exact start time of an incident cannot be confirmed.
“High level of internal escalation” would probably be more appropriately worded as “exceptional level of escalation” as incidents going through established governance could be misinterpreted as receiving a high level of internal escalation.
Annotation on whether amounts are estimates or final figures could also be included.
We would also welcome further clarity on what is meant under authenticity."
Two hour window: We feel that the timescales are unrealistic and inconvenient especially in the context of a major security incident. Focus in an incident is generally given to identifying and resolving the problem/s and having a short deadline for notification will divert critical resource away from resolving incidents. Furthermore, if the incident were to happen out of business hours, often staff have to be mobilised which can take time. During the first two hours of an incident it is often incredibly unclear as to how widespread the issue is, to avoid further compromises firms often seek to limit communications to those areas directly impacted and those required in recovery activities.
Furthermore, we feel that early estimates in regards to the scale of incidents offer little to no value and only seek to spread panic. This can also have a huge reputational impact on companies affected. As an example, the recent TalkTalk data breach in the UK, initial estimates raised suggested it could be hundreds of thousands of payment details breached. In the end this was dramatically revised down and was revealed as just over 15,000 customers. Whilst still a significant number, the scale estimated was substantially wrong. We would therefore encourage the EBA to significantly revise the initial notice period as it is currently unworkable for many institutions.
Where the incident has been identified and resolved within the two hour window would the EBA expect this incident to still be reported? If so, would this be reported by the submission of a final report? In our view, this seems the most sensible approach as it provides the competent authority with the comfort that the incident has already been fixed and gives the fullest picture. In this case however, we would ask the EBA for a little more flexibility in the reporting deadline for firms to be able to pull that final report together.
Incident discovery point: In terms of further clarity, we recommend that more detail is included within the Guidelines to fully explain what is meant by 'the incident discovery point' in direct relation to the incident cycle; consideration here would result in different timescales, for example:
(a) From the moment the incident was first detected, for example through an incident alerting process. At this time, investigation and assessment would be required to determine the nature of the incident alert and the impact of the issue, including whether it meets ‘major’ status. This investigation will reasonably take a period of time to conclude depending on the nature of the incident; or
(b) From the moment the incident was assessed or reclassified as a ‘major’ incident.
Classification triggers: If all incidents that meet the triggers are notifiable to competent authorities, (irrespective of whether any impact is felt or not), then this effectively would generate a new class of ‘notification’ and we would welcome the EBA’s clarification on this.
• Should the EBA wish to have the information on all ‘bumps’ in the payments road, these will result in additional work for firms to complete the notification template, updates and final reports.
Reporting:
Initial: We would suggest that the 2 hour window should be extended to a slightly longer timeline (12-24 hours would be more appropriate) for the initial report with details. Should this not be possible, we suggest that the initial report should be made shorter as outlined under question 5. The EBA could achieve this by using only the “1 – General Details” section of the major incident report under Annex 1. Firms would remain free to provide further detail in the first notification should they wish. Whilst some organisations are comfortable with such short timescales, others cannot accommodate this; therefore we would suggest that more clarity is provided on the level of detail required in the initial report within the 2 hour window should this not be the case.
Intermediate: Again, there may be limited information but ongoing actions will enable sight of a plan in place for investigation and recovery.
Final: The full report should be sent within two weeks of recovery and back to normal" status. However, it may not always be possible to determine the root cause of the incident within this period, for example, if the firms needs to carry out forensic analysis following a complex cyber-attack, or detailed diagnostics are required by a third party supplier to assess a hardware failure. It is recommended that an indication of when the final report would be available is provided when the final interim report is completed."
It is very unlikely that firms would delegate reporting obligations for incidents but may report on behalf of third parties to provide details of the incident, incident impact etc. which will be relevant to the market and add value by ensuring accuracy and consistency of information. It is also beneficial that the reporting guidelines provide a standard process which allows all PSPs to work to the same process.
Some of our members would like clarity on whether intra-group agreements were also included (e.g. a non-EU head office reporting on behalf of the EU entity) in the scope of EBA’s delegated reporting as a ‘third party’.
We understand that the information provided will be anonymised by the competent authority when being shared with other domestic authorities, however, we would appreciate further detail to understand what is in place to ensure the confidentiality and/or intellectual property rights are upheld and anonymised.
We would suggest that there may be some other instances where consolidated reporting from payment schemes when a major incident is triggered could be beneficial. An example of this may be where there are issues with a payment scheme that affect a number of individual PSPs. It might be more effective for there to be a consolidated incident report from the one payment scheme or CSM detailed reporting of the incident rather than individual submissions from each PSP which could result in duplication of information and the competent authority being inundated with like-for-like reports.
From a UK standpoint, which we would assume is similar in other Member States; the introduction of the new EBA template will create some duplication. We would therefore welcome clarity from the EBA on whether the proposed reporting of major incidents via the proposed EBA template will replace or interfere with existing process of reporting major incidents to competent authorities that are in place today
It is also suggested that more clarity is required on how the consolidated reporting process will work and the information which could be shared with other PSPs. There is too little detail to be able to determine potential benefit at this stage. It would be beneficial to the industry if the competent authority plans to provide anonymised early warning to other PSPs in a timely manner on security incidents and emerging threats, with sufficient detail to facilitate understanding of the specific cause, to enable precautions to be taken if necessary/possible. It is often the case that there is little or no feedback, or dissemination of the results of analysis or the data collected from competent authorities. Often anonymised data could be extremely useful to the industry to better processes, products, etc.
The EBA should go back to principles and consider what the purpose of gathering the information proposed within the consultation is – i.e. once it is gathered will it be analysed? Will the analysis/data be disseminated back to the participant PSPs, institutions and/or government bodies and central banks for use and reflection in determining procedures, operational gaps or policies going forward? Will the information be used to form future policy, regulations, or procedure and if so, by whom?
One other major consideration the EBA should have is the case of a PSP having an incident but either not classifying it as ‘major’ or even therefore, report an incident. It would be helpful to understand the ramifications of this.
Question 1: Do you consider the definitions included in the draft Guidelines to be sufficiently clear?
Question 1: Do you consider the definitions included in the draft Guidelines to be sufficiently clear?We generally think the definitions included are clear and welcome the general clarity in the draft Guidelines. However, there are certain areas which we would appreciate clarification or have suggestions. Specifically, we would like to make some comments on the following points:
• Availability – The term “upon demand by authorised clients” implies that all payment-related services are automatically available all of the time (24 x 7 x 365). We do not think that this necessarily applies in all situations. The ability to access and use some payment-related services may be subject to certain restrictions e.g. processing cut-off times, use of particular delivery channels, branch opening times, bank holidays, and scheduled system/service maintenance.
• Definition of incident: There appears to be a mismatch in the definition of incident. In the Guidelines (page 21, paragraph 13) it specifies “Payment Related services” but in the Rationale (page 7, paragraph 13) it states incidents affecting transactions, processes, data or funds". We would welcome clarification from the EBA as to whether any incident impacting a non-payment service would need to be reported. Our assumption is that non-payment related incidents are deemed out of scope of PSD2 reporting to competent authorities. Planned system outages should be clearly defined within the Guidelines as out of scope. Additionally, we would welcome clarity on whether an impact to customer payments in the event of an external incident (i.e. security, national disaster), would be classed as a ‘reportable’ incident.
• Incident classification: In terms of reporting major incidents that could impact payment services provided to Payment Initiation Service Providers (PISPs), Account Information Service Providers (AISPs) or Card-Based Payment Instrument Issuers by firms and in absence of any contractual obligations (as stated under the Directive), we suggest that the incident classification section within the template (Annex 1) could somehow reference this, if needed.
• Scope of incident and wider reporting: We would welcome clarity on whether there is any cross-over with the scope and reporting timelines of many other regulatory/legislative reporting requirements, such as the GDPR requirements (as a limited example). Firms are often required to report to a large number of regulators and competent authorities. We would therefore welcome more specificity on the scope of reporting (i.e. simply payment services) and also which competent authorities should be notified (i.e. just those with authority for PSD2 or competent authorities more widely). Furthermore, more clarity would be welcomed on who to notify in the event an incident affects more than one Member State, would this be the home or host competent authority, or both?
• Definition of authenticity: We are unclear what authenticity specifically refers to in the context of the incident management process. Further clarification would be welcome e.g. does this refer to verification and confidence in data received from third parties during the course of an incident, or does it refer to something else?
• Definition of reputation: We would welcome further clarity on reputational impact, which could be more clearly defined.
• Clarity: If at all applicable it would be useful for the EBA (or the national competent authority) to confirm if these Guidelines supersede any other reporting requirements."
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?
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?We think the criteria are generally clear in the draft Guidelines; however we have some general and specific commentary as follows:
As a general comment, it is implied in the Guidelines that an incident is ranked as major when a certain number of the thresholds are reached or exceeded. It is not clear from the definitions as to whether the thresholds must actually be exceeded before the incident is classified as a major incident, or whether incidents should be classified as major if there is a potential that thresholds may be exceeded. For example, a payments system incident has the potential impact that a significant volume of same day payments may not be processed if the incident is not resolved before payment cut off times, however the impact may not materialise if the system is recovered ahead of payment cut-off times.
We would also like to make some comments on the following specific points:
• Clients affected: The guidance in this area would benefit from different wording to ensure greater clarity for PSPs. Depending on the individual interpretation of the guidance this could result in very different numbers which could make comparison across different organisations/incidents meaningless. We would welcome the EBA’s clarification on clients affected. We assume that those within scope would be all clients within the scope of PSD2 under ‘payment service user’, with other financial institutions out of scope.
• Service downtime: The threshold for service downtime is less than two hours. At what point is the service downtime deemed to have started? Is this at the point that an initial alert is received or at the point when investigation has determined that there is a system issue? More clarity on this point would be welcomed.
Do the same criteria apply for a partial outage to a payments system - for example if the system is operational but with reduced functionality? We would welcome further clarification around service downtime and what constitutes “service not available”. In particular, where there are multiple channels and services. Would a service be considered not available where there are alternative services that can be used to process a payment? This would be considered sensibly with customer segments in mind (e.g. a service for a retail customer would likely not be considered as an alternative for a service provided to a corporate customer), but we would like to clarify more specifically when a service is not available.
• High level of internal escalation: We feel that using, high level of incident escalation" is not an appropriate indicator for triggering external reporting for regulators. The guidance provided may not provide consistent returns from different PSPs. There are certain challenges to using this as an indicator or priority, as it is an outcome following assessment of a PSP internally to ensure that the right stakeholders are made aware as necessary and in the appropriate timescales. We also feel that internal escalation is subject to different risk appetites within individual PSPs. We would therefore encourage an alternative indicator or at least more clarity could be included to make the classifications less open to interpretation, for example the seniority of the CIO may vary per firm therefore should be clearer on the level of visibility of escalation expected to be reached within the organisation? As under question 4, we recommend that the criteria is changed to 'exceptional level of incident escalation’.
• Transactions/Clients impacted: Further clarity may be required by firms as to whether this is 10% or 25% of:
o The total client base;
o Total number of payment transactions;
o The client base using the specific payment service that is impacted, or;
o The transactions processed by the impacted payment service;
• Thresholds: It would generally be assumed by firms that level 1 incidents are the highest priority incidents and therefore it would be helpful if the level 1/level 2 indicators are swapped. We would recommend that higher thresholds be used for a near miss of the threshold (where there is a potential for thresholds to be breached) if these are indeed required to be reported.
• Incident Notification: It would be helpful for the guidance to stipulate that notification should take place when an incident deemed to be ‘major’ is first detected. It would also be helpful to clarify that if incidents are reclassified, do the same criteria apply (e.g. impact figures and timing)."
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.
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.All of our members agree that the thresholds as currently set would result in significantly more incidents being considered ‘major’. This would be especially true for large PSPs. Some of the thresholds for reporting could be triggered by just one large-value payment failing to be processed.
In our view this may undermine the meaning of ‘major’. We feel the low thresholds as currently drafted would devalue the reporting procedure and would have consequences for adequate treatment of those major incidents which require proper attention from the authorities. We also have questions as to whether competent authorities are geared up to deal with a possibly significant increase in notifications of major incidents.
As a further point, firms would typically rate impact based on actual or potential financial impact, not on transaction value. For example, if a EUR 1 billion payment is late, then the financial impact of the incident would be related to a more limited scope (for example, the interest, fees or compensation associated with the late payment), not the actual value of the payment. It would be helpful for values to be completed for both levels of each threshold.
We encourage the EBA to give more consideration and to bolster the Guidelines around reputational impacts. A significant proportion of incidents carry some degree of potential reputational impact, especially with the volume/usage of social media. We recommend that additional Guidelines are included as to when reputational impact would become reportable.
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.
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.We propose the following amendments to the thresholds referred to in Guideline 1.3:
• Value: The value threshold for transactions to trigger a level 2 major incident seems very low. One large-value trade or corporate payment can easily be in excess of this amount and this could lead to an increased number of incidents being reported if a single payment incident can trigger the major incident classification. We also noticed a difference on the definition of the thresholds as level 1 are defined with ‘and’, with level 2 defined as ‘or’, is this intentional by the EBA?
• Internal Escalations: Firms will provide internal escalations in line with their internal guidelines, which will differ between firms and may also lead to an increased volume of incidents being reported if a senior escalation triggers the major incident criteria. We recommend that the criteria are changed to 'exceptional level of incident escalation’.
• Crisis mode: We would like to see greater clarity regarding the term crisis mode" as referred to in the "High level of internal escalation". Providers may utilise a "crisis mode" structure with various tiers of severity, relatively minor incidents may be handled via such a process but would not constitute a major incident.
• Service downtime: The two hour threshold is a short period of time for an outage and we feel this should be longer with the time of day also taken into consideration. There should also be recognition that different services/systems present different levels of impact if taken out of service. For example, a four hour outage of a system that processes direct debits has a lower impact on customers than a four hour outage to debit card or instant payment systems."
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.
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.We feel the requested information is generally sufficient; however we have additional comments below:
First notification: In the event of a major incident, primary focus in an organisation will be given to fixing the incident. Whilst the notification is of upmost importance, we feel more consideration should be given to the timeline. Two hours for first notification could result in inaccurate reporting.
We also feel that having a two hour notification can also have major impacts on the competent authority’s resources as they would likely need to build a 24 hour capability.
We recognise that a short timescale will be valuable in the context of a competent authority sharing early notification with PSPs to help prevent wider incidents. Should the competent authority not be geared up to achieve this, the benefits of a short notification window are mitigated and reduced.
In the past we have seen other bodies implement a similar outage notification requirement and with it, there was a need to implement a 24 hour and 7 day a week hotline to receive the notifications.
If it is not possible for a lengthened timeline, shorter details should be given as a first notification in the two hour time window, with further detail to follow on in the next stage of communication. The EBA could achieve this by using only the “1 – General Details” section of the major incident report under Annex 1. Firms would remain free to provide further detail in the first notification should they wish.
Furthermore, the EBA should ask whether the incident is historic/has been reclassified. The EBA should also include provision to withdraw a notification should it be discovered that an incident is in fact not major.
Incident Impact: There should be a measure of staff impact as this may affect the ability to maintain services, for example, security incidents such as a terrorist attack where staff are unable to travel or are directly at risk.
Incident Classification: For 'reputational' - this appears to be very subjective and response will be dependent on author and organisation. Explicit questions should be included. As an example some firms may state that the incident could impact the PSP's share price.
Incident discovery: The EBA should ask ‘how was the incident discovered’ to understand whether learnings could be made from the incident and also to understand if there may be an incident affecting more than one firm.
Cause of Incident: The list under ‘attack type’ does not seem to be a complete list. For example, malware attack is missing (e.g. external system infected as in most attacks against online banking systems).
System failure: This section should be split into separate categories, for example, software or hardware failure, to allow for a greater level of understanding across PSPs.
Suggested additional Information: Further consideration should be given to the wider security incident and firm’s activities, for example, in the context of payment service impact such as a DDOS attack, this may have been reported to law enforcement/other agencies and this may be useful for a competent authority to understand in the event of a large-scale attack impacting more than one provider and for working collaboratively in the event with other government authorities.
Further guidance in terms of reporting economic impact would be welcomed. The economic impact is typically dependent upon and determined on the nature of an incident. Dependent upon the incident, firms will not necessarily notify on direct or indirect costs to competent authorities. However, the overall economic impact of a major incident would be dependent on the nature of those costs. For example, firms would advise the financial impacts to its customers and any direct/indirect costs associated with the remediation and redress activity, including a total value and average amount of redress paid. We would welcome further clarity from the EBA on this.
It would be useful for the EBA to include a currency drop down box in the form for non-euro currencies. The reportable currency within the template should also allow for the host currency of the Member State i.e. UK = GBP Ireland = EUR to be reported.
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.
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.Overall, we welcome the instructions level of clarity but have the following specific suggestions:
Some of the very specific requests e.g. start of incident" may be difficult for firms to confirm. The EBA should accept reasonable estimated times, based on investigation and internal/external intelligence, where exact start time of an incident cannot be confirmed.
“High level of internal escalation” would probably be more appropriately worded as “exceptional level of escalation” as incidents going through established governance could be misinterpreted as receiving a high level of internal escalation.
Annotation on whether amounts are estimates or final figures could also be included.
We would also welcome further clarity on what is meant under authenticity."
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.
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.Two hour window: We feel that the timescales are unrealistic and inconvenient especially in the context of a major security incident. Focus in an incident is generally given to identifying and resolving the problem/s and having a short deadline for notification will divert critical resource away from resolving incidents. Furthermore, if the incident were to happen out of business hours, often staff have to be mobilised which can take time. During the first two hours of an incident it is often incredibly unclear as to how widespread the issue is, to avoid further compromises firms often seek to limit communications to those areas directly impacted and those required in recovery activities.
Furthermore, we feel that early estimates in regards to the scale of incidents offer little to no value and only seek to spread panic. This can also have a huge reputational impact on companies affected. As an example, the recent TalkTalk data breach in the UK, initial estimates raised suggested it could be hundreds of thousands of payment details breached. In the end this was dramatically revised down and was revealed as just over 15,000 customers. Whilst still a significant number, the scale estimated was substantially wrong. We would therefore encourage the EBA to significantly revise the initial notice period as it is currently unworkable for many institutions.
Where the incident has been identified and resolved within the two hour window would the EBA expect this incident to still be reported? If so, would this be reported by the submission of a final report? In our view, this seems the most sensible approach as it provides the competent authority with the comfort that the incident has already been fixed and gives the fullest picture. In this case however, we would ask the EBA for a little more flexibility in the reporting deadline for firms to be able to pull that final report together.
Incident discovery point: In terms of further clarity, we recommend that more detail is included within the Guidelines to fully explain what is meant by 'the incident discovery point' in direct relation to the incident cycle; consideration here would result in different timescales, for example:
(a) From the moment the incident was first detected, for example through an incident alerting process. At this time, investigation and assessment would be required to determine the nature of the incident alert and the impact of the issue, including whether it meets ‘major’ status. This investigation will reasonably take a period of time to conclude depending on the nature of the incident; or
(b) From the moment the incident was assessed or reclassified as a ‘major’ incident.
Classification triggers: If all incidents that meet the triggers are notifiable to competent authorities, (irrespective of whether any impact is felt or not), then this effectively would generate a new class of ‘notification’ and we would welcome the EBA’s clarification on this.
• Should the EBA wish to have the information on all ‘bumps’ in the payments road, these will result in additional work for firms to complete the notification template, updates and final reports.
Reporting:
Initial: We would suggest that the 2 hour window should be extended to a slightly longer timeline (12-24 hours would be more appropriate) for the initial report with details. Should this not be possible, we suggest that the initial report should be made shorter as outlined under question 5. The EBA could achieve this by using only the “1 – General Details” section of the major incident report under Annex 1. Firms would remain free to provide further detail in the first notification should they wish. Whilst some organisations are comfortable with such short timescales, others cannot accommodate this; therefore we would suggest that more clarity is provided on the level of detail required in the initial report within the 2 hour window should this not be the case.
Intermediate: Again, there may be limited information but ongoing actions will enable sight of a plan in place for investigation and recovery.
Final: The full report should be sent within two weeks of recovery and back to normal" status. However, it may not always be possible to determine the root cause of the incident within this period, for example, if the firms needs to carry out forensic analysis following a complex cyber-attack, or detailed diagnostics are required by a third party supplier to assess a hardware failure. It is recommended that an indication of when the final report would be available is provided when the final interim report is completed."
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.
Question 8: Do you consider that the delegated reporting procedure proposed in the draft Guidelines will provide added value to the market? Please explain your reasoning.It is very unlikely that firms would delegate reporting obligations for incidents but may report on behalf of third parties to provide details of the incident, incident impact etc. which will be relevant to the market and add value by ensuring accuracy and consistency of information. It is also beneficial that the reporting guidelines provide a standard process which allows all PSPs to work to the same process.
Some of our members would like clarity on whether intra-group agreements were also included (e.g. a non-EU head office reporting on behalf of the EU entity) in the scope of EBA’s delegated reporting as a ‘third party’.
We understand that the information provided will be anonymised by the competent authority when being shared with other domestic authorities, however, we would appreciate further detail to understand what is in place to ensure the confidentiality and/or intellectual property rights are upheld and anonymised.
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.
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.We would suggest that there may be some other instances where consolidated reporting from payment schemes when a major incident is triggered could be beneficial. An example of this may be where there are issues with a payment scheme that affect a number of individual PSPs. It might be more effective for there to be a consolidated incident report from the one payment scheme or CSM detailed reporting of the incident rather than individual submissions from each PSP which could result in duplication of information and the competent authority being inundated with like-for-like reports.
From a UK standpoint, which we would assume is similar in other Member States; the introduction of the new EBA template will create some duplication. We would therefore welcome clarity from the EBA on whether the proposed reporting of major incidents via the proposed EBA template will replace or interfere with existing process of reporting major incidents to competent authorities that are in place today
It is also suggested that more clarity is required on how the consolidated reporting process will work and the information which could be shared with other PSPs. There is too little detail to be able to determine potential benefit at this stage. It would be beneficial to the industry if the competent authority plans to provide anonymised early warning to other PSPs in a timely manner on security incidents and emerging threats, with sufficient detail to facilitate understanding of the specific cause, to enable precautions to be taken if necessary/possible. It is often the case that there is little or no feedback, or dissemination of the results of analysis or the data collected from competent authorities. Often anonymised data could be extremely useful to the industry to better processes, products, etc.
The EBA should go back to principles and consider what the purpose of gathering the information proposed within the consultation is – i.e. once it is gathered will it be analysed? Will the analysis/data be disseminated back to the participant PSPs, institutions and/or government bodies and central banks for use and reflection in determining procedures, operational gaps or policies going forward? Will the information be used to form future policy, regulations, or procedure and if so, by whom?
One other major consideration the EBA should have is the case of a PSP having an incident but either not classifying it as ‘major’ or even therefore, report an incident. It would be helpful to understand the ramifications of this.