Blog

My mailbox doth overflow — with GDPR consent-seeking emails pleading for me to “opt back in” to continue receiving whatever marketing is on offer. In some cases I do not remember signing up to the service in the first place. And in at least two cases I know I never did (notably the recruitment agency which has scraped an email address only published on my curriculum vitae, and the real estate agency for exclusive property in London).

All that email activity seems to have triggered a few customers to get in touch about GDPR. Some have asked that we tell them what to do for GDPR, and I’ve had to explain that as their supplier (in GDPR parlance their data processor) it is not our responsibility to tell them how to control their personally identifiable data. One of the key themes in GDPR is that of responsibility, and making it clear who in the chain of controller, processor and any sub-processors has responsibility for what. Good information governance (and indeed project management) says that these must come from the top: the customer.

As an Internet services provider we are unlikely to have sufficient knowledge about — for example — the range of data a customer might gather, what its lifecycle might be, how long that data should be retained. These would all vary based on the nature of that organisation, what legitimate uses there are for that information, and potentially industry sector or regulatory retention standards; and plenty more besides. We probably do not process all the data for which a customer is the controller, given they are likely to have a finance system offered by a third party cloud provider, or a spreadsheet of staff in the office manager’s filestore.

While pushing back would be an easy response, it is not particularly helpful to our customers. Some of them have struggled to understand the jargon-heavy guides to GDPR. Some have been stressed out by the headline-grabbing fines that non-compliance would attract. Customers trust us to look after their technical requirements, but are now worried they have to understand cryptography cipher-suites and roll out multifactor authentication with centralised auditing across their organisation’s IT infrastructure (two laptops). How can we help?

Earlier today, following a discussion with one of our larger media and PR agency clients, I finished writing up our GDPR Position Statement. In this document we outline what we believe our responsibilities to our data controller (and processor) customers might be. This should be sufficient for the vast majority of our customers. It explains how our standard contract already includes many GDPR themes. We originally wrote those terms with the Data Protection Act 1998 in mind, and GDPR is more of an evolution of that legislation.

Our position statement also explains some of the technical and organisation measures we have in place to help safeguard customers’ data. It explains where and how we use encryption, how we manage physical security, and how we physically secure our infrastructure. I hope that it serves as a starting point for any of our customers who feel they need to update contracts or formalise those responsibilities in any updated agreements. It may also serve as a starting point for thinking about any wider issues within our customers’ organisations, or data for which Faelix is not the processor.

All relationships are based on a foundation of trust. Our position statement (as a data processor to data controllers) aspires to echo the respect, honesty and openness that GDPR requires that data controllers give to data subjects. I am optimistic that this will help our customers to forge stronger relationships with their customers — because Faelix believes that a “privacy first” approach can benefit everybody: data subject, controller, and processor alike.