Viewing entries tagged

GDPR: making our customers "compliant by default"

A huge thanks to Rebecca, our Privacy Sheriff.

A huge thanks to Rebecca, our Privacy Sheriff.

Since May of this year, our self-titled "Privacy Sheriff", Rebecca, has been cracking the whip on our efforts to understand and prepare for the General Data Protection Regulation (GDPR), which takes effect on 25th May 2018.

We've undertaken an information audit (an ongoing process), identified steps that we must take as an organisation to protect our data and that of own data subjects, and have made ourselves battle-ready. We have a few feet to cover before May but we're proud to report that Solomon, as an organisation, will meet all the demands of the new data protection laws.

That work covers our role as a Data Processor; a party who acts on data on behalf of our customers. But what about our customers, as owners of the data held in Solomon; what the Information Commissioner calls Data Controllers

On the one hand, our BID customers are in a good position because they have a "legitimate interests" in processing much of the data they hold. Going a step further, we would argue that there is a "legal obligation" to hold liable party information, to ensure a Ballot/Renewal is legitimate. When it comes to some other points of data that is personally identifiable - personal information about individuals the BID team communicate with day-to-day - GDRP includes some new rights for data subjects that BIDs, as Data Controllers, must take account of.

Today we are announcing that we plan to spend the first few months of 2018 adding some new features to Solomon that will provide tools to address these new rights, and to make all our customers "compliant by default."

Undertaking this work will mean pressing pause on the development of some new features but this is a major shift in the law that affects all BIDs, regardless of size and shape, and we what to do everything we can to help.

Three key areas require our attention:

  1. Consent and the right to unsubscribe: every data subject must give consent for their data to be processed, including email addresses used for electronic communication. Data Controllers must receive "positive, freely given, specific, informed and unambiguous" consent for their data to be processed. Controllers need to say how long they will hold data for, what they will do with the data, have clear procedures for deleting the data once any deadline passes, and outline the subject's rights. We want Solomon to incorporate a set of tools for managing consents.

  2. The right to access: upon request, any data subject can ask a Data Controller to provide, free of charge and in a commonly used electronic format, copies of any data held about that subject. We want Solomon to incorporate a "one-click" solution for our customers.

  3. The right to be forgotten: every data subject has the right to request that the Controller erase any personal data held concerning them. We want Solomon to incorporate tools that allow you to flag personally identifiable data, and destroy it on-demand. 

GDPR represents the biggest change in data protection rules in two decades. Delivering these new features will require a huge amount of effort from our team but it's essential to us that Solomon customers are compliant by default.

335 days to GDPR: the story so far

"29-page documents" have become something of a running joke in our office as we've waded through guidance emanating from the Information Commissioner's Office (ICO), trying to wrap our heads around the General Data Protection Regulation (GDPR).

We are 335 days out from its introduction and awareness is turning into a mild panic: "When the hell is something personal data, and when is it not?" "Really, I can't legally market to someone who gave me their business card at a trade event?" "What in Solomon's name is a 'double opt-in'?" 

Answers to the above and other questions will follow in the coming weeks. In the meantime, here's an update on our progress working through the 12 Steps of GDPR preparation suggested by the ICO, along with some tips that might help to save you time. 

Step 1, Awareness, is all about who needs to know and as far as we were concerned that's everyone in our team. In one way or another, everyone at Solomon is a "decision maker" and someone that needs to be "aware that the law is changing" and "to appreciate the impact this is likely to have."

Rebecca, who has been blessed(?) with the responsibility for leading us through this process prepared a summary of what the GDPR is and how it's likely to affect our people, our technology, and our customers. She presented this to the team along with a flow-chart describing the 12 steps and how we will approach them.

We used Step 1 as an opportunity to check our compliance under the current Data Protection Act arrangement. We thought it would be interesting to share one of the documents Rebecca prepared, which outlines the current responsibilities of Data Controllers (if you are a BID then you almost certainly are one) with regards to their use of cloud computing services like Solomon. I'm delighted to say that Solomon passes the test. If you are reading this and you are not a Solomon customer then I hope the document will provide some talking points you can use with your current supplier to ensure you're compliant too.

Step 2, Information you hold, is fundamental. The remaining 10 steps are pretty dependant on  getting this bit right. Here's what the ICO says:

You should document what personal data you hold, where it came from and who you share it with. You may need to organise an information audit.

We headed right over to the deep end and organised an information audit. We started this by defining some questions we wanted the audit to answer. Here's the list:

  1. Where is our electronic information stored and processed?
  2. What personally identifiable information do we hold in each of those places?
  3. What is the origin of that information?
  4. Why do we store that information - what's the business case?
  5. Is there a legal basis for storing that information?
  6. What is our responsibility for the information we hold - are we a Controller or a Processor?
  7. What are its "exit points" - when, how and why is it shared outside of our organisation?
  8. For each type of information we hold, how do we record consent from the data subject?
  9. How secure are each of the places where we store data - what are the risks of a breach?
  10. What steps are necessary to eliminate or mitigate those risks, and to identify and report breaches?

A tip from us is to start by getting your team in one room and generating a list of all the software and hardware everybody uses. Including computers, phones, external drives, cloud software tools and our own technologies, we identified 29 data stores that need auditing. 

The next time we post our progress report, we will have answered all of the questions listed above. We hope to have built a comprehensive picture of what we hold and why and will be armed with what we need to define processes and policies fit for the GDRP.

If you have any questions about what we've learned please feel free to contact me directly: If you haven't done so already, please subscribe to our mailing list and we'll send future updates straight to your inbox.