From 8e27d582a517e0985998d15cec931e1384acfbdb Mon Sep 17 00:00:00 2001 From: kleuveld Date: Tue, 3 Oct 2023 08:58:57 +0000 Subject: [PATCH] kleuveld published a site update --- 404.html | 6 +++--- fss-guidelines-archiving.html | 9 +++------ index.html | 12 +++++++----- new-rdm.html | 6 +++--- ongoing-rdm.html | 6 +++--- proposal-content-rdm.html | 6 +++--- rdm-faq.html | 6 +++--- rdm-policy.html | 6 +++--- rdm-presentations.html | 6 +++--- rdm-tools.html | 10 +++++----- search_index.json | 2 +- templates.html | 32 +++++++++++++++++++------------- 12 files changed, 56 insertions(+), 51 deletions(-) diff --git a/404.html b/404.html index e83cc35..9804ee3 100644 --- a/404.html +++ b/404.html @@ -23,7 +23,7 @@ - + @@ -110,13 +110,13 @@
  • Re-usable
  • What to archive?
    • -
  • Knowledge and Guidelines
  • Templates
  • RDM: VU FSS guidelines for data management
  • RDM: Tools
  • RDM: Presentations
    • diff --git a/fss-guidelines-archiving.html b/fss-guidelines-archiving.html index cdebc2f..b210ed1 100644 --- a/fss-guidelines-archiving.html +++ b/fss-guidelines-archiving.html @@ -23,7 +23,7 @@ - + @@ -110,13 +110,13 @@
  • Re-usable
  • What to archive?
    • -
  • Knowledge and Guidelines
  • Templates
  • RDM: VU FSS guidelines for data management
  • RDM: Tools
  • RDM: Presentations
    • @@ -254,9 +254,6 @@

    What to archive? - - - diff --git a/index.html b/index.html index 15fb04c..cd69f74 100644 --- a/index.html +++ b/index.html @@ -23,7 +23,7 @@ - + @@ -110,13 +110,13 @@
  • Re-usable
  • What to archive?
    • -
  • Knowledge and Guidelines
  • Templates
  • RDM: VU FSS guidelines for data management
      @@ -143,7 +143,7 @@
  • RDM: Tools
  • RDM: Presentations
    • @@ -166,7 +166,7 @@

    Index

    @@ -228,7 +228,9 @@

    Table of contents - + @@ -110,13 +110,13 @@
  • Re-usable
  • What to archive?
    • -
  • Knowledge and Guidelines
  • Templates
  • RDM: VU FSS guidelines for data management
      @@ -143,7 +143,7 @@
  • RDM: Tools
  • RDM: Presentations
    • diff --git a/ongoing-rdm.html b/ongoing-rdm.html index 982be3c..c8f8bad 100644 --- a/ongoing-rdm.html +++ b/ongoing-rdm.html @@ -23,7 +23,7 @@ - + @@ -110,13 +110,13 @@
  • Re-usable
  • What to archive?
    • -
  • Knowledge and Guidelines
  • Templates
  • RDM: VU FSS guidelines for data management
      @@ -143,7 +143,7 @@
  • RDM: Tools
  • RDM: Presentations
    • diff --git a/proposal-content-rdm.html b/proposal-content-rdm.html index a9d295a..c5f4e4c 100644 --- a/proposal-content-rdm.html +++ b/proposal-content-rdm.html @@ -23,7 +23,7 @@ - + @@ -110,13 +110,13 @@
  • Re-usable
  • What to archive?
    • -
  • Knowledge and Guidelines
  • Templates
  • RDM: VU FSS guidelines for data management
      @@ -143,7 +143,7 @@
  • RDM: Tools
  • RDM: Presentations
    • diff --git a/rdm-faq.html b/rdm-faq.html index 754c635..f45fa6f 100644 --- a/rdm-faq.html +++ b/rdm-faq.html @@ -23,7 +23,7 @@ - + @@ -110,13 +110,13 @@
  • Re-usable
  • What to archive?
    • -
  • Knowledge and Guidelines
  • Templates
  • RDM: VU FSS guidelines for data management
      @@ -143,7 +143,7 @@
  • RDM: Tools
  • RDM: Presentations
    • diff --git a/rdm-policy.html b/rdm-policy.html index e0de768..a233e28 100644 --- a/rdm-policy.html +++ b/rdm-policy.html @@ -23,7 +23,7 @@ - + @@ -110,13 +110,13 @@
  • Re-usable
  • What to archive?
    • -
  • Knowledge and Guidelines
  • Templates
  • RDM: VU FSS guidelines for data management
      @@ -143,7 +143,7 @@
  • RDM: Tools
  • RDM: Presentations
    • diff --git a/rdm-presentations.html b/rdm-presentations.html index 39d8eb2..a297f64 100644 --- a/rdm-presentations.html +++ b/rdm-presentations.html @@ -23,7 +23,7 @@ - + @@ -110,13 +110,13 @@
  • Re-usable
  • What to archive?
    • -
  • Knowledge and Guidelines
  • Templates
  • RDM: VU FSS guidelines for data management
      @@ -143,7 +143,7 @@
  • RDM: Tools
  • RDM: Presentations
    • diff --git a/rdm-tools.html b/rdm-tools.html index 7fed4dc..32583f4 100644 --- a/rdm-tools.html +++ b/rdm-tools.html @@ -23,7 +23,7 @@ - + @@ -110,13 +110,13 @@
  • Re-usable
  • What to archive?
    • -
  • Knowledge and Guidelines
  • Templates
  • RDM: VU FSS guidelines for data management
      @@ -143,7 +143,7 @@
  • RDM: Tools
  • RDM: Presentations
    • @@ -255,8 +255,8 @@

    RDM: Tools -
    -

    More resources

    +
    +

    More resources

    • Information when starting a new project
    • FSS RDM Guidelines
      • diff --git a/search_index.json b/search_index.json index 4ff86a3..ff5ce1e 100644 --- a/search_index.json +++ b/search_index.json @@ -1 +1 @@ -[["index.html", "FSS RDM Pages Index Table of contents", " FSS RDM Pages FSW Data Steward 28 September 2023 Index This web site contains the latest draft versions of the Research Support Office’s pages on Research Data Management. The current “official” versions of these pages can be accessed through the Social Sciences Getting Started page. Table of contents Support throughout the Research Cycle Plan & Design Content for proposals: Ethics, Privacy, RDM (Koen) Starting a new project (Time to Grant) Ethics, Data Management and Privacy for new projects Managing ongoing projects Organizing your research data (Koen) Publishing, and Impact Archiving and/or publishing data (Koen) Knowledge and Guidelines Templates RDM Data Management Policy RDM FAQ RDM Tools A Guide to FAIR data "],["proposal-content-rdm.html", "Content for proposals: Privacy, ethics and data management Personal Data Ethics Research Data Management", " Content for proposals: Privacy, ethics and data management This document contains example texts to be used in proposals. The text should be adapted to the specific project for as much as possible. Personal Data The [interview/survey/…] data collected for this project constitutes personal data in the sense of the GDPR. The researcher will work with the faculty data steward and the VU’s privacy team to ensure compliance with GDPR. The legal ground for processing this data is informed consent. All respondents will be fully informed about the means and purposes of the data processing, and no data will be collected unless this consent has been given. The information sheets that will be used for these are based on standard forms developed in consultation with the VU’s privacy lawyers, and include information on what data will be processed, the purposes and the legal ground for processing, information on who will be able to access the data, the duration of data retention and how respondents can exercise their privacy rights. For verification purposes, the data for this project will be retained for 10 years after the last publication. After this, the data will be destroyed. The data will stored on storage infrastructure provided by the VU, which can only be accessed using strong passwords and multi-factor authentication. Data will be pseudonymized after it has been collected; any data containing directly identifying data (such as the raw, unpseudonymized data) will be stored separately from other data. The VU ensures that any storage solutions offered by third parties [e.g. Research Drive and Yoda by SURF, or qualtrics, name whichever apply] are governed by Data Processing Agreements, and that no personal data is stored outside the EEA [check if this last is true for the specific services you use!]. Ethics The researcher will work with the faculty of Social Sciences’ Research Ethics Review Committee (RERC) to ensure that the research is in line with ethics standards governing research at the faculty. The researcher will perform a scan of the research to flag ethics issues and will discuss any issues found with a representative of the RERC. [This really depends on the research. It is wise to do the self-check before and possibly consult your department’s RERC representative] Research Data Management Below are two examples of data management paragraphs that can be adapted and expanded on to suit most templates. There is one example for projects where the data will not be shared, and one where it will be. Example with no data sharing The data stored for this project will be stored on secure network storage provided by the VU, in accordance with VU’s ICT regulations. Access to the network storage is only granted to authorized personnel, using strong passwords and multi-factor authentication. In compliance with European Union’s General Data Protection Regulation (GDPR), no personal data will be stored without prior, explicit consent by the data subjects. After completion of the project, all data will be archived for ten years, in accordance with the FAIR principles. Because of the se sensitive nature of the topic, the data will not be shared publically, but only be accessible for verification purposes. If for this verification it is needed to share the data with staff outside the VU, this access will be governed by a data transfer agreement. Information on the access condition will be made public through a registry of the data set on VU’s Research Portal (which uses PURE). All data storage, archiving and registry solutions will be chosen in consultation with the faculty of social sciences’ data steward; these choices will be registered in a Data Management Plan before the start of the project. Example with data Sharing The data stored for this project will be stored on secure network storage provided by the VU, in accordance with VU’s ICT regulations. Access to the network storage is only ranted to authorized personnel, using strong passwords and multi-factor authentication. In compliance with European Union’s General Data Protection Regulation (GDPR), no personal data will be stored without prior, explicit consent by the data subjects. After completion of the project, pseudonymized data will be published on DataVerseNL, where it will be accompanied by rich metadata and full documentation. All data storage and archiving solutions will be chosen in consultation with the faculty of social sciences’ data steward; these choices will be registered in a Data Management Plan before the start of the project. "],["new-rdm.html", "FSS Starting a new project: Ethics, Data Management and Privacy Getting support", " FSS Starting a new project: Ethics, Data Management and Privacy When working with data from human respondents it is important to consider matters around ethics, data management and privacy before collecting (or analysing) any data. So when starting a new project or study – or significantly updating or expanding and existing one – it’s good to check whether the following things are in order: Ethics Review: the Research Ethics Review Committee provides a self-check that consist of a list of Yes/No questions that takes less than five minutes to complete. This scans for ethics issues, and advises on next steps. More information on Ethics Review can be found here. Research Data Management (RDM): you will need to consider what you do with your research data before you collect it, because you need to tell your respondents what you’re doing with it. The faculty advises you to use Yoda for Storaging, Archiving and/or Publishing your research data. Other options are available, check out the tools overview and/or the storage finder. Privacy: all data that can be linked in any way to living persons is considered personal data under GDPR. For most researchers this means: You must take appropriate technical and organization measures to secure data. For most data (including sensitive data, such as data on health, sexual preferences, political opinions etc.), Yoda and VU-managed devices offer sufficient protection. If you have sensitive data and want to use other storage solutions, it’s best to check in with the Data Steward or RDM Support Desk to find what would work best for your needs. You should ensure that you have unambiguous informed consent of your research participants. Note that informed really means informed: you have to provide your participants with information about what you will do with the data, and what their rights are and how to excercise them. You can do this by having your respondents sign an informed consent sheet based on the faculty template (Dutch), or provide them with (a link to) a privacy statement based on the VU template (Dutch) and ask them if they’ve read it and accept it. If you cannot obtain consent, you should contact your Data Steward to see how you can still legally work with your data. You must ensure that all data processing activities (collection, analysis, publishing, archiving, etc.) are entered in the VU’s central data processing registry. Currently, DMPs created using the VU template in DMP Online are linked automatically to this registry, meaning the researcher does not need to take additional action for this. If you don’t have DMP on DMP Online, there is a short form available on DMP Online that you can use to just enter the legally required information. If personal data is handled by third parties (e.g. a survey firm or data collection platform), you should contact the Data Steward to help you get the proper agreements in place to do this securely, for example Data Processing Agreements. The VU has these agreements in place with VU-provided tools such as Yoda and Qualtrics. The Data Steward is there to help you with templates and getting legal advice for getting these agreements with other service providers and partners. Data Management Plan (DMP): all data collection done at the faculty should be covered by a Data Managment Plan (DMP). So once you have given all of the above some thought, you should start writing one, or adapt an existing one, by going to DMP Online. DMPs are living documents: you are encouraged to change them if what you plan to do with the data changes. Ideally, you make your DMPs public on DMP Online, so your colleagues can easily learn from all the hard work you put into steps 1-3. Getting support You can get support and find more information in the following places: The Faculty Data Steward (or the RDM Support Desk in case you can’t reach the data steward) The Faculty RDM Page (which includes links to templates of informed consent letters, a FAQ, and content you can use for proposals etc.) The RDM Libguides. "],["ongoing-rdm.html", "VU FSS guidelines for data organization Introduction General advice Use cases", " VU FSS guidelines for data organization Introduction Researchers of the Faculty of Social Sciences (FSS) are responsible for organizing their data in such a way that they can be archived without excessive effort. In general terms, the aim is to ensure that a fellow researcher can use the data without asking too many questions. This ensures that the results of the research can be verified if the need arises. Furthermore, should additional researchers be added to a project - or a researcher gets back from a long hiatus - they can get started quickly. These guidelines are not prescriptive; they are meant to inspire researchers on how to manage their data when starting a new project, since changing folder structures once a project has started can be very difficult. These guidelines provide some general advice on data organization, as well as several use cases (quantitative and qualitative) that serve as inspriration for organizing research data. Each use case gives an outline of a folder organization that is used during the research. These use cases serve as examples, researchers are free to use any organization that fits the needs of their research. General advice When thinking about organizing your files, start at the end: where should these files end up? It’s a good idea to keep files that you want to publish together with other files you want to publish. This saves times and prevents error when – after project completion – you decide which files should be archived, and which files should be published. Follow these best practices when naming files and folders. Use cases Simple quantitative research project using Research Drive and Yoda Get the sample DMP for this use case here. This use case describes a fictional project using survey data. It uses Yoda for archiving only; for storage of data the project uses Research Drive. While Yoda is suitable for storage as well, Research Drive offers more fine-grained access control, which this fictional project needs to make sure student-assistants can’t access all information stored on the research drive. Research drive is used for day-to-day storage and synced to researcher’s devices using the OwnCloud software. The folder is organized as follows: Data Pseudonymized research data (access is granted as needed) Documentation Questionnaires, proposals, data management plan etc. (everyone in project can access) Papers One sub-folder per paper containing text, analysis scripts etc. for each paper. (access is granted as needed) Admin Project admin information, such as budgets; not accessible to students Yoda is used in this project for archiving, and is thus not synced to any devices. Directly following data collection, the raw data was pseudonymized. The pseudonymized data was stored on Research Drive. The raw, unpseudonymized data was archived on Yoda, assigned to the Vault and permanently deleted everywhere else. This ensures that a copy of the original data is always available (with a DOI), and minimizes the risk of leaking unpseudonymized data. Once a paper based on the data is published, a folder is created for that paper with all things that can be shared publicly. This folder copies the Yoda metadata of the root folder, making complying with the FAIR principles very easy. The folder is made public on Yoda and looks as follows: Raw data (Vault) Data files Documentation -Yoda metadata Replication files for each paper (Public): Author manuscript of paper Analysis and pseudonymization scripts Documentation Yoda metadata Note that the data itself is not publicly available because of privacy concerns. The raw data is only archived for verification purposes. In case of doubts about the research integrity, the Raw Data’s DOI (listed in each paper’s data statement and replication files’ metadata) can be used to quickly identify the data set for verification purposes. Simple qualitative research project using Yoda The following is a basic qualitative project. All data is stored on Yoda. Once data collection is complete, the data folder is added to Yoda vault, a DOI of which is included in every paper. Yoda Raw Data (Vault) Interview recordings List of names with interviewees Data Pseudonymized interview transcripts Documentation Sampling information Topic lists Ethics review information Blank informed consent form Paper 1 Text of paper Figures Using Yoda to archive PhD data As part of their portfolio, PhD candidates are required to follow the FAIR principles to ensure that their data is available for verification purposes. In this use case, the data is archived in Yoda. The organization is starts by asking the question where data needs to end up, and then works backwards to make that possible. This project has some data assets that need to be archived restricively, while others can be made freely available. We therefore made two top-level folders in Yoda: public and restricted, and divided the data assets among these two folders. Restricted Raw data Sampling lists Public Documentation Informed consent templates Sampling guides Topic lists Manuscript "],["fss-guidelines-archiving.html", "VU FSS guidelines for archiving data How to apply the FAIR principles Findable Accessible Inter-operable Re-usable What to archive?", " VU FSS guidelines for archiving data These guidelines are an extension of the FSS RDM Guidelines. When publishing research outputs, researchers at the Faculty of Social Sciences are expected apply the FAIR principles and to archive “all data that can be reasonably deemed necessary to verify the findings of the research”. These guidelines serve as practical advice on how to achieve this. The first section discuss the constituent principles of FAIR data (Findability, Accessibility, Inter-operability and Re-usability), the second provides practical advice on what to archive, based on the Archiving Guidelines from the Deans of Social Sciences in the Netherlands. How to apply the FAIR principles The FAIR principles are a set of principles that guide researchers in making their data (or other research outputs) more valuable by increasing visibility, fostering collaboration, facilitating co-creation, and promoting transparency. To effectively implement the FAIR principles, it is beneficial to envision how your data will be reused, and then apply each principle accordingly. This involves ensuring discoverability of your data by end users, enabling easy access, facilitating integration with existing knowledge and workflows, and promoting its reuse. Given the diverse research traditions and approaches to data reuse within the faculty, there isn’t a universally prescribed approach for applying the FAIR principles. However, as a minimum requirement, all data utilized within FSS should be usable for verifying the findings presented in publications resulting from the data. This section provides practical pointers, aligned with the FAIR principles, on how you can make verification possible. Additionally, it presents further steps you can take to increase the impact of your research outputs. Findable Findable means people can find out about the existence of your dataset, and know where to find more information about it. Actions required to allow for verification: Register your data set in a registry like the VU Research Portal. (NB: you don’t need to upload your data set for this!) Ensure your data set is assigned a DOI (for example by adding it to a Vault on Yoda and publishing the metadata). More actions you can take to make your data set more Findable: Cite your data sets in your paper. Accessible Accessible means that there should be an established way to access your data. This does not mean your data should be public, just that there is a clearly communicated and transparent procedure put in place to access the data. Actions required to allow for verification: Add a data availability statement in your publication that explains how, and under what conditions, the data can be accessed. Archive your data in a restricted-access repository like Yoda. More actions you can take to make your data set more Accessible: Make your data publicly available on Yoda, the OSF or DataVerseNL. Inter-operable Inter-operable means that someone else can use your data and combine it with their existing knowledge and workflows. Actions required by to allow for verification: Use common, preferably open, file formats. Include documentation that can help people make sense of your data, such as codebooks, interviewer manuals, and topic lists. Wherever possible, use a language that can be understood by anyone who may reasonably be expected to use your research outputs. More actions you can take to make your data set more Inter-operable: Use standardized variables, coding schemes and vocabularies. Make sure the metadata of your datasets link to related datasets, publications and other relevant research outputs. Re-usable For your data to be re-usable, it needs to be clear what can and cannot happen with your data. Actions required to allow for verification: Include the informed consent sheets or privacy statements you provided your respondents, so that it is clear what they allow the data to be used for. Make sure that when you register your dataset, or deposit it into a repository, you include detailed information like author, topic, keywords, etc. See the VU’s minimal metadata standards. Note that Yoda requires you to include this information before submission. Actions you can take to make your data more Re-usable: Include detailed information, for example in a readme, on the provenance of your data: where it comes from, how was it has been collected and how it was processed. Include a license, like CC-BY or the DANS license, with your data; or set out a Data Sharing Agreement that exactly states what a recipient can do with the data. What to archive? The following materials should be archived, within one month after the publication date: A copy of the publication that uses the data. Most publications allow you to upload the submitted version (i.e. without the journal’s layout etc.). Raw data: unedited data files providing the most direct registration of the behaviour or reactions of test subjects/respondents. If the raw data files have been accessibly stored in an external archive (such as storage facilities at DANS), or if the data cannot be archived on university servers (for example due to IP restrictions) making reference to the location of the files will suffice. The VU researcher must ensure that such externally stored raw data will be available for verification purposes. Raw data may not be changed once they have been made digitally available. Analyzed data: the data files that were eventually analysed when preparing the article (e.g. an SPSS data file after transforming variables, after applying selections, etc.). This is not necessary if the raw data file was directly analysed, or if the analyzed data can be constructed without excessive effort from the raw data (for example by running a script). A description of the procedures to transform the raw data into analyzed data. This could be computer code (for example Atlas.ti, SPSS/JASP syntax file, MATLAB analysis scripts, R code) or a description of the steps taken in the qualitative analysis of primary research data, i.e. themes, domains, taxonomies, components. A description of the steps taken to process the analyzed data into results in the manuscript. This could be computer code or a description of the steps taken in the qualitative analysis of primary research data. Any documentation that can reasonably be deemed necessary in order for other researchers to understand the data and/or verify the research’s findings. The precise documentation depends on the methods used, but examples include: study design documents, interview guides, questionnaires, surveys, and topic lists. The materials must be available in the language in which the research was conducted. A readme file (metadata) describing which documents and files can be found where and how they should be interpreted. The readme file must be sufficiently clear, so that a relevant fellow researcher can verify the results discussed in the publication. The readme file must also contain the following information: Name of the person who stored the documents or files Division of roles among authors, indicating at least who analysed the data Date on which the manuscript was accepted, including reference Date/period of data collection Names of people who collected the data If relevant: addresses of field locations where data were collected and contact persons (if any) Whether the data is made open or not and if not, a valid reason for not opening up the data Documents received from the Research Ethics Review Committee: at least the result of the self-check, and if applicable result from a full review. If using personal data: information about the informed consent procedure, such as a privacy statement, or a blank informed consent form. "],["templates.html", "Templates Data Management Plans Informed consent Data Protection Impact Assessment Agreements", " Templates Data Management Plans The University Library manages DMP Online so that all templates are up-to-date. It is advisable to use the VU template whenever possible (this is accepted by ZonMW and NWO instead of their own templates). Filled in examples can be found in the following places: There is a page with public DMPs on DMP Online. You are encouraged to make your own DMP public as well. The LIBER Research Data Management Working Group maintains a page with example DMPS. These focus mostly on economics, but may be of use to other Social Scientists as well. The FSS Guidelines for Data Organization include an example DMP for each use case. Informed consent Before collecting data, you are required to inform your respondents about what data you will collect, and what you intend to do with it. This can be through the use of a signed informed consent form, but this is not needed. In any case, the consent should be demonstrable. Ticking a box prior to an electroninc survey, clearly stating in a recording “I agree to be interviewed” (it is wise to separate this from the research data) or sending an email with the same text all are valid forms of consent. Whatever form you choose, you need to make sure your respondents are well informed. For this, there are the following documents: Informed Consent Form (English/Dutch): this form can given to respondents, and should be kept on file (preferably digitally) for the duration of the use of the data. Privacy Statement (English/Dutch): You can send interviewees a privacy statement by email prior to interviews, or put a link to a detailed privacy statement in a digital survey, and then ask the respondent whether they agree to be interviewed. If you collect particularly sensitive data (especially special categories) or do sensitive things with the data (like publishing) make sure to mention this in the question, so repsondents explicitly consent to this. The Faculty Data Steward can help you find the right way to inform your respondents and obtaining their consent. Data Protection Impact Assessment A Data Protection Impact Assessment (DPIA) is a systematic process that helps identify, assess, and mitigate the risks associated with the processing of personal data. While it is never a bad idea to do a DPIA, in some cases it’s mandatory. To check whether you need to do a DPIA, you can fill out the pre-DPIA tool. If the result is that a DPIA is needed, you can contact the Faculty Data Steward to assist in drafting one, or have a look at the DPIA template. Agreements Data Sharing Statement: if students (or student assistants) work on sensitive data, it is wise to have them sign a statement that they will treat the data confidentially. "],["rdm-policy.html", "RDM: VU FSS guidelines for data management Introduction Stepping stones for good data management To whom do these guidelines apply? Underlying policies Abbreviations Definitions", " RDM: VU FSS guidelines for data management Introduction As a faculty committed to excellence in the quality of the research our staff and students undertake, it is essential to have guidelines on good practice in Research Data Management (RDM) as part of our framework to support the integrity of our research. These FSS guidelines serve both as a means of developing and supporting a culture of good practice in data management and demonstrating that we are committed to a culture and environment where high standards are encouraged and expected. The purpose of these guidelines is to reduce work pressure by condensing the various, and often conflicting, regulations into one cohesive set of procedures that ensure maximum compliance. Details on the various underlying policies can be found below. In this document, the following verbal forms are used: “shall”, “are required to” and “must” indicate a requirement; “should” indicates a recommendation; “may” indicates a permission; “can” indicates a possibility or a capability Stepping stones for good data management Before Researchers must follow the ethics review procedure of the Research Ethics Review Committee (RERC). Researchers must write a Data Management plan (DMP) using https://dmponline.vu.nl), so that they can easily provide an up-to-date version to their department head at any moment. Researchers shall ensure that all planned activities with personal data comply with GDPR. In particular: They must plan to take appropriate technical and organization measures to secure data. Because of the wide variety of data used in the faculty, there is not one answer as to what measures are appropriate. Researchers should discuss the measures they take with colleagues, department heads, with the faculty data steward, privacy champion and/or the RDM support desk. They should ensure that all personal data is processed with full consent of all data subjects. If consent cannot be obtained, the researcher must ensure that there is another legal ground for processing the data. A privacy champion can assist with this. They shall ensure that if personal data is handled by third parties, the proper agreements are in place to do this securely, for example Data Processing Agreements. A privacy champion can assist with this. They shall ensure that all data processing activities (collection, analysis, publishing, archiving, etc.) are entered in the VU’s central data processing registry. Currently, DMPs created using the VU template in DMP Online are linked automatically to this registry, meaning the researcher does not need to take additional action for this. Contracts and agreements relating to the commissioning, funding and conduct of research, including data sharing, intellectual property rights, collaboration and non-disclosure agreements must all be processed through IXA-GO to ensure the safeguarding of (the autonomy of) your research. Such contracts must be signed by those with the appropriate delegated authority to do so on behalf of the University. The signature process is a chain of responsibility that starts with the submission from the Researcher for approval of the Head of Department, before the final signature from the Managing Director of the faculty or a member of the Executive Committee of the University. The Data Steward can advise researchers on how to manage this process. During Researchers shall keep their DMP up to date. Researchers should ensure that their data is stored in such a way that it can later be archived in accordance with section 3.3 of these guidelines without excessive effort. This includes: Ensuring data is well-organized (for more information, see the FSS Guidelines on Data Organization); Data is stored in the same place as vital documentation. Depending on the discipline of the researcher, this can include interviewer guides, questionnaires, topic lists, sampling information, power calculations, etc. Making sure the data is accompanied by a basic “Readme File” containing basic metadata such as an explanation of the purpose of the data, who is responsible for collecting it, and how the folder is organized, etc. Researchers must ensure that data is reliably, traceably and securely stored throughout the research life cycle. The VU offers storage infrastructure that meets these requirements (see the storage finder). If project data needs to be stored elsewhere (for example with project partners), researchers must ensure that the storage solution chosen meets these requirements. The data steward will help in this assessment. Researchers must take appropriate technical and organizational measures to secure any personal data. They can store directly identifiable data (see definitions, below) separately from other data, either by storing it on a different server or device, or through encryption. They must not store directly identifiable data longer than needed. Note that it may be impossible to remove directly identifying data without editing the raw data, which would compromise data integrity and provenance. In such cases, the directly identifiable data may be stored as long as long as the rest of the raw data. Researchers are expected to decide what data to destroy what data to keep. Researchers should discuss the choices they make with colleagues, department heads, with the faculty data steward, privacy champion and/or the RDM support desk, and record these choices in their DMP. After Archiving and Registration Researchers must ensure that the underlying data for each published empirical study (article, volume, book chapter, PhD thesis chapter, Research Master’s thesis, consultable internal report, etc.) is archived according to the following: What: all data that can be reasonably deemed necessary to verify the findings of the research. This includes the raw data (or a link to it, if secondary data was used), the data that was analysed and a description of all modifications to obtain the analysed data from the raw data (or the computer code used to perform these modifications) and full documentation of all steps involved in acquiring, processing and analysing the data. Detailed guidelines on what to archive can be found here. When: the data must be archived no later than one month after the publication date, and be available until at least 10 years after the publication date. If this is not possible, a justification for deviating from this should be provided in the DMP. Where: a secure and reliable location that is accessible for verification (see the section on verification below), and that provides a persistent identifier. The archiving options provided by the VU satisfy these criteria. If data needs to be archived elsewhere (for example with project partners), researchers must ensure that the storage solution chosen meets these requirements. FSS follows the ERC’s approach “as open as possible, as closed as necessary”. In practice, this means that public data is preferable, but that personal data does not need to be published1. Should researchers want to publish such data, they should ensure that they meet all legal and ethical requirements to do so, consulting with the faculty data steward if needed. Public data must always be accompanied by a license and, in case of personal data, information about the informed consent procedure. The decision to publish data or not should be explained in the DMP. Who: the first author of the publication is responsible for archiving the data. Second or later authors must know that the data have been carefully stored and how this has been arranged. This is particularly important if the first author does not work at FSS. For PhD candidates and research master’s students, the primary supervisor or the day-today supervisor respectively are responsible for archiving, but can delegate the work to the PhD candidate. Furthermore: Researchers should include in their published empirical studies a data statement containing the repository where the data is archived, the persistent identifier of the data, and instructions on how this data can be accessed and for what reasons. For sensitive data that is not published and that can only be accessed for verification purposes, a persistent email address may be provided where questions regarding the data can be directed. Researchers should ensure that all datasets that they produce are registered on the VU’s Research Portal, including sufficiently descriptive metadata, and the persistent identifier of the data set. Data verification In case of doubts about the research integrity of FSS research, the faculty board can decide that verification of archived (non-public data) is needed. In making this decision, the board shall balance the need for confidentiality and security with the interests of transparency. If it is decided that the data needs to be reviewed, the Faculty Board will then decide who will access the data while ensuring confidentiality of the data and work with VU IT and the Data Steward to ensure that this access is possible. Administrative procedures End of employment If a researcher leaves the VU, the department head should work with the researcher to ensure: That the data for any ongoing projects is properly stored according to these guidelines; That the data for any pending publications is properly archived according to these guidelines; That responsibility for any data sets archived by the researcher on VU infrastructure is transferred to an FSS colleague; and, That the researcher doesn’t lose access to data they need for their further career, if such access can be reasonably organized; for example through the signing of a data transfer agreement between the VU and the researcher’s new institution. Performance and appraisal reviews Adherence to these RDM guidelines will be discussed in performance and appraisal interviews. Formal final responsibility lies with the dean. To whom do these guidelines apply? These guidelines apply to all faculty staff members who conduct research in the context of a temporary or permanent employment contract, all PhD candidates who conduct research under the supervision of a professor, and all research master’s students. The guidelines do not apply to bachelor’s and one-year master’s students, unless their research results in an academic publication. Research conducted by bachelor’s and one-year master’s students falls under the formal responsibility of their supervisors. Underlying policies TThe list below contains the regulations that these guidelines are based on. Since there are often conflicts between the regulations, the list includes a comparison between each item and these guidelines, so that any deviation from the regulation is made explicit. General Data Protection Regulation (GDPR) Date: 2018 Last reviewed: 25/07/2023 URL: https://gdpr-info.eu GDPR FSS Note: The GDPR is too large to include a full comparion here. Netherlands Code of Conduct for Research Integrity , Standards for good research practices Date: Sep-18 Last reviewed: 15/06/2023 URL: https://doi.org/10.17026/dans-2cj-nvwu Code of Conduct FSS In research with external partners, make clear written agreements about research integrity and related matters such as intellectual property rights. FSS guidelines include instructions to do this. The primary contact for FSS researchers about this is IXA-GO. As necessary, describe how the collected research data are organized and classified so that they can be verified and reused. FSS guidelines include instructions to write a readme file which covers this. A template readme file is also provided. As far as possible, make research findings and research data public subsequent to completion of the research. If this is not possible, establish valid reasons for their non-disclosure. The possible exceptions listed (in a footnote in the original text) are included in FSS guidelines, including a requirement to record in the DMP the reasons not to publish data. 12 a. In the event of an investigation into alleged research misconduct, make all relevant research and data available for verification subject to the confidentiality safeguards established by the board of the institution FSS guidelines ensure that all data is archived in a place where it can be accessed for verification purposes. 12 b. In highly exceptional cases, there may be compelling reasons for components of the research, including data, not to be disclosed to an investigation into alleged research misconduct. Such cases must be recorded and the consent of the board of the institution must be obtained prior to using the components and/or data in question in the scientific or scholarly research. They must also be mentioned in any results published. There are currently no provisions for this in the FSS guidelines, since it is not clear what steps should be taken, and what criteria should be satisfied, to qualify for these exceptions. Ensure that sources are verifiable. Verifiability is the cornerstone of the FSS RDM guidelines. All FSS Data should be archived in such a way that verification is possible. Describe the data collected for and/or used in your research honestly, scrupulously and as transparently as possible. FSS RDM Guidelines ask for full documentation of all datasets, and for the data sets to be described with descriptive metadata or readme file. Researchers should also follow this point in their publications, but that goes beyond the scope of the FSS RDM Guidelines. Manage the collected data carefully and store both the raw and processed versions for a period appropriate for the discipline and methodology at issue. The FSS guidelines specify this. Contribute, where appropriate, towards making data findable, accessible, interoperable and reusable in accordance with the FAIR principles The FSS guidelines follow the FAIR principles explicitly. As far as possible, make research findings and research data public subsequent to completion of the research. If this is not possible, establish the valid reasons for this. From the perspective of the VU guidelines, this is redundant with item 11. VU RDM Policy Date: Feb-20 Last reviewed: 15/06/2023 URL: https://libguides.vu.nl/ld.php?content_id=32045526 VU RDM Policy FSS Researchers are responsible for compliance with legal and ethical requirements regarding their research data, including review by ethics committees if necessary. This is included in FSS Policy. Researchers are responsible for ensuring that their research data are reliably, traceably and securely stored throughout the data life cycle and that they are able to report the storage location of their data to the department head, for example upon termination of their employment at the VU. At the same time, department heads are also responsible for making agreements with researchers on such issues, see article 7 under ‘Responsibilities’ in this policy. FSS guidelines ask researchers to use VU-provided infrastructure whenever needed, and if not ensure that the infrastructure lives up to this standard. Researchers are responsible for archiving their research data for a minimum of ten years after research results are published, unless legal requirements, discipline-specific guidelines or contractual arrangements dictate otherwise. The moment of publication is defined as the first online appearance of the publication. If there is no online publication date, the formal publication date of the publisher applies. If a researcher’s employment terminates between the events of submitting a publication and the actual moment of publication, agreements must be made regarding these data archiving responsibilities according to articles 2 and 7 under ‘Responsibilities’ in this policy. FSS guidelines follow this. If the data is not archived for 10 years, motivation is required in the DMP. Researchers are responsible for being able to share their research data for scientific use and verification, by making them accessible (A in FAIR) to others, preferably and where possible with a Persistent Identifier. Before research data are shared for reuse or verification, a researcher has to make sure that this is compliant with applicable legislation and ethical requirements. When research data include personal data, an assessment must first take place to determine whether these data can be shared and if so, under which conditions. FSS guidelines follow this, and explicitly recommend not publishing personal data, unless the researcher can ensure that they meet all legal and ethical requirements for publishing. The VU ensures that research data that are generated at the VU are Findable (F in FAIR) by including descriptions of these datasets in the Current Research Information System (CRIS) of the VU.10 Researchers’ responsibilities in this process are as follows: researchers can perform this registration themselves, or they or their research support staff can request the CRIS administrator vuresearchportal.ub@vu.nl) to do this registration by providing the necessary information (e.g. the storage location of the dataset, author information, project information). Researchers register their data sets on PURE. Researchers who collect and process personal data for their research, must comply with the requirements of the GDPR and the UAVG and, additionally, they must register these activities in a processing register. Keeping a record of processing activities is a legal requirement (imposed by the GDPR). The Privacy Champions in the faculties are the first point of contact for support on these matters. VU guidelines include explict references to GDPR, and the privacy register. Department heads are responsible for arranging agreements with researchers in their departments regarding the management of research data, particularly when a researcher’s employment is ending. See article 2 of this policy for more detail. FSS guidelines include a section on what to do upon contract termination. Faculties must establish their own Research Data Management policies which are applicable to all of their departments and institutes, and that include, where necessary, discipline- specific protocols. FSS has an RDM policy that specifically acknowledges the variety of disciplines within the faculties. Guidelines for the archiving of academic research for faculties of behavioural and social sciences in the Netherlands Date: Mar-22 Last reviewed: 15/06/2023 URL: https://zenodo.org/record/7583831 DSW FSS Preamble The principles of honesty, scrupulousness, transparency, independence, and responsibility form the basis of research integrity (UNL, 2018). Abiding by these principles enlarges trust and quality of academic research, thereby improving its relevance to society. The current guideline is developed with input from all DSW faculties and offers guidance for the archiving of academic research published by researchers at the Dutch faculties of social and behavioural sciences, drawn from the principles of scrupulousness, transparency, and responsibility. The guideline seeks to improve archiving of social and behavioural research using both quantitative and qualitative methods, in order to safeguard continued availability of qualitative or quantitative research data, detailed descriptions of research materials and approaches, and an overview of the data processing and publication processes after the research has been published. This guideline is not meant to replace other existing guidelines or regulations related to data management, open science, data processing agreements and privacy aspects in the design stage of a research project. The document can be seen as an initiative that is part of a broader effort to promote research integrity among researchers focusing on both quantitative and qualitative studies at faculties of behavioural and social sciences in the Netherlands. Rather than functioning as a strict straightjacket, it intends to provide a clear guideline, which can be further fleshed out under the motto ‘apply or explain’, taking into account existing regulations at the faculty or university level. Researchers working in the social and behavioural sciences at a Dutch university will be held to these standards to ensure that research integrity in general and transparency in particular can be ensured. Given the various distinct methodologies of scholarly research carried out under the general “social science” header, there are two main approaches that can be identified and should be implemented to ensure scientific integrity and its future assessment. The first is primarily for quantitative research designs and quantitative data that can most often relatively easily be de-identified (pseudonymized or anonymized) and stored in a repository in full. The second is for scientific research that is structured by qualitative and interpretive research designs and epistemologies that generate data and information that may have a different character and most often cannot be de-identified and stored in an identical manner as quantitative data. Regardless of methodological approach, all researchers have an obligation to follow the standards of integrity and transparency set in this document. All researchers must be aware of the specific regulations that govern their type of research and adhere to these regulations (except where motivated exceptions are allowed). FSS guidelines follow the spirit of these guidelines, but FSS disagrees that qualitative and quantitative data should be treated differently. The reasoning for this can be summarized as follows: While there is difference in the ease of de-identification of quantitative vs qualitative data, this difference is not such that it should have implications for the way data is handled: it is often still very difficult to fully anonymize quantitative data, and it is possible to pseudonymize qualitative data. Even if pseudonymization of qualitative data is impossible, non-pseudonymized data can still be archived following our guidelines. Much of our research combines elements of quantitative data analysis and qualitiative data analysis, making a distinction problematic to put into practice. A distinction would further divide social sciences and complicate efforts to promote inter-disciplinarity. FSS therefore does not differentiate based on qualitative or quantitative, but on the specific nature of the data: for example the privacy risks posed by the data, the IP rights over the data, whether the data is available elsewhere, etc. 1.1 Purpose of these guidelines These guidelines for the archiving of academic research set out the preconditions for the archiving of data, materials and information that form the basis for publications – in other words, (descriptions of) data, materials and information that are needed in order for academic peers and other consumers of the research to replicate, reproduce, and/ or assess the published research results. These guidelines relate to the data, materials and information with respect to publications that appear in their definitive form as of 1 September 2021 . The guidelines are based on the principle of retroactive accountability, i.e. reporting after a publication has appeared. The norm behind these guidelines is that each researcher is responsible for archiving data, materials and information, and the publications based on them, in a responsible and transparent way, in order to keep the data for future verification or checking by academic peers, and re-use. In situations where this document does not provide clear-cut rules, researchers are expected to act in the spirit of these guidelines rather than observing them to the letter. Faculties will be expected to apply these national guidelines. The guidelines will be evaluated every two years, under the responsibility of the deans of the faculties of social and behavioural sciences (DSW). FSS endorses this purpose. 1.2 To whom do these guidelines apply? These guidelines apply to all faculty staff members who conduct research in the context of a temporary or permanent employment contract, all PhD candidates who conduct research under the supervision of a professor, and all research master’s students. The guidelines do not apply to bachelor’s and one-year master’s students, unless their research results in an academic publication. Research conducted by bachelor’s and one-year master’s students falls under the formal responsibility of their supervisors. All researchers at the faculty must adhere to The Netherlands Code of Conduct for Research Integrity . These guidelines are a concrete embodiment of the principle of transparency and the related norms set out in the UNL Code of Conduct. The Netherlands Code of Conduct also requires researchers to make data as open as possible after publication or to document valid reasons for not sharing the data. FSS adopted this exact wording in the RDM guidelines. 1.3 Raw data, personal data and research data Within the framework of the transparency and replicability of research, raw data must of course be retained. Raw data are the unedited data that are collected within the framework of a research project, for example: Registrations derived from experimental research Survey data from questionnaires completed within the framework of research (including longitudinal research), collected by the researcher themselves or by an external fieldwork organization (Transcripts of) video material collected within the framework of qualitative research (open interviews, observations) Notes taken within the framework of qualitative research or research using source material Raw data must always be de-identified as soon as and insofar possible so that they cannot be directly traced back to people or groups of people. Data that can be directly or indirectly traced back to a person are known as personal data. This includes not only name and address details, but also photographs, audio - and video material, and other identifying information. The de-identified raw data and the personal data together form the research data FSS guidelines do not use the word “de-indentificaion” as it can mean both anonymization and pseudonymization, which are related but have different implications for the data. It is assumed the DSW guidelines mean pseudonymization in this section, so that is the wording used in this comparison. FSS do not include the advice to pseudonymize all raw data, for the following reasons: - Once data is pseudonymized, it may no longer be considered raw. - Fully pseudonymizing some forms of data (e.g. audiovisual data) is extremely complex and time consuming. - The identity of the data subject, or factors making indirect identification trivial, may be of crucial importance to the research. Pseudonymization will damage the data set in such cases. FSS therefore takes a pragmatic approach with respect to pseudonymization. It is considered as one of many measures available to the researcher to secure their data, and it is up to the researcher to decide which measures appropriately secure their data. Guidelines concerning publication packages These guidelines relate to all research publications listed in the faculty’s academic annual report. In order to ensure the transparency of qualitative and quantitative empirical research, all information that is needed to be able to assess the results must be archived (in English). This information is stored in a ‘publication package’. The FSS RDM guidelines do not mention the term “publication package”. The term may lead to confusion: first, a researcher may think that the package itself must be published. Second, they may think that all elements need to be archived together. However, neither is the case: data may be archived in a restricted-access repository, and it is acceptable to have some items in a public repository, while others are in a restricted archive, as long as the various components link to each other. 2.1 What must be stored in a publication package? We make a distinction between publication packages resulting from quantitative research and from qualitative research projects, while noting the existence of mixed methods that employ both qualitative and quantitative elements and should be handled according to their main focus. As stated above, FSS does not make a distinction between qualitative data and quantitative data. In the interest of brevity, specific instructions on what to archive are not included in the FSS RDM Guidelines. The focus is instead on the reasoning behind selecting data to archive: “all data than can be reasonably deemed necessary to verify the findings of the research.” A separate document with specific FSS Archiving Guidelines exists which is linked to in the general RDM guidelines. The FSS Archiving Guidelines closely follow the DSW guidelines for quantitative data. 2.1.1 Quantitative research The following materials must be stored for each published empirical study (article, volume, book chapter, PhD thesis chapter, Research Master’s thesis, consultable internal report, etc.): NA The published (or accepted) manuscript or publication. Included in FSS Archiving Guidelines. A brief description of the problem definition, research design, data collection (sampling, selection and representativeness of informants) and methods used. An electronic version of the published manuscript will generally suffice. This is considered redundant with point 1. The instructions, procedures, the design of the experiment and stimulus materials (interview guide, questionnaires, surveys, tests) that can reasonably be deemed necessary in order to replicate the research. The materials must be available in the language in which the research was conducted. The publication package must be in English. This has been reworded slightly in the FSS Archiving Guidelines, since replication is not possible for all research at the faculty. We therefore only talk about verification. The FSS guidelines require materials to be available in the original language, and in English. When using primary data, the (de-identified) raw data files (providing the most direct registration of the behaviour or reactions of test subjects/respondents, for example an unfiltered export file of an online survey or raw time series for an EEG measurement, e-dat files for an E-Prime behaviour experiment, recordings or transcripts of interviews, descriptions of observations, archive and other source or media material). Documentation of the steps taken to de-identify the data and a blank consent form. If the raw data files have been accessibly stored in an external archive (such as storage facilities at DANS), making reference to the files in this archive will suffice. Such externally archived raw data may include primary or secondary data. Raw data may not be changed once they have been made digitally available. FSS Archiving Guidelines do not require the data to be pseudonymized, as outlined above, but otherwise this is included. Computer code (for example Atlas.ti, SPSS/JASP syntax file, MATLAB analysis scripts, R code) describing the steps taken to process the raw data into analysis data, including brief explanations of the steps in English, for example a brief description of the steps taken in the qualitative analysis of primary research data, i.e. themes, domains, taxonomies, components. Included in FSS Archiving Guidelines for applicable data sets. The data files (either raw or processed) that were eventually analysed when preparing the article (e.g. an SPSS data file after transforming variables, after applying selections, etc.) The latter is not necessary if the raw data file was directly analysed. Included in FSS Archiving Guidelines, with an exception for cases where this data can easily be constructed from the raw data by running a script. In such cases providing the script and the raw data suffices. Computer code (for example syntax files from SPSS/JASP, Atlas.ti, Matlab, R; syntaxes of tailored software) describing the steps taken to process the analysis data into results in the manuscript, including brief explanations of the steps in English. Included in FSS Archiving Guidelines for applicable data. The data management plan Included in FSS Archiving Guidelines. A readme file (metadata) describing which documents and files can be found where and how they should be interpreted. The readme file must also contain the following information: Name of the person who stored the documents or files Division of roles among authors, indicating at least who analysed the data Date on which the manuscript was accepted, including reference Date/period of data collection Names of people who collected the data If relevant: addresses of field locations where data were collected and contact persons (if any) Whether or not an ethical assessment took place before the research, and, if relevant, study reference from and statements made by the Ethics Review Committee Whether the data is made open or not and if not, a valid reason for not opening up the data Included in FSS Archiving Guidelines. A VU template is expected to be available soon. The readme file must be sufficiently clear. A relevant fellow researcher must be able to replicate the results discussed in the publication based on the components of the publication package. Included in FSS Archiving Guidelines, without the word “replicate”. Documents relating to the ethical approval or a reference to such documents. Included in FSS Archiving Guidelines, with wording specific to our ethics committee. 2.1.2 Qualitative research For qualitative, interpretative methodologies, a distinction should be made between the two main criteria for research integrity, i.e., transparency and reproduction. Transparency is a valid and legitimate demand also for qualitative research (and data), but reproduction is not considered possible in all cases, due to the very nature of the research designs and epistemology. Qualitative data are often impossible to fully de-identify and the research data is often gathered in forms and formats that cannot be stored in a digital repository. Of course, some of these data may be highly sensitive and cannot be shared with others without breaking ethical rules and the confidentiality that is often guaranteed to informants and other (human) sources of information. But as the aim of these guidelines is not sharing data but storing data, qualitative research should also be archived. Sensitive data should be stored on secured faculty servers. And when the format does not allow researchers to store original objects, it suffices to store pictures of the material. These data should be stored safely in a way that is accessible to the researcher who gathered the data. Researchers are therefore expected to store their data safely and to make specific plans for the time period of storage of their data, where and in which manner the data will be stored, and what will be done with the data once the research project ends or, for longterm ongoing research, once the researcher retires from research reporting etc. This calls for an elaborate and transparent data management plan or another, similar or equivalent form of data storage plan that describes: what kind of data will be gathered, by whom, in what format, where and in which form these will be stored, and to what extent and under what conditions this data will be shared and with whom, and any specific steps that will be taken to share the data that is safe to be shared. The researcher should be aware that according to the Netherlands Code of Conduct for Research Integrity there may be (highly exceptional) cases in which there are compelling reasons for components of the research, including data, not to be disclosed to an investigation into alleged research misconduct. Such cases must be recorded and the consent of the board of the institution must be obtained prior to storing the components and/or data in question. This documented exception must also be mentioned in any results published. In addition to safely storing data, the (qualitative) researcher shall make sure to maintain a record of the following metadata: The dates that the researcher carried out the data collection (e.g. dates of interviews or observation, period(s) of time spent in the field (start date and return date), etc.; The type of activities carried out (e.g., participant observation, number of interviews, frequency and character of observation, familiarizing oneself with the field, informal and formal conversations, other types of recording activities); Interview and observation guides (if available); Any hard evidence of the period of time spent in the field (e.g. flight reservations, train tickets, etc.). FSS does not provide separate archiving guidelines for qualitative data. Archiving of qualitative data is important for verification purposes, and there is no reason why qualitative data should not be archived along the standards outlined above. 2.2 When must a publication package be stored? A publication package must be stored within one month after the definitive publication of the manuscript. A publication package must be stored for each submitted research master’s thesis. A publication package must be stored for each empirical chapter of a PhD thesis submitted to the thesis committee (or one single publication package if the thesis is a monograph). Once a publication package has been stored, it will be fixed and can then no longer be modified (read only). FSS guidelines follow this. 2.3 Who is responsible for storing publication packages? If the first author works at one of the faculties of behavioural and social sciences, they will always be responsible for the archiving of the publication package, i.e. the storage of raw and edited data, syntax and materials, and additional information about the publication process as discussed above. Second or later authors who work at a faculty of behavioural and social sciences must know that the data have been carefully stored and how this has been arranged. This is particularly relevant if the first author does not work at a faculty of behavioural and social sciences. If an FSS researcher is first author, they are responsible for archiving. If they are second or later, they “must know that the data have been carefully stored and how this has been arranged.”, regardless of first author affiliation. If the first author works at one of the faculties of behavioural and social sciences, the second or later author may assume that the first author will follow the guidelines of his or her own university, and the second or later author will not have to create a publication package. See above. For PhD candidates and research master’s students, the primary supervisor or the day-today supervisor respectively are responsible for storing publication packages. The primary supervisor or day-to-day supervisor may delegate the execution of this task, but they will continue to bear final responsibility. This is in FSS guidelines. In collaborative projects a specific plan to clarify responsibilities related to the data after the project might be required. The person who coordinates the research programme that covers the publication (which, depending on the faculty in question, could be a professor, head of programme or head of department) is ultimately responsible. This is not explicit in the FSS guidelines. Adherence to the guideline will be discussed in performance and appraisal interviews. Formal final responsibility lies with the dean. This is in FSS guidelines. 2.4 Who has access to the publication package? Publication packages should be accessible by more than one researcher. The first author will have reading rights, but no right to delete or change versions. The first author will have writing rights for adding new versions. If a faculty has appointed a ‘co-pilot’ to check the analysis or a data steward to consider data management compliance, they will also be assigned reading rights. The faculty board can assign reading rights to a specific official to prepare for audits of publication packages on its behalf, for example, the coordinator of a research programme or a member of an academic integrity committee. After publication, academic peers should be granted access to the publication package if they make a reasonable request to verify or examine the published research results in the context of academic debate. The archiving infrastructure offered by the VU (the Yoda Vault) follows this. Minimum storage period For the retention period regarding research, a distinction is made between research data (and software) and the documentation of the process that has been carried out. Publication packages must be centrally stored on a secure faculty server facility for at least 10 years after the publication appeared. In the event of research (or secondary research) data including personal data, the principle of data minimization (conform GDPR regulation) must be applied as soon as possible. The Netherlands Code of Conduct for Research Integrity offers options to deviate from the retention period of 10 years. However, in that case the raw and processed data must be saved for a period suitable for the discipline and the methodology. The following could be taken into consideration when deciding on the the nature (and especially the privacy sensitivity) of the data; the need for source material to substantiate the results; the applied scientific value of the research results; the effort to make the data available for re-use; the efforts of long-term preservation; the usefulness of source material for follow-up research. The retention period of data management plans and data management protocols of projects, faculties and research institutes is at least 10 years, but not shorter than the retention period of the dataset . These documents primarily relate to policy making, execution and financing of research, and quality assessment. Also included here are the (legal) advice of ethical committees and evaluations and further agreements with research partners. Following VU policy, the FSS guidelines say to archive for 10 years, with the possibility to deviate if motivated in the DMP. 3.2 Data minimization and retention Data that can be traced back to individuals may in principle not be linkable to research data when this is no longer necessary for the purposes of the study. These personal data must be destroyed once they are no longer necessary for the purpose for which they were collected. Some specific studies may require retention of data that can be traced back to individuals, for example for the purpose of follow-up research or for longitudinal studies. Technical and organizational measures to protect the rights of data subjects need to be documented and will preferably be standardized for specific research scenarios. Protecting the right of data subjects is particularly important for raw data that cannot be de-identified (for example, video- and audio data). One complicating factor lies in the wish to retain personal data for the purpose of reviewing the integrity of the research itself, for example to check whether the participants did indeed participate in the research. If such integrity reviews are regarded as part of the research whose integrity is reviewed and considered necessary in the field it is allowed to store data that can be traced back to individuals for this purpose. When research is published, such personal data must be stored separately; not in the publication package. As an alternative option, researchers, faculties and research institutes can develop a protocol to monitor the integrity of the research before archiving, after which the personal data can be deleted. It is not necessary to store the personal data for the sole purpose of enabling participants to exercise their rights under the GDPR. The head of the relevant department or research program is responsible for monitoring the destruction of the research data on the required date. Official final responsibility lies with the dean. The discussion by DSW ignores the fact that once data is pseudonymized, it is no longer raw data. The decision on what directly identifying data to keep and what not is thus extremely context-dependent. FSS trusts its researchers to make the right call, and thus takes a pragmatic approach here, where researchers decide on a case-by-case basis what to keep, and keep a record of their decisions in their DMP. 3.3 How are storage and archiving of research data arranged? The raw de-identified data must be saved on a faculty server that satisfies the relevant requirements for data storage in terms of security, robustness and automatic back-up facilities. The recommendation is to save the raw data in read-only format, before the data are made available for processing. Raw data stored in this way become fixed, which means that researchers will no longer be able to modify them deliberately or by accident. The FSS guidelines recommend researchers use VU infrastructure (such as Yoda) which satisfy this. All data that can be traced back to individuals must be stored on a second faculty server, which is physically separate from the first faculty server and thus from the raw data. If a key is required to link pseudonymized raw data to the personal data, this key must be stored on the second faculty server. This includes raw data that cannot be de-identified and must be stored, such as audio- and video data in its original format that cannot be transcribed. The FSS guidelines don’t include this as a hard requirement, since few researchers have access to a second server. Currently, suggested alternatives to this are: - Encrypting directly identifying data. - Making sure that directly identifying data is not synced to local devices. External storage of raw data, for example in national or international data archives such as DANS – which makes the data publicly available, retrievable and citable – is recommended and in some cases required, for example when NWO requires this in a contract. However, this does not relieve researchers of their duty to store the data internally on the first faculty server. FSS does not comply with this, as archiving data twice puts an undue burden on researchers, and risks creating conflicting versions of data sets. Individual storage on an own hard drive, USB stick or cloud solution such as Dropbox does not suffice. Data that are collected within the framework of PhD or postdoc research must be archived in such a way that continuity is ensured when the PhD candidate or postdoc in question leaves the faculty. This is not explicit in FSS policy, but data needs to be stored on VU infrastructure. These storage requirements do not apply to sections of raw data that are managed by external organizations. Researchers who use data from external organizations must verify that the organization in question stores its data in accordance with a protocol that satisfies the requirements of these faculty guidelines. FSS guidelines are not explicit about this. Faculty-specific policy Individual faculties can choose to add the following rules to the above-mentioned guidelines concerning publication packages and storage of raw data: 1. Faculties may decide that the guidelines also apply to data collected within the framework of one-year master’s and bachelor’s research projects. The supervisor can then be appointed as the responsible party. 2. Faculties may decide to extend these guidelines to include storage of all data, including research that has not been published. This must be set out in a data management plan. 3. Faculties may define rules concerning ownership of data, for example that storage of data in a publication package will not result in a change of ownership. 4. Faculties may decide to make random inspections to check the existence and quality of publication packages. 5. Faculties may use different time periods and, for example, indicate that a publication package must be archived upon acceptance (rather than publication) of a manuscript. 6. Faculties may decide that each manuscript must state where the data are stored (a data statement) and which roles the various authors played. FSS does not extend to Bachelor and 1-year Master students, as sufficient infrastructure is not available for this. For now, FSS policy only applies to published research. VU has central policy that data is owned by the VU. FSS encourages department heads to ensure that researchers who leave FSS can continue to work with their data. Random inspections do not fit within the culture of trust that FSS aims to cultivate. DSW guidelines and VU guidelines are both for 10 years, and there is no reason to deviate. This is included in the FSS guidelines. FAIR Principles Date: Mar-16 Last reviewed: 15/06/2023 URL: https://www.go-fair.org/fair-principles/ FAIR Principles FSS F1. (Meta)data are assigned a globally unique and persistent identifier FSS guidelines require data to be archived in a repository that issues a unique and persistent identifier. F2. Data are described with rich metadata (defined by R1 below) FSS guidelines are for researchers to do this on PURE (at a minimum). F3. Metadata clearly and explicitly include the identifier of the data they describe FSS guidelines are for researchers to do this on PURE (at a minimum). F4. (Meta)data are registered or indexed in a searchable resource PURE meets this criterion. A1. (Meta)data are retrievable by their identifier using a standardised communications protocol A1.1 The protocol is open, free, and universally implementable A1.2 The protocol allows for an authentication and authorisation procedure, where necessary Public data repositories provide a link that works for this. For private data, researchers have to provide persistent contact details. A2. Metadata are accessible, even when the data are no longer available FSS relies on PURE and Yoda for this. I1. (Meta)data use a formal, accessible, shared, and broadly applicable language for knowledge representation. FSS does not have specific guidelines to ensure machine readability, but does recommend all archiving to be done in English. I2. (Meta)data use vocabularies that follow FAIR principles FSS requires all documentation to be uploaded in the same repository, under the same identifier as the data. I3. (Meta)data include qualified references to other (meta)data FSS has no specific guidelines for this. R1. (Meta)data are richly described with a plurality of accurate and relevant attributes R1.1. (Meta)data are released with a clear and accessible data usage license R1.2. (Meta)data are associated with detailed provenance R1.3. (Meta)data meet domain-relevant community standards FSS requires all public data to include licenses , and all personal data to have information about the informed consent procedure. Data that is not made publically available, but only archived for verification purposes, should only be made available under strict data transfer agreement that limit the use of data to the verification of the findings of the original research. To ensure provenance, FSS requires researchers to upload the rawest data they can, and a description of all modification to this data. Guidelines for Anthropological Research: Data Management, Ethics and Integrity Date: 2019 Last reviewed: 15/06/2023 URL: https://antropologen.nl/app/uploads/2019/01/guidelines-for-anthropological-research.pdf ABV FSS Data ownership, data protection, and Open Science: Anthropological research materials cannot be considered as disembodied and transferable ‘data’. As much anthropological knowledge is co-produced with our interlocutors, we cannot transfer possession, access, or ownership rights of ‘our data’ to others (such as employers, fellow-scientists, or the general public) without their consent. Based on relations of trust, our interlocutors often share personal and sensitive material with us. We are responsible for keeping such personal and potentially sensitive materials protected and confidential. Providing open access to fieldwork materials is therefore limited; in the case of an integrity inquiry we can at most provide confidential access. The definition of data as used by the ABV is slightly different than that used by most of the policies that the FSS RDM guidelines are based on. Therefore, for the purposes of the FSS RDM Guidelines, anthropological research materials are considered data. However, the FSS RDM policy fully supports researchers stiving to keep personal and potentially sensitive materials protected and confidential: protection of respondents’ privacy is a valid reason not to grant open access to data. Anonymizing ethnographic research materials is often not a workable solution, as it is not only overly time-consuming but above all removes so much detail, that the material becomes virtually meaningless The FSS RDM Guidelines are written with the realization that anonymization (or more often pseudonymization) comes at a real cost (in terms of time, effort, and data quality), and that only the researcher can determine whether the costs of anonymization/ pseudonymization outweigh the benefits. It therefore lists pseudonymization as something researchers can do to further secure their data, not as something they must do. Anthropological knowledge production: Anonymity as default option and non-disclosure of fieldwork data are a precondition for anthropological knowledge production before they are turned into ethical concerns. If we do not allow for anonymity and the protection of our fieldwork material, many of our interlocutors would be hesitant, if not positively reluctant, to share their insights with us. Moreover, much of the knowledge we co-produce with our interlocutors is embodied and personal. Our fieldnotes function as a memory bank, rather than a complete record of knowledge acquired. Using this material without such personal knowledge runs the serious risk of misinterpretation of the material. This character of anthropology as a science dealing with research materials that can often not be reduced to ‘data’ has serious ethical consequences, especially regarding the following. This relates to the points above: for the FSS RDM Guidelines, field notes would fall under the category “data”, but the practical implications are limited: it is not necessary for data (and thus field notes) to be published or be interpreted by others. For verification purposes, the data should be archived as a record of the steps the researcher took to arrive at the conclusions in publications. Such archived data will only be accessed in case of doubts regarding academic integrity. Academy of Management Code of Ethics Date: undated Last reviewed: 15/06/2023 URL: https://aom.org/about-aom/governance/ethics/code-of-ethics AoM FSS 2.4.1. When maintaining or accessing personal identifiers in databases or systems of records, such as division rosters, annual meeting submissions, or manuscript review systems, AOM members delete such identifiers before the information is made publicly available or employ other techniques that mask or control disclosure of individual identities. FSS guidelines require pseudonymization before publication of data sets. 2.4.2. When deletion of personal identifiers is not feasible, AOM members take reasonable steps to determine that the appropriate consent of personally identifiable individuals has been obtained before they transfer such data to others or review such data collected by others. FSS requires researchers to follow GDPR which has a more comprehensive approach on what can and cannot be done without consent. 2.5. Electronic Transmission of Confidential Information:  AOM members use extreme care in delivering or transferring any confidential data, information, or communication over public computer networks when conducting AOM work. AOM members are attentive to the problems of maintaining confidentiality and control over sensitive material and data when the use of technological innovations, such as public computer networks, may open their communication to unauthorized persons. Following GDPR, FSS requires researchers to take appropriate technical measures to secure personal data. Beroepscode Nederlandse Kring voor Wetenschap der Politiek Date: May-08 Last reviewed: 15/06/2023 URL: http://politicologie.nl/wp-content/uploads/2021/10/Beroepscode-2008.doc NKWP FSS II.5: Politicologen dienen bij het verrichten van onderzoek maximaal zorg te dragen voor de intersubjectieve controleerbaarheid van hun bevindingen die zowel mogelijk dient te zijn voor collega-politicologen alsook voor derden die niet tot de kring der politicologen behoren. Daartoe zijn zij verplicht om, na de eerste publicatie dienaangaande, hun originele gegevens en relevante documentatie daarvan, eventueel onder bepaalde restricties, ter inzage en ter beschikking van derden te stellen teneinde replicaties en vergelijkingen mogelijk te maken. Het verdient aanbeveling de gegevens na op zijn laatst twee jaar onder te brengen in een openbaar data-archief. This matches closely FSS Guidelines. FSS requires researchers to archive data in such a way that findings are verifiable, and also recommends publishing data. III.4 Gegevens die ten behoeve van wetenschappelijke doeleinden zijn verzameld, mogen uitsluitend voor wetenschappelijk onderzoek worden gebruikt en dus niet worden aangewend voor justitiële of commerciële doeleinden. FSS guidelines makes no such requirement, as it may be difficult to put in practice. “Commercial purposes” is poorly defined, and excluding those purposes may prove more restrictive than anticipated. It is therefore advised to make published data available under that doesn’t limit such use. For more information see: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3234435/ III.5 De direct identificerende gegevens van de informanten blijven anoniem voor derden, tenzij de informanten uitdrukkelijk toestemming hebben gegeven om hun identiteit in de openbaarheid te brengen. Onder direct identificerende gegevens worden verstaan: naam, adres, telefoonnummer, fiscaal nummer, kortom, gegevens die onmiddellijk tot één persoon te herleiden zijn. Reeds in het proces van gegevensverzameling dient vertrouwelijk te worden omgegaan met identificerende persoonsgegevens. Vertrouwelijkheid in deze fase houdt onder meer in dat direct identificerende persoonsgegevens gescheiden van andere gegevens worden bewaard en daaraan verbonden zijn door versleuteling. Als politicologen het vergaren van gegevens laten verrichten door anderen, zien ze er op toe dat die het in dit artikel gestelde in acht nemen. Politicologen zorgen ervoor dat direct identificerende gegevens niet in handen van derden komen, tenzij deze derden gehouden zijn aan de regels van deze code. Direct identificerende gegevens worden na afloop van het veldwerk vernietigd als ze niet meer nodig zijn voor het controleren van verzamelde gegevens. Als regel wordt een termijn van zes maanden na het afsluiten van het veldwerk aangehouden. FSS guidelines are roughly in line with these requirements, but explicitly acknowledge that it may be difficult to remove directly identifying information while simultaneously maintaining data integrity and provenance. Beroepscode Nederlandse Sociologische Vereniging Date: 2002 Last reviewed: 15/06/2023 URL: https://www.nsv-sociologie.nl/?page_id=17 NSV FSS Sociologen dienen bij het verrichten van onderzoek maximaal zorg te dragen voor de intersubjectieve controleerbaarheid van hun bevindingen die zowel mogelijk dient te zijn voor collega-sociologen alsook voor derden die niet tot de kring der sociologen behoren. Daartoe zijn zij verplicht om, na de eerste publicatie dienaangaande, hun originele gegevens en relevante documentatie daarvan, eventueel onder bepaalde restricties, ter inzage en ter beschikking van derden te stellen teneinde replicaties en vergelijkingen mogelijk te maken. Het verdient aanbeveling de gegevens na op zijn laatst twee jaar onder te brengen in een openbaar data-archief. FSS guidelines are in line with this. Gegevens die ten behoeve van wetenschappelijke doeleinden zijn verzameld, mogen uitsluitend voor wetenschappelijk onderzoek worden gebruikt en dus niet worden aangewend voor justitiële of commerciële doeleinden. FSS guidelines makes no such requirement, as it may be difficult to put in practice. “Commercial purposes” is poorly defined, and excluding those purposes may prove more restrictive than anticipated. It is therefore advised to make published data available under that doesn’t limit such use. For more information see: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3234435/ De direct identificerende gegevens van de informanten blijven anoniem voor derden, tenzij de informanten uitdrukkelijk toestemming hebben gegeven om hun identiteit in de openbaarheid te brengen. Onder direct identificerende gegevens worden verstaan: naam, adres, telefoonnummer, fiscaal nummer, kortom, gegevens die onmiddellijk tot één persoon te herleiden zijn. Reeds in het proces van gegevensverzameling dient vertrouwelijk te worden omgegaan met identificerende persoonsgegevens. Vertrouwelijkheid in deze fase houdt onder meer in dat direct identificerende persoonsgegevens gescheiden van andere gegevens worden bewaard en daaraan verbonden zijn door versleuteling. Als sociologen het vergaren van gegevens laten verrichten door anderen, zien ze er op toe dat die het in dit artikel gestelde in acht nemen. Sociologen zorgen ervoor dat direct identificerende gegevens niet in handen van derden komen, tenzij deze derden gehouden zijn aan de regels van deze code. Direct identificerende gegevens worden na afloop van het veldwerk vernietigd als ze niet meer nodig zijn voor het controleren van verzamelde gegevens. Als regel wordt een termijn van zes maanden na het afsluiten van het veldwerk aangehouden. FSS takes a pragmatic approach here, where researchers need to decide on a case-by-case basis what to keep, and keep a record of their decisions in their DMP. Abbreviations DMP Data Management Plan RDM Research Data Management FSS Faculty of Social Sciences VU Vrije Universiteit Amsterdam GDPR General Data Protection Regulation RERC Research Ethics Review Committee Definitions Personal Data All data that can be directly or indirectly tied to a living person. Identification Two types of identification are possible, based on research data: Direct: the data includes information that directly reveal the identify of a respondent, such as name address, phone number date of birth, etc. Indirect: the data can be combined with other information to reveal the identity of a respondent. Indirect identification is extremely difficult to prevent, and possible with most FSS Data sets. Data Storage Storing data during the research process, when it’s actively being worked on Data Archiving Keeping data for verification purposes, usually not publicly available Verification Review to assess whether the data supports the conclusions drawn in a publication. Registration Entering the details of a data set (but not the data set itself) on a public page, such as PURE. Valid grounds not to publish data include Intellectual Property Rights, personal data protection and confidentiality, security concerns, as well as global economic competitiveness, and other legitimate interests. These exceptions can be found here (paragraph 14)↩︎ "],["rdm-faq.html", "RDM: FAQ General Data Storage and Security Personal Data Sharing Data and Notes Data Management Plans (DMPs) metadata and FAIR Data", " RDM: FAQ General Where can I go with questions about Research Data Management? Either the Faculty Data Steward (Koen Leuveld, k.leuveld@vu.nl) or the Library’s RDM Support Desk: rdm@vu.nl. The Data Steward can help you best with questions that are specific to the work we do at the faculty, and with questions about specific grants; the RDM Support Desk is best equipped to deal with questions that could be asked by any VU researcher, for example about storage or archiving options. But both work together, so you can’t ask the wrong person. Where can I find more information about Research Data Management? We maintain a number of resources you can consult. At the VU level, there is the Research Data Support Portal which contains links to anything you might want to know about RDM, and the library maintains a series of Libguides explaining various topics related to the management of your data. At the faculty level, the data steward maintains a page giving advice that is specific to researchers in Social Sciences, including links to content you can use in proposals. I don’t have data. I only have observations. As RDM experts, we would say that observations are also a type of data. But that doesn’t really matter: in any case, you want to protect your observations, make backups of your observations and make sure that they are archived securely or shared with the world so that you can demonstrate you did your research well. That is to say, many important aspects of Research Data Management apply whether you call your observations data or not. Data Storage and Security Where should I store my data? Our advice is to use Yoda for storage and archiving, even for sensitive data, and only use VU-managed to devices to access the data. You can find other options in the Storage Finder, but check with the Data Steward if they work for the sensitivity level of your data. What is the difference between data storage and archiving? Data storage refers to where you save your data during the research. Your data storage option needs to be available to all collaborators, while still ensuring a sufficient level of security. Data archiving is where you keep your data after you are done with it, but it may need to be accessed when there are doubts about research integrity. Your data archiving solution can be publicly accessible if there is no sensitive data, or restricted-access if there is. The solution needs to be permanent and secure, so that the data cannot be changed, and any links to it will remain functional indefinitely. What security measures should I take? When using personal data (see below), per GDPR you should take “appropriate organizational and technical measures” to secure your data. The specific actions you should take are not set in stone; you should consider the potential consequences of a data breach, and whether or not the actions you would have to take to prevent them are reasonable. All VU storage solutions offer a number of security measures. For example, access is only allowed using passwords and multi-factor authentication. If your data is sensitive, there is a number of additional security measures you can take that reduce the risk of data leak, either by reducing the chance a leak happens, or by reducing the impact of a leak: Make sure people only have access to the data they need to do their task in your project. For example, with Research Drive it is possible to give each collaborator only access to the folders they need. Don’t sync data from your Research Drive to your personal computer if you don’t have to. For example, once you are done with your raw data, having it on your personal computer only increases the chance that your data is leaked: keep the raw data online-only, and only sync the processed (pseudonymized) data you are working on. Make sure everyone in your project is trained in security procedures, such as strong passwords, not clicking attachments in emails from unknown senders etc. Pseudonymize your personal data by removing any directly identifying information, so that any data that is leaked is less likely to be linked to your respondents. If you need to keep the directly identifying data (for example, because it’s part of your raw data which you want to keep to demonstrate the provenance of your data, or because you need to contact participants for follow-up), make sure this data will not be leaked at the same time as the pseudonymized data. You can do this either by storing it separately or by encrypting it. See “When should I pseudonymize?”, below. Encrypt your data, so that if someone accesses the hard drive that holds your data, they can’t read the data. Software such as Cryptomator makes encryption very convenient. Encryption does have a large downside: loss of your password means loss of the data. You can use a password manager to minimize this risk, but it is wise to think twice before deciding to use encryption. For help on deciding what measures are appropriate for your data, and with the practical implementation of any of these, you can contact your data steward. Personal Data What is personal data? Personal data is any data that can be directly or indirectly linked to a living person. You can directly link data to a person if a direct identifier like their name, phone number, email address etc. is included in the data. You can indirectly link the data if you can combine the data with another piece of data or information to find the person who the data is about. This is possible for more data than you think, so if you collected data from people, it’s safe to assume your data is personal data, even if you remove things like names, phone numbers and addresses. What is the difference between anonymization and pseudonymization? Both these terms mean that you make it less likely that the data that you have can be linked to your respondents, increasing the security of your data. In case of pseudonymization, you remove the possibility of directly linking the data to your respondents, by removing things like names and addresses from the data. Anonymization removes entirely the possibility of linking your data to your respondents, both directly and indirectly. This means that the data is no longer personal data, and GDPR does not apply. However, anonymization is difficult and we don’t usually recommend it (see below). When should I pseudonymize? There is no “one-size-fits-all” answer to this: in general, we do recommend pseudonymizing your data, but in some cases the benefits of pseudonymization may not outweigh the costs. These costs and benefits depend on the nature of your data. A tabular data set is easily pseudonymized by dropping certain variables and generating random identifiers, so it should probably be pseudonymized. On the other hand, for an audio recording it may be practically impossible to edit out all the names. Likewise, the benefits differ; for a dataset containing speeches by famous politicians, leaving out the names will not make identification appreciably more difficult, and yield no security benefits as the data is publicly available anyway. Whether the costs of pseudonymization outweigh the benefits thus depends on the specific project. If you feel the costs don’t outweigh the benefits, feel free to contact your Data Steward to see if they agree, and make sure to write down your reasoning in your Data Management Plan. Should I keep my unpseudonymized data? If so, where? If possible, directly identifying data is kept completely separate from research data. For example, your Qualtrics form should not contain fields for email addresses if that’s not needed for the research itself. If you need email addresses to send rewards, use a separate form. In this way, you can destroy any personal data as soon as possible, without editing the raw data. However, this is not always possible, since some times the directly identifying data is integral part of the raw data (for example in video recording). In these cases you should not destroy the data, because you should keep an unedited version of your data for transparency purposes. This raw copy of the data should be stored safely, and in such a way that a data breach doesn’t necessarily mean a breach of both pseudonymized and unpseudonymized data. Examples are: Store the raw data on a separate server (however, most research programs don’t have two servers available). Store both raw and pseudonymized data on the same server (or device) but encrypt the raw data. You should make sure that you can’t lose your encryption password, or else you lose your raw data. Keep both both pseudonymized data on the same server, but make sure the raw data is never synced to personal computers or other devices (for example by adding it to a Yoda Vault). This way, the raw data is protected from the most common data breaches (e.g. losing a laptop in the train). Why is it so hard to anonymize data? Anonymization is potentially very attractive because it removes the need to comply with GDPR. However, it is difficult to combine with the goals of researchers in practice. This is because it will almost always involve making data less detailed, which will harm your ability to draw conclusions from the data. To see why, first consider a quantitative data set about work satisfaction, containing gender and age of all respondents. If I know my colleague is a respondent in this survey, I may be able to infer things about my colleague from the public data set. If only one person in the data set matches his age and gender, I have successfully (indirectly) identified him in the data set. If there are multiple people matching his age and gender are present, but none has indicated liking their colleagues, I have still inferred something about him, and may become very disappointed! To prevent me from identifying of my colleague, you as the researcher should thus ensure that there are no unique combinations of age and gender (for example by using broader age bins) and that within each combination of age and gender there is sufficient variation in answers that nothing can be inferred about individuals (so there is always a mix of people who like their colleagues and those who don’t). It is easy to see how the binning of variables may lead to less precision in the analysis, and how difficult it is to ensure that proper variation exists in all (combinations of) variables. There are ways to do this, but it is usually more attractive to keep the data as personal data, even if this puts restrictions on data use due to GDPR. Qualitative data sets are usually so rich that all observations are unique, and thus potentially identifiable by someone who knows your respondents well (or otherwise has detailed information on them). Qualitative data is therefore usually impossible to fully anonymize, though pseudonymization may be possible. I know it’s difficult, but I would still like to anonymize my data, how do I do this? That’s great! A good place to start is the R package sdcMicro. Your data steward may be able to help out when using it. Alternatively, there is Amnesia. Note that anonymization means modifying your data, so if you want to anonymize data for replication purposes, not all analyses that you did with your unanonymized data can be fully replicated using anonymized data. This is acceptable, if explained properly in your paper (e.g. in a footnote). I don’t have informed consent forms for my research. Is that bad? It’s not necessarily bad, because written informed consent is only required by law in cases of health research (where WMO applies). You can have participants give informed consent orally if you’re not doing WMO research, but make sure you record it and store it safely. You can ask advice from your data steward or privacy champion if you will ask oral informed consent. There are also other legal grounds (than informed consent) on which you can do research. However, if you should have asked informed consent, but did not do so, that could be bad and we recommend that you contact your privacy champion as soon as possible. Sharing Data and Notes Can I publish personal data? Yes you can. But make sure: Your respondents have given explicit consent to publishing the data; To use VU provided services, such as OSF, Yoda or DataverseNL; Not to publish more than needed. In particular, the data should be pseudonymized; and, You publish nothing sensitive, and your respondents run no risk because of the data you publish. I don’t want to share my data, because participants in my research (or other people) may get in trouble. In that case, it is not ethical to share them and we recommend that you do not do so. It is still important to archive your data for verification purposes. The Yoda Vault exists for this exact purposes: data stored there can only ever be accessed by other researchers who have a reasonable request for verification. In your DMP you can outline your reasoning why you don’t want to share your data. Nobody else but me will understand my notes. Then why should I share them with others? If your notes contain personal data, you should not probably not share them at all, but you should still archive them so that it can be verified that your research has been done in the way you claim in your publications. If the notes do not contain personal data, sharing your notes is a good way of opening up your research. It’s best not to assume no one is interested in your notes. Even if you think your notes are unreadable, someone may still find them of great use. For example, someone who wants to do research into how researchers take notes, or someone studying early 21st century hand writing. If you want to share your notes in a more useful and readable way, but are worried about the workload you could also consider cleaning up only a subset of them and sharing that. Small steps to more transparent science can very worthwhile! In the informed consent forms, I didn’t ask if data may be reused by other researchers. Can I share them now? In this situation, you cannot share the personal data with researchers outside the VU. There are two things that you could do: If possible, go back to your participants and ask them if other researchers may reuse their data; If this turns out to be impossible, anonymize the data. Then the data are no longer personal. We do recommend that you ask your data steward for help, because this can be tricky (see above: Personal Data > Why is it so hard to anonymize data?). If neither these are possible, you can’t share the data. This is one of the reasons why it’s so important that you write a Data Management Plan before collecting data, so you will have thought of these things in advance. Can I be forced to publish my data because of the WOB? The Wet Openbaarheid van Bestuur (WOB) only applies to public entities, so not to the Stichting VU (the VU is unique among Dutch universities in this). However, the WOB may apply to the commissioner of your research, for example if your research is commissioned by the national government, or about the functioning of local governments or the police. In these cases, the WOB most likely still doesn’t apply to research data, since there are numerous grounds for exemption, such as the protection privacy. Get in touch with your Data Steward if you’re still worried about this. I’m afraid that other researchers will misuse my data. How can I prevent that from happening? It depends on what you mean by “misuse”. If this concerns using your data commercially, you can add a license to your data that specifies non-commercial use only. The same goes for data that may not be remixed. If, however, the misuse can occur simply by the nature of your data, then we recommend that you speak to a data steward and/or a representative of the ethical review committee to discuss your doubts and your options. Data Management Plans (DMPs) metadata and FAIR Data How can I start writing a Data Management Plan? You can log into DMPOnline with your VU credentials to start writing a DMP. It has templates of most funders which are kept up to date by the university library. If you need any help (for example with the technical terms used in many DMP templates), feel free to contact the faculty data steward. Where can I find examples of Data Management Plans? DMPOnline has a large number of Data Management Plans from which you can get inspiration for your own DMP. What DMP template should I use? For projects involving personal data, it is recommended that you use the VU template. You can currently only access the VU Template by ticking the box “No funder associated with this plan or my funder is not listed”. This template is accepted by ZonMW and NWO. By using this template you make sure that the information of your project can be used in the “GDPR registry”, which the VU is obligated to maintain and provide to the privacy authorities on request. What if my funder doesn’t accept the VU template? You can make use of the template provided by your funder (most funders’ templates are on DMP Online). To make sure your project is included in the GDPR registry, you need to fill out the VU GDPR registration for for reseatch, which you can find as a template on DMP Online: select “Create Plans”, and then make sure to tick the box “No funder associated with this plan or my funder is not listed”. I never created a Data Management Plan. Is that bad? There are some situations in which writing a DMP is mandatory. For example, if you have received a grant, you almost always have to write a DMP. The Faculty of Social Sciences also requires you to write a DMP for any new research project you start. And DMPs are sometimes necessary components of various requests, such as an ethics application (for a full procedure) and a storage application (in some cases). And obviously, if you are following the course “Writing a DMP”, you have to write a DMP to complete the course. Now, for research that is already underway, writing a DMP is a good practice, but not doing so is not necessarily bad. Writing a DMP, though, is a good way to keep you accountable and not let things come down to chance and luck. And it helps you to avoid last-minute panic. Although you are already under way with the research, it can still be a good idea to write a DMP. You can get in touch with your data steward or the RDM Support Desk if you still want to do it. What is metadata? Metadata is data about your data. It is simply information such as authors, colloborators, dates, description, key words. It is not the data itself. So even if your data itself is very sensitive, the metadata may be freely published (though in some cases metadata can be sensitive as well). What metadata and documentation should I include with my data? If you use Yoda, you can simply fill out the metadata form included in the portal. Otherwise, you can use this file to write a “readme file” that contains the same information. As for documentation: this is very much dependent on your data. A useful excercise is to imagine yourself having to take a break from research for a few years. What information would you need to get back into understanding your data again? This can include questionnaires, codebooks, field manuals, topic lists, proposals, ethics applications, data management plans etc. What metadata standard should I use? The one that is used by the service where your data will be archived, published, or registered. PURE used a standard called CERIF; Yoda uses DataCite. The forms on those services will ensure that everyhting is stored according to these standards, so this is not something you need to worry about. What does FAIR data stand for? FAIR stands for Findable, Accessbile, Inter-operable, and Re-usable. Many of these sub-elements of FAIR cover a wide spectrum of possibilities: some data can be made more easily accessible than others, for example. Below are some tips on how to ensure that your data is acceptably FAIR. Findable: your data needs a persistent identifier, and be registered on a public page somewhere. At the very least, your dataset should be registered on the VU Research Portal (PURE). Here you should also include a DOI link to the data set if your data is publically available. Data arhived on Yoda gets a DOI as soon as you publish the metadata. (The data itself can remain private.) Accessible: make sure that people can access the data in case its needed. You do this by archiving the data in a repository when you publish findings. This doesn’t need to be a public repository, but your data needs to be at least available for verification purposes, in case there’s doubts about scientific integrity. A Yoda vault is perfect for this. Public repositories may offer restricted access, where you control who accesses the data, or public access. Inter-operable: make sure that if someone has access to your data, they can make use of it (potentially even combine it with other data, if you choose to give people that option). Make sure to use standard file extensions and make sure the data is accompanied by enough information that a well-informed colleague can start using the data without to many difficulties. At a minimum, you should include a Readme file, and any tools used to generate the data (topic lists, questionnaires, interviewer guides, manuals, cleaning scripts etc.). Re-usable: make sure that if people have access to your data, they know what they are allowed to do with it. This means that the terms of use of all outputs are clear, for example by using licenses (as open as possible is best, for example the CC-BY license), and that information about the informed consent procedure is included, so other researchers know what your respondent consented to. For using restricted (i.e. non-public) data from Yoda, a strict data sharing agreement can be drafted, limiting the use to verification of the research findings. My funder wants me to make my data FAIR, but I can’t share the data because of privacy concerns. This is not a problem. Data needs to be Accessible. This means that there is a well-defined procedure for accessing the data, for example in cases where there are doubt about scientific integrity. Archiving your data securely on Yoda is sufficient for this. "],["rdm-tools.html", "RDM: Tools More resources", " RDM: Tools The figure below gives an overview of the tools that are available throughout the research lifecycle. Faculty-specific advice and guidance on which tools are recommended is provided in the table below. If you would like to use other tools, feel free to contact the Faculty Data Steward for more information. More general information about the data management tools provided by the VU can be found on the Research Data Support Portal. Information about costs can be found here. Tool FSS Guidance How to get started Storage Finder The storage finder offers information about all storage options offered for research data, even those not typically used in the faculty of social sciences https://vu.nl/en/research/storagefinder DMP Online All work you do on data needs to be covered by a DMP in the VU template on DMP Online. This is because both your department head and the Dutch privacy regulator need to be able to have insight into what happens to the data used in the faculty. This is facilitated by DMP Online. If, for whatever reason, you have a DMP elsewhere, you can fill out the shortened \"GDPR registration form\" on DMP Online to ensure transparency. Visit https://dmponline.vu.nl, log in with your institutional credentials, and start writing! If you are not sure about what to enter, please don’t spend hours researching the answer: you can always schedule a session with the Faculty Data Steward. Yoda Yoda is the preferred solution for storing and archiving data at FSS. It is rated for sensitive data, can be used with (external) collaborators, and allows for secure access both on and off campus. Data can be added to a \"vault\" to preserve a persistent copy. This copy can be assigned metadata, a DOI,and (optionally) be published. Visit yoda.vu.nl, fill out the request form, and the functional manager of yoda will schedule an intake with you. Research Drive Research Drive can be used to store data during your research, but, unlike yoda, can’t be used for archiving or publishing. It does have two advantages over Yoda. Firstly, it offers fine-grained access control to sub-folders. This allows you to specify folder which team members can access it. For example, you can choose not to give students access to senstive materials. Secondly, it offers better syncing, allowing you use more effectively offline. Because of the lack of archiving options, you will mostl likely have to combine Research Drive with Yoda. Visit https://services.vu.nl/esc?id=kb_article&sysparm_article=KB0012856 for more information and a request form. OSF The OSF is great for making your work more transparent, pre-resgistering studies and publishing data. There is much information on OSF.io; VU has an institutional account with the OSF, meaning you can log in with your VU credentials. Teams / SURF Drive While Teams and SURF Drive are great for collaboration with colleagues and students, we recommended not to use them for storing research data since the backup and security features of other storage solutions such as Yoda and Research Drive are much more robust. Access to Teams and SURF Drive is standard for all employees. More resources Information when starting a new project FSS RDM Guidelines FSS Guidelines for data organization FSS Guidelines for data archiving RDM FAQ Overview of RDM Tools "],["rdm-presentations.html", "RDM: Presentations", " RDM: Presentations 15 and 22 June 2023: Workshop Writing a DMP 19 June 2023, PSPA Department Meeting "],["404.html", "Page not found", " Page not found The page you requested cannot be found (perhaps it was moved or renamed). You may want to try searching to find the page's new location, or use the table of contents to find the page you are looking for. "]] +[["index.html", "FSS RDM Pages Index Table of contents", " FSS RDM Pages FSW Data Steward 03 October 2023 Index This web site contains the latest draft versions of the Research Support Office’s pages on Research Data Management. The current “official” versions of these pages can be accessed through the Social Sciences Getting Started page. Table of contents Support throughout the Research Cycle Plan & Design Content for proposals: Ethics, Privacy, RDM (Koen) Starting a new project (Time to Grant) Ethics, Data Management and Privacy for new projects Managing ongoing projects Organizing your research data (Koen) Publishing, and Impact Archiving and/or publishing data (Koen) Knowledge and Guidelines Templates RDM Data Management Policy RDM FAQ RDM Tools A Guide to FAIR data "],["proposal-content-rdm.html", "Content for proposals: Privacy, ethics and data management Personal Data Ethics Research Data Management", " Content for proposals: Privacy, ethics and data management This document contains example texts to be used in proposals. The text should be adapted to the specific project for as much as possible. Personal Data The [interview/survey/…] data collected for this project constitutes personal data in the sense of the GDPR. The researcher will work with the faculty data steward and the VU’s privacy team to ensure compliance with GDPR. The legal ground for processing this data is informed consent. All respondents will be fully informed about the means and purposes of the data processing, and no data will be collected unless this consent has been given. The information sheets that will be used for these are based on standard forms developed in consultation with the VU’s privacy lawyers, and include information on what data will be processed, the purposes and the legal ground for processing, information on who will be able to access the data, the duration of data retention and how respondents can exercise their privacy rights. For verification purposes, the data for this project will be retained for 10 years after the last publication. After this, the data will be destroyed. The data will stored on storage infrastructure provided by the VU, which can only be accessed using strong passwords and multi-factor authentication. Data will be pseudonymized after it has been collected; any data containing directly identifying data (such as the raw, unpseudonymized data) will be stored separately from other data. The VU ensures that any storage solutions offered by third parties [e.g. Research Drive and Yoda by SURF, or qualtrics, name whichever apply] are governed by Data Processing Agreements, and that no personal data is stored outside the EEA [check if this last is true for the specific services you use!]. Ethics The researcher will work with the faculty of Social Sciences’ Research Ethics Review Committee (RERC) to ensure that the research is in line with ethics standards governing research at the faculty. The researcher will perform a scan of the research to flag ethics issues and will discuss any issues found with a representative of the RERC. [This really depends on the research. It is wise to do the self-check before and possibly consult your department’s RERC representative] Research Data Management Below are two examples of data management paragraphs that can be adapted and expanded on to suit most templates. There is one example for projects where the data will not be shared, and one where it will be. Example with no data sharing The data stored for this project will be stored on secure network storage provided by the VU, in accordance with VU’s ICT regulations. Access to the network storage is only granted to authorized personnel, using strong passwords and multi-factor authentication. In compliance with European Union’s General Data Protection Regulation (GDPR), no personal data will be stored without prior, explicit consent by the data subjects. After completion of the project, all data will be archived for ten years, in accordance with the FAIR principles. Because of the se sensitive nature of the topic, the data will not be shared publically, but only be accessible for verification purposes. If for this verification it is needed to share the data with staff outside the VU, this access will be governed by a data transfer agreement. Information on the access condition will be made public through a registry of the data set on VU’s Research Portal (which uses PURE). All data storage, archiving and registry solutions will be chosen in consultation with the faculty of social sciences’ data steward; these choices will be registered in a Data Management Plan before the start of the project. Example with data Sharing The data stored for this project will be stored on secure network storage provided by the VU, in accordance with VU’s ICT regulations. Access to the network storage is only ranted to authorized personnel, using strong passwords and multi-factor authentication. In compliance with European Union’s General Data Protection Regulation (GDPR), no personal data will be stored without prior, explicit consent by the data subjects. After completion of the project, pseudonymized data will be published on DataVerseNL, where it will be accompanied by rich metadata and full documentation. All data storage and archiving solutions will be chosen in consultation with the faculty of social sciences’ data steward; these choices will be registered in a Data Management Plan before the start of the project. "],["new-rdm.html", "FSS Starting a new project: Ethics, Data Management and Privacy Getting support", " FSS Starting a new project: Ethics, Data Management and Privacy When working with data from human respondents it is important to consider matters around ethics, data management and privacy before collecting (or analysing) any data. So when starting a new project or study – or significantly updating or expanding and existing one – it’s good to check whether the following things are in order: Ethics Review: the Research Ethics Review Committee provides a self-check that consist of a list of Yes/No questions that takes less than five minutes to complete. This scans for ethics issues, and advises on next steps. More information on Ethics Review can be found here. Research Data Management (RDM): you will need to consider what you do with your research data before you collect it, because you need to tell your respondents what you’re doing with it. The faculty advises you to use Yoda for Storaging, Archiving and/or Publishing your research data. Other options are available, check out the tools overview and/or the storage finder. Privacy: all data that can be linked in any way to living persons is considered personal data under GDPR. For most researchers this means: You must take appropriate technical and organization measures to secure data. For most data (including sensitive data, such as data on health, sexual preferences, political opinions etc.), Yoda and VU-managed devices offer sufficient protection. If you have sensitive data and want to use other storage solutions, it’s best to check in with the Data Steward or RDM Support Desk to find what would work best for your needs. You should ensure that you have unambiguous informed consent of your research participants. Note that informed really means informed: you have to provide your participants with information about what you will do with the data, and what their rights are and how to excercise them. You can do this by having your respondents sign an informed consent sheet based on the faculty template (Dutch), or provide them with (a link to) a privacy statement based on the VU template (Dutch) and ask them if they’ve read it and accept it. If you cannot obtain consent, you should contact your Data Steward to see how you can still legally work with your data. You must ensure that all data processing activities (collection, analysis, publishing, archiving, etc.) are entered in the VU’s central data processing registry. Currently, DMPs created using the VU template in DMP Online are linked automatically to this registry, meaning the researcher does not need to take additional action for this. If you don’t have DMP on DMP Online, there is a short form available on DMP Online that you can use to just enter the legally required information. If personal data is handled by third parties (e.g. a survey firm or data collection platform), you should contact the Data Steward to help you get the proper agreements in place to do this securely, for example Data Processing Agreements. The VU has these agreements in place with VU-provided tools such as Yoda and Qualtrics. The Data Steward is there to help you with templates and getting legal advice for getting these agreements with other service providers and partners. Data Management Plan (DMP): all data collection done at the faculty should be covered by a Data Managment Plan (DMP). So once you have given all of the above some thought, you should start writing one, or adapt an existing one, by going to DMP Online. DMPs are living documents: you are encouraged to change them if what you plan to do with the data changes. Ideally, you make your DMPs public on DMP Online, so your colleagues can easily learn from all the hard work you put into steps 1-3. Getting support You can get support and find more information in the following places: The Faculty Data Steward (or the RDM Support Desk in case you can’t reach the data steward) The Faculty RDM Page (which includes links to templates of informed consent letters, a FAQ, and content you can use for proposals etc.) The RDM Libguides. "],["ongoing-rdm.html", "VU FSS guidelines for data organization Introduction General advice Use cases", " VU FSS guidelines for data organization Introduction Researchers of the Faculty of Social Sciences (FSS) are responsible for organizing their data in such a way that they can be archived without excessive effort. In general terms, the aim is to ensure that a fellow researcher can use the data without asking too many questions. This ensures that the results of the research can be verified if the need arises. Furthermore, should additional researchers be added to a project - or a researcher gets back from a long hiatus - they can get started quickly. These guidelines are not prescriptive; they are meant to inspire researchers on how to manage their data when starting a new project, since changing folder structures once a project has started can be very difficult. These guidelines provide some general advice on data organization, as well as several use cases (quantitative and qualitative) that serve as inspriration for organizing research data. Each use case gives an outline of a folder organization that is used during the research. These use cases serve as examples, researchers are free to use any organization that fits the needs of their research. General advice When thinking about organizing your files, start at the end: where should these files end up? It’s a good idea to keep files that you want to publish together with other files you want to publish. This saves times and prevents error when – after project completion – you decide which files should be archived, and which files should be published. Follow these best practices when naming files and folders. Use cases Simple quantitative research project using Research Drive and Yoda Get the sample DMP for this use case here. This use case describes a fictional project using survey data. It uses Yoda for archiving only; for storage of data the project uses Research Drive. While Yoda is suitable for storage as well, Research Drive offers more fine-grained access control, which this fictional project needs to make sure student-assistants can’t access all information stored on the research drive. Research drive is used for day-to-day storage and synced to researcher’s devices using the OwnCloud software. The folder is organized as follows: Data Pseudonymized research data (access is granted as needed) Documentation Questionnaires, proposals, data management plan etc. (everyone in project can access) Papers One sub-folder per paper containing text, analysis scripts etc. for each paper. (access is granted as needed) Admin Project admin information, such as budgets; not accessible to students Yoda is used in this project for archiving, and is thus not synced to any devices. Directly following data collection, the raw data was pseudonymized. The pseudonymized data was stored on Research Drive. The raw, unpseudonymized data was archived on Yoda, assigned to the Vault and permanently deleted everywhere else. This ensures that a copy of the original data is always available (with a DOI), and minimizes the risk of leaking unpseudonymized data. Once a paper based on the data is published, a folder is created for that paper with all things that can be shared publicly. This folder copies the Yoda metadata of the root folder, making complying with the FAIR principles very easy. The folder is made public on Yoda and looks as follows: Raw data (Vault) Data files Documentation -Yoda metadata Replication files for each paper (Public): Author manuscript of paper Analysis and pseudonymization scripts Documentation Yoda metadata Note that the data itself is not publicly available because of privacy concerns. The raw data is only archived for verification purposes. In case of doubts about the research integrity, the Raw Data’s DOI (listed in each paper’s data statement and replication files’ metadata) can be used to quickly identify the data set for verification purposes. Simple qualitative research project using Yoda The following is a basic qualitative project. All data is stored on Yoda. Once data collection is complete, the data folder is added to Yoda vault, a DOI of which is included in every paper. Yoda Raw Data (Vault) Interview recordings List of names with interviewees Data Pseudonymized interview transcripts Documentation Sampling information Topic lists Ethics review information Blank informed consent form Paper 1 Text of paper Figures Using Yoda to archive PhD data As part of their portfolio, PhD candidates are required to follow the FAIR principles to ensure that their data is available for verification purposes. In this use case, the data is archived in Yoda. The organization is starts by asking the question where data needs to end up, and then works backwards to make that possible. This project has some data assets that need to be archived restricively, while others can be made freely available. We therefore made two top-level folders in Yoda: public and restricted, and divided the data assets among these two folders. Restricted Raw data Sampling lists Public Documentation Informed consent templates Sampling guides Topic lists Manuscript "],["fss-guidelines-archiving.html", "VU FSS guidelines for archiving data How to apply the FAIR principles Findable Accessible Inter-operable Re-usable What to archive?", " VU FSS guidelines for archiving data These guidelines are an extension of the FSS RDM Guidelines. When publishing research outputs, researchers at the Faculty of Social Sciences are expected apply the FAIR principles and to archive “all data that can be reasonably deemed necessary to verify the findings of the research”. These guidelines serve as practical advice on how to achieve this. The first section discuss the constituent principles of FAIR data (Findability, Accessibility, Inter-operability and Re-usability), the second provides practical advice on what to archive, based on the Archiving Guidelines from the Deans of Social Sciences in the Netherlands. How to apply the FAIR principles The FAIR principles are a set of principles that guide researchers in making their data (or other research outputs) more valuable by increasing visibility, fostering collaboration, facilitating co-creation, and promoting transparency. To effectively implement the FAIR principles, it is beneficial to envision how your data will be reused, and then apply each principle accordingly. This involves ensuring discoverability of your data by end users, enabling easy access, facilitating integration with existing knowledge and workflows, and promoting its reuse. Given the diverse research traditions and approaches to data reuse within the faculty, there isn’t a universally prescribed approach for applying the FAIR principles. However, as a minimum requirement, all data utilized within FSS should be usable for verifying the findings presented in publications resulting from the data. This section provides practical pointers, aligned with the FAIR principles, on how you can make verification possible. Additionally, it presents further steps you can take to increase the impact of your research outputs. Findable Findable means people can find out about the existence of your dataset, and know where to find more information about it. Actions required to allow for verification: Register your data set in a registry like the VU Research Portal. (NB: you don’t need to upload your data set for this!) Ensure your data set is assigned a DOI (for example by adding it to a Vault on Yoda and publishing the metadata). More actions you can take to make your data set more Findable: Cite your data sets in your paper. Accessible Accessible means that there should be an established way to access your data. This does not mean your data should be public, just that there is a clearly communicated and transparent procedure put in place to access the data. Actions required to allow for verification: Add a data availability statement in your publication that explains how, and under what conditions, the data can be accessed. Archive your data in a restricted-access repository like Yoda. More actions you can take to make your data set more Accessible: Make your data publicly available on Yoda, the OSF or DataVerseNL. Inter-operable Inter-operable means that someone else can use your data and combine it with their existing knowledge and workflows. Actions required by to allow for verification: Use common, preferably open, file formats. Include documentation that can help people make sense of your data, such as codebooks, interviewer manuals, and topic lists. Wherever possible, use a language that can be understood by anyone who may reasonably be expected to use your research outputs. More actions you can take to make your data set more Inter-operable: Use standardized variables, coding schemes and vocabularies. Make sure the metadata of your datasets link to related datasets, publications and other relevant research outputs. Re-usable For your data to be re-usable, it needs to be clear what can and cannot happen with your data. Actions required to allow for verification: Include the informed consent sheets or privacy statements you provided your respondents, so that it is clear what they allow the data to be used for. Make sure that when you register your dataset, or deposit it into a repository, you include detailed information like author, topic, keywords, etc. See the VU’s minimal metadata standards. Note that Yoda requires you to include this information before submission. Actions you can take to make your data more Re-usable: Include detailed information, for example in a readme, on the provenance of your data: where it comes from, how was it has been collected and how it was processed. Include a license, like CC-BY or the DANS license, with your data; or set out a Data Sharing Agreement that exactly states what a recipient can do with the data. What to archive? The following materials should be archived, within one month after the publication date: A copy of the publication that uses the data. Most publications allow you to upload the submitted version (i.e. without the journal’s layout etc.). Raw data: unedited data files providing the most direct registration of the behaviour or reactions of test subjects/respondents. If the raw data files have been accessibly stored in an external archive (such as storage facilities at DANS), or if the data cannot be archived on university servers (for example due to IP restrictions) making reference to the location of the files will suffice. The VU researcher must ensure that such externally stored raw data will be available for verification purposes. Raw data may not be changed once they have been made digitally available. Analyzed data: the data files that were eventually analysed when preparing the article (e.g. an SPSS data file after transforming variables, after applying selections, etc.). This is not necessary if the raw data file was directly analysed, or if the analyzed data can be constructed without excessive effort from the raw data (for example by running a script). A description of the procedures to transform the raw data into analyzed data. This could be computer code (for example Atlas.ti, SPSS/JASP syntax file, MATLAB analysis scripts, R code) or a description of the steps taken in the qualitative analysis of primary research data, i.e. themes, domains, taxonomies, components. A description of the steps taken to process the analyzed data into results in the manuscript. This could be computer code or a description of the steps taken in the qualitative analysis of primary research data. Any documentation that can reasonably be deemed necessary in order for other researchers to understand the data and/or verify the research’s findings. The precise documentation depends on the methods used, but examples include: study design documents, interview guides, questionnaires, surveys, and topic lists. The materials must be available in the language in which the research was conducted. A readme file (metadata) describing which documents and files can be found where and how they should be interpreted. The readme file must be sufficiently clear, so that a relevant fellow researcher can verify the results discussed in the publication. The readme file must also contain the following information: Name of the person who stored the documents or files Division of roles among authors, indicating at least who analysed the data Date on which the manuscript was accepted, including reference Date/period of data collection Names of people who collected the data If relevant: addresses of field locations where data were collected and contact persons (if any) Whether the data is made open or not and if not, a valid reason for not opening up the data Documents received from the Research Ethics Review Committee: at least the result of the self-check, and if applicable result from a full review. If using personal data: information about the informed consent procedure, such as a privacy statement, or a blank informed consent form. "],["templates.html", "Templates Data Management Plans Informed consent Data Protection Impact Assessment Agreements More resources", " Templates Data Management Plans The University Library manages DMP Online so that all templates are up-to-date. It is advisable to use the VU template whenever possible (this is accepted by ZonMW and NWO instead of their own templates). The FSS Guidelines for Data Organization includes example DMPs that you can use for inspiration. For detailed guidance, you are encouraged to plan a consult with the Faculty Data Steward Informed consent Before collecting data, you are required to inform your respondents about what data you will collect, and what you intend to do with it. This can be through the use of a signed informed consent form, but this is not needed. In any case, the consent should be demonstrable. Ticking a box prior to an electroninc survey, clearly stating in a recording “I agree to be interviewed” (it is wise to separate this from the research data) or sending an email with the same text all are valid forms of consent. Whatever form you choose, you need to make sure your respondents are well informed. For this, there are the following documents: Informed Consent Form (English/Dutch): this form can given to respondents, and should be kept on file (preferably digitally) for the duration of the use of the data. Privacy Statement (English/Dutch): You can send interviewees a privacy statement by email prior to interviews, or put a link to a detailed privacy statement in a digital survey, and then ask the respondent whether they agree to be interviewed. If you collect particularly sensitive data (especially special categories) or do sensitive things with the data (like publishing) make sure to mention this in the question, so repsondents explicitly consent to this. The Faculty Data Steward can help you find the right way to inform your respondents and obtaining their consent. Data Protection Impact Assessment A Data Protection Impact Assessment (DPIA) is a systematic process that helps identify, assess, and mitigate the risks associated with the processing of personal data. While it is never a bad idea to do a DPIA, it’s mandatory only in specific cases. To check whether you need to do a DPIA, you can fill out the pre-DPIA tool. If the result is that a DPIA is needed, you can contact the Faculty Data Steward to assist in drafting one, or have a look at the DPIA template. Agreements Data Sharing Statement: if students (or student assistants) work on sensitive data, it is wise to have them sign a statement that they will treat the data confidentially. For agreements with third parties, it’s best to be in touch with the Faculty Data Steward who can assist in liasing with the relevant departments at the VU. More resources Information when starting a new project FSS RDM Guidelines FSS Guidelines for data organization FSS Guidelines for data archiving RDM FAQ Overview of RDM Tools "],["rdm-policy.html", "RDM: VU FSS guidelines for data management Introduction Stepping stones for good data management To whom do these guidelines apply? Underlying policies Abbreviations Definitions", " RDM: VU FSS guidelines for data management Introduction As a faculty committed to excellence in the quality of the research our staff and students undertake, it is essential to have guidelines on good practice in Research Data Management (RDM) as part of our framework to support the integrity of our research. These FSS guidelines serve both as a means of developing and supporting a culture of good practice in data management and demonstrating that we are committed to a culture and environment where high standards are encouraged and expected. The purpose of these guidelines is to reduce work pressure by condensing the various, and often conflicting, regulations into one cohesive set of procedures that ensure maximum compliance. Details on the various underlying policies can be found below. In this document, the following verbal forms are used: “shall”, “are required to” and “must” indicate a requirement; “should” indicates a recommendation; “may” indicates a permission; “can” indicates a possibility or a capability Stepping stones for good data management Before Researchers must follow the ethics review procedure of the Research Ethics Review Committee (RERC). Researchers must write a Data Management plan (DMP) using https://dmponline.vu.nl), so that they can easily provide an up-to-date version to their department head at any moment. Researchers shall ensure that all planned activities with personal data comply with GDPR. In particular: They must plan to take appropriate technical and organization measures to secure data. Because of the wide variety of data used in the faculty, there is not one answer as to what measures are appropriate. Researchers should discuss the measures they take with colleagues, department heads, with the faculty data steward, privacy champion and/or the RDM support desk. They should ensure that all personal data is processed with full consent of all data subjects. If consent cannot be obtained, the researcher must ensure that there is another legal ground for processing the data. A privacy champion can assist with this. They shall ensure that if personal data is handled by third parties, the proper agreements are in place to do this securely, for example Data Processing Agreements. A privacy champion can assist with this. They shall ensure that all data processing activities (collection, analysis, publishing, archiving, etc.) are entered in the VU’s central data processing registry. Currently, DMPs created using the VU template in DMP Online are linked automatically to this registry, meaning the researcher does not need to take additional action for this. Contracts and agreements relating to the commissioning, funding and conduct of research, including data sharing, intellectual property rights, collaboration and non-disclosure agreements must all be processed through IXA-GO to ensure the safeguarding of (the autonomy of) your research. Such contracts must be signed by those with the appropriate delegated authority to do so on behalf of the University. The signature process is a chain of responsibility that starts with the submission from the Researcher for approval of the Head of Department, before the final signature from the Managing Director of the faculty or a member of the Executive Committee of the University. The Data Steward can advise researchers on how to manage this process. During Researchers shall keep their DMP up to date. Researchers should ensure that their data is stored in such a way that it can later be archived in accordance with section 3.3 of these guidelines without excessive effort. This includes: Ensuring data is well-organized (for more information, see the FSS Guidelines on Data Organization); Data is stored in the same place as vital documentation. Depending on the discipline of the researcher, this can include interviewer guides, questionnaires, topic lists, sampling information, power calculations, etc. Making sure the data is accompanied by a basic “Readme File” containing basic metadata such as an explanation of the purpose of the data, who is responsible for collecting it, and how the folder is organized, etc. Researchers must ensure that data is reliably, traceably and securely stored throughout the research life cycle. The VU offers storage infrastructure that meets these requirements (see the storage finder). If project data needs to be stored elsewhere (for example with project partners), researchers must ensure that the storage solution chosen meets these requirements. The data steward will help in this assessment. Researchers must take appropriate technical and organizational measures to secure any personal data. They can store directly identifiable data (see definitions, below) separately from other data, either by storing it on a different server or device, or through encryption. They must not store directly identifiable data longer than needed. Note that it may be impossible to remove directly identifying data without editing the raw data, which would compromise data integrity and provenance. In such cases, the directly identifiable data may be stored as long as long as the rest of the raw data. Researchers are expected to decide what data to destroy what data to keep. Researchers should discuss the choices they make with colleagues, department heads, with the faculty data steward, privacy champion and/or the RDM support desk, and record these choices in their DMP. After Archiving and Registration Researchers must ensure that the underlying data for each published empirical study (article, volume, book chapter, PhD thesis chapter, Research Master’s thesis, consultable internal report, etc.) is archived according to the following: What: all data that can be reasonably deemed necessary to verify the findings of the research. This includes the raw data (or a link to it, if secondary data was used), the data that was analysed and a description of all modifications to obtain the analysed data from the raw data (or the computer code used to perform these modifications) and full documentation of all steps involved in acquiring, processing and analysing the data. Detailed guidelines on what to archive can be found here. When: the data must be archived no later than one month after the publication date, and be available until at least 10 years after the publication date. If this is not possible, a justification for deviating from this should be provided in the DMP. Where: a secure and reliable location that is accessible for verification (see the section on verification below), and that provides a persistent identifier. The archiving options provided by the VU satisfy these criteria. If data needs to be archived elsewhere (for example with project partners), researchers must ensure that the storage solution chosen meets these requirements. FSS follows the ERC’s approach “as open as possible, as closed as necessary”. In practice, this means that public data is preferable, but that personal data does not need to be published1. Should researchers want to publish such data, they should ensure that they meet all legal and ethical requirements to do so, consulting with the faculty data steward if needed. Public data must always be accompanied by a license and, in case of personal data, information about the informed consent procedure. The decision to publish data or not should be explained in the DMP. Who: the first author of the publication is responsible for archiving the data. Second or later authors must know that the data have been carefully stored and how this has been arranged. This is particularly important if the first author does not work at FSS. For PhD candidates and research master’s students, the primary supervisor or the day-today supervisor respectively are responsible for archiving, but can delegate the work to the PhD candidate. Furthermore: Researchers should include in their published empirical studies a data statement containing the repository where the data is archived, the persistent identifier of the data, and instructions on how this data can be accessed and for what reasons. For sensitive data that is not published and that can only be accessed for verification purposes, a persistent email address may be provided where questions regarding the data can be directed. Researchers should ensure that all datasets that they produce are registered on the VU’s Research Portal, including sufficiently descriptive metadata, and the persistent identifier of the data set. Data verification In case of doubts about the research integrity of FSS research, the faculty board can decide that verification of archived (non-public data) is needed. In making this decision, the board shall balance the need for confidentiality and security with the interests of transparency. If it is decided that the data needs to be reviewed, the Faculty Board will then decide who will access the data while ensuring confidentiality of the data and work with VU IT and the Data Steward to ensure that this access is possible. Administrative procedures End of employment If a researcher leaves the VU, the department head should work with the researcher to ensure: That the data for any ongoing projects is properly stored according to these guidelines; That the data for any pending publications is properly archived according to these guidelines; That responsibility for any data sets archived by the researcher on VU infrastructure is transferred to an FSS colleague; and, That the researcher doesn’t lose access to data they need for their further career, if such access can be reasonably organized; for example through the signing of a data transfer agreement between the VU and the researcher’s new institution. Performance and appraisal reviews Adherence to these RDM guidelines will be discussed in performance and appraisal interviews. Formal final responsibility lies with the dean. To whom do these guidelines apply? These guidelines apply to all faculty staff members who conduct research in the context of a temporary or permanent employment contract, all PhD candidates who conduct research under the supervision of a professor, and all research master’s students. The guidelines do not apply to bachelor’s and one-year master’s students, unless their research results in an academic publication. Research conducted by bachelor’s and one-year master’s students falls under the formal responsibility of their supervisors. Underlying policies TThe list below contains the regulations that these guidelines are based on. Since there are often conflicts between the regulations, the list includes a comparison between each item and these guidelines, so that any deviation from the regulation is made explicit. General Data Protection Regulation (GDPR) Date: 2018 Last reviewed: 25/07/2023 URL: https://gdpr-info.eu GDPR FSS Note: The GDPR is too large to include a full comparion here. Netherlands Code of Conduct for Research Integrity , Standards for good research practices Date: Sep-18 Last reviewed: 15/06/2023 URL: https://doi.org/10.17026/dans-2cj-nvwu Code of Conduct FSS In research with external partners, make clear written agreements about research integrity and related matters such as intellectual property rights. FSS guidelines include instructions to do this. The primary contact for FSS researchers about this is IXA-GO. As necessary, describe how the collected research data are organized and classified so that they can be verified and reused. FSS guidelines include instructions to write a readme file which covers this. A template readme file is also provided. As far as possible, make research findings and research data public subsequent to completion of the research. If this is not possible, establish valid reasons for their non-disclosure. The possible exceptions listed (in a footnote in the original text) are included in FSS guidelines, including a requirement to record in the DMP the reasons not to publish data. 12 a. In the event of an investigation into alleged research misconduct, make all relevant research and data available for verification subject to the confidentiality safeguards established by the board of the institution FSS guidelines ensure that all data is archived in a place where it can be accessed for verification purposes. 12 b. In highly exceptional cases, there may be compelling reasons for components of the research, including data, not to be disclosed to an investigation into alleged research misconduct. Such cases must be recorded and the consent of the board of the institution must be obtained prior to using the components and/or data in question in the scientific or scholarly research. They must also be mentioned in any results published. There are currently no provisions for this in the FSS guidelines, since it is not clear what steps should be taken, and what criteria should be satisfied, to qualify for these exceptions. Ensure that sources are verifiable. Verifiability is the cornerstone of the FSS RDM guidelines. All FSS Data should be archived in such a way that verification is possible. Describe the data collected for and/or used in your research honestly, scrupulously and as transparently as possible. FSS RDM Guidelines ask for full documentation of all datasets, and for the data sets to be described with descriptive metadata or readme file. Researchers should also follow this point in their publications, but that goes beyond the scope of the FSS RDM Guidelines. Manage the collected data carefully and store both the raw and processed versions for a period appropriate for the discipline and methodology at issue. The FSS guidelines specify this. Contribute, where appropriate, towards making data findable, accessible, interoperable and reusable in accordance with the FAIR principles The FSS guidelines follow the FAIR principles explicitly. As far as possible, make research findings and research data public subsequent to completion of the research. If this is not possible, establish the valid reasons for this. From the perspective of the VU guidelines, this is redundant with item 11. VU RDM Policy Date: Feb-20 Last reviewed: 15/06/2023 URL: https://libguides.vu.nl/ld.php?content_id=32045526 VU RDM Policy FSS Researchers are responsible for compliance with legal and ethical requirements regarding their research data, including review by ethics committees if necessary. This is included in FSS Policy. Researchers are responsible for ensuring that their research data are reliably, traceably and securely stored throughout the data life cycle and that they are able to report the storage location of their data to the department head, for example upon termination of their employment at the VU. At the same time, department heads are also responsible for making agreements with researchers on such issues, see article 7 under ‘Responsibilities’ in this policy. FSS guidelines ask researchers to use VU-provided infrastructure whenever needed, and if not ensure that the infrastructure lives up to this standard. Researchers are responsible for archiving their research data for a minimum of ten years after research results are published, unless legal requirements, discipline-specific guidelines or contractual arrangements dictate otherwise. The moment of publication is defined as the first online appearance of the publication. If there is no online publication date, the formal publication date of the publisher applies. If a researcher’s employment terminates between the events of submitting a publication and the actual moment of publication, agreements must be made regarding these data archiving responsibilities according to articles 2 and 7 under ‘Responsibilities’ in this policy. FSS guidelines follow this. If the data is not archived for 10 years, motivation is required in the DMP. Researchers are responsible for being able to share their research data for scientific use and verification, by making them accessible (A in FAIR) to others, preferably and where possible with a Persistent Identifier. Before research data are shared for reuse or verification, a researcher has to make sure that this is compliant with applicable legislation and ethical requirements. When research data include personal data, an assessment must first take place to determine whether these data can be shared and if so, under which conditions. FSS guidelines follow this, and explicitly recommend not publishing personal data, unless the researcher can ensure that they meet all legal and ethical requirements for publishing. The VU ensures that research data that are generated at the VU are Findable (F in FAIR) by including descriptions of these datasets in the Current Research Information System (CRIS) of the VU.10 Researchers’ responsibilities in this process are as follows: researchers can perform this registration themselves, or they or their research support staff can request the CRIS administrator vuresearchportal.ub@vu.nl) to do this registration by providing the necessary information (e.g. the storage location of the dataset, author information, project information). Researchers register their data sets on PURE. Researchers who collect and process personal data for their research, must comply with the requirements of the GDPR and the UAVG and, additionally, they must register these activities in a processing register. Keeping a record of processing activities is a legal requirement (imposed by the GDPR). The Privacy Champions in the faculties are the first point of contact for support on these matters. VU guidelines include explict references to GDPR, and the privacy register. Department heads are responsible for arranging agreements with researchers in their departments regarding the management of research data, particularly when a researcher’s employment is ending. See article 2 of this policy for more detail. FSS guidelines include a section on what to do upon contract termination. Faculties must establish their own Research Data Management policies which are applicable to all of their departments and institutes, and that include, where necessary, discipline- specific protocols. FSS has an RDM policy that specifically acknowledges the variety of disciplines within the faculties. Guidelines for the archiving of academic research for faculties of behavioural and social sciences in the Netherlands Date: Mar-22 Last reviewed: 15/06/2023 URL: https://zenodo.org/record/7583831 DSW FSS Preamble The principles of honesty, scrupulousness, transparency, independence, and responsibility form the basis of research integrity (UNL, 2018). Abiding by these principles enlarges trust and quality of academic research, thereby improving its relevance to society. The current guideline is developed with input from all DSW faculties and offers guidance for the archiving of academic research published by researchers at the Dutch faculties of social and behavioural sciences, drawn from the principles of scrupulousness, transparency, and responsibility. The guideline seeks to improve archiving of social and behavioural research using both quantitative and qualitative methods, in order to safeguard continued availability of qualitative or quantitative research data, detailed descriptions of research materials and approaches, and an overview of the data processing and publication processes after the research has been published. This guideline is not meant to replace other existing guidelines or regulations related to data management, open science, data processing agreements and privacy aspects in the design stage of a research project. The document can be seen as an initiative that is part of a broader effort to promote research integrity among researchers focusing on both quantitative and qualitative studies at faculties of behavioural and social sciences in the Netherlands. Rather than functioning as a strict straightjacket, it intends to provide a clear guideline, which can be further fleshed out under the motto ‘apply or explain’, taking into account existing regulations at the faculty or university level. Researchers working in the social and behavioural sciences at a Dutch university will be held to these standards to ensure that research integrity in general and transparency in particular can be ensured. Given the various distinct methodologies of scholarly research carried out under the general “social science” header, there are two main approaches that can be identified and should be implemented to ensure scientific integrity and its future assessment. The first is primarily for quantitative research designs and quantitative data that can most often relatively easily be de-identified (pseudonymized or anonymized) and stored in a repository in full. The second is for scientific research that is structured by qualitative and interpretive research designs and epistemologies that generate data and information that may have a different character and most often cannot be de-identified and stored in an identical manner as quantitative data. Regardless of methodological approach, all researchers have an obligation to follow the standards of integrity and transparency set in this document. All researchers must be aware of the specific regulations that govern their type of research and adhere to these regulations (except where motivated exceptions are allowed). FSS guidelines follow the spirit of these guidelines, but FSS disagrees that qualitative and quantitative data should be treated differently. The reasoning for this can be summarized as follows: While there is difference in the ease of de-identification of quantitative vs qualitative data, this difference is not such that it should have implications for the way data is handled: it is often still very difficult to fully anonymize quantitative data, and it is possible to pseudonymize qualitative data. Even if pseudonymization of qualitative data is impossible, non-pseudonymized data can still be archived following our guidelines. Much of our research combines elements of quantitative data analysis and qualitiative data analysis, making a distinction problematic to put into practice. A distinction would further divide social sciences and complicate efforts to promote inter-disciplinarity. FSS therefore does not differentiate based on qualitative or quantitative, but on the specific nature of the data: for example the privacy risks posed by the data, the IP rights over the data, whether the data is available elsewhere, etc. 1.1 Purpose of these guidelines These guidelines for the archiving of academic research set out the preconditions for the archiving of data, materials and information that form the basis for publications – in other words, (descriptions of) data, materials and information that are needed in order for academic peers and other consumers of the research to replicate, reproduce, and/ or assess the published research results. These guidelines relate to the data, materials and information with respect to publications that appear in their definitive form as of 1 September 2021 . The guidelines are based on the principle of retroactive accountability, i.e. reporting after a publication has appeared. The norm behind these guidelines is that each researcher is responsible for archiving data, materials and information, and the publications based on them, in a responsible and transparent way, in order to keep the data for future verification or checking by academic peers, and re-use. In situations where this document does not provide clear-cut rules, researchers are expected to act in the spirit of these guidelines rather than observing them to the letter. Faculties will be expected to apply these national guidelines. The guidelines will be evaluated every two years, under the responsibility of the deans of the faculties of social and behavioural sciences (DSW). FSS endorses this purpose. 1.2 To whom do these guidelines apply? These guidelines apply to all faculty staff members who conduct research in the context of a temporary or permanent employment contract, all PhD candidates who conduct research under the supervision of a professor, and all research master’s students. The guidelines do not apply to bachelor’s and one-year master’s students, unless their research results in an academic publication. Research conducted by bachelor’s and one-year master’s students falls under the formal responsibility of their supervisors. All researchers at the faculty must adhere to The Netherlands Code of Conduct for Research Integrity . These guidelines are a concrete embodiment of the principle of transparency and the related norms set out in the UNL Code of Conduct. The Netherlands Code of Conduct also requires researchers to make data as open as possible after publication or to document valid reasons for not sharing the data. FSS adopted this exact wording in the RDM guidelines. 1.3 Raw data, personal data and research data Within the framework of the transparency and replicability of research, raw data must of course be retained. Raw data are the unedited data that are collected within the framework of a research project, for example: Registrations derived from experimental research Survey data from questionnaires completed within the framework of research (including longitudinal research), collected by the researcher themselves or by an external fieldwork organization (Transcripts of) video material collected within the framework of qualitative research (open interviews, observations) Notes taken within the framework of qualitative research or research using source material Raw data must always be de-identified as soon as and insofar possible so that they cannot be directly traced back to people or groups of people. Data that can be directly or indirectly traced back to a person are known as personal data. This includes not only name and address details, but also photographs, audio - and video material, and other identifying information. The de-identified raw data and the personal data together form the research data FSS guidelines do not use the word “de-indentificaion” as it can mean both anonymization and pseudonymization, which are related but have different implications for the data. It is assumed the DSW guidelines mean pseudonymization in this section, so that is the wording used in this comparison. FSS do not include the advice to pseudonymize all raw data, for the following reasons: - Once data is pseudonymized, it may no longer be considered raw. - Fully pseudonymizing some forms of data (e.g. audiovisual data) is extremely complex and time consuming. - The identity of the data subject, or factors making indirect identification trivial, may be of crucial importance to the research. Pseudonymization will damage the data set in such cases. FSS therefore takes a pragmatic approach with respect to pseudonymization. It is considered as one of many measures available to the researcher to secure their data, and it is up to the researcher to decide which measures appropriately secure their data. Guidelines concerning publication packages These guidelines relate to all research publications listed in the faculty’s academic annual report. In order to ensure the transparency of qualitative and quantitative empirical research, all information that is needed to be able to assess the results must be archived (in English). This information is stored in a ‘publication package’. The FSS RDM guidelines do not mention the term “publication package”. The term may lead to confusion: first, a researcher may think that the package itself must be published. Second, they may think that all elements need to be archived together. However, neither is the case: data may be archived in a restricted-access repository, and it is acceptable to have some items in a public repository, while others are in a restricted archive, as long as the various components link to each other. 2.1 What must be stored in a publication package? We make a distinction between publication packages resulting from quantitative research and from qualitative research projects, while noting the existence of mixed methods that employ both qualitative and quantitative elements and should be handled according to their main focus. As stated above, FSS does not make a distinction between qualitative data and quantitative data. In the interest of brevity, specific instructions on what to archive are not included in the FSS RDM Guidelines. The focus is instead on the reasoning behind selecting data to archive: “all data than can be reasonably deemed necessary to verify the findings of the research.” A separate document with specific FSS Archiving Guidelines exists which is linked to in the general RDM guidelines. The FSS Archiving Guidelines closely follow the DSW guidelines for quantitative data. 2.1.1 Quantitative research The following materials must be stored for each published empirical study (article, volume, book chapter, PhD thesis chapter, Research Master’s thesis, consultable internal report, etc.): NA The published (or accepted) manuscript or publication. Included in FSS Archiving Guidelines. A brief description of the problem definition, research design, data collection (sampling, selection and representativeness of informants) and methods used. An electronic version of the published manuscript will generally suffice. This is considered redundant with point 1. The instructions, procedures, the design of the experiment and stimulus materials (interview guide, questionnaires, surveys, tests) that can reasonably be deemed necessary in order to replicate the research. The materials must be available in the language in which the research was conducted. The publication package must be in English. This has been reworded slightly in the FSS Archiving Guidelines, since replication is not possible for all research at the faculty. We therefore only talk about verification. The FSS guidelines require materials to be available in the original language, and in English. When using primary data, the (de-identified) raw data files (providing the most direct registration of the behaviour or reactions of test subjects/respondents, for example an unfiltered export file of an online survey or raw time series for an EEG measurement, e-dat files for an E-Prime behaviour experiment, recordings or transcripts of interviews, descriptions of observations, archive and other source or media material). Documentation of the steps taken to de-identify the data and a blank consent form. If the raw data files have been accessibly stored in an external archive (such as storage facilities at DANS), making reference to the files in this archive will suffice. Such externally archived raw data may include primary or secondary data. Raw data may not be changed once they have been made digitally available. FSS Archiving Guidelines do not require the data to be pseudonymized, as outlined above, but otherwise this is included. Computer code (for example Atlas.ti, SPSS/JASP syntax file, MATLAB analysis scripts, R code) describing the steps taken to process the raw data into analysis data, including brief explanations of the steps in English, for example a brief description of the steps taken in the qualitative analysis of primary research data, i.e. themes, domains, taxonomies, components. Included in FSS Archiving Guidelines for applicable data sets. The data files (either raw or processed) that were eventually analysed when preparing the article (e.g. an SPSS data file after transforming variables, after applying selections, etc.) The latter is not necessary if the raw data file was directly analysed. Included in FSS Archiving Guidelines, with an exception for cases where this data can easily be constructed from the raw data by running a script. In such cases providing the script and the raw data suffices. Computer code (for example syntax files from SPSS/JASP, Atlas.ti, Matlab, R; syntaxes of tailored software) describing the steps taken to process the analysis data into results in the manuscript, including brief explanations of the steps in English. Included in FSS Archiving Guidelines for applicable data. The data management plan Included in FSS Archiving Guidelines. A readme file (metadata) describing which documents and files can be found where and how they should be interpreted. The readme file must also contain the following information: Name of the person who stored the documents or files Division of roles among authors, indicating at least who analysed the data Date on which the manuscript was accepted, including reference Date/period of data collection Names of people who collected the data If relevant: addresses of field locations where data were collected and contact persons (if any) Whether or not an ethical assessment took place before the research, and, if relevant, study reference from and statements made by the Ethics Review Committee Whether the data is made open or not and if not, a valid reason for not opening up the data Included in FSS Archiving Guidelines. A VU template is expected to be available soon. The readme file must be sufficiently clear. A relevant fellow researcher must be able to replicate the results discussed in the publication based on the components of the publication package. Included in FSS Archiving Guidelines, without the word “replicate”. Documents relating to the ethical approval or a reference to such documents. Included in FSS Archiving Guidelines, with wording specific to our ethics committee. 2.1.2 Qualitative research For qualitative, interpretative methodologies, a distinction should be made between the two main criteria for research integrity, i.e., transparency and reproduction. Transparency is a valid and legitimate demand also for qualitative research (and data), but reproduction is not considered possible in all cases, due to the very nature of the research designs and epistemology. Qualitative data are often impossible to fully de-identify and the research data is often gathered in forms and formats that cannot be stored in a digital repository. Of course, some of these data may be highly sensitive and cannot be shared with others without breaking ethical rules and the confidentiality that is often guaranteed to informants and other (human) sources of information. But as the aim of these guidelines is not sharing data but storing data, qualitative research should also be archived. Sensitive data should be stored on secured faculty servers. And when the format does not allow researchers to store original objects, it suffices to store pictures of the material. These data should be stored safely in a way that is accessible to the researcher who gathered the data. Researchers are therefore expected to store their data safely and to make specific plans for the time period of storage of their data, where and in which manner the data will be stored, and what will be done with the data once the research project ends or, for longterm ongoing research, once the researcher retires from research reporting etc. This calls for an elaborate and transparent data management plan or another, similar or equivalent form of data storage plan that describes: what kind of data will be gathered, by whom, in what format, where and in which form these will be stored, and to what extent and under what conditions this data will be shared and with whom, and any specific steps that will be taken to share the data that is safe to be shared. The researcher should be aware that according to the Netherlands Code of Conduct for Research Integrity there may be (highly exceptional) cases in which there are compelling reasons for components of the research, including data, not to be disclosed to an investigation into alleged research misconduct. Such cases must be recorded and the consent of the board of the institution must be obtained prior to storing the components and/or data in question. This documented exception must also be mentioned in any results published. In addition to safely storing data, the (qualitative) researcher shall make sure to maintain a record of the following metadata: The dates that the researcher carried out the data collection (e.g. dates of interviews or observation, period(s) of time spent in the field (start date and return date), etc.; The type of activities carried out (e.g., participant observation, number of interviews, frequency and character of observation, familiarizing oneself with the field, informal and formal conversations, other types of recording activities); Interview and observation guides (if available); Any hard evidence of the period of time spent in the field (e.g. flight reservations, train tickets, etc.). FSS does not provide separate archiving guidelines for qualitative data. Archiving of qualitative data is important for verification purposes, and there is no reason why qualitative data should not be archived along the standards outlined above. 2.2 When must a publication package be stored? A publication package must be stored within one month after the definitive publication of the manuscript. A publication package must be stored for each submitted research master’s thesis. A publication package must be stored for each empirical chapter of a PhD thesis submitted to the thesis committee (or one single publication package if the thesis is a monograph). Once a publication package has been stored, it will be fixed and can then no longer be modified (read only). FSS guidelines follow this. 2.3 Who is responsible for storing publication packages? If the first author works at one of the faculties of behavioural and social sciences, they will always be responsible for the archiving of the publication package, i.e. the storage of raw and edited data, syntax and materials, and additional information about the publication process as discussed above. Second or later authors who work at a faculty of behavioural and social sciences must know that the data have been carefully stored and how this has been arranged. This is particularly relevant if the first author does not work at a faculty of behavioural and social sciences. If an FSS researcher is first author, they are responsible for archiving. If they are second or later, they “must know that the data have been carefully stored and how this has been arranged.”, regardless of first author affiliation. If the first author works at one of the faculties of behavioural and social sciences, the second or later author may assume that the first author will follow the guidelines of his or her own university, and the second or later author will not have to create a publication package. See above. For PhD candidates and research master’s students, the primary supervisor or the day-today supervisor respectively are responsible for storing publication packages. The primary supervisor or day-to-day supervisor may delegate the execution of this task, but they will continue to bear final responsibility. This is in FSS guidelines. In collaborative projects a specific plan to clarify responsibilities related to the data after the project might be required. The person who coordinates the research programme that covers the publication (which, depending on the faculty in question, could be a professor, head of programme or head of department) is ultimately responsible. This is not explicit in the FSS guidelines. Adherence to the guideline will be discussed in performance and appraisal interviews. Formal final responsibility lies with the dean. This is in FSS guidelines. 2.4 Who has access to the publication package? Publication packages should be accessible by more than one researcher. The first author will have reading rights, but no right to delete or change versions. The first author will have writing rights for adding new versions. If a faculty has appointed a ‘co-pilot’ to check the analysis or a data steward to consider data management compliance, they will also be assigned reading rights. The faculty board can assign reading rights to a specific official to prepare for audits of publication packages on its behalf, for example, the coordinator of a research programme or a member of an academic integrity committee. After publication, academic peers should be granted access to the publication package if they make a reasonable request to verify or examine the published research results in the context of academic debate. The archiving infrastructure offered by the VU (the Yoda Vault) follows this. Minimum storage period For the retention period regarding research, a distinction is made between research data (and software) and the documentation of the process that has been carried out. Publication packages must be centrally stored on a secure faculty server facility for at least 10 years after the publication appeared. In the event of research (or secondary research) data including personal data, the principle of data minimization (conform GDPR regulation) must be applied as soon as possible. The Netherlands Code of Conduct for Research Integrity offers options to deviate from the retention period of 10 years. However, in that case the raw and processed data must be saved for a period suitable for the discipline and the methodology. The following could be taken into consideration when deciding on the the nature (and especially the privacy sensitivity) of the data; the need for source material to substantiate the results; the applied scientific value of the research results; the effort to make the data available for re-use; the efforts of long-term preservation; the usefulness of source material for follow-up research. The retention period of data management plans and data management protocols of projects, faculties and research institutes is at least 10 years, but not shorter than the retention period of the dataset . These documents primarily relate to policy making, execution and financing of research, and quality assessment. Also included here are the (legal) advice of ethical committees and evaluations and further agreements with research partners. Following VU policy, the FSS guidelines say to archive for 10 years, with the possibility to deviate if motivated in the DMP. 3.2 Data minimization and retention Data that can be traced back to individuals may in principle not be linkable to research data when this is no longer necessary for the purposes of the study. These personal data must be destroyed once they are no longer necessary for the purpose for which they were collected. Some specific studies may require retention of data that can be traced back to individuals, for example for the purpose of follow-up research or for longitudinal studies. Technical and organizational measures to protect the rights of data subjects need to be documented and will preferably be standardized for specific research scenarios. Protecting the right of data subjects is particularly important for raw data that cannot be de-identified (for example, video- and audio data). One complicating factor lies in the wish to retain personal data for the purpose of reviewing the integrity of the research itself, for example to check whether the participants did indeed participate in the research. If such integrity reviews are regarded as part of the research whose integrity is reviewed and considered necessary in the field it is allowed to store data that can be traced back to individuals for this purpose. When research is published, such personal data must be stored separately; not in the publication package. As an alternative option, researchers, faculties and research institutes can develop a protocol to monitor the integrity of the research before archiving, after which the personal data can be deleted. It is not necessary to store the personal data for the sole purpose of enabling participants to exercise their rights under the GDPR. The head of the relevant department or research program is responsible for monitoring the destruction of the research data on the required date. Official final responsibility lies with the dean. The discussion by DSW ignores the fact that once data is pseudonymized, it is no longer raw data. The decision on what directly identifying data to keep and what not is thus extremely context-dependent. FSS trusts its researchers to make the right call, and thus takes a pragmatic approach here, where researchers decide on a case-by-case basis what to keep, and keep a record of their decisions in their DMP. 3.3 How are storage and archiving of research data arranged? The raw de-identified data must be saved on a faculty server that satisfies the relevant requirements for data storage in terms of security, robustness and automatic back-up facilities. The recommendation is to save the raw data in read-only format, before the data are made available for processing. Raw data stored in this way become fixed, which means that researchers will no longer be able to modify them deliberately or by accident. The FSS guidelines recommend researchers use VU infrastructure (such as Yoda) which satisfy this. All data that can be traced back to individuals must be stored on a second faculty server, which is physically separate from the first faculty server and thus from the raw data. If a key is required to link pseudonymized raw data to the personal data, this key must be stored on the second faculty server. This includes raw data that cannot be de-identified and must be stored, such as audio- and video data in its original format that cannot be transcribed. The FSS guidelines don’t include this as a hard requirement, since few researchers have access to a second server. Currently, suggested alternatives to this are: - Encrypting directly identifying data. - Making sure that directly identifying data is not synced to local devices. External storage of raw data, for example in national or international data archives such as DANS – which makes the data publicly available, retrievable and citable – is recommended and in some cases required, for example when NWO requires this in a contract. However, this does not relieve researchers of their duty to store the data internally on the first faculty server. FSS does not comply with this, as archiving data twice puts an undue burden on researchers, and risks creating conflicting versions of data sets. Individual storage on an own hard drive, USB stick or cloud solution such as Dropbox does not suffice. Data that are collected within the framework of PhD or postdoc research must be archived in such a way that continuity is ensured when the PhD candidate or postdoc in question leaves the faculty. This is not explicit in FSS policy, but data needs to be stored on VU infrastructure. These storage requirements do not apply to sections of raw data that are managed by external organizations. Researchers who use data from external organizations must verify that the organization in question stores its data in accordance with a protocol that satisfies the requirements of these faculty guidelines. FSS guidelines are not explicit about this. Faculty-specific policy Individual faculties can choose to add the following rules to the above-mentioned guidelines concerning publication packages and storage of raw data: 1. Faculties may decide that the guidelines also apply to data collected within the framework of one-year master’s and bachelor’s research projects. The supervisor can then be appointed as the responsible party. 2. Faculties may decide to extend these guidelines to include storage of all data, including research that has not been published. This must be set out in a data management plan. 3. Faculties may define rules concerning ownership of data, for example that storage of data in a publication package will not result in a change of ownership. 4. Faculties may decide to make random inspections to check the existence and quality of publication packages. 5. Faculties may use different time periods and, for example, indicate that a publication package must be archived upon acceptance (rather than publication) of a manuscript. 6. Faculties may decide that each manuscript must state where the data are stored (a data statement) and which roles the various authors played. FSS does not extend to Bachelor and 1-year Master students, as sufficient infrastructure is not available for this. For now, FSS policy only applies to published research. VU has central policy that data is owned by the VU. FSS encourages department heads to ensure that researchers who leave FSS can continue to work with their data. Random inspections do not fit within the culture of trust that FSS aims to cultivate. DSW guidelines and VU guidelines are both for 10 years, and there is no reason to deviate. This is included in the FSS guidelines. FAIR Principles Date: Mar-16 Last reviewed: 15/06/2023 URL: https://www.go-fair.org/fair-principles/ FAIR Principles FSS F1. (Meta)data are assigned a globally unique and persistent identifier FSS guidelines require data to be archived in a repository that issues a unique and persistent identifier. F2. Data are described with rich metadata (defined by R1 below) FSS guidelines are for researchers to do this on PURE (at a minimum). F3. Metadata clearly and explicitly include the identifier of the data they describe FSS guidelines are for researchers to do this on PURE (at a minimum). F4. (Meta)data are registered or indexed in a searchable resource PURE meets this criterion. A1. (Meta)data are retrievable by their identifier using a standardised communications protocol A1.1 The protocol is open, free, and universally implementable A1.2 The protocol allows for an authentication and authorisation procedure, where necessary Public data repositories provide a link that works for this. For private data, researchers have to provide persistent contact details. A2. Metadata are accessible, even when the data are no longer available FSS relies on PURE and Yoda for this. I1. (Meta)data use a formal, accessible, shared, and broadly applicable language for knowledge representation. FSS does not have specific guidelines to ensure machine readability, but does recommend all archiving to be done in English. I2. (Meta)data use vocabularies that follow FAIR principles FSS requires all documentation to be uploaded in the same repository, under the same identifier as the data. I3. (Meta)data include qualified references to other (meta)data FSS has no specific guidelines for this. R1. (Meta)data are richly described with a plurality of accurate and relevant attributes R1.1. (Meta)data are released with a clear and accessible data usage license R1.2. (Meta)data are associated with detailed provenance R1.3. (Meta)data meet domain-relevant community standards FSS requires all public data to include licenses , and all personal data to have information about the informed consent procedure. Data that is not made publically available, but only archived for verification purposes, should only be made available under strict data transfer agreement that limit the use of data to the verification of the findings of the original research. To ensure provenance, FSS requires researchers to upload the rawest data they can, and a description of all modification to this data. Guidelines for Anthropological Research: Data Management, Ethics and Integrity Date: 2019 Last reviewed: 15/06/2023 URL: https://antropologen.nl/app/uploads/2019/01/guidelines-for-anthropological-research.pdf ABV FSS Data ownership, data protection, and Open Science: Anthropological research materials cannot be considered as disembodied and transferable ‘data’. As much anthropological knowledge is co-produced with our interlocutors, we cannot transfer possession, access, or ownership rights of ‘our data’ to others (such as employers, fellow-scientists, or the general public) without their consent. Based on relations of trust, our interlocutors often share personal and sensitive material with us. We are responsible for keeping such personal and potentially sensitive materials protected and confidential. Providing open access to fieldwork materials is therefore limited; in the case of an integrity inquiry we can at most provide confidential access. The definition of data as used by the ABV is slightly different than that used by most of the policies that the FSS RDM guidelines are based on. Therefore, for the purposes of the FSS RDM Guidelines, anthropological research materials are considered data. However, the FSS RDM policy fully supports researchers stiving to keep personal and potentially sensitive materials protected and confidential: protection of respondents’ privacy is a valid reason not to grant open access to data. Anonymizing ethnographic research materials is often not a workable solution, as it is not only overly time-consuming but above all removes so much detail, that the material becomes virtually meaningless The FSS RDM Guidelines are written with the realization that anonymization (or more often pseudonymization) comes at a real cost (in terms of time, effort, and data quality), and that only the researcher can determine whether the costs of anonymization/ pseudonymization outweigh the benefits. It therefore lists pseudonymization as something researchers can do to further secure their data, not as something they must do. Anthropological knowledge production: Anonymity as default option and non-disclosure of fieldwork data are a precondition for anthropological knowledge production before they are turned into ethical concerns. If we do not allow for anonymity and the protection of our fieldwork material, many of our interlocutors would be hesitant, if not positively reluctant, to share their insights with us. Moreover, much of the knowledge we co-produce with our interlocutors is embodied and personal. Our fieldnotes function as a memory bank, rather than a complete record of knowledge acquired. Using this material without such personal knowledge runs the serious risk of misinterpretation of the material. This character of anthropology as a science dealing with research materials that can often not be reduced to ‘data’ has serious ethical consequences, especially regarding the following. This relates to the points above: for the FSS RDM Guidelines, field notes would fall under the category “data”, but the practical implications are limited: it is not necessary for data (and thus field notes) to be published or be interpreted by others. For verification purposes, the data should be archived as a record of the steps the researcher took to arrive at the conclusions in publications. Such archived data will only be accessed in case of doubts regarding academic integrity. Academy of Management Code of Ethics Date: undated Last reviewed: 15/06/2023 URL: https://aom.org/about-aom/governance/ethics/code-of-ethics AoM FSS 2.4.1. When maintaining or accessing personal identifiers in databases or systems of records, such as division rosters, annual meeting submissions, or manuscript review systems, AOM members delete such identifiers before the information is made publicly available or employ other techniques that mask or control disclosure of individual identities. FSS guidelines require pseudonymization before publication of data sets. 2.4.2. When deletion of personal identifiers is not feasible, AOM members take reasonable steps to determine that the appropriate consent of personally identifiable individuals has been obtained before they transfer such data to others or review such data collected by others. FSS requires researchers to follow GDPR which has a more comprehensive approach on what can and cannot be done without consent. 2.5. Electronic Transmission of Confidential Information:  AOM members use extreme care in delivering or transferring any confidential data, information, or communication over public computer networks when conducting AOM work. AOM members are attentive to the problems of maintaining confidentiality and control over sensitive material and data when the use of technological innovations, such as public computer networks, may open their communication to unauthorized persons. Following GDPR, FSS requires researchers to take appropriate technical measures to secure personal data. Beroepscode Nederlandse Kring voor Wetenschap der Politiek Date: May-08 Last reviewed: 15/06/2023 URL: http://politicologie.nl/wp-content/uploads/2021/10/Beroepscode-2008.doc NKWP FSS II.5: Politicologen dienen bij het verrichten van onderzoek maximaal zorg te dragen voor de intersubjectieve controleerbaarheid van hun bevindingen die zowel mogelijk dient te zijn voor collega-politicologen alsook voor derden die niet tot de kring der politicologen behoren. Daartoe zijn zij verplicht om, na de eerste publicatie dienaangaande, hun originele gegevens en relevante documentatie daarvan, eventueel onder bepaalde restricties, ter inzage en ter beschikking van derden te stellen teneinde replicaties en vergelijkingen mogelijk te maken. Het verdient aanbeveling de gegevens na op zijn laatst twee jaar onder te brengen in een openbaar data-archief. This matches closely FSS Guidelines. FSS requires researchers to archive data in such a way that findings are verifiable, and also recommends publishing data. III.4 Gegevens die ten behoeve van wetenschappelijke doeleinden zijn verzameld, mogen uitsluitend voor wetenschappelijk onderzoek worden gebruikt en dus niet worden aangewend voor justitiële of commerciële doeleinden. FSS guidelines makes no such requirement, as it may be difficult to put in practice. “Commercial purposes” is poorly defined, and excluding those purposes may prove more restrictive than anticipated. It is therefore advised to make published data available under that doesn’t limit such use. For more information see: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3234435/ III.5 De direct identificerende gegevens van de informanten blijven anoniem voor derden, tenzij de informanten uitdrukkelijk toestemming hebben gegeven om hun identiteit in de openbaarheid te brengen. Onder direct identificerende gegevens worden verstaan: naam, adres, telefoonnummer, fiscaal nummer, kortom, gegevens die onmiddellijk tot één persoon te herleiden zijn. Reeds in het proces van gegevensverzameling dient vertrouwelijk te worden omgegaan met identificerende persoonsgegevens. Vertrouwelijkheid in deze fase houdt onder meer in dat direct identificerende persoonsgegevens gescheiden van andere gegevens worden bewaard en daaraan verbonden zijn door versleuteling. Als politicologen het vergaren van gegevens laten verrichten door anderen, zien ze er op toe dat die het in dit artikel gestelde in acht nemen. Politicologen zorgen ervoor dat direct identificerende gegevens niet in handen van derden komen, tenzij deze derden gehouden zijn aan de regels van deze code. Direct identificerende gegevens worden na afloop van het veldwerk vernietigd als ze niet meer nodig zijn voor het controleren van verzamelde gegevens. Als regel wordt een termijn van zes maanden na het afsluiten van het veldwerk aangehouden. FSS guidelines are roughly in line with these requirements, but explicitly acknowledge that it may be difficult to remove directly identifying information while simultaneously maintaining data integrity and provenance. Beroepscode Nederlandse Sociologische Vereniging Date: 2002 Last reviewed: 15/06/2023 URL: https://www.nsv-sociologie.nl/?page_id=17 NSV FSS Sociologen dienen bij het verrichten van onderzoek maximaal zorg te dragen voor de intersubjectieve controleerbaarheid van hun bevindingen die zowel mogelijk dient te zijn voor collega-sociologen alsook voor derden die niet tot de kring der sociologen behoren. Daartoe zijn zij verplicht om, na de eerste publicatie dienaangaande, hun originele gegevens en relevante documentatie daarvan, eventueel onder bepaalde restricties, ter inzage en ter beschikking van derden te stellen teneinde replicaties en vergelijkingen mogelijk te maken. Het verdient aanbeveling de gegevens na op zijn laatst twee jaar onder te brengen in een openbaar data-archief. FSS guidelines are in line with this. Gegevens die ten behoeve van wetenschappelijke doeleinden zijn verzameld, mogen uitsluitend voor wetenschappelijk onderzoek worden gebruikt en dus niet worden aangewend voor justitiële of commerciële doeleinden. FSS guidelines makes no such requirement, as it may be difficult to put in practice. “Commercial purposes” is poorly defined, and excluding those purposes may prove more restrictive than anticipated. It is therefore advised to make published data available under that doesn’t limit such use. For more information see: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3234435/ De direct identificerende gegevens van de informanten blijven anoniem voor derden, tenzij de informanten uitdrukkelijk toestemming hebben gegeven om hun identiteit in de openbaarheid te brengen. Onder direct identificerende gegevens worden verstaan: naam, adres, telefoonnummer, fiscaal nummer, kortom, gegevens die onmiddellijk tot één persoon te herleiden zijn. Reeds in het proces van gegevensverzameling dient vertrouwelijk te worden omgegaan met identificerende persoonsgegevens. Vertrouwelijkheid in deze fase houdt onder meer in dat direct identificerende persoonsgegevens gescheiden van andere gegevens worden bewaard en daaraan verbonden zijn door versleuteling. Als sociologen het vergaren van gegevens laten verrichten door anderen, zien ze er op toe dat die het in dit artikel gestelde in acht nemen. Sociologen zorgen ervoor dat direct identificerende gegevens niet in handen van derden komen, tenzij deze derden gehouden zijn aan de regels van deze code. Direct identificerende gegevens worden na afloop van het veldwerk vernietigd als ze niet meer nodig zijn voor het controleren van verzamelde gegevens. Als regel wordt een termijn van zes maanden na het afsluiten van het veldwerk aangehouden. FSS takes a pragmatic approach here, where researchers need to decide on a case-by-case basis what to keep, and keep a record of their decisions in their DMP. Abbreviations DMP Data Management Plan RDM Research Data Management FSS Faculty of Social Sciences VU Vrije Universiteit Amsterdam GDPR General Data Protection Regulation RERC Research Ethics Review Committee Definitions Personal Data All data that can be directly or indirectly tied to a living person. Identification Two types of identification are possible, based on research data: Direct: the data includes information that directly reveal the identify of a respondent, such as name address, phone number date of birth, etc. Indirect: the data can be combined with other information to reveal the identity of a respondent. Indirect identification is extremely difficult to prevent, and possible with most FSS Data sets. Data Storage Storing data during the research process, when it’s actively being worked on Data Archiving Keeping data for verification purposes, usually not publicly available Verification Review to assess whether the data supports the conclusions drawn in a publication. Registration Entering the details of a data set (but not the data set itself) on a public page, such as PURE. Valid grounds not to publish data include Intellectual Property Rights, personal data protection and confidentiality, security concerns, as well as global economic competitiveness, and other legitimate interests. These exceptions can be found here (paragraph 14)↩︎ "],["rdm-faq.html", "RDM: FAQ General Data Storage and Security Personal Data Sharing Data and Notes Data Management Plans (DMPs) metadata and FAIR Data", " RDM: FAQ General Where can I go with questions about Research Data Management? Either the Faculty Data Steward (Koen Leuveld, k.leuveld@vu.nl) or the Library’s RDM Support Desk: rdm@vu.nl. The Data Steward can help you best with questions that are specific to the work we do at the faculty, and with questions about specific grants; the RDM Support Desk is best equipped to deal with questions that could be asked by any VU researcher, for example about storage or archiving options. But both work together, so you can’t ask the wrong person. Where can I find more information about Research Data Management? We maintain a number of resources you can consult. At the VU level, there is the Research Data Support Portal which contains links to anything you might want to know about RDM, and the library maintains a series of Libguides explaining various topics related to the management of your data. At the faculty level, the data steward maintains a page giving advice that is specific to researchers in Social Sciences, including links to content you can use in proposals. I don’t have data. I only have observations. As RDM experts, we would say that observations are also a type of data. But that doesn’t really matter: in any case, you want to protect your observations, make backups of your observations and make sure that they are archived securely or shared with the world so that you can demonstrate you did your research well. That is to say, many important aspects of Research Data Management apply whether you call your observations data or not. Data Storage and Security Where should I store my data? Our advice is to use Yoda for storage and archiving, even for sensitive data, and only use VU-managed to devices to access the data. You can find other options in the Storage Finder, but check with the Data Steward if they work for the sensitivity level of your data. What is the difference between data storage and archiving? Data storage refers to where you save your data during the research. Your data storage option needs to be available to all collaborators, while still ensuring a sufficient level of security. Data archiving is where you keep your data after you are done with it, but it may need to be accessed when there are doubts about research integrity. Your data archiving solution can be publicly accessible if there is no sensitive data, or restricted-access if there is. The solution needs to be permanent and secure, so that the data cannot be changed, and any links to it will remain functional indefinitely. What security measures should I take? When using personal data (see below), per GDPR you should take “appropriate organizational and technical measures” to secure your data. The specific actions you should take are not set in stone; you should consider the potential consequences of a data breach, and whether or not the actions you would have to take to prevent them are reasonable. All VU storage solutions offer a number of security measures. For example, access is only allowed using passwords and multi-factor authentication. If your data is sensitive, there is a number of additional security measures you can take that reduce the risk of data leak, either by reducing the chance a leak happens, or by reducing the impact of a leak: Make sure people only have access to the data they need to do their task in your project. For example, with Research Drive it is possible to give each collaborator only access to the folders they need. Don’t sync data from your Research Drive to your personal computer if you don’t have to. For example, once you are done with your raw data, having it on your personal computer only increases the chance that your data is leaked: keep the raw data online-only, and only sync the processed (pseudonymized) data you are working on. Make sure everyone in your project is trained in security procedures, such as strong passwords, not clicking attachments in emails from unknown senders etc. Pseudonymize your personal data by removing any directly identifying information, so that any data that is leaked is less likely to be linked to your respondents. If you need to keep the directly identifying data (for example, because it’s part of your raw data which you want to keep to demonstrate the provenance of your data, or because you need to contact participants for follow-up), make sure this data will not be leaked at the same time as the pseudonymized data. You can do this either by storing it separately or by encrypting it. See “When should I pseudonymize?”, below. Encrypt your data, so that if someone accesses the hard drive that holds your data, they can’t read the data. Software such as Cryptomator makes encryption very convenient. Encryption does have a large downside: loss of your password means loss of the data. You can use a password manager to minimize this risk, but it is wise to think twice before deciding to use encryption. For help on deciding what measures are appropriate for your data, and with the practical implementation of any of these, you can contact your data steward. Personal Data What is personal data? Personal data is any data that can be directly or indirectly linked to a living person. You can directly link data to a person if a direct identifier like their name, phone number, email address etc. is included in the data. You can indirectly link the data if you can combine the data with another piece of data or information to find the person who the data is about. This is possible for more data than you think, so if you collected data from people, it’s safe to assume your data is personal data, even if you remove things like names, phone numbers and addresses. What is the difference between anonymization and pseudonymization? Both these terms mean that you make it less likely that the data that you have can be linked to your respondents, increasing the security of your data. In case of pseudonymization, you remove the possibility of directly linking the data to your respondents, by removing things like names and addresses from the data. Anonymization removes entirely the possibility of linking your data to your respondents, both directly and indirectly. This means that the data is no longer personal data, and GDPR does not apply. However, anonymization is difficult and we don’t usually recommend it (see below). When should I pseudonymize? There is no “one-size-fits-all” answer to this: in general, we do recommend pseudonymizing your data, but in some cases the benefits of pseudonymization may not outweigh the costs. These costs and benefits depend on the nature of your data. A tabular data set is easily pseudonymized by dropping certain variables and generating random identifiers, so it should probably be pseudonymized. On the other hand, for an audio recording it may be practically impossible to edit out all the names. Likewise, the benefits differ; for a dataset containing speeches by famous politicians, leaving out the names will not make identification appreciably more difficult, and yield no security benefits as the data is publicly available anyway. Whether the costs of pseudonymization outweigh the benefits thus depends on the specific project. If you feel the costs don’t outweigh the benefits, feel free to contact your Data Steward to see if they agree, and make sure to write down your reasoning in your Data Management Plan. Should I keep my unpseudonymized data? If so, where? If possible, directly identifying data is kept completely separate from research data. For example, your Qualtrics form should not contain fields for email addresses if that’s not needed for the research itself. If you need email addresses to send rewards, use a separate form. In this way, you can destroy any personal data as soon as possible, without editing the raw data. However, this is not always possible, since some times the directly identifying data is integral part of the raw data (for example in video recording). In these cases you should not destroy the data, because you should keep an unedited version of your data for transparency purposes. This raw copy of the data should be stored safely, and in such a way that a data breach doesn’t necessarily mean a breach of both pseudonymized and unpseudonymized data. Examples are: Store the raw data on a separate server (however, most research programs don’t have two servers available). Store both raw and pseudonymized data on the same server (or device) but encrypt the raw data. You should make sure that you can’t lose your encryption password, or else you lose your raw data. Keep both both pseudonymized data on the same server, but make sure the raw data is never synced to personal computers or other devices (for example by adding it to a Yoda Vault). This way, the raw data is protected from the most common data breaches (e.g. losing a laptop in the train). Why is it so hard to anonymize data? Anonymization is potentially very attractive because it removes the need to comply with GDPR. However, it is difficult to combine with the goals of researchers in practice. This is because it will almost always involve making data less detailed, which will harm your ability to draw conclusions from the data. To see why, first consider a quantitative data set about work satisfaction, containing gender and age of all respondents. If I know my colleague is a respondent in this survey, I may be able to infer things about my colleague from the public data set. If only one person in the data set matches his age and gender, I have successfully (indirectly) identified him in the data set. If there are multiple people matching his age and gender are present, but none has indicated liking their colleagues, I have still inferred something about him, and may become very disappointed! To prevent me from identifying of my colleague, you as the researcher should thus ensure that there are no unique combinations of age and gender (for example by using broader age bins) and that within each combination of age and gender there is sufficient variation in answers that nothing can be inferred about individuals (so there is always a mix of people who like their colleagues and those who don’t). It is easy to see how the binning of variables may lead to less precision in the analysis, and how difficult it is to ensure that proper variation exists in all (combinations of) variables. There are ways to do this, but it is usually more attractive to keep the data as personal data, even if this puts restrictions on data use due to GDPR. Qualitative data sets are usually so rich that all observations are unique, and thus potentially identifiable by someone who knows your respondents well (or otherwise has detailed information on them). Qualitative data is therefore usually impossible to fully anonymize, though pseudonymization may be possible. I know it’s difficult, but I would still like to anonymize my data, how do I do this? That’s great! A good place to start is the R package sdcMicro. Your data steward may be able to help out when using it. Alternatively, there is Amnesia. Note that anonymization means modifying your data, so if you want to anonymize data for replication purposes, not all analyses that you did with your unanonymized data can be fully replicated using anonymized data. This is acceptable, if explained properly in your paper (e.g. in a footnote). I don’t have informed consent forms for my research. Is that bad? It’s not necessarily bad, because written informed consent is only required by law in cases of health research (where WMO applies). You can have participants give informed consent orally if you’re not doing WMO research, but make sure you record it and store it safely. You can ask advice from your data steward or privacy champion if you will ask oral informed consent. There are also other legal grounds (than informed consent) on which you can do research. However, if you should have asked informed consent, but did not do so, that could be bad and we recommend that you contact your privacy champion as soon as possible. Sharing Data and Notes Can I publish personal data? Yes you can. But make sure: Your respondents have given explicit consent to publishing the data; To use VU provided services, such as OSF, Yoda or DataverseNL; Not to publish more than needed. In particular, the data should be pseudonymized; and, You publish nothing sensitive, and your respondents run no risk because of the data you publish. I don’t want to share my data, because participants in my research (or other people) may get in trouble. In that case, it is not ethical to share them and we recommend that you do not do so. It is still important to archive your data for verification purposes. The Yoda Vault exists for this exact purposes: data stored there can only ever be accessed by other researchers who have a reasonable request for verification. In your DMP you can outline your reasoning why you don’t want to share your data. Nobody else but me will understand my notes. Then why should I share them with others? If your notes contain personal data, you should not probably not share them at all, but you should still archive them so that it can be verified that your research has been done in the way you claim in your publications. If the notes do not contain personal data, sharing your notes is a good way of opening up your research. It’s best not to assume no one is interested in your notes. Even if you think your notes are unreadable, someone may still find them of great use. For example, someone who wants to do research into how researchers take notes, or someone studying early 21st century hand writing. If you want to share your notes in a more useful and readable way, but are worried about the workload you could also consider cleaning up only a subset of them and sharing that. Small steps to more transparent science can very worthwhile! In the informed consent forms, I didn’t ask if data may be reused by other researchers. Can I share them now? In this situation, you cannot share the personal data with researchers outside the VU. There are two things that you could do: If possible, go back to your participants and ask them if other researchers may reuse their data; If this turns out to be impossible, anonymize the data. Then the data are no longer personal. We do recommend that you ask your data steward for help, because this can be tricky (see above: Personal Data > Why is it so hard to anonymize data?). If neither these are possible, you can’t share the data. This is one of the reasons why it’s so important that you write a Data Management Plan before collecting data, so you will have thought of these things in advance. Can I be forced to publish my data because of the WOB? The Wet Openbaarheid van Bestuur (WOB) only applies to public entities, so not to the Stichting VU (the VU is unique among Dutch universities in this). However, the WOB may apply to the commissioner of your research, for example if your research is commissioned by the national government, or about the functioning of local governments or the police. In these cases, the WOB most likely still doesn’t apply to research data, since there are numerous grounds for exemption, such as the protection privacy. Get in touch with your Data Steward if you’re still worried about this. I’m afraid that other researchers will misuse my data. How can I prevent that from happening? It depends on what you mean by “misuse”. If this concerns using your data commercially, you can add a license to your data that specifies non-commercial use only. The same goes for data that may not be remixed. If, however, the misuse can occur simply by the nature of your data, then we recommend that you speak to a data steward and/or a representative of the ethical review committee to discuss your doubts and your options. Data Management Plans (DMPs) metadata and FAIR Data How can I start writing a Data Management Plan? You can log into DMPOnline with your VU credentials to start writing a DMP. It has templates of most funders which are kept up to date by the university library. If you need any help (for example with the technical terms used in many DMP templates), feel free to contact the faculty data steward. Where can I find examples of Data Management Plans? DMPOnline has a large number of Data Management Plans from which you can get inspiration for your own DMP. What DMP template should I use? For projects involving personal data, it is recommended that you use the VU template. You can currently only access the VU Template by ticking the box “No funder associated with this plan or my funder is not listed”. This template is accepted by ZonMW and NWO. By using this template you make sure that the information of your project can be used in the “GDPR registry”, which the VU is obligated to maintain and provide to the privacy authorities on request. What if my funder doesn’t accept the VU template? You can make use of the template provided by your funder (most funders’ templates are on DMP Online). To make sure your project is included in the GDPR registry, you need to fill out the VU GDPR registration for for reseatch, which you can find as a template on DMP Online: select “Create Plans”, and then make sure to tick the box “No funder associated with this plan or my funder is not listed”. I never created a Data Management Plan. Is that bad? There are some situations in which writing a DMP is mandatory. For example, if you have received a grant, you almost always have to write a DMP. The Faculty of Social Sciences also requires you to write a DMP for any new research project you start. And DMPs are sometimes necessary components of various requests, such as an ethics application (for a full procedure) and a storage application (in some cases). And obviously, if you are following the course “Writing a DMP”, you have to write a DMP to complete the course. Now, for research that is already underway, writing a DMP is a good practice, but not doing so is not necessarily bad. Writing a DMP, though, is a good way to keep you accountable and not let things come down to chance and luck. And it helps you to avoid last-minute panic. Although you are already under way with the research, it can still be a good idea to write a DMP. You can get in touch with your data steward or the RDM Support Desk if you still want to do it. What is metadata? Metadata is data about your data. It is simply information such as authors, colloborators, dates, description, key words. It is not the data itself. So even if your data itself is very sensitive, the metadata may be freely published (though in some cases metadata can be sensitive as well). What metadata and documentation should I include with my data? If you use Yoda, you can simply fill out the metadata form included in the portal. Otherwise, you can use this file to write a “readme file” that contains the same information. As for documentation: this is very much dependent on your data. A useful excercise is to imagine yourself having to take a break from research for a few years. What information would you need to get back into understanding your data again? This can include questionnaires, codebooks, field manuals, topic lists, proposals, ethics applications, data management plans etc. What metadata standard should I use? The one that is used by the service where your data will be archived, published, or registered. PURE used a standard called CERIF; Yoda uses DataCite. The forms on those services will ensure that everyhting is stored according to these standards, so this is not something you need to worry about. What does FAIR data stand for? FAIR stands for Findable, Accessbile, Inter-operable, and Re-usable. Many of these sub-elements of FAIR cover a wide spectrum of possibilities: some data can be made more easily accessible than others, for example. Below are some tips on how to ensure that your data is acceptably FAIR. Findable: your data needs a persistent identifier, and be registered on a public page somewhere. At the very least, your dataset should be registered on the VU Research Portal (PURE). Here you should also include a DOI link to the data set if your data is publically available. Data arhived on Yoda gets a DOI as soon as you publish the metadata. (The data itself can remain private.) Accessible: make sure that people can access the data in case its needed. You do this by archiving the data in a repository when you publish findings. This doesn’t need to be a public repository, but your data needs to be at least available for verification purposes, in case there’s doubts about scientific integrity. A Yoda vault is perfect for this. Public repositories may offer restricted access, where you control who accesses the data, or public access. Inter-operable: make sure that if someone has access to your data, they can make use of it (potentially even combine it with other data, if you choose to give people that option). Make sure to use standard file extensions and make sure the data is accompanied by enough information that a well-informed colleague can start using the data without to many difficulties. At a minimum, you should include a Readme file, and any tools used to generate the data (topic lists, questionnaires, interviewer guides, manuals, cleaning scripts etc.). Re-usable: make sure that if people have access to your data, they know what they are allowed to do with it. This means that the terms of use of all outputs are clear, for example by using licenses (as open as possible is best, for example the CC-BY license), and that information about the informed consent procedure is included, so other researchers know what your respondent consented to. For using restricted (i.e. non-public) data from Yoda, a strict data sharing agreement can be drafted, limiting the use to verification of the research findings. My funder wants me to make my data FAIR, but I can’t share the data because of privacy concerns. This is not a problem. Data needs to be Accessible. This means that there is a well-defined procedure for accessing the data, for example in cases where there are doubt about scientific integrity. Archiving your data securely on Yoda is sufficient for this. "],["rdm-tools.html", "RDM: Tools More resources", " RDM: Tools The figure below gives an overview of the tools that are available throughout the research lifecycle. Faculty-specific advice and guidance on which tools are recommended is provided in the table below. If you would like to use other tools, feel free to contact the Faculty Data Steward for more information. More general information about the data management tools provided by the VU can be found on the Research Data Support Portal. Information about costs can be found here. Tool FSS Guidance How to get started Storage Finder The storage finder offers information about all storage options offered for research data, even those not typically used in the faculty of social sciences https://vu.nl/en/research/storagefinder DMP Online All work you do on data needs to be covered by a DMP in the VU template on DMP Online. This is because both your department head and the Dutch privacy regulator need to be able to have insight into what happens to the data used in the faculty. This is facilitated by DMP Online. If, for whatever reason, you have a DMP elsewhere, you can fill out the shortened \"GDPR registration form\" on DMP Online to ensure transparency. Visit https://dmponline.vu.nl, log in with your institutional credentials, and start writing! If you are not sure about what to enter, please don’t spend hours researching the answer: you can always schedule a session with the Faculty Data Steward. Yoda Yoda is the preferred solution for storing and archiving data at FSS. It is rated for sensitive data, can be used with (external) collaborators, and allows for secure access both on and off campus. Data can be added to a \"vault\" to preserve a persistent copy. This copy can be assigned metadata, a DOI,and (optionally) be published. Visit yoda.vu.nl, fill out the request form, and the functional manager of yoda will schedule an intake with you. Research Drive Research Drive can be used to store data during your research, but, unlike yoda, can’t be used for archiving or publishing. It does have two advantages over Yoda. Firstly, it offers fine-grained access control to sub-folders. This allows you to specify folder which team members can access it. For example, you can choose not to give students access to senstive materials. Secondly, it offers better syncing, allowing you use more effectively offline. Because of the lack of archiving options, you will mostl likely have to combine Research Drive with Yoda. Visit https://services.vu.nl/esc?id=kb_article&sysparm_article=KB0012856 for more information and a request form. OSF The OSF is great for making your work more transparent, pre-resgistering studies and publishing data. There is much information on OSF.io; VU has an institutional account with the OSF, meaning you can log in with your VU credentials. Teams / SURF Drive While Teams and SURF Drive are great for collaboration with colleagues and students, we recommended not to use them for storing research data since the backup and security features of other storage solutions such as Yoda and Research Drive are much more robust. Access to Teams and SURF Drive is standard for all employees. More resources Information when starting a new project FSS RDM Guidelines FSS Guidelines for data organization FSS Guidelines for data archiving RDM FAQ Overview of RDM Tools "],["rdm-presentations.html", "RDM: Presentations", " RDM: Presentations 15 and 22 June 2023: Workshop Writing a DMP 19 June 2023, PSPA Department Meeting "],["404.html", "Page not found", " Page not found The page you requested cannot be found (perhaps it was moved or renamed). You may want to try searching to find the page's new location, or use the table of contents to find the page you are looking for. "]] diff --git a/templates.html b/templates.html index b7310a6..8955756 100644 --- a/templates.html +++ b/templates.html @@ -23,7 +23,7 @@ - + @@ -110,13 +110,13 @@
    • Re-usable
    • What to archive?
    -
  • Knowledge and Guidelines
  • Templates
  • RDM: VU FSS guidelines for data management
      @@ -143,7 +143,7 @@
  • RDM: Tools
  • RDM: Presentations
    • @@ -167,33 +167,39 @@

    Templates

    Data Management Plans

    -

    The University Library manages DMP Online so that all templates are up-to-date. It is advisable to use the VU template whenever possible (this is accepted by ZonMW and NWO instead of their own templates).

    -

    Filled in examples can be found in the following places:

    -
      -
    • There is a page with public DMPs on DMP Online. You are encouraged to make your own DMP public as well.
      • -
    • The LIBER Research Data Management Working Group maintains a page with example DMPS. These focus mostly on economics, but may be of use to other Social Scientists as well.
      • -
    • The FSS Guidelines for Data Organization include an example DMP for each use case.
      • -
    +

    The University Library manages DMP Online so that all templates are up-to-date. It is advisable to use the VU template whenever possible (this is accepted by ZonMW and NWO instead of their own templates). The FSS Guidelines for Data Organization includes example DMPs that you can use for inspiration. For detailed guidance, you are encouraged to plan a consult with the Faculty Data Steward

    Data Protection Impact Assessment

    -

    A Data Protection Impact Assessment (DPIA) is a systematic process that helps identify, assess, and mitigate the risks associated with the processing of personal data. While it is never a bad idea to do a DPIA, in some cases it’s mandatory. To check whether you need to do a DPIA, you can fill out the pre-DPIA tool. If the result is that a DPIA is needed, you can contact the Faculty Data Steward to assist in drafting one, or have a look at the DPIA template.

    +

    A Data Protection Impact Assessment (DPIA) is a systematic process that helps identify, assess, and mitigate the risks associated with the processing of personal data. While it is never a bad idea to do a DPIA, it’s mandatory only in specific cases. To check whether you need to do a DPIA, you can fill out the pre-DPIA tool. If the result is that a DPIA is needed, you can contact the Faculty Data Steward to assist in drafting one, or have a look at the DPIA template.

    Agreements

    • Data Sharing Statement: if students (or student assistants) work on sensitive data, it is wise to have them sign a statement that they will treat the data confidentially.
    +

    For agreements with third parties, it’s best to be in touch with the Faculty Data Steward who can assist in liasing with the relevant departments at the VU.

    +
    +