GDPR for Sole Traders – Controllers, Processors and ICO Registration

This entry is part 4 of 5 in the series GDPR for Sole Traders

This morning my other half mentioned a concern that was popping up about ICO registration fees for sole traders working with personal data under GDPR. Since there seems to be a lot of confusion (including from the ICO phone staff themselves who have been reported as giving varying answers to the same people) I thought I’d try and help. All the usual provisos apply, and I am working only from the information published by the ICO – simply summarising it and cutting out some of the parts I don’t think are relevant.

First of all, the way that the ICO is funded and the requirements for notification/registration have changed. I won’t go into the old rules, but the new ones are quite simple – there is now a legal requirement for data controllers to pay a data protection fee to the ICO. These fees are not unreasonable, running between £40 to £2900 per year depending on size and turnover. You can also get a £5 discount for paying by direct debit. Data processors do not need to pay this fee. There are certain other exemptions, but frankly they really only complicate the issue for most sole traders. I will talk about them shortly, but the core issue is that difference between controllers and processors – which is fundamentally quite simple but poorly explained.

The definition is this – a data controller determines the purposes for which data is processed. For most sole traders and small businesses who work with personal data, this will not be the case – in the vast majority of cases you will be fulfilling a commission or contract for a client, which means that you are not determining the purpose of processing any data they have passed you. You will still have the same duty to protect that data under the GDPR of course, but are not the data controller and so do not have to pay the data protection fee to the ICO. If, however, you are gathering the data, determining the purposes of processing and analysis, or anything similar then you will either need to pay the fee or rely on one of the other exemptions.

A data processor meanwhile may process the data, but does not decide the purposes of processing. As an example – a translator asked to translate a CV by an individual or a company is the data processor, while the client would be the data controller. A data processor does not have to pay the ICO data protection fee.

What if I am a data controller?

If you are a data controller there are certain exemptions which might apply, for example if your only purpose in processing data is staff administration you are exempt from the fee. In general though you will need to pay it – the exemptions are clear and narrow in terms of the data you can process and the purposes of processing it. Unless everything you process (where you are defining the purposes of processing it, not a client) falls under the exemptions then you will need to pay the fee.

The exemptions are listed, clearly, in the ICO’s own literature:

  • Staff administration
  • Advertising, marketing and public relations
  • Accounts and records
  • Not-for-profit purposes
  • Personal, family or household affairs
  • Maintaining a public register
  • Judicial functions
  • Processing personal information without an automated system such as a computer

Take special note of that last one – the definition the ICO is using here of an automated system is different to the GDPR’s definition of automated processing. In essence, if you are using any system with any level of automation for any point in the processing of data, then you do not fall under this exemption. Hopefully the others and the reasons for them are clear.

As always, feel free to send me any questions either here or on Twitter, and hopefully the picture is a little clearer for some of you now.

Security and Compliance

A common error is to think that because a system, solution, process, company, person, or other entity is not compliant with a particular standard, it’s insecure. It’s not a grievous error, and is an understandable one to make which doesn’t cause any harm (except occasionally causing more investment in security, which is usually a good thing anyway).

The flip side of this is where the problem comes in – when the assumption is made that because an entity is compliant with a particular standard or standards it is secure.

The reason that people often fall into this error is because compliance is straight-forward (not necessarily easy): it’s a very binary set of conditions to meet in order to be compliant, and if you fail them you’re not compliant. It’s a very easy idea to understand, and quite comforting to conflate with the idea of being secure – because compliance is achievable. Security is not.

In a similar way to illness in people, compliance is the regular checkup with the doctor who confirms that you’re in a fine state of health, because you don’t have any symptoms on the checklist. A year later the heart attack hits, because not only were the predictive symptoms not on the list, but the doctor’s reassuring words convinced the patient they could be a little lazier and put less work into their fitness.

It isn’t that compliance and standards aren’t important, they are, very much so. It’s that they simply should not be the one measuring point used to determine whether or not something is secure. In fact they shouldn’t be used to determine whether something is secure at all. At most a few days after a standard is written, it’ll have sections that are out of date. Security moves fast, and standards bodies have no real way to keep up without moving to a living standards model – which would be a completely different discussion.

Security is an aspiration, not a goal that can be reached through checklists. The checklists help, but the important aspects of genuinely continuously improving security are a company culture which takes security seriously, security subject matter experts always looking to make justified improvements to reduce risk, a high value placed on using actionable threat intelligence to anticipate and prevent incidents, and instilling a culture of security knowledge, engagement and awareness throughout the entirety of an organisation.

Or to sum it all up with a nice little aphorism, we must be careful not to confuse the map for the territory.