Managing Personal Data Breaches under GDPR

The EU General Data Protection Regulation (GDPR) is almost upon us, widely acknowledged as providing a significantly more robust framework to protect personal data in our modern, digital world. At its heart is Article 25, requiring that organisations ensure that their personal data processing activities benefit from “data protection by design and by default”. In essence, we need to understand the risks to personal data from its proposed processing in advance, and implement and manage appropriate controls to ensure that bad things simply aren’t allowed to happen.

That’s a sound approach that none of us would argue with, and has already been a catalyst for the redesign of many existing business processes and applications. But it would be naïve for any of us to believe that Article 25 will see an end to personal data breaches – unauthorised or erroneous disclosures caused by careless employees, unexpected interactions between software applications or a negligent supplier. To address these occurrences, GDPR includes several updated requirements: Article 33 requires notification of personal data breaches to the supervisory authority (ICO within the UK), and Article 34 requires similar notifications to be made to affected data subjects, explaining the likely consequences to them of the breach that has occurred.

Let’s look at this important area in more detail.

Firstly, what is a “personal data breach”? It’s no surprise that these events are defined as breaches of security which affect personal data, for example its loss, theft, disclosure, unauthorised access or unlawful destruction. For those of us familiar with information security, these could be:

  1. A breach of Confidentiality, encompassing an unauthorised or accidental disclosure of personal data to a person, organisation or system not authorised to see it, or
  2. A breach of Integrity, which may arise from an unauthorised or accidental alteration to personal data, meaning it can no longer be trusted to be accurate, or
  3. A breach of Availability, which includes any unauthorised or accidental actions which result in loss of legitimate access to personal data, or its unauthorised or accidental deletion.

But there are additional criteria which help us to understand when the supervisory authority and data subjects need to be informed, and this is focused on an assessment of whether the “rights and freedoms of natural persons” are at risk from the data breach. The accidental disclosure of a staff telephone list, for example, will not reach the risk threshold for reporting. There are other circumstances where reporting may not be necessary: for example the loss of encrypted data (where the decryption key itself has not been compromised) would not need to be notified.

It’s not as simple as just training our personnel to undertake their tasks securely, trusting that they will follow our policies and procedures, and notifying their internal Data Protection Officer (or equivalent role) if they believe that they have done or seen something which could indicate a personal data breach has taken place. We need to remember that almost every organisation uses third-party suppliers to undertake some form of personal data processing, whether that’s for HR or payroll administration, security checks, accounting purposes, off-site training provision etc. and encompasses the provision of a multitude of outsourced IT services, including cloud services.

It is for each organisation, as data controller, to choose their providers (data processors) who are “demonstrably compliant” with GDPR’s requirements. Addressed within Article 28, this means that we have a clear responsibility to identify and validate the technical and organisational capabilities and security controls of our supply chain, including their abilities to keep personal data securely, and promptly identify and report to us any personal data breaches which may have occurred on their watch. To facilitate the prompt reporting of personal data breaches, they need to be promptly identified: GDPR requires that the data controller makes this notification to the ICO within 72 hours of becoming aware of the breach.

Within UKCloud, our cloud platforms and systems adhere to the robust protective monitoring controls outlined within GPG13 – the “good practice guide” for protective monitoring of ICT systems. By the near real-time automated review of millions of individual events contained within a multitude of log files (e.g. successful and unsuccessful logins, firewall log entries, traffic traversing network boundaries etc.) these can be promptly distilled down to identify activities of interest, which might indicate a personal data breach to our experienced Security Analysts. By providing near real-time visibility of such analysis to our customers, we are well placed to provide them with the fastest possible notifications, supporting them in meeting their own breach reporting obligations to the ICO.

Whilst we’ve invested in the technology and skills to detect out-of-line activities on UKCloud’s platforms, it’s equally important that our cloud customers understand and build similar capabilities inside their respective hosted application environments, and can act upon these results swiftly.

So, we may find ourselves believing that we have encountered a personal data breach. Once we become aware of this, and have undertaken necessary validations to confirm that this is indeed the case, we now have 72 hours to inform the ICO. This can take the form of an initial notification, with more details to follow in phases as our investigation proceeds. The notification should identify whether there are high risks to data subjects, and separate communications to them should be made if this is the case. For low numbers of affected data subjects, individual communications should be issued (e.g. by email, text message or letter), but for larger volumes a press release or clear messages on websites may be more appropriate.

The breach has been detected. The ICO has been notified. The affected data subjects have been informed. Now’s the time to focus on our incident response plan, which should be readily available to assist in managing, controlling and remediating the event, ensuring a permanent resolution which will prevent its future recurrence. This will involve many areas of our organisation: it’s not simply a challenge for the IT department, and will need specialist inputs from senior management, operational teams, legal advisors, risk assessors and media specialists. Remember to keep full records of the investigation and remediation tasks – even if we are not required to report to the ICO or data subjects.

In summary, none of us wants to be the source of a personal data breach. To minimise the risk of such breaches, reduce the impact of associated fines and negative publicity, and maintain the trust and credibility we have with our customers, we must look to maintain confidence in four key areas:

  1. that our personal data processing activities are designed to be secure and resilient
  2. that our supply chain is competent and able to meet its data protection obligations
  3. that we have an ability to promptly detect, validate and report personal data breaches
  4. that our organisation is laser-focused on prompt and effective incident response plans

John Godwin is UKCloud’s Director of Compliance & Information Assurance. As a Certified Data Protection Officer, he is responsible for co-ordinating UKCloud’s preparations for the forthcoming EU General Data Protection Regulation, and is a regular conference and event speaker on information security and data protection matters.

John Godwin Director of Compliance & Information Assurance

John Godwin is UKCloud’s Director of Compliance & Information Assurance. He has responsibility for UKCloud’s portfolio of accreditations and certifications, and as a Certified Data Protection Officer is responsible for UKCloud’s compliance with the EU General Data Protection Regulation. John is a regular conference and event speaker on information security and data protection matters.


Post A Comment