GDPR: Ready or Not!

Compared to the Insolvency Rules, getting to grips with the GDPR has felt a lot more painful.  Personally, I have struggled with the GDPR for two reasons: (i) the position of an IP working within a practice and having control over insolvent entities is so clearly a square peg in the GDPR’s round hole; and (ii) for anyone who has been treating personal data with respect already, it seems to be just lots more hassle, simply more documentation of no interest to anyone except the regulators and those who look for causes to complain.

But, if I have not persuaded you already to go off and do something far more interesting instead, here is a summary of an IP’s GDPR to-do list (or, hopefully, a “done” list).  My special thanks go to Jo Harris, who has endured the pain to get the Compliance Alliance’s packs GDPR-ready and whose webinar has informed most of the content of this blog.

(UPDATE 22/05/2018: far more authoritative than our blog is a fantastic FAQs written by the ICAEW and R3 and released just yesterday: https://bit.ly/2x7HPm2.  I think that this article is pretty-much aligned with the FAQs, but the ICAEW does provide more information on their expectations, particularly when taking on an appointment and in notifying creditors of the necessaries.)

  

Privacy Notices

Privacy Notices are probably the most obvious sign that you have prepared for the GDPR world.

Data controllers must provide privacy information to individuals when they collect personal data from them or, if the data is from another source, no later than one month of receipt.  Although the GDPR prescribes a long list of information that must be given, it also states that privacy notices must be concise and easy to understand – if only the GDPR were written so!

To draft a GDPR-compliant privacy notice, you need to have a clear picture of what personal data you hold and what you do with it… in your role as a data controller.

 

Who is a data controller?

The GDPR defines a data controller as:

“the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data; where the purposes and means of such processing are determined by Union or Member State law, the controller or the specific criteria for its nomination may be provided for by Union or Member State law”

Where an IP processes data as an office holder, they are clearly in control.  An IP deals with personal data on creditors, employees, directors, shareholders, debtors (i.e. insolvent ones and those who owe the insolvent), probably also debtors’ family members…  And we’re not just talking about individual creditors etc.: you will also process personal data on staff working within corporate entities, e.g. emails containing names, email addresses and telephone numbers, sufficient to identify the individual.

What about the personal data contained in the insolvent’s books and records?  Does the IP become the data controller for those on appointment?  I have not attended a GDPR-for-IPs event without the case of Re Southern Pacific Personal Loans Limited ([2013] EWHC 2485 (Ch)) being mentioned.  Although of course this was a decision about the application of the Data Protection Act 1998, it has given many people comfort that at least a liquidator is not considered to be the data controller in relation to data processed by the company prior to liquidation.

So, for practical purposes (unless/until it is overturned), it is probably safe to draw a distinction between data processed by the IP and the insolvent’s data that just sits in a storage facility in case it is needed one day.  This fairly clean line probably doesn’t exist however for a trustee in bankruptcy, as the agency relationship is absent.  Also, at what stage does an IP begin “processing” data in their own right: what if you only review some company records in your possession?  What if you hold electronic data on your system, but never use it?

These fuzzy lines aside, how does understanding when we are a data controller help us draft our privacy notices?

 

The legal basis for processing

For the most part, privacy notices are pretty standard text.  But you do need to hang your flag on a mast when it comes to describing your legal basis/bases for processing the data.

Here are the options:

  • the data subject’s consent – not something that we associate with being in office
  • necessary to perform a contract – again, not something for an office holder, but it may be relevant for work we do (i.e. personal data we process) outside a formal appointment
  • necessary for compliance with a legal obligation – yep, this one is clearly relevant to office holders
  • necessary to protect individuals’ vital interests – nope
  • necessary to perform a task in the public interest – I have heard some say this is relevant for office holders, but it seems to have fallen out of favour more recently
  • necessary for legitimate interests – creditors and others have a legitimate interest in keeping informed and engaging in an insolvency process, so this is relevant

So there are at least two legal bases that are relevant to IPs’ work.

 

The purposes of the processing

Your privacy notice also needs to describe the purposes for which you will be processing data.  It is worth remembering that an insolvency practice will process data for a wide range of purposes: not only formal appointments, but also to deliver other services to clients, and you will also hold data for marketing purposes, for running your business…

Therefore, you might want to consider: should you have one privacy notice covering every purpose or do you want several privacy notices?  A third way, which I’ve seen work well for a particularly large accountancy/insolvency practice, is a single privacy notice with links leading to the descriptions of their processing activities relating to different groups of data subjects.

Taking a look at other firms’ privacy notices might also bring to mind other, less obvious, purposes for processing data, such as carrying out AML due diligence, detecting or preventing crime or fraud.

 

What do you do with the privacy notice?

As mentioned at the start, the GDPR puts data controllers under a requirement to provide the privacy information to all data subjects.  This can seem onerous for an IP: do we really need to send a copy of the privacy notice to all individuals whose data we hold and how can we comply with those timescales, especially on existing cases?

There are a couple of ways you can make life much easier for yourself:

  • Put your privacy notice on your website, preferably on a page with a very simple www address, because…
  • Then you can add the link/address to your email footers and letterhead, so that the next time you email or write to an individual, you have brought the privacy notice to their attention.

 

What about existing cases?

Does the GDPR mean that we must have notified every person whose data we hold of our privacy notice by 25 June?  I would like to think that the regulators – the RPBs and the ICO – might be prepared to give us some slack on this requirement.  Would a more manageable approach be to ensure that such notifications are made, say, at the time of the next progress report?

If this is acceptable, then how about the interaction with R1.50?  Where we have already issued to creditors (and members) a notice stating that every other document will be uploaded to our website without further written notice, would this suffice such that we only need to ensure that the website contains the privacy notice or a link to it?  Or, because R1.50 only provides website-only delivery for documents “required to be delivered in the insolvency proceedings”, does this mean that the privacy notice required to be delivered under the GDPR cannot be delivered by website?

Of course, the requirement stretches further than creditors and members.  For some people, you might like to make an extra-special effort to contact them asap to prove compliance with the GDPR, perhaps those who are most likely to complain – bankrupts and other individual debtors, perhaps.

 

What about closed cases?

Under the GDPR, “storage” is a form of processing.  Therefore, IPs will be continuing to “process” personal data long after a case has closed.  Do we need to contact individuals on closed cases?  Isn’t this taking things too far?!

The new Data Protection Act (which is currently still a Bill) may help us (thanks, JN, for highlighting this).  S93(4)(b) states that we need not notify data subjects where it “would be impossible or involve disproportionate effort”.  This must apply to closed cases, surely!

 

Privacy notices: is there more?

Oh yes, indeed!

Another meaty requirement of the GDPR is that data processors’ work must be governed by a contract with the data controller.  What data processors does an IP instruct?  And if someone is instructing an IP, does this need to be governed by a contract?

 

Who is a data processor?

The GDPR’s definition of a data processor is someone who “processes personal data on behalf of the controller”.  But a data processor’s activities may mean that they become a controller in their own right.  As I set out above, according to the GDPR’s definition, a data controller determines the purposes and means of processing data.  So logically, if someone has no control over either the purposes and/or the means of processing the data, they must be a processor, right?  For example, you instruct a debt collector to use debtors’ personal data solely to pursue debts – this sounds like a data processor, doesn’t it?

So who might an IP instruct that is not a data processor?  Surely every instruction defines at least the purposes of processing data, doesn’t it?

The ICO has provided guidance on the distinction between processors and controllers (https://ico.org.uk/media/for-organisations/documents/1546/data-controllers-and-data-processors-dp-guidance.pdf), which, although it was seemingly published in 2014, we understand is still considered relevant by the ICO for the post-GDPR world.

Paragraph 45 is interesting: “Where specialist service providers are processing data in accordance with their own professional obligations they will always be acting as the data controller”.  This is written in the context of an accountant, who will have obligations on detecting malpractice.  The guidance similarly singles out solicitors who “determine the manner in which the personal data obtained from the [client] will be processed” (paragraph 44).

 

And IPs?

Of course, I wouldn’t expect the ICO to mention IPs in their guidance (they don’t).  But I think the ICO’s guidance leads to the logical conclusion that usually IPs/insolvency practices will become data controllers in their own right when processing data on behalf of a client, e.g. when they’re instructed to help put a company into CVL.

 

Controller-processor contracts

But for anyone whom we instruct who is a data processor, we need to ensure that a GDPR-compliant contract is in place with them.  And even though you may personally be acting as agent of a company that continues to trade post-appointment, you will want to ensure that the company trades in a compliant fashion with appropriate contracts in place with their suppliers/service-providers… although remember that it’s only where the supplier/service-provider is processing personal data.

The GDPR sets out what must be included in such a contract and model clauses are widely available (although of course you may like to engage a solicitor to help).

 

Data sharing agreements

Although not mandatory, you may want to consider entering into data sharing agreements with parties who you instruct who are data controllers in their own right – the ICO guidance recommends this where you are sharing large-scale or particularly risky data.

As an IP receiving instructions, you are unlikely to want to volunteer a data sharing agreement.  However, you should amend your engagement letters, not only to refer to your privacy notice, but also to confirm your position as a data controller and remind the client of the need to comply with the GDPR and DPA.  ICAS has suggested some appropriate wording at: https://www.icas.com/regulation/preparing-for-gdpr.

 

Fuzzy lines

I confess to remaining confused about the boundary between controllers and processors.  After all, wouldn’t following the GDPR definitions and ICO guidance lead us to a different conclusion from that arising from Re Southern Pacific Personal Loans Limited?  Doesn’t an IP store company records in accordance with their own obligations and doesn’t the IP decide the purposes and means of processing that data?  If so, why are they considered only a data processor?

In addition, different instructions may lead to different levels of control by the third party.  For example, on one case we may ask an agent simply to help us return items to their owners, but on another case the agent may be managing a marketing and sale process, dealing with RoT claims, wiping hardware clean…

Where these fuzzy lines exist, would it be an idea to engage with third parties via a catch-all controller-processor/data-sharing agreement?

 

Managing instructions

If you haven’t already set up a system, perhaps you might start a central register to help you record who has signed up an agreement.  Then, whenever you come to instruct a third party who will be processing personal data provided by you, you can check whether they have already signed up and, if not, you can set the ball rolling.

 

Ok, is that everything?

Nope.  There’s a whole host of additional items on the to-do list, including:

  • If you haven’t already got them, generate policies and procedures to cover areas such as data security, retention, dealing with breaches and subject access requests;
  • Before processing data on a new engagement/appointment, assess the risks associated with the proposed processing, and keep it under review during the engagement (yep, another checklist!); and
  • For each engagement/appointment, document the data held and the reasons why it is held – the ICO has produced 30-column wide spreadsheet for each data controller (and another one for a processor), so admittedly it is stupidly cumbersome for each case, but once completed for one case, there will be little variation needed for the next. But of course, it is worth giving every case a bit of thought, just in case there are some unusual considerations arising from, e.g., a novel business or an entity holding data in different countries.

Certain other aspects of our insolvency work require careful attention:

  • On (or preferably before) appointment, we will need to gather information on what data the insolvent holds and where/how it is stored and accessed;
  • If we are contemplating trading-on, we will need to review carefully the business’ data processing practices and documentation and identify whether any changes need to be made to bring them into line with the GDPR;
  • We should perhaps take more care in deciding what data we need to collect post-appointment and what happens to any data that we choose not to collect (also having regard, of course, to the recent Dear IP on collecting books and records);
  • Although generally databases and customer lists can continue to be sold in an insolvency process, we can expect to be asked more questions by potential purchasers about the insolvent’s data processing (will sale prices decrease and will sales to unconnected parties be less common as a consequence?) and some additional clauses will be required in agreements; and
  • We will want to have a good understanding – and ensure that staff have also – of our obligations on identifying a data breach.

Jo’s webinar helps to explain all these requirements and more.

 

Will it all become second nature?

It is a shame that the regulatory current seems to flow to ever more requirements for documentation and disclosure.  The regulatory burden never seems to lighten up, but personally I struggle to see how business or the economy is any better for it.

There remain a number of unanswered questions, some of which I’ve mentioned above, about how the GDPR works practically for IPs.  I’m sure that over time most of these will be resolved, hopefully with pragmatic solutions acceptable to the regulators.  One day, perhaps GDPR-compliance will become second nature.