Regulatory demands around how security incidents are handled are increasing in several areas. One of the main, and most pressing (oppressing?) sets of requirements comes from GDPR, but PSD2 also has a set of standards.
PSD2 imposes time limit for data breach notifications
The GDPR regulation imposes a 72 hour time limit for breaches to be notified to the regulator (where they qualify as being serious enough) and then the information passed on to affected customers/citizens/users “without undue delay”. See our other blog posts here, here and here.
The PSD regulations have requirements in this regard also. Clearly in the finance and payments world there is (a) a lot of personal data kicking about and (b) the impacts of a security and fraud breach can get very expensive very quickly.
The EBA security incident handling requirements for PSD2
Under PSD2 (which is an EU directive) the requirements for security have been defined by the European Banking Authority (EBA). We covered the wider security obligations here (link to above post) but the incident reporting requirements are available.
The EBA Guidelines on“Major Incident Reporting” provide further detail on the method and timescales for major incidents (e.g. widespread fraud or significant data losses) to be reported. These are structured as below:
- Guideline 1: Classification as major incident
- Guideline 2: Notification process
- Guideline 3: Delegated and consolidated reporting
- Guideline 4: Operational and security policy
- Guideline 5: Assessment of the relevance of the incident
- Guidelines 6-7: Information to be shared
- Guideline 8: Communication
The main areas that security teams should pay attention to are the classification process in Guideline 1 and the notification process in Guideline 2.
The classification process defines criteria for whether an incident is minor or major – and hence how it is handled, then there is a reporting process with defined stages and aggressive timelines. This will stretch security teams even further with the addition of GDPR requirements in the same timeframe.
Incident Classification under PSD2
The incident classification process is based on higher and lower impact criteria. These are used, as per the diagram below to define the severity.
The criteria are then based on the corresponding impacts in respect of a number of areas. These are:
- Number of transactions affected
- Number of service users affected
- Amount of service downtime
- Degree of economic impact
- The level of internal escalation
- Effects on other providers or systems
- Reputational impact
PSD2 Incident reporting
Initial Report (After 4 hours)
The initial requirement is to provide a high-level set of details on who is reporting the incident, how it was detected and a short description of the nature of the incident and the time when an update will be issued. See form excerpt below.
The initial incident report template.
In many ways this is a placeholder – a communication channel with the upfront circumstances and the points of contact so that future communications and escalation/investigation can be coordinated
Intermediate Report (At least every 3 days)
As the investigation into a breach, loss or fraud progresses (potentially becoming both wider and deeper in its scope) there is a mechanism for interim reports on a 3-business day basis (or earlier if possible).
This is a more in-depth analysis report, regularly refreshed, that covers the incident details, classification and description, the impact and mitigations.
The content of this report is defined in another template form which we have reproduced below. However clearly as the investigation progresses any scant initial details are going to need to be fleshed out and the “more DETAILED description” box at the top is going to have to be filled up!
Part of the PSD2 / EBA Interim report form
Final Report (Maximum 2 weeks)
The close-down report for an incident is expected two weeks after the business is ‘back to normal’.
The final report includes the root cause analysis and follow-up recommendations. At a point before any legal/criminal processes have even commenced and before the final monetary costs of making redress are fully known – the reality of this is it that it will have to be limited to the more technological aspects of what went wrong and what needs to be put right.
The PSD2 / EBA Final Incident report form
PSD2 security incident handling: The clock is ticking
Four hours is a very short time in which to determine that a security incident is a major incident. Clearly in some cases this is fine – detection is immediate and automatic, but in others the results of an access violation, fraud, abnormal flow of funds or some other security situation may be less evident and less easy to initially diagnose as “a security problem”
Having three days (as per GPDR breach notification reporting requirements) to understand what is going on is also a challenge – whether you are driven by the EBA incident reporting rules or the needs of the ICO and EU GDPR. However, at least the details of what is required are defined and as such that initial window can be used to populate as much understanding as possible. While also of course dealing with customers, other service providers, retailers, the social media channels and the press!
However, with the money involved, and the knock effects on other parts of the payment, banking, retail and service networks that open banking might create – the incident handling reporting process is always going to be a challenge under Open Banking and PSD2.
The interconnectedness of systems, the range of customer interactions, the vast number of industry players of all sizes… all make for a complicated environment for security threat detection and management, incident detection, understanding, reporting and resolving.
To discover the cyber security implications of PSD2, go to our PSD2 web page.
You can also download our Infographic:
Products
Solutions by Industry
Learning & Resources
About Huntsman
