Why it pays to face down your fear of GDPR
Will you, as a researcher, be collecting any information relating to any identified or identifiable living individuals? If the answer is ‘yes’ then you will be processing personal data as part of your project and you will need to consider the issue of data protection.
I’m coming at this topic as someone who’s been involved with the General Data Protection Regulation enough to discuss some of the more common terminology and what you need to do to ensure your project is compliant. However, I’m not an expert, and this area is subject to reams of legislation.
In the UK, this is even more the case since Brexit, as it now has both an EU and a UK GDPR.
Impact assessments
Even after years of increasing regulation, many academics do not realise that they might need to submit a data protection impact assessment. This DPIA helps to ensure that research participants—‘data subjects’ in GDPR-speak—are treated as carefully and responsibly as possible. The data protection team will review the project and data management plans, and may suggest ways to mitigate any risks that researchers might not have considered.
Different organisations will have different policies for when, and whether, a DPIA should be done. My recommendation is to try to do this as early as possible in the application process.
It can be annoying, especially if you don’t even know whether your application will be successful, but it’s better to know sooner rather than later whether you will need costly equipment or if your plans to capture certain data will need a higher level of scrutiny than you were anticipating.
Scrutiny takes time and the longer you give yourself to get this done, the less likely it will be that you need to delay the start of your project.
Anonymise and pseudonymise
In addition to navigating the DPIA, you will want to get to grips with two pairs of words.
The first is ‘anonymise and pseudonymise’. This is all about how difficult (or easy) it might be to identify individuals from the data collected.
In my experience, there is a perception that having to comply with data protection legislation will hamper research. It’s not an entirely unfounded view and there is increasing acknowledgment of this in policy circles.
It is difficult to anonymise your data to GDPR standards. To do so, you would have to make it so that the data subject is no longer identifiable, even by someone who is willing to put a lot of effort into figuring it out. More likely, the data you collect will be pseudonymised.
Pseudonymisation is defined by UK GDPR as occurring when “personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person”.
In short, if your primary dataset has a key that you keep in a locked cabinet, it will be pseudonymous.
Controller and processor
We now come to the second pair of words: ‘controller and processor’. In simplified terms, you are a controller if you are making decisions about which data to collect, the purpose of the data collection and what you plan to do with the data. You are a processor if you are following instructions, you were told which data to collect and you did not decide the purpose of collecting the data.
Some funders think that if they are paying you to do a certain project then this makes them the controller and you the processor by default. But it depends on the circumstances of the project, how much input you have had into the design of the research and what you want to do with the data. The moment you start making decisions, you are not just a processor.
If you are doing a collaborative project with many partners, there may be a combination of controllers and processors, depending on the role each partner plays. Each party will need to be clear on its role and what is required of it under data protection legislation, and the contract will set this out.
For all these questions around GDPR, it is expected that you will know all of the answers because you designed the project, and you know which data you’re collecting and why you’re collecting it. It’s all there in your application.
If you’re thinking about these issues right from the very start, you will find that everything goes much smoother when it’s time we’re ready to set up the contracts and start the research. It might be a pain, but I promise you: it’s a pain that will only get worse the longer you leave it untended.
Stephanie Harris is a contracts manager at City, University of London, writing here in a personal capacity
This is an extract from an article in Research Professional’s Funding Insight service. To subscribe contact sales@researchresearch.com