What's happened?

The business has grown substantially over a number of years, and now has a number of different business units providing different services. Some of that growth has been through acquisitions. There are a number of policies which impact on information security in place across the business. The business takes payment online via credit and debit card, but considers that it has appropriate security measures in place, and is working towards PCI-DSS certification. The growth of the business has resulted in fragmentation of databases across multiple servers, and the business has recently sought to move to a cloud solution. Multiple third parties have access to certain data through APIs.

The CISO (Chief Information Security Officer) receives an automatic alert that some data on a server has been decrypted because the encryption key was accessible in plain text. Initial investigation by IT security indicates that:

  • The data decrypted includes name, address, time at address, email address, and credit card data (16-digit PAN, card name and expiry date. CVVs were not stored);
  • Personal information was stored on the same server in plain text;
  • Data loss prevention software has flagged a data file going to an IP address in Indonesia, but from a different server, and the data file is encrypted;
  • Indications are that the patching policy may not have been properly followed in the relevant part of the business;
  • There is unusual activity on a single third party's API access;
  • Data on the server storing credit card data has been accessed using a legitimate login; Further investigation indicates that the attackers also gained access to the server from which the file was sent, and there is evidence that a web shell was uploaded which had encryption capability; and
  • Further investigation indicates that penetration testing had not been properly carried out, and that if it had, there was at least a reasonable chance that the vulnerabilities exploited would have been identified.

Context

Any breaches which happen after 25 May 2018 will be subject to the GDPR. That means that not only does a business face fines of up to the greater of €20m or 4% of global group turnover in relation to a breach, but failure to comply with notification obligations can attract an additional fine of up to €10m or 2% of global group turnover. These fines are cumulative. The GDPR also requires notification to the appropriate supervisory authority.

Of course, the exact fact pattern would vary case by case and business by business, and the above is an amalgamation of factors from a number of incidents, but it would not be atypical to see one of more of the above issues, or similar ones, in data breaches. In this case, we are assuming that the business is the data controller for the relevant data.

Next steps

Activate the breach response plan and convene the team who will manage the incident response process

In this scenario, although the compromise is still open, there is no evidence of ongoing data exfiltration. The first thing to do is to activate the breach response plan and convene the team who will manage the incident response process. This should include a director with responsibility and authority on decision-making, legal, commercial, internal IT function, HR, and PR/comms.

Notify insurers and external advisers

If the business has cyberliability insurance, insurers should be notified and, if appropriate, guidance sought as to next steps and to obtain initial confirmation of cover. Depending on the policy, insurers may provide their own incident response services. External advisers such as legal, forensic IT / cybersecurity consultants, PR and call centre capacity should be on standby or involved from the start, depending on capabilities within the business.

Instruct third party forensic IT and cybersecurity specialists through legal advisors

At this point, there is very little information as to how bad actors obtained access to the business' systems, what data may have been accessed and whether it was stolen, and what else the bad actors may have done. Investigation requires the instruction of third party forensic IT and cybersecurity specialists who have the skills to properly investigate what has happened without compromising evidence. Internal IT security may (very unusually) have the skills to investigate, but bear in mind that they are not independent and may be investigating activity which highlights failings on their part. It is crucial at this stage that the business properly understands the risk it is facing.

Make sure the forensic IT report is privileged

One early error which we have seen all too often is forensic IT being instructed without any involvement of legal, either internal or external. This means that the work carried out by forensic IT support is not privileged. It is consequently disclosable to the ICO or any other relevant supervisory authority, and in any subsequent dispute (either with data subjects or other businesses in the data management chain). If the forensic IT report indicates significant failings, that may make it much more difficult to avoid regulatory action or defend litigation

Legal function instructing forensic IT support does not mean delay. In practice, it should take less than 30 minutes to add wording to engagement terms to show that the instruction is by legal and that any work carried out is to allow internal or external legal (as appropriate) to advise the business on risks arising out of the incident. In the U.S., where breach investigation has been a significant issue for many more years that in the UK, reputable forensic IT companies will not accept instructions other than from either in-house counsel or external lawyers, for precisely this reason. Unfortunately in the UK forensic IT support often seem surprised to be instructed by legal, and insurers all too often do not insist on it (despite any lack of privilege cover increasing their own exposure).

Start information gathering and keep information under review

The first 48-72 hours of breach response usually involve gathering as much information as possible, and using that to triage potential risks to the business and the direction of the investigation. The breach response team should continually review information as to what data may have been accessed and exfiltrated, and what parts of the business attackers may have accessed. Insurers should also be kept informed on a regular basis. The business may be keen to know who attacked them, but at this stage that is not important, and may never be known.

Do you need to notify the ICO (or another regulator)?

The business will need to continually review whether it needs to notify the ICO (or other relevant supervisory authority) or data subjects on an ongoing basis. The obligation under the GDPR is to notify the relevant supervisory authority of a data breach without undue delay and where feasible not later than 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. That is not a significant hurdle, and it is likely that under the GDPR a very significant number of breaches will be notifiable.

Data breach is a broad concept; the Article 29 paper gives a good insight into how to approach the question of whether an event constitutes a breach. In this case, there is no direct evidence that the data on the server was compromised. However, there is evidence that the data was the subject of unauthorised access, and a large (encrypted) file was sent shortly after decryption of the data to an IP address in Indonesia (with no legitimate reason for that file transfer). This is a not an uncommon fact pattern, and it is very difficult indeed to argue, under these circumstances, that a breach has not occurred. The clock is, therefore, ticking for notification to the ICO. That notification will be "pending further information", but there is sufficient evidence that a breach has taken place to notify the ICO.

Do you need to notify individuals?

Where a personal data breach is likely to result in a high risk to the rights and freedoms of a data subject, the controller must communicate the breach to the data subject without undue delay. The communication must describe in clear and plain language, the nature of the breach and at least:

  • the name and contact details of the relevant Data Protection Officer or contact point;
  • the likely consequences of the data breach; and
  • measures taken or proposed by the controller to address the breach and/or mitigate its effects.

There is, however, no requirement to make a notification to the data subject where any of the following conditions have been met:

  • technical and organisational measures have been applied to the personal data which will render it unintelligible to unauthorised persons (such as encryption);
  • the controller has taken steps to ensure the originally high risk is no longer likely to materialise; or
  • to notify each data subject would involve disproportionate effort, in which case a public communication or other method of information may be used which would inform the affected data subjects in similarly effective manner.

In this case, it is likely that the business will never be able to ascertain with certainty whether the credit cards stored were contained within the file removed from the business. The business does, however, have evidence of decryption of specific data, the creation of an encrypted file, transfer of an encrypted file outside the course of business, from a server known to have been accessed by the attackers. Although CVVs were not stored, it appears that sufficient data was accessed, and likely exfiltrated, to create a high risk to the rights and freedoms of individuals (due to increased risk of fraud). Notification to data subjects should be seriously considered.

If notification to data subjects takes place, then this should be prepared in conjunction with legal and PR. There is a fine line between giving data subjects enough information and the comfort they need (particularly under the more prescriptive GDPR regime) and not making statements which prove problematic later on. In addition, public FAQs should be prepared and made available on the business's website, as well as internal FAQs for dealing with data subject responses to notification. An internal escalation procedure on data subject responses needs to be prepared, and mechanisms put in place to ensure consistency of response to data subjects.

Review contracts for notification obligations and information rights

At the same time, legal should be reviewing contracts for contractual notification obligations to third parties, and for contractual rights to information that may be useful to obtain information from contracting parties. In the scenario here, it may be that information is sought from the third party whose API access shows irregularities, even if only to rule out their API access as a point of compromise.

What's the damage?

The failure to adhere to the patching policy in part of the business means that vulnerabilities were likely to have been exploited which might not have been exploited had the most recent patches been applied. Remedial action could then have been taken before a breach occurred. This is a significant risk factor for both regulatory enforcement and any follow-on litigation; if reports from forensic IT consultants highlighting this issue are not privileged, then the business has, in effect, immediately lost control of that information which makes regulatory sanctions and/or successful claims more likely.

The business might point to the fact that some, perhaps all, of the data was accessed via a legitimate login credential as indicating that this was an attack which the business could not have prevented, because it may be that the credential was compromised for reasons beyond its control. It may also be that access took place through the third party's API. The reality is that it is often not possible to identify with certainty how access was obtained. It appears in this case, however, steps were not taken which resulted in: (a) access being easier than it should have been and; (b) the business failing to identify (and remediate) vulnerabilities.

Assuming that the business notified the ICO and impacted data subjects promptly, in this case regulatory fines would be likely for the breach itself, and security failures (up 4% / €20m and 2% / €10m respectively). The Information Commissioner has been at pains to point out that we will not immediately see fines of tens of millions of dollars. However, where a business gets security badly wrong and significant amounts of personal data are compromised, significant fines are likely. It will become even more important to ensure that a proper investigation is conducted, with privilege protection, and with full recording of each step taken in the investigation. Many more breaches will enter the public domain after GDPR than has historically been the case; the ability to point to a well-conducted investigation, and for the business to have control over information, will be ever more important.