Abiding by the Data Protection Act

Hi everyone,

I’m Yves from the Oxford Hackspace.

Lately I’ve been working on a fob-based sign-in system for our hackspace. The project is now functional and the only thing left for me to do before going live is to make sure it respects the restrictions set out in the Data Protection Act.

I’ve had a read through of a few online resources about this, and they’re all fairly vague (I assume intentionally). So, I’m wondering how other hackspaces handle this kind of thing.

How do hackspaces go about storing their membership data in a way that is DPA compliant?

How do you make sure member projects used throughout the space (like mine) are DPA compliant? Does it matter if they aren’t?

One point that is annoyingly ambiguous is:

They must make sure the information is not transferred outside the European Economic Area without adequate protection.

How have other hackspaces defined “adequate protection?”

Currently, my system exports a snapshot of the system state to a google doc so that trusted members can use it in case of a fire. This document is most likely hosted (and duplicated) in datacenters around the world. I have limited access to it to specific Google accounts, but how can I know this is “adequate protection?”

I’m curious to hear how other hackspaces and members have tackled this problem.


Reading the details on “security” under the DPA - https://ico.org.uk/for-organisations/guide-to-data-protection/principle-7-security/ - its very much “as much as you see fit based on the type of data”…

For us, our system stores names, emails, addresses and dates of birth… on a system in the space itself, and on backups - the system is only accessible by a small subset of trusted people. For other purposes we export names and emails - for member email messaging and counting purposes - some of that is on google drive with restricted access.

It appears from the docs that adequate protection is what you define it to be…

It appears from the docs that adequate protection is what you define it to be…

That’s pretty much what I thought.

I was talking about this to a couple of people at my hackspace and the idea of encrypting our databases kept coming up. To me, that seemed a bit excessive if access to the database was correctly controlled. Of course data like passwords and credit card numbers need special attention, but for my project I don’t have to deal with those things.

Do other hackspaces encrypt their databases? If so, how do you keep the decryption key safe?

On the servers around the world issue there is the EU safe harbour thing to be aware of.

Makerspace has a server that is secure with the data in it, in principal like any system it could be hacked.

The only way to access member data is via an API with a valid key, and even then the data provided is extremely limited.

Safe harbor was declared invalid by the EUCJ just over a year ago unfortunately.

The DPA is fairly light touch as long as you are sending your data - you are unlikely to be collecting any personal sensitive data.

The new GDPR regulations coming from the EU are more of a worry - I’m currently working through these at work with a hope to understanding how these apply to Hackspace.


I’m much more on the no system is secure side myself and therefore I’d say that any PID beyond first name needs to be secured by at a minimum encryption with a salted hash. Sure, Hackspaces are low volume targets and probably low value too but the principle that no one should have access to PID without a valid reason should still hold

Can you point to an example I plementation, I struggle to understand where a key is kept safe that would mean it couldn’t be copied.

That’s a fair point.
Not really my area of expertise but I’d have thought a 2FA login ought to
be adequate.
The key itself is encrypted and only unlocked once the user is
authenticated. That way, even if the key is copied, the data remains

Hi Yves,

Other people have talked about security quite a bit but nobody has mentioned principle 3 which is arguably the one you should concentrate on first:

“Personal data shall be adequate, relevant and not excessive in relation to the purpose or purposes for which they are processed.”

Many people here are of a technical mindset and the temptation is to construct a database or spreadsheet with as much information in as you can, but you need to step back and carefully justify why you need each and every piece of information you hold.

I’ve seen mention of date of birth and even sexuality and gender in various discussions along the way recently and I’d certainly argue that those could be seen as excessive. Gender and sexuality are interesting things to record for tracking the diversity of your community, but do they need to be personally identifiable or is keeping that data anonymously a better approach? If you’re recording date of birth, is that so that you know a person is over a minimum age, if so is a boolean field to say that the person is over 16 (or whatever) a better way to record the information?

I’d recommend a chat with the Information Commissioners Office if in doubt, the times I’ve had cause to talk to them they have been really nice and helpful. They would much rather advise people before issues than be prosecuting people for data breaches.

Hope that helps.


Hi Ian

Very valid point. And here’s something I pinched from SQLServerCentral.com which could be seen as threats and opportunities…
(I didn’t just grab it because it agrees with my point about needing to secure everything, either. It goes way beyond that).

"The General Data Protection Regulation (GDPR) is soon, in a year’s time, to become law in all EU countries, including the UK. The regulation also applies immediately to organisations based outside the European Union if they collect or process personal data of EU residents. We’re not just talking about potentially embarrassing medical records here. No, personal data includes anything like a name, a home address, purchasing habits, a photo, an email address, bank details, posts on social networking websites, or a computer’s IP address. To use this personal information will require explicit consent, which can be subsequently withdrawn. It can only be retained for a period of time.

"Organisations can’t shrug and say that they delegate the processing of personal information to a third-party. If they use and benefit from the data, they are responsible. They have to show that access to such data is prevented by design. We have to prepare now before it becomes enforceable in May next year. Many existing IT systems will have to be re-engineered before next year.

"Organisations over a certain size whose main activities involve processing operations, and that are operating in Europe will have to appoint Data Protection Officers to ensure that the organisation complies with the legislation. These people will need to be data experts with experience in security and a lot of knowledge about the protection of data, able to sure that IT systems protect data ‘by design and by default’.

“The mood in the USA towards personal privacy is rather different, favouring as it does the rights of the state, as defined in the Patriot Act. However, because of the long-standing international agreements of Safe Harbour and more recently Privacy Shield, the GDPR affects all businesses processing personal data who trade with Europe. The EU has the most progressive laws on data protection, and will determine the data standards of a globalised market, so it looks inevitable that the international standards for handling personal data will derive from the GDPR. Yes, the ramifications of GDPR could easily affect your work.”


Webinar of interest for this Wednesday.


Slides will be made available even if you could not attend so might be worth attending.

Further resources or review of resources:

Shame about the typo in the splash across each page, but looks like a useful list of resources.