Response to consultation on Guidelines on major incidents reporting under PSD2
Go back
1) Incidents are related to the availability and continuity of services and
2) Incidents are related to the security, definitions integrity and authenticity.
ING’s main consideration for using different definitions is that the nature and severity of those two types of incidents are not comparable and therefore cannot to be captured in one definition. Using two definitions will help the industry and NCA’s, to focus on those incidents which should be reported under these guidelines to fulfil the defined goals. In the response to question 4 ING substantiates its position in more detail.
The definition of a major incident, as currently stated in the guidelines, includes incidents that do not have a material impact. Since this expression is not time-bound, it is open for too much interpretation and may include threats, where only incidents should be reported. For example, when a phishing mail campaign is initiated, potentially many clients’ accounts are at risk. Following the proposed definition it might be considered as a major incident. However, in most of the cases, the actual impact is low since only a limited number of clients will actually react on the phishing mail besides having other mechanisms in place to detect and prevent fraud.
It would be more appropriate to define a major incident as an incident that actually has material impact or has a very high probability of becoming an incident with material impact. Preferably the definitions are aligned with definitions that are defined by international bodies such as ISO, the Bank for International Settlement and ENISA.
The definitions of affected clients and affected transactions are too stringent and do not take the circumstances of an incident into consideration. A strict interpretation leads to reporting of incidents that are not considered to be major. For example, when the processing of a batch of payment orders is delayed, all transactions are affected. A batch of payments easily contains more than 50,000 transactions, thus reaching the threshold. However, when the batch is processed within the Service Level Agreement (SLA) that is agreed with the client, ING would not classify this delay as an incident with major impact.
Furthermore, the criteria and definitions do not take into account alternative payment methods that are available to a client. For example, the impact of an outage in the internet banking environment seems major at first sight. However it could been considered as moderate, or even low, if a significant number of clients primarily uses the mobile banking app.
For incidents that are related to the availability and continuity of a service ING therefore proposes:
1) A reference to a norm / SLA.
2) The usage of relative thresholds only (such as a percentage of total transactions, or active clients in a channel).
For security incidents ING would like to suggest that only materialized incidents need to be reported that actually have impact on transactions and clients. The threshold for this type of incidents should be more stringent and may be absolute (for example more than a specific number of clients)
With respect to the methodology, ING agrees with rationale 17 that the criteria mentioned (such as number of transactions affected) indicate how severe an incident is likely to be. Following this rationale, ING is of the opinion that an assessment of the incident by (senior) management should be part of the procedure. Such an assessment will assure that only relevant incidents are reported, which is in line with the goals of the guidelines. The evaluation of the Cybercrime Incident Reporting by ECB, illustrates that an assessment by (senior) management is indeed good practice.
Most incidents, which should be reported under the current definitions and thresholds, are solved before any actual client impact occurs or even before a client may notice. ING proposes to report only the incidents for which ING cannot meet the Service Level Agreements (SLA) as agreed with the clients.
1) Incidents are related to the availability and continuity of services and
2) Incidents are related to the security, integrity and authenticity.
ING is of the opinion that the thresholds described in the Consultation Paper can be used for the incidents related to integrity, confidentiality and authenticity. They should always be aligned with the thresholds as used by ECB for Cybercrime Reporting.
For incidents related to availability / continuity of the payment related services, ING proposes to introduce only level 1 thresholds (a combination of thresholds), which opens the possibility to include circumstances of the incident in the classification. As an example the time of the event: during business hours unavailability of the online banking environment has a more severe impact than the same incident in the middle the night.
Furthermore ING is opposed to use the reputational impact as a criteria for availability and continuity incidents. Reputational impact cannot be determined in numbers, is not a stable and objective criterion and therefore not suitable to serve as a guideline.
With respect to the process, as stated in the response on question 2, ING is of the opinion that an assessment of the incident by (senior) management should be part of the procedure. Such an assessment will assure that only relevant incidents are reported, which is in line with the goals of the guidelines.
ING proposes to specify mandatory templates per phase:
- Initial report: section 1 (General details) and section 2 (Incident Discovery)
- Interim report: section 3 (Incident classification), section 4 (Incident description), section 5 (Incident impact) and update of data that has already been provided.
- Final report: section 6 (Incident mitigation) and update of data that has already been provided.
In section 8 the PSP can indicate whether the information is shared with other PSP’s. Especially for security incidents, sharing information with other PSP’s may be essential. The relation between the draft guidelines and sharing of incident information with other PSP’s is not clear. ING proposes to add the obligation for a PSP to report security incidents that may affect other PSP’s to the potentially affected PSP’s as soon as possible (also during the weekend and bank holidays).
Furthermore ING proposes that information on incidents will be shared (anonymised) with other relevant PSP’s. This data is useful since it may prevent similar incidents occurring at other PSP’s.
• In the “Instruction to fill out the template” there is no indication if a field is mandatory or optional. It would clarify if explicitly is stated if a field is optional or mandatory
• PSP Affected: it is not clear to us is what is meant with “PSP unique identification number” and “PSP authorisation number”
• A field is missing to specify the PSP’s internal incident reference number. Such a field could help in the (internal) communication.
Furthermore, ING proposes to increase the timeline for the final report from 2 to 4 weeks. In that part of the process, a timely delivery is of less importance than the quality of the report. To cater for a proper detailed analysis of the incident, from ING’s experience, in some cases more time is needed than 2 weeks.
Question 1: Do you consider the definitions included in the draft Guidelines to be sufficiently clear?
ING welcomes the guidelines and believes these are a very good starting point. However, ING proposes a significant adjustment in the definition of a major incident. ING proposes to use two different definitions for incidents.1) Incidents are related to the availability and continuity of services and
2) Incidents are related to the security, definitions integrity and authenticity.
ING’s main consideration for using different definitions is that the nature and severity of those two types of incidents are not comparable and therefore cannot to be captured in one definition. Using two definitions will help the industry and NCA’s, to focus on those incidents which should be reported under these guidelines to fulfil the defined goals. In the response to question 4 ING substantiates its position in more detail.
The definition of a major incident, as currently stated in the guidelines, includes incidents that do not have a material impact. Since this expression is not time-bound, it is open for too much interpretation and may include threats, where only incidents should be reported. For example, when a phishing mail campaign is initiated, potentially many clients’ accounts are at risk. Following the proposed definition it might be considered as a major incident. However, in most of the cases, the actual impact is low since only a limited number of clients will actually react on the phishing mail besides having other mechanisms in place to detect and prevent fraud.
It would be more appropriate to define a major incident as an incident that actually has material impact or has a very high probability of becoming an incident with material impact. Preferably the definitions are aligned with definitions that are defined by international bodies such as ISO, the Bank for International Settlement and ENISA.
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?
According to ING the criteria and method are in general the right basis for the assessment and classification of incidents. However, a few adjustments should be made.The definitions of affected clients and affected transactions are too stringent and do not take the circumstances of an incident into consideration. A strict interpretation leads to reporting of incidents that are not considered to be major. For example, when the processing of a batch of payment orders is delayed, all transactions are affected. A batch of payments easily contains more than 50,000 transactions, thus reaching the threshold. However, when the batch is processed within the Service Level Agreement (SLA) that is agreed with the client, ING would not classify this delay as an incident with major impact.
Furthermore, the criteria and definitions do not take into account alternative payment methods that are available to a client. For example, the impact of an outage in the internet banking environment seems major at first sight. However it could been considered as moderate, or even low, if a significant number of clients primarily uses the mobile banking app.
For incidents that are related to the availability and continuity of a service ING therefore proposes:
1) A reference to a norm / SLA.
2) The usage of relative thresholds only (such as a percentage of total transactions, or active clients in a channel).
For security incidents ING would like to suggest that only materialized incidents need to be reported that actually have impact on transactions and clients. The threshold for this type of incidents should be more stringent and may be absolute (for example more than a specific number of clients)
With respect to the methodology, ING agrees with rationale 17 that the criteria mentioned (such as number of transactions affected) indicate how severe an incident is likely to be. Following this rationale, ING is of the opinion that an assessment of the incident by (senior) management should be part of the procedure. Such an assessment will assure that only relevant incidents are reported, which is in line with the goals of the guidelines. The evaluation of the Cybercrime Incident Reporting by ECB, illustrates that an assessment by (senior) management is indeed good practice.
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.
ING considers that the methodology will capture significantly more incidents than the number of incidents that are currently considered by all parties as major. Large banks, such as ING, will report much more incidents based on proposed methodology due to the large number of processed transactions and large number of clients, compared to the absolute thresholds. As an example, the outage of an individual ATM in the centre of a big city, could affect many clients. However, mostly there is no actual impact because those clients can use an ATM of another bank and/or use terminal payments (POS) for most of their payments.Most incidents, which should be reported under the current definitions and thresholds, are solved before any actual client impact occurs or even before a client may notice. ING proposes to report only the incidents for which ING cannot meet the Service Level Agreements (SLA) as agreed with the clients.
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.
ING proposes to use two different types of threshold matrices for incidents in line with ING’s answer on question 11) Incidents are related to the availability and continuity of services and
2) Incidents are related to the security, integrity and authenticity.
ING is of the opinion that the thresholds described in the Consultation Paper can be used for the incidents related to integrity, confidentiality and authenticity. They should always be aligned with the thresholds as used by ECB for Cybercrime Reporting.
For incidents related to availability / continuity of the payment related services, ING proposes to introduce only level 1 thresholds (a combination of thresholds), which opens the possibility to include circumstances of the incident in the classification. As an example the time of the event: during business hours unavailability of the online banking environment has a more severe impact than the same incident in the middle the night.
Furthermore ING is opposed to use the reputational impact as a criteria for availability and continuity incidents. Reputational impact cannot be determined in numbers, is not a stable and objective criterion and therefore not suitable to serve as a guideline.
With respect to the process, as stated in the response on question 2, ING is of the opinion that an assessment of the incident by (senior) management should be part of the procedure. Such an assessment will assure that only relevant incidents are reported, which is in line with the goals of the guidelines.
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.
The proposed reporting template closely resembles the reporting template that is currently used for reporting of cybercrime incidents to the ECB. In the evaluation on this procedure and template some improvements on the templates were identified, especially additional clarification is provided on the required information per reporting phase (initial, interim and final).ING proposes to specify mandatory templates per phase:
- Initial report: section 1 (General details) and section 2 (Incident Discovery)
- Interim report: section 3 (Incident classification), section 4 (Incident description), section 5 (Incident impact) and update of data that has already been provided.
- Final report: section 6 (Incident mitigation) and update of data that has already been provided.
In section 8 the PSP can indicate whether the information is shared with other PSP’s. Especially for security incidents, sharing information with other PSP’s may be essential. The relation between the draft guidelines and sharing of incident information with other PSP’s is not clear. ING proposes to add the obligation for a PSP to report security incidents that may affect other PSP’s to the potentially affected PSP’s as soon as possible (also during the weekend and bank holidays).
Furthermore ING proposes that information on incidents will be shared (anonymised) with other relevant PSP’s. This data is useful since it may prevent similar incidents occurring at other PSP’s.
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.
For ING the following items are not (fully) clear.• In the “Instruction to fill out the template” there is no indication if a field is mandatory or optional. It would clarify if explicitly is stated if a field is optional or mandatory
• PSP Affected: it is not clear to us is what is meant with “PSP unique identification number” and “PSP authorisation number”
• A field is missing to specify the PSP’s internal incident reference number. Such a field could help in the (internal) communication.
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.
ING mostly disagrees with deadline of the initial report. The first hours of an incidents are critical for the speed of containing the incident and minimising the impact for clients. Therefore in these so called ‘golden hours’, the teams working on the solution should focus on their tasks and should not to be disturbed. Therefore ING proposes to set the timeline for the initial report to 12-24 hours.Furthermore, ING proposes to increase the timeline for the final report from 2 to 4 weeks. In that part of the process, a timely delivery is of less importance than the quality of the report. To cater for a proper detailed analysis of the incident, from ING’s experience, in some cases more time is needed than 2 weeks.