The following is a list of frequently asked questions from FGB researchers on the topics of research data management (RDM), privacy (in particular, with regards to the European General Data Protection Regulation (GDPR)) and security requirements at the faculty and the VU. This list will be updated as regularly as possible as new developments are made, as new tools become available or as policies, guidelines, and other rules change.
This question is difficult to generalize to all situations because it varies per study as to what forms, approvals and other requirements are necessary. However, there are some general things to be aware of. All new research projects at the faculty for which external funding is being requested or has been granted, require a data management plan (DMP). For information on DMPs see the question I need to write a data management plan (DMP) to get funding for my research. How can I do this? Additionally, if you are using data about people (which is most of the research at FGB) you may need to complete a DPIA. See Do I need to complete a data protection impact assessment (DPIA) for more information about DPIAs and when they should be carried out.
While working on a DMP and/or DPIA, you will need to determine where you should store your data and, if applicable, how you can safely share data with others. For information on where to safely store your data see the question How do I know if I am storing my data in the correct location?. This question will also answer some questions about data sharing, but you can also find information about safe data sharing in the question I want to e-mail data to my colleague/student. How can I do this?.
If in your DPIA or DMP you determine that multiple third parties ( i.e. companies or institutions outside the VU) will need to have access or control over any of the data in your research, then it's important to determine whether an agreement needs to be signed with the other parties and if so, what type. See the questions:
Additionally, you need to determine whether ethical approval is required for your research. If you are conducting medical research, you should determine whether your research must be approved by an METC, which is an ethical committee for research that falls under the WMO law. If your research does not need to be reviewed by an METC, it is strongly advised that you submit your research to FGB Scientific and Ethical Review Committee (VCWE). This process is voluntary, but it ensures that you are following all ethical requirements. If you are uncertain as to whether you should submit your research to this Ethical Committe, contact the VCWE for advice. Also, be aware that the current informed consent and information letter templates on the VCWE page do not yet meet all GDPR requirements. Underneath these templates on the VCWE webpage you will find a GDPR checklist for informed consent forms and information letters, which will help you to ensure that you meet all GDPR requirements in these forms and letters.
The various issues discussed here need to be addressed before data collection begins and the sooner the better because every process above takes time. Note that if you are thinking about hiring a third party for technical solutions, e.g. for app development or data collection software, check first with the faculty's Technical Support (TO3) department as to whether they can develop an in-house solution. This can still take time and has costs associated with it, but it will help to avoid some of the legal and privacy issues that would otherwise need to be sorted out if you were to hire a third party. As always, contact the Technical Support department as early as possible for advice.
Finally, prior to submitting an application for research funding it is important to consider the costs of your planned research project. Information on data storage costs can be found under the question How much does data storage at the VU cost?. You should also consider the costs of hiring a third party for technical solutions or the costs of an in-house solution developed by the faculty's Technical Support department. Any of the issues discussed above that don't have to do with the costs of your research can be addressed after you receive a grant (although this may depend on the grant provider), but these other issues should, of course, still be dealt with well before you begin data collection.
Basically, privacy is about the rights of and risks for people whose data you are collecting, using and analysing. It doesn't matter whether data was directly collected from research participants or indirectly obtained from another institution; if data are about individual people and the data are not anonymous, then it is necessary to protect the data to protect the privacy of the individuals. (For more information on what is and isn't anonymous data, see the question The GDPR only applies to personal data, but my data are anonymous. Why do I have to worry about the GDPR?).
Security has more to do with risks for institutions. Privacy is an aspect of this: if we don't sufficiently protect the privacy of people whose data we are using, we can lose the trust of the population, especially of future research participants, which could make it even more difficult to recruit research subjects. In addition to these privacy aspects, security also addresses the risks related to whether data become unavailable, lost or contain incorrect information. We also need to consider whether the data need to handled confidentially; this is not just important for privacy, but also when we are working with data that contains confidential information such as intellectual property data or business secrets. If third parties expect us to handle data c onfidentially and we don't, those parties can lose trust in us and will be unwilling to work with us again in the future.
There is an important distinction that needs to be made: data that follow the FAIR-principles are not the same as open data, nor it is a requirement of the FAIR-principles that data be openly and publicly accessible to everyone in the world, whereas that is a requirement of Open Data. Data are only allowed to be completely open and accessible, without restriction, if:
Firstly, data must be archived in a VU archive (see the question How can I meet my archiving requirements? for information on how to archive your data). It is not currently possible to archive data that must be protected under the GDPR in any external archives, such as DANS or OSF, because the VU does not have agreements in place with these organizations; you are still welcome to register information about your research data in external archives just not the data itself. You can also store research scripts/code/syntaxes in these external archives as long as there isn't any confidential information in the code (also make sure to remove any absolute directory paths, e.g. "/home/myresearch/data/analysis/", in the code you openly share as this information can be a security risk). Make sure to stay apprised of research support developments at the VU, because storage of research data in external archives will be an option in the near future.
Next, you will need to plan ahead for data sharing and accessibility by obtaining, whenever possible, consent from your participants for data sharing. (Note: if you did not obtain consent for this purpose and it is no longer possible to obtain consent from your participants, it may still be possible to share the data with others without consent, but first check with the FGB Research Data Officer to see whether this is allowed). When obtaining consent from participants for data sharing make sure to:
If you plan to share the data with third parties outside of the EU/EEA, where the GDPR does not apply, inform participants of this fact. In this case also make sure to inform participants that the data may not be protected to the same level that they are under the GPDR because every country has their own rules, but that we will require all third parties using the data to have sufficient security measures.
NOTE: This does not mean that you are asking for consent from participants to share the data outside the EU/EEA, because meeting the GDPR requirements to obtain consent for this purpose is almost impossible. Instead, you are meeting your obligation to fully inform participants about their data and where it may end up. The burden still falls to the research institution to ensure that the data are sufficiently protected when shared outside the EU/EEA. For more infomration on what is required for sharing data outside the EU/EEA see the question What do I do if I plan to share research data outside of the EU/EEA?
For additional information on the FAIR-principles and how to apply them to your data in practice (whether or not the GDPR applies to your data) see the question What are the FAIR-principles? How can I apply them in my work at the VU?.
You can find DMP templates from the most common research grant providers here under "Forms and Templates". The VU also provides a tool called DMPonline, which includes these funder templates as well as a VU specific template if you don't need to use a template from a specific grant provider. If you wish to make use fo the VU DMP template in DMPonline, click on the "Create Plan" button, and then don't select any specific funder.
If you need advice on your DMP, you can contact the FGB Research Data Officer via the e-mail firstname.lastname@example.org. If you are using DMPonline, you can also share your DMP with the FGB Research Data Officer for feedback, by adding her as a read-only collaborator under the "Share" tab. Note: Please use the personal e-mail email@example.com of the FGB Research Data Officer if sharing your DMP through DMPonline; the collaboration tooling unfortunately does not recognize functional e-mail accounts. Also make sure to send a complete version of your DMP to the FGB Research Data Officer. This information will be used for the creation a processing register which is required by the GDPR.
Please note that sometimes what is required in a grant provider's DMP template is not all that meaningful to how you will manage your data during your research; the focus of these templates tends to be on what you will do with your data once your research is complete, as well as what the data management activities will cost. While, it's important to know how much data management will cost so that this can be budgeted for, it is recommended that after you've received a grant, you develop your DMP further with a focus on how you will specifically collect, transport, clean, store, document, organize and analyse your data. The VU DMP template gives more insight into these phases of research than the funder templates, so it is advised to take the work you've already done in the funder template and build on that in a DMP using the VU template. This is purely a recommendation and you don't need to resubmit your DMP for review after you've done this; the purpose of these extra steps is simply to help you think about and plan ahead for how you will deal with your research data so that you can avoid problems and ensure the quality of your data. It will also help if you are working in a research team because then everyone will know the correct procedures to follow.
For the purposes of your DMP, it is generally sufficent just to report which generic metadata standard you will use to describe your data and research project. CERIF, DataCite and Dublin Core are all good metadata standards that are frequently used to create generic metadata. Because it's VU policy to register all archived datasets in PURE, which uses CERIF, you can report in your DMP that you will use, at a minimum, the CERIF metadata standard. If you plan to archive your data in a trusted repository, the repository may require that you use a specific metadata standard that you can also report in the DMP. Additionally, if your research involves surveys, you can report in your DMP that you'll use the discipline-specific Data Documentation Initiative(DDI) metadata standard.
If you look up information about metadata standards, you will see a lot of information about machine-readable formats. These formatted metadata are usually created when you fill in a form about your data. For example, when you register your dataset in PURE, structured CERIF metadata is created behind the scenes. That means for your generic metadata, the most important thing you should do is find out what information you will need to report for a certain metadata standard and record that information during your research, even in a simple text file. Then you will have that information on hand when you need to report it later on. For more information on recording metadata, including templates for making your own machine-readable metadata, see this page from the CESSDA Research Data Management tutorial. For your discipline-specific metadata, if you have structured data and are using a codebook to describe all of your variables, you can try making a DDI codebook which can be read by both people and machines.
In addition to metadata standards, you may be asked in your DMP about what ontologies, terminologies and/or controlled vocabularies you will use. There is a lot of overlap between these topics and metadata standards and some of the concepts are quite complex. Ontologies have to do more with taking the information reported in a metadata standard and making that information understandable to machines. Most of the work happens behind the scenes, so unless you are being explicitly asked to figure out ontologies, don't worry too much about that concept. What you can report in your DMP are any standards for terminology or controlled vocabulary you plan to use. You may already apply the concept of controlled vocabularies in your research, e.g. in a survey where only a specific set of answers are allowed for questions about ethnicity, highest level of education or language proficiency. Something that will make your data more understandable to others is if you aim to use terminology and controlled vocabularies that are (inter)nationally agreed upon and well recognized in your discipline, rather than generating new vocabularies and terminolgy just for your research.
You can find information on VUnet about data storage costs. You will need to determine the costs of storage for both during and after your research. Although it's not explicitly stated in the overview of storage costs after research, the faculty will cover the costs for storing data after research for up to 50 GB of data.
The FGB research data management framework has been in place since February 1, 2019, and one of the requirements of this framework is that if a scientific article is approved for publication, an archiving package must be submitted to an appropriate archive as soon as the manuscript has been approved for publication. These guidelines provide extensive information about making an archiving package and what your reponsibilities regarding archiving are. There is a lot text in these guidelines, so it's recommended to at a minimum review the following sections to learn about what you need to do when archiving data:
Every department has a paper archive and you can contact your department's secretaries to get access to these archives for your paper data.
As to whether you can destroy original papers after they've been scanned, at the moment it is not allowed to destroy any original paper data after it has been digitized. For researchers doing medical research that needs to meet WMO and/or Good Clinical Practice requirements, original paper data can never be destroyed because the Health and Youth Care Inspectorate (Inspectie Gezondheidszorg en Jeugd) requires that all original paper data created during these types of research be saved for the entire post-research storage term (usually 15 years). For all other types of research, the VU is validating methods for paper digitization; these methods have yet to be approved and until that is the case, even for non-WMO research, it is not allowed to destroy any original paper data; these papers must be archived for as long as any of your digital data are archived. This may change in the future for non-WMO research, so stay apprised of new developments.
The FAIR-principles were developed to give structure and guidance in how to achieve good data management, especially for data that will be reused in the future (by you, your research team, or other third parties). There is no requirement that FAIR-data be made publicly available, a.k.a. open. Additionally, just because a dataset is openly available, doesn't mean that it is FAIR. There are many datasets publicly available right now that are not reusable because there is insufficient documentation about the data to be able to fully understand, interpret and use that data.
The F in FAIR refers to findable data. This means that an individual can find the right dataset for their needs and purposes. At the VU, this aspect needs further development, but currently you can make your datasets findable by registering your archived datasets in PURE. You can also contact the administrator for PURE and inform them of your archived dataset so that they can register it in PURE for you. You should do this, even if you've registered information about your dataset on another catalog such as OSF, because the VU is better able to monitor and report on data production activities at our institution if all datasets are reported in PURE. Another tip, that isn't specifically discussed by the FAIR-principles, is to strive to make your data findable to you and your research team by using logical file structures and naming conventions for your datasets, scripts and documentation. This data management tutorial provides some really useful tips for how to organize your work, name your files and structure your folders.
The A in FAIR refers to accessible data. This term leads to a lot of confusion; it does NOT mean that your data must be publicly accessible. It means that there needs to be clear documentation regarding how the data can be accessed, if appropriate. See the question How can I meet the FAIR-principes/Open Data requirements if my data are subject to the GDPR and therefore I'm not allowed to share them? above for more information about what needs to be considered so that data can be appropriately shared, especially if those data fall under the purview of the GDPR privacy law.
The I in FAIR means data and metadata (data about data) should be Interoperable. This word is pretty new for a lot of people (even native English speakers). What it basically means is that you should have metadata that describes your research data in a standard fashion so that others can understand your data and reuse it. See the question I'm writing a data management plan (DMP) and the template is asking about which metadata standards, metadata schema, ontologies, terminologies and controlled vocabulary I will use. What does this mean? for more information about metadata. In addition to creating metadata about your research data, one way to help you meet this "interoperability" requirement is to make use of open-source software (e.g. R) and data formats (e.g. csv, txt) as much as possible. If someone needs to use special software that must be purchased before they can open and use your data, then the data are less readily interoperable. Additional infrastructure at the VU is being developed to support researchers in meeting the Interoperability requirement, so don't worry too much about it at the moment. For now, just make sure to write a data management plan and to keep good documentation records about your data, for example, by:
Finally, the R in FAIR means reusable. In simple terms, it's a summary of the F, A, I aspects of the FAIR-principles: if you meet those requirements, your data should be reusable. There are some more details that apply here, but those will be explained as the FAIR-data infrastructure at the VU develops.
One final important point. Making your data FAIR does not guarantee that your data are of a high quality. Following the FAIR principles only ensures that data can be reused by others. The best way to ensure data quality is to take the time to do good data management planning before starting your research. Take the time to think about which variables are necessary to answer your research question and whether the planned methods of collecting data for these variables could lead to unreliable results. For example, if you are creating a question in a questionnaire that contains both open text fields (e.g. "other, namely", "Comments") alongside questions with pre-defined answers, consider whether there is a risk of collecting conflicting information. For example, a participant could answer the multiple choice question one way, but the additional information that they enter in the text field contradicts the original answer. There is no one perfect way to deal with this kind of issue; it ultimately depends on what information you need to answer your research question. But if you plan ahead for these kinds of issues, you can choose to avoid unnecessary open text fields, thus avoiding potentially contradicting information, or you can develop a data cleaning protocol for managing these issues as they arise so that all members of your research team correct these contradictions in a consistent manner. And then, of course, any data cleaning should be carried out using a script/syntax or reported in a logbook so that others who may need to verify your findings know exactly how you handled such issues. If there is no record of why and how data were cleaned and changed in a certain way to manage potential issues like contradicting answers, it could look like you were fudging your data, which you obviously don't want someone to think!
The VU is working on solutions for this. Unfortunately at the moment, the VU does not have a processing agreement with any external archive (neither DANS nor OSF), so if your data are protected by the GDPR, they cannot be stored in these external archives. See the question How can I meet the FAIR-principes/Open Data requirements if my data are subject to the GDPR and therefore I'm not allowed to share them? for details on where to store your data as well as what aspects need to addressed and considered when planning on sharing datasets that are protected by the GDPR. The plans you develop and document will help to inform the funder or journal regarding the processes you will have in place for making the data accessible to others. Also, See the question What are the FAIR-principles? How can I apply them in my work at the VU? about how you can make your data "Findable" under current VU requirements. By following these steps, you can demonstrate to the funder or journal how your data can be found by other users.
Good research data management not only helps a research project run more smoothly, it can result in higher quality data and improve the validity and reproducibility of your study results. There have been cases where published studies have been retracted because the variables used in the analysis were mislabeled, leading to completely invalid and misleading results. Clear documentation could have helped to avoid this. Clear documentation also makes your data more understandable to yourself, your internal research team and any future users of the data.
Planning ahead with research data management helps you to ensure the privacy and security of your research data; for example, you may need to plan out a good method for collecting data outside the VU. Writing this down in a data management plan gives everyone in your research team a clear understanding of what their responsibilities are and shows any data protection authorities that you’ve considered the risks and taken appropriate and strategic measures to minimize these risks.
Data management planning can also help minimize the amount of work required to clean your data; for example, by building validation checks into your data entry forms, you prevent impossible values (e.g. age of 200) from being entered. Additionally, if you will be using questionnaires in your research and you take the time during data management planning to think about the structure of your questionnaire, you can determine where and when open text fields are absolutely necessary, minimizing the amount of text data that will need to be recoded into categorical data during data processing.
Finally, data management planning helps with preparing for archiving and publishing of research data. Data archiving after an article is published is a requirement of the VSNU Code of Conduct for Research Integrity. There have been numerous cases around the world where research publications have been retracted because the original data were not findable, meaning that the validity of the research findings could not be confirmed. Additionally, data should not only be archived to allow for verification of research findings, but also described clearly and effectively through documentation and metadata so that others who may need to check the data can fully understand the data and interpret them. Archiving takes a lot of work, but the stress of archiving can be reduced if you plan ahead for it during your data management planning (by thinking ahead about what parts of your research need to be archived, what documentation is necessary to understand the data and which archiving location should be used.)
These are just a few examples of how research data management plays a role in how smoothly your research project will run. It’s not necessary to know all of the details about data management at the start of your research, but it is important to document what is known at the start of a project and to regularly review and update the data management plan as more information becomes available.
You can find links to additional information about research data management in this document .
This document provides a summary of what the GDPR means for you as a researcher.
This is a complex issue. The GDPR has broadened the definition of personal data to: “any information relating to an identified or identifiable natural person; an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person”. It is the indirect identification of individuals that makes it difficult to say with certainty that data about people are anonymous because through the combination of several indirect identifiers or by coupling these identifiers with publicly available data a person could actually be quite easily identified. In a world of Big Data, AI and learning algorithms it's almost never possible to 100% guarantee anonimity when data about people are collected. Additionally the rules that the Dutch Data Protection Authority applies when considering if data are anonymous are quite strict. For data about people to be anonymous, the following three conditions must all apply:
Because of these very strict rules, the faculty advises all researchers using data about humans to treat such data as personal data under the GDPR. This means that all data about people should be protected with at least some security measures such as those suggested in this guide. Lower risk data (e.g. benign information about healthy adults) don't require as many or as strict security measures, but at a minimum these data should be saved in a pseudonymized manner (i.e. no names and contact information stored in the same dataset as the research data) and these data should be stored on and shared through VU approved facilities.
For more tips about personal data, pseudonymous data and anonymous data and when the GDPR does or doesn't apply, see this postcard from the National Coordination Point for RDM. Finally, if you think your data are anonymous, check first with the FGB Research Data Officer whether this is actually the case. If your data truly are anonymous, then the GDPR does not apply to you data.
There are new rules regarding the collection of BSNs since the GDPR came into force. The implementation law for the GDPR in the Netherlands (UAVG) forbids the collection of BSNs unless it is legally required to do so. In the past at the VU, researchers would collect BSNs in order to register research participant reimbursement payments with the Financial Service Center. This is because the VU is required to register these reimbursements with the Tax Authorities. It is still required to register these payments with the FSC, but BSNs are no longer required to complete this registration, which means that BSNs should not be collected for this purpose (more information about research participant reimbursement is available on this VUnet page); note that the forms available for this registration still include a column for BSNs, but these values cannot be entered, so make sure your research team is not collecting BSNs. In short: it is no longer necessary (nor allowed) to collect BSNs for the registration of reimbursement payments with the FSC.
The Data Protection Officer for the VU can be reached at firstname.lastname@example.org.
Under the GDPR, it is no longer necessary to register the processing of personal data with the Data Projection Authority for the Netherlands. Instead a data processing registry must be maintained by the VU. To meet this requirement within the faculty, please forward any completed data management plans and data protection impact assessments to the FGB Research Data Officer.
Unfortunately, this isn’t really something that can be avoided, particularly when the information is coming from participants or their parents. With regards to institutional third parties such as schools, hospitals or clinics that you are working with, contact the institution to determine whether data will continue to be transferred in this way so that a safe method can be agreed upon. If data will continue to be shared with you in this way, you should set up data transfer methods in line with this guide. For example, it's possible to set up access to a SURFdrive file or create a guest user in SURFFileSender for third parties including for those that don't normally have access to SURF products. SURFdrive and SURFFileSender are safer methods than e-mail is that your partners can use if they need to share sensitive information with you.
If you receive an e-mail containing sensitive information just as a one-time situation, contact the sender to say you have recorded the information in a safe location and deleted the e-mail. Advise the sender to delete the e-mail from their outbox and then let him or her know that e-mailing is not a particularly safe method for sending sensitive information; if sensitive information needs to be sent again in the future, advise the sender to first contact the research team to set up a safer method of transfer, such as with ZIVVER. You can find more information on ZIVVER on this VUnet page and in this instruction manual (which is about using ZIVVER for obtaining digital consent. This is discussed in the question How can I obtain consent from participants digitally, but also securely and in a way that follows the privacy rules?).
It is understandable that if A LOT of these kinds of e-mails are received, that they will not be addressed immediately. Just try to manage them in a timely manner; your research team can document in your research data management plan or data protection impact assessment what standard response you should send when receiving these e-mails and the time frame within which you will address these e-mails. The GDPR does not define any time frame to manage such situations; instead you simply need to document how you handle personal data, so it is your responsibility to define a reasonable time frame (for example, 2 weeks), then document that time frame and stick to it.
Under the GDPR, there are specific rules you must follow if you plan to share non-anonymous data outside of the EU/EEA. The most feasible options for meeting these rules are to send the data to a country that has an adequate level of data protection according to the European Commission. Note that in Canada, this only applies to commercial organizations and in the U.S., this only applies to commericial organizations that are certified under the Privacy Shield framework. If there is no equivalency status, then you can have the receiving party in the other country sign a Standard Contractual Clause. If none of these options are feasible, contact the FGB Privacy Champion for further assistance.
The first thing to check is whether the informed consent methods used prior to the GDPR meet GDPR requirements. This document includes information about the requirements for valid consent under the GDPR. If you determine that the manner in which consent was previously obtained is not valid under the GDPR and you still need to continue using participant data, then first try to contact participants (if you still have their contact information) to renew consent in a manner that is valid under the GDPR. If it is no longer possible to contact participants (e.g. all contact information has been deleted) then it is not absolutely necessary to renew consent under the GDPR, but you will need to document clearly in a data management plan or data protection impact assessment that it was impossible to contact the participants to renew consent under the GDPR rules and provide an explanation as to why this was impossible.
This question will need to be partially addressed by the FGB Ethical Committee during the ethical approval process, but with regards to privacy law, under the GDPR it is possible to process personal data based on legitimate interests. First assess whether legitimate interests may be appropriate with a legitimate interests assessment. If it looks like this may be a reasonable legal ground for data processing, contact the FGB Privacy Champion for further advice on this topic. Be aware that legitimate interests alone cannot be a legal reason to work with special data types; for more information about the requirements for processing special data types without consent see this document.
First things first, the preferred method of obtaining consent is to have your participants sign and date a paper consent form. If you are conducting clinical research (whether it is WMO-appplicable or not) it may also be a requirement to obtain consent on papier. For WMO studies and clinical research that is non-WMO, check with the VUmc METC as to whether you are required to use paper consent forms (especially in the time of the coronavirus!)
If digital consent is an option for you, the second thing you want to ensure is that you can obtain consent legally:
If you are running a survey with a panel provider (see the question Do I need to set up a processing agreement with panel providers, such as MTurk or Prolific Academic? ), you should obtain consent using your questionnaire tool at the very start of your survey. Make sure the information provided and the way consent is obtained follows the requirements of this checklist.
The ICO, the Data Protection Authority for the UK, created a checklist to help you determine which role(s) you will have for the planned data processing. You can also use this checklist to determine whether third parties that you are going to work with will function as joint controllers and/or processors. It's necessary to determine what everyone's role is because you can then determine if agreements between the various parties need to be signed and if so, which type of agreement.
Check first if the VU or FGB already has a contract with the company you wish to hire or with another company that provides a similar solution. The FGB Research Data Officer can help you with this. Also check if the faculty technicians (TO3) could create an in-house solution for you so that an external company doesn't need to be hired.
If a new company needs to be hired, use the standard VU model processing agreement, which you can obtain from the FGB Privacy Champion. The main text of this model agreement must not be changed, but the annexes at the end of the agreement need to be filled in. Contact the FGB Privacy Champion to review Annex 1 and contact the RDM support desk to get support from an IT expert who can review Annex 3 to check that the security measures of the company are sufficient. Be aware: it's very likely that the IT expert who will review Annex 3 will want to see a data classification about the data that will be collected or stored by the company you are hiring. This will help the expert in their assessment as to whether the security measures are sufficient. You can complete a data classification with this tool, although check first with your supervisor or research teammembers as to whether a data classification has already been completed.
Please note that some companies will wish to use their own model processing agreement. If it’s absolutely not possible to use the VU model then it may be possible to use the model of the company; however the FGB Privacy Champion will need to check the processor's model to make sure it meets the needs of the VU.
In all cases, setting up a processing agreement with an external company will take time, regardless of which model agreement is used. To help avoid trying to set up such agreements last minute, make sure to plan ahead in your data management planning as to whether an external company needs to be hired so that the process of setting up an agreement with that company happens well before data collection needs to begin.
If you are using a panel provider to recruit participants by having the provider share a link for your survey, there is no need to set up a processing agreement with that provider. The provider is in this case an independent controller, according to the GDPR, meaning they are responsible for the data they collect and maintain; the VU is also an independent controller and we are responsible for the data we collect through the surveys. But neither party sees that data of the other party so there is no need for an agreement. This applies even if the panel provider is located outside of the EU/EEA.
If you are using panel providers to recruit participants located outside the EU/EEA, be aware that other privacy laws may apply to the data collected; the VU is required to meet both GDPR requirements and international privacy laws when working with international participants. Finally, the only other thing to keep in mind when recruiting participants with panel providers is that you must ensure that you have a GDPR-compliant informed consent process at the start of the survey. Review this checklist to make sure your consent process is valid.
The VU has developed model agreements for situations where the VU functions as a joint controller with another party (if you are unsure of what the roles of the VU and the other parties are see the question How can I determine what my role is (controller, joint controller or processor) under the GDPR? ). You can obtain this model agreement from the FGB Privacy Champion.
In other situations, the VU sends or receives data from another party, but then both parties process the data without any further input from the other party. In that case a joint controller agreement is not necessary, but other agreements, such as data sharing agreements may be required. The VU has a model agreement for data sharing when data that fall under the GDPR are being shared, but this only covers the privacy aspects. If these kinds of data are being shared and all other legal agreements have been settled with the other parties (such as those found here) then you can use the VU model data sharing agreement which addresses the privacy aspects that have not been addressed in the other agreements legal agreements. You can obtain this model agreement from the FGB Privacy Champion.
If the other legal agreements have not yet been set up, it's advised to contact IXA for advice about what agreements are required and to get help with setting up the required agreements. The lawyers at IXA can also help to make sure that the privacy aspects of data sharing are included in this data sharing agreement so that a separate agreement addressing privacy aspects doesn't need to be signed.
A good starting point to assess what kind of privacy agreements are necessary is to complete this checklist and see whether the VU and the third party are joint controllers. If they are joint controllers, a joint controller agreement needs to be signed; you can obtain a model agreement from the FGB Privacy Champion. You should also consider where the research data will be collected from and stored because if all data are maintained externally by the third party and the PhD candidate is employed by that third party, generally no joint controller or data sharing agreements are required. However, if the third party has no facilities for maintaining the data long-term after the research project is complete (namely for archiving the research data) data may need to be transferred to the VU at which point a data sharing agreement and potentially a joint controller agreement will be necessary. You can contact IXA for help with drawing up a data sharing agreement.
Make sure to also review the question I am an external PhD candidate/I am supervising an external PhD candidate. Can I make use of services licensed by the VU, such as Qualtrics or Survalyzer? for more information about the use of VU-licensed services by external PhD candidates.
This document addresses how to assess the privacy risks of the data that will be shared with a student and what the best workplace options for your student are based on the privacy risk level. If, for example, a VU work station is not feasible for your student, see whether the data that the student will use can be modified to reduce the privacy risks.
This is a complex question. Ultimately the VU would bear the brunt of the responsibility if a breach occurs. However students are responsible for handling data carefully according to the requirements of the VU. In order to ensure students behave appropriately while under VU supervision, students must carefully read, understand and sign confidentiality agreements before they work with research data. If students will be collecting or transporting data outside of the VU or they will be borrowing equipment from the TO3 Borrowing Service, they must also read this guide on security basics and this guide on physical transport of data so that they know how to carefully handle the data until they can store it in a safe VU location. It is also a good idea to develop a protocol for collecting data outside the VU that will be documented in the data management plan so that everyone collecting and transporting data knows what their responsibilities are; having clear, documented procedures that everyone must follow will minimize the risks of leaking data.
If the student will be conducting research under the sole supervision of the VU and there isn’t another third party (e.g. a hospital, long-term care centre, physiotherapy clinic etc.) involved in the data collection, then a confidentiality agreement can be obtained from your department or section head. He or she can also sign this agreement on behalf of the Director of Operations for the Faculty. If all data collection and data storage will take place at the location of a third party, and the only role for the VU is to provide supervision for the research internship, then the third party is responsible for setting up a confidentiality agreement with the student.
If both the third party and the VU are responsible for the data that the student will work with (i.e. data collection and/or storage happens at both the VU and the third party location) then the student must sign confidentiality agreements for both the VU and the third party. It is advised that the supervisor review the confidentiality agreement template in this situation to make sure that there isn't anything in the agreement that might a problem for the collaboration; if there seems to be a problem, contact the FGB Privacy Champion for advice.
Because of the type of research that is done at FGB, it's very likely that a DPIA will need to be carried out before you begin your research project. First you can check whether it's legally required that you complete a DPIA by completing a pre-DPIA. You can find an English pre-DPIA here under Forms and Templates; a Dutch version is found here under "Formulieren en Templates". If after completing the pre-DPIA you are still uncertain whether a DPIA should be completed, it's recommended to go ahead and complete one because this will ensure that everything is in order with respect to the GDPR. If you need advice on your DPIA, you can contact the FGB Research Data Officer. Once you have completed the DPIA, please send it to the FGB Research Data Officer; the information in the DPIA will be used to develop a processing register, which is required by the GDPR, as well as develop a database of existing DPIAs, so that if a future project follows similar processes, an earlier DPIA for those processes could be re-used.
Under the GDPR there are no specific rules that state that all data must be pseudonymized or anonymized nor that this must happen immediately. Instead it just generally requires that the privacy risks to the people from whom the data were collected be reduced as quickly as possible. If as far as you can tell there is no way to reduce the privacy risks with your data, you can contact the FGB Research Data Officer to see if there are any methods that you may not have thought of that could be used to modify the data and reduce the privacy risks. If there is absolutely no way to reduce the privacy risks with your data, then the data require the highest level of security measures. At the moment, the standard solution at the VU for high risk data is SciStor, but if the nature of the data is particularly sensitive and/or the participants are particularly vulnerable (e.g. children being interviewed in a video recording about sexual abuse), then it may be necessary for IT to new extra infrastructure that provides additional security. Creating new IT infrastructure can take a long time, so make sure to begin as early as possible thinking about privacy risks with your data management plan, and where applicable, your data protection impact assessment and data classification. For advice about security solutions for extremely sensitive data, you can contact an IT expert via RDM support desk. The IT expert will expect that you have already completed a DPIA (in English or Dutch) and a data classification.
Be aware that when modifying data to meet GDPR requirements, we have to balance this with our research integrity requirements. If, for example, you make video recordings and code interactions in the video, then you may only need to analyse the coded interactions. The coded dataset has a lower privacy risk, which is ideal for the GPDR, but we don't necessarily want to delete the video data as soon as all interactions have been coded because there may have been mistakes in how the interactions were coded. In order to meet our research integrity requirements we often have to maintain raw data that may have quite high privacy risks for at least 10 years after our research was published. Fortunately, the GDPR doesn't prohibit this, it just requires that these higher risk data be kept safe and that they be deleted as soon as possible. In this case we simply store these data in our most secure archive, DarkStor, and we delete the data when the archiving term is up.
As of December 2020, the issues with Qualtrics under the GDPR have been resolved. It is now possible to collect personal data with Qualtrics for your research. FGB has also maintained the license for the alternative questionnaire tool Survalyzer. There are a variety of reasons why you may want to use one questionnaire tool over the other. Additionally, there are important steps you can take when using either of these questionnaire tools to make your data extra secure. For more information on these matters, please refer to this guide on the secure use of questionnaire tools.
No. The reason you can use your VUnet ID to log in to these services is so that they can be used for educational purposes. Google Drive remains an inappopriate solution for storing and sharing data that falls under the purview of the GDPR or any other sensitive types of data.
There are a variety of free online courses available to learn about the GDPR and privacy issues. These include:
The VU offers a few different options for video calling. Review this VUnet page to decide which video calling tool is appropriate for your needs and whether it is suitable with regards to security and privacy.
On Windows workstations, Skype for Business has an option to allow for a call to be recorded. These calls are recorded on the local hard drive, but it is advised to double check the settings on the Skype for Business app to determine where exactly the recordings will be stored.
On Mac workstations, the Skype for Business app does not allow for calls to be recorded. However, QuickTime can be used to record any audio created on a Mac and these recordings are also stored on the local hard drive.
In both cases, once the recordings have been saved on the hard drive, they should be moved to an appropriate secure location, such as the G-drive or SciStor. Then make sure to permanently delete the recordings from the hard drive of your workplace.
E-mailing data without additional security measures is strongly discouraged, even if it seems like the data are anonymous (because the standards that one must meet to call data anonymous are much stricter that many people realize and much of our research data do not meet these standards). The VU has multiple options for sending data safely, so it is advised to use these solutions. See this guide for information about these options. On VUnet you can also find more information about the security extension, ZIVVER, that can be used with Outlook to secure e-mail traffic. If you aren't sure how to use ZIVVER on a personal computer, a red workstation or MacOS/Linux check out this instruction manual about using ZIVVER for obtaining digital consent (discussed in the question How can I obtain consent from participants digitally, but also securely and in a way that follows the privacy rules?). This manual explains how you can set up ZIVVER on these types of workstations.
See this guide for information on how to safely transport data to and from the VU. This guide also describes the TO3 borrowing service from which researchers and their assistants can borrow devices for offsite data collection.
When you delete data from your computer or an external drive, the data are still on the drive, but the path to the data has been removed. Someone with good technical skills could easily access the ‘deleted’ data. To permanently remove data from a drive you can use Software such as KillDisk or Eraser. The VU does not currently support any of these software, so if you are working on a green or orange workspace, contact the IT Servicedesk for support to permanently remove data from your hard drive.
Unfortunately external PhD candidates are not allowed to use VU-licensed services. These are only to be used by VU employees and students. It is a good idea to check whether the external PhD candidate can make use of services within the institution they are associated with. If that is not possible, an option is to set up a VU guest account, but this can cost a lot of money and it does not necessary guarantee immediate access to VU licensed services; often more steps need to be carried out. Therefore it is advised to contact the RDM support desk for more information and support on this complex issue.
Actually, your best option for creating a short URL for your research (and also for any educational purposes) is edu.nl. This is a service offered by SURF to all researchers, students and staff with access to SURF services and the main advantage is that the URL that is created does not track the website visitors, which can be an issue with things like bitly.
Inform the IT Service Desk immediately. Provide them with details about what happened, the type of data that may have been leaked and a description of the population from which the data were collected. The Service Desk will forward your question on to the Security Operations and Control Centre and the VU Legal Department, who will review the issue and determine what kind of follow-up is necessary.
For more information on data breaches (a.k.a. data leaks), see this VUnet page,