About this page
A DMP is expected for any research project with clear temporal boundaries that is conducted at ETH Zurich (see Guidelines for Research Data Management at ETH Zurich). The purpose of this Data Management Plan (DMP) template and instructions is to assist ETH researchers with writing a DMP in line with good practice for data management and complies with the Guidelines for Research Data Management at ETH Zurich (RDM Guidelines) and the ETH Zurich Guidelines on scientific integrity (Integrity Guidelines). The actual blank ETH DMP template can be found here.
If your project is supported by a research funding agency, please adhere to the requirements of the respective funder when writing and implementing the associated DMP. In case you have to prepare a DMP for the Swiss National Science Foundation (SNSF), this website can provide you with information about ETH-specific solutions. However, in such a case, please follow mainly the guidance for an SNSF DMP to address all relevant questions. The guide for the SNSF DMP can be found here.
The structure of the DMP template provided by the Swiss National Science Foundation (SNSF) served as the main basis for the elaboration of this ETH specific DMP template and was further complemented with content of the Checklist for a Data Management Plan from the Digital Curation Center (DCC) and the DLCM template for the SNSF Data Management Plan.
The next paragraph provides key questions and links to further information that should help to comprehend and answer the questions of each section in the template. Example answers for the questions in each subsection included in the DMP are provided below. Please consider your DMP as a declaration of intent. It should reflect your decisions and practices in data management, but necessary changes can and should be made within the time frame of your project. To refer to this page please use the following: “ETH Library (2021), DMP Instructions for ETH Zurich Researchers”.
DMP Instructions for ETH Zurich Researchers © 2021 by ETH Library is licensed under CC BY 4.0 . For reusing example answers from each of the subsections, no citation is necessary.
Guidance and instructions for the ETH Zurich DMP template
This section incorporates the structure and content of the SNSF’s DMP template. Every subsection comprises the same questions as found in the SNSF’s template (as expandable section) with some slight modifications. This guide is supplemented by key questions (bold and underlined) and corresponding suggestions (in italic) as well as useful information to provide the minimum content required for each specific sub-section.
Note that you are not expected to describe technical services in detail if you rely on an established service at ETH. However, please at least name the service and its provider.
Section 1: Data collection and documentation
1.1 What data will you collect, generate or reuse?
- What are the types and formats of your research data?
Please list all the data types that will arise during your project and add the corresponding file formats.
Are the file formats and software you use open source? Do they enable sharing and long-term access to the data?
You can of course use proprietary file formats and software, but keep in mind that they are not open to everybody and therefore they limit the reusability of your data. To ensure reusability, data in proprietary formats should be converted into open and properly documented standard formats.
- What will be the estimated volume of data generated during the project?
Indicate the approximate volume, ideally per data type.
Are you reusing existing data (yours or third-party)?
If yes, please detail the nature of these data and ideally list the persistent identifiers (e.g. DOIs) if available.
The data produced in this project will fall into  categories:
Data in category 1 will be saved and documented in [...] format and will amount to approximately […TB]. Data in category 2 will be saved and documented in […] format and will amount to approximately […GB]. Data in category 3 will be saved and documented in […] format and will amount to approximately […MB].
Reused data stem from Smith (2000, DOI: […]) and Miller (2011, DOI: […]).
No other pre-existing data will be reused.
[back to overview]
1.2 How will the data be collected or generated?
- What methodologies and standard procedure will you use for data collection?
Briefly describe every collecting and processing step related to your research data during the entire project. The use of community standard procedures is to be preferred in case there are some already established in your research field or discipline.
- What measures are you taking to assure quality and consistency of generated data?
Measures may include but are not limited to usage of a controlled vocabulary, calibration processes, repetition of measurements or whole experiments, standardised data capture, data entry validation or data peer review.
What file naming conventions and file folder structure will you use? How will you handle versioning of files?
File names should represent content and should not exceed 30 characters. Use ASCII characters, no spaces, no upper cases and points only before file extension. Example: YYYYMMDD_experiment1_scientist2.pdf
The reaction conditions will be recorded and collated using a spreadsheet application and named according to each generation of reaction as follows: YYYYMMDD_HHmm_ProjectW_ReactionX_GenerationY_ScientistZ.csv
The various experimental procedures and associated compound characterization will be written up using the [e.g., Royal Society of Chemistry (adapt to your own discipline)] standard formatting in a Word document. Each Word document will also be exported to PDF-A. The associated NMR spectra will be collated in chronological order in a PDF-A document.
All samples on which data are collected will be prepared according to published standard protocols in the field [cite reference]. Files will be named according to a pre-agreed convention. The dataset will be accompanied by a README file which will describe the directory hierarchy.
Each directory will contain an INFO.txt file describing the experimental protocol used in that experiment. It will also record any deviations from the protocol and other useful contextual information.
Microscope images capture and store a range of metadata (field size, magnification, lens phase, zoom, gain, pinhole diameter etc.) with each image.
This should allow the data to be understood by other members of our research group and add contextual value to the dataset should it be reused in the future.
All files produced during this project will be stored in our Electronic Laboratory Notebook (ELN) and Laboratory Information Management System (LIMS) openBIS.
In this ELN, each scientist has a personal folder where to organize projects and experiments. Each experiment is described in the electronic notebook and all data related to the experiment is directly attached to it, in so called “datasets”. Each dataset is immutable, thus different file versions are stored in the lab notebook in different datasets with a manually generated version number. Very large datasets (100s of TBs) are not directly stored in openBIS datasets, but they are linked to the experimental description using an extension to openBIS called BigDataLink. This works similarly to the git version control software, so every time changes are made to the data, these need to be committed to openBIS, which automatically keeps track of the versioning.
[back to overview]
1.3 What documentation and metadata will you provide with the data?
- What information about your data (i.e., metadata) is required to make reuse of your data in the future?
Just imagine what you would need to know so that you are able to reuse other researchers’ data within your scientific field. At least it should include basic metadata such as the name of the data(set), persistent identifier, names of creators and contributors, date of creation and access conditions. However, it might further contain more specific details as on methodology, analytical and procedural information, definition of variables, defined vocabularies, units of measurements. Do not forget to mention system environments as well as software and the software version, which you have used, for example, for data analysis.
Are you using certain community standards for the annotation of metadata?
The usage of metadata standards enables interoperability meaning that computers and other machines can read this information. If community standards exist in your research field or discipline, they should be preferred.
How will data documentation be carried out?
A README file should be attached, which contains all the metadata associated with the dataset that are relevant for verification, validation, and exploitation of research results. The information in the README file usually exceeds the amount and type of metadata gathered at the data repository that you have selected for uploading your research data.
Files and folders will be named according to a pre-agreed convention [XYZ], which includes for each dataset identifications of the researcher, the date, the study and the type of data (see section 1.2).
The final dataset as deposited in the chosen data repository will also be accompanied by a README file listing the contents of the other files and outlining the file-naming convention used.
Metadata will be tagged in XML using the Data Documentation Initiative (DDI) format. The codebook will contain information on study design, sampling methodology, fieldwork, variable-level detail, and all information necessary for a secondary analyst to use the data accurately and effectively.
It will be the responsibility of:
- each researcher to annotate data with metadata,
- the Principal Investigator to check weekly (during the field season, monthly otherwise) with all participants to assure data is being properly processed, documented, and stored.
Two types of metadata will be considered within the frame of the project X: (i) metadata corresponding to the project publications, and (ii) that corresponding to the published research data.
The metadata that would best describe the data depends on the nature of the data. For research data generated in project X, it is difficult to establish global criteria for all data, since the nature of the initially considered datasets will be different, so that the metadata will be based on a generalised metadata schema as the one used in [e.g., ZENODO (gathered metadata depends on the chosen repository)] which includes elements such as:
- Title: free text
- Creator: Last name, first name
- Subject: Choice of keywords and classifications
- Description: Text explaining the content of the data set and other contextual information needed for the correct interpretation of the data,
- Format: Details of the file format,
- Resource Type: data set, image, audio, etc.,
- Identifier: DOI,
- Access rights: closed access, embargoed access, restricted access, open access.
Additionally, a readme.txt file will be used as an established way of accounting for all the files and folders entailed in the project and explaining how all the files that make up the data set relate to each other, what their file format is or whether particular files are intended to replace other files, etc.
In the data management system (openBIS ELN-LIMS), metadata are provided as attributes of the respective datasets. Based on the defined metadata schema, openBIS ELN-LIMS will be configured so that the required metadata is automatically assigned to datasets and / or manually provided by the researcher. Within openBIS we will provide metadata in line with the following metadata schema: […to be added by researcher…]
[back to overview]
Section 2: Ethics, legal and security issues
2.1 How will ethical issues be addressed and handled?
Are parts of your data sensitive data? What makes them sensitive?
Sensitive personal data is information that makes a person identifiable. Sensitive data can also be confidential data such as contractual agreements with external partners. If the project deals with human subjects, ethical approval from the Ethics Committee of the Canton of Zurich (KEK) or the ETH Ethics Commission is needed.
- Have you applied for ethical approval and was it granted?
If your study requires ethical approval, your DMP must be in line with the conditions under which ethical approval was granted.
Did you inform study participants, and did they give their consent to collection, sharing and preservation of their data?The consent form is part of the application for the ETH Ethics Commission. Normally, you can briefly outline what is written in the consent form of the approved application. Please keep in mind that sensitive data can only be published in a completely anonymized form. 1
- What methods will you use to ensure the protection of personal or other sensitive data?
Please describe any necessary protection measure such as the storage location, data encryption, pseudonymization, anonymization2 as well as the time of application. Be aware that the identification key of pseudonymized data should be kept in a separate physical storage location. Please also describe what happens with the data after the end of the project: Is part of these data supposed to be archived or does it need to be deleted?
The project does not involve human or animal subjects. Therefore, no ethical issues are expected to occur during the generation of results from this project. None of the data collected or reused in this project is subject to a confidentiality agreement.
We will gain formal approval by our ETH ethics committee for all our studies before starting the data collection. All participants will be carefully instructed about the aim and nature of our studies prior to participation. Before the study starts, participants will be asked to provide informed consent, using the forms that have been approved by our ethics committee. Participation is voluntary. Participants will be told explicitly that they have the right to withdraw from our study without explanation and without penalty.
All data will be collected anonymously.
The PI and the research team will work in conformity with all applicable rules, guidelines and principles such as the EU directive 2010/63/EU on the protection of animals used for scientific purposes, the Swiss federal law on animal protection (RS 455), the federal ordinance on animal protection (RS 455.1), and the federal ordinance on animal experimentation, production, and housing (RS 455.163). All animal experiments will only be initiated after having received the approval of the Cantonal and Federal authorities.
Details on animal usage:
In performing the experiments, we strive to strictly adhere to the 3Rs principle of Replacement, Refinement, and Reduction.
Training: All researchers and technicians working with the animals receive proper animal welfare training in conformity with DFE Ordinance 455.109.1 on ‘Training in animal husbandry and in the handling of animals’.
All data are anonymised3, and as such, we are in line with the Swiss Federal Act on Data Protection as described on the page of the Federal Data Protection and Information Commissioner (FDPIC). The anonymized data will only be published in line with the consent forms signed by participants. Moreover, we will adhere to the recommendations of the selected FAIR repository regarding upload and licensing of the anonymized data.
[back to overview]
2.2 How will data access and security be managed?
The data will be processed, managed, and analysed on […description of server infrastructure…], which is regularly and automatically backed up. Raw sequencing data is stored on the group storage on […e.g, the Euler cluster at ETH]. Only authorised persons (project members) will have access to the storage server via their password-protected institutional accounts. Since no personal or confidential data is produced or reused in the project, no special infrastructure or security measures will be necessary. Research data used in this project will be classified in line with the Directive on “Information Security at ETH Zurich” and marked accordingly. [For the directive, see the Directive on “Information Security at ETH Zurich”, Appendix 1b in particular could be relevant and helpful for classification]
All input data for analysis and output data from analysis will be shared in a GitLab repository [e.g., GitLab repository hosted by ETH Zurich’s IT Services, https://gitlab.ethz.ch] available to the project members. The same holds for the metadata about input and output data together with text file documentation for code. The systems from which these data are extracted by the company is only available to their employees. For security reasons, we do not share data or code in any other ways (e.g., by email). Research data used in this project will be classified in line with the Directive on “Information Security at ETH Zurich” and marked accordingly.
[For the directive, see the Directive on “Information Security at ETH Zurich”, Appendix 1b in particular could be relevant and helpful for classification]
Leonhard Med is the ETH secure scientific Data and IT platform to securely store, manage and process confidential research data [e.g., sensitive personal data in biomedical research]. Sufficient security is provided by this tool, i.e. strictly restricted access to authorized users, secure isolated storage and encrypted backup, shared or dedicated compute resources, logging and monitoring of user activity, strictly restricted access to trusted external internet sites, compliancy with the Leonhard Med Acceptable Use Policy (https://rechtssammlung.sp.ethz.ch/Dokumente/438.1.pdf).
Data analysis of offline data (i.e., processing that was not performed in real time) will be performed in the Leonhard Med platform. If the analysis requires software that is not available to the moment in Leonhard Med, computed statistical maps on the individual level (individuals cannot be identified) will be transferred to a dedicated computer where the analysis can be performed. Only internal research personnel will have access to Leonhard Med and will be trained for it. General authentication and authorization at ETH Zurich are handled by the Identity- and Access Management System of the central IT-Services at ETH.
Specific guidelines apply for using the Leonhard Med Cluster at ETH Zurich to securely store, manage, compute on and share confidential research data (https://ethz.ch/services/en/it-services/it-security/guidelines.html).
Because we will deal with personal, sensitive data, project members will be provided with and sign confidentiality agreements. Access to personal/sensitive data will be restricted.
Storage media and safety back-ups will require password access to prevent misuse. The applicant and the supervisor are responsible for secured access to datasets as well as for safeguarding the code keys.
The level of the data availability risk is low, the level of data integrity risk is high, and the level of data confidentiality is high.
Regarding anonymization / encryption: All sensitive data will be encrypted at rest (e.g., on file system when not in use, in backups) and in transit and keys will be managed only by the [name of data controller]. Pseudonymized data are still sensitive personal data and there will be a concordance table stored at the data controller. All sensitive, personal data will be handled securely (concordance table will be encrypted as it is not actively used). We will follow the policy and available procedures of Leonhard Med for ensuring data security during transfer. Leonhard Med offers a specific secure data transfer process in encrypted form, via encrypted channels.
Regarding access rights: Sensitive personal data will be accessible only to the following people working in the project: [name person A] [name person B]. The grantee and the Principal Investigator of the project will be responsible to ensure compliance with these defined access rights.
Regarding storage and back-up: All data will be backed-up on a regular basis [good practice is minimum daily] and access to backup media will be managed according to data access rules. All damaged media containing sensitive data will be physically destroyed. Research data used in this project will be classified in line with the Directive on “Information Security at ETH Zurich” and marked accordingly.
[For the directive, see https://rechtssammlung.sp.ethz.ch/Dokumente/203.25en.pdf, Appendix 1b in particular could be relevant and helpful for classification]
[back to overview]
2.3 How will you handle copyright and Intellectual Property Rights issues?
Who will be the owner of the data?
In principle, the data creator is the owner (i.e., copyright holder) of the data and therefore has the right to allocate a licence to these data. For multi-partner projects a consortium agreement might be worthwhile. Make sure that you keep enough rights when a transfer of rights occurs as for instance during data upload into a commercial data repository. In case you would lose all rights when using such a repository service, look for alternatives. In addition, all the data that have been generated during an employment at ETH Zurich shall in principle remain at ETH Zurich (see Integrity Guidelines).
- Which licenses will be applied to the data?
For research data we recommend the use of Creative Commons (CC) licenses such as CC0 and CC-BY, because they allow easy reuse. However, CC-licences should neither be applied for sensitive data, nor for software and code. Furthermore, all code and software developed at ETH Zurich must be registered at ETH transfer prior to sharing them. Appropriate software licenses apply.
- Are there any constraints for data sharing and/or reuse of third-party data?
If you have specific contract agreements on parts of your data with for instance an industrial partner you just need to state that you cannot disclose that data due to this fact. Do not name the partner in case this is already confidential. Please contact ETH transfer, if you are in doubt about contract agreements with research or industrial partners as well as if you are aiming for a patent application.
The collected data is suitable for sharing. They are observational [or: experimental] data and could be used for other analyses or for comparison in future studies. Reuse opportunities are vast. For this reason, the project participants aim to allow the widest reuse of the data and will release them under a Creative Commons public domain dedication (CC0) [alternative: creative commons CC-BY licence]. With regards to data sharing, there are no restrictions due to copyright or intellectual property rights.
All data used in the project is owned by the collaborating company. A contract has been signed by both parties stating the project’s aims, methods, ownership rights, and how the project outcomes will be used.
[back to overview]
Section 3: Data storage and preservation
3.1 How will your data be stored and backed up during the research?
How will the data be backed up and who is responsible?
State how often the data will be backed up: daily back-up is recommended. You can also indicate the retention time of backed up files (e.g., for recovering of older versions). As long as data is stored on standard ETH Zurich storage infrastructure, your departmental IT services take care of the automatic backup (see below). If you are not certain, which storage locations are included, contact your departmental IT services.
- Where will the data be stored during the research project and are there limitations regarding storage capacity?
Please consider the various types of storage that exist at ETH Zurich. For more information on departmental procedures, consult the IT support group in your department. Keep in mind that sensitive data require special solutions for data storage (see above).
All data are stored on the standard departmental ETH server. If the data sets are exceeding a reasonable amount it is switched to the Network Attached Storage (NAS) also hosted by ETH. Both, standard ETH server and NAS include automatic daily backups6 and are maintained by ETH Zurich’s IT Services.
[Example 1 +] All data will also be uploaded to and stored on GitLab for version control [e.g., GitLab repository hosted by ETH Zurich’s IT Services, https://gitlab.ethz.ch]. This holds for both the raw input data that will be processed for analysis and any output data from the analysis.
The data will be stored via using the following resources:
- For general storage, ETH’s server infrastructure (for aggregated, non-personal and non-sensitive data) and Leonhard Med (for personal, sensitive data) will be used, with standardized, daily backup procedures.
- A copy of the non-personal and non-sensitive data will also be stored on local hard-drives.
- For code storage and version control, we will use GitLab. (https://gitlab.ethz.ch/).
Data stored on the ETH server infrastructure and Leonhard Med will be automatically backed-up daily and storage in hard drives will be backed-up weekly. Insertions and changes made in GitLab are tracked and versions are kept automatically. The team will be instructed to follow a checklist for storing and backing up data, standardizing the procedure.
[back to overview]
3.2 What is the long-term preservation plan for your research data?
Which parts of your research data could be of use in the long term and should therefore be preserved?
You should describe here what happens to the research data far beyond the lifetime of a project. Data with long-term value could be, but are not limited to, all the data underlying a publication that are necessary to verify, validate and reproduce published research results. Please also consider ethical and legal issues that might prohibit long-term storage of certain data types. Data with long-term value might be placed into a digital archive for long-term preservation. The standard way how research data can be preserved at ETH Zurich is by submitting data to the ETH Research Collection. A copy of the data is then automatically transferred to the ETH Data Archive, ETH Zurich’s long-term digital archive (except for data deposited via Libdrive).
- Which file formats will be used for preservation?
Please consider our recommendation table for file formats that are suitable for digital long-term preservation. Comment also on the choice of your file formats and on the use of community standards.
We will preserve the data for 10 years on ETH’s servers and also deposit it in an appropriate data archive at the end of the project [e.g., disciplinary data repository/archive, ETH Research Collection (with long-term preservation in the ETH Data Archive, or Zenodo, see examples in section 4.1 below)]. Where possible, we will store files in open archival formats, for example, Word files converted to PDF-A or simple text files encoded in UTF-8 and Excel files converted to CSV. In case this is not possible, we will include information on the software used and its version number.
This research project is an industrial collaboration. The data are owned by the collaborating company and constitutes a valuable resource in the highly competitive industry in which they operate. For this reason, the original data cannot be preserved in a public data archive. Instead, the original raw input data owned by the industrial partner is preserved by the collaborating company. All aggregated, non-confidential parts of the data will be submitted to the [name of the archive, e.g., disciplinary data repository/archive, ETH Research Collection (with long-term preservation in ETH Data Archive), or Zenodo] to be kept for a minimum of 10 years. Where possible, we will store these files in open archival formats. E.g., Word files will be converted to PDF-A or simple text files encoded in UTF-8 and Excel files will be converted to CSV. In case this is not possible, we will include information on the software used and its version number.
The data will only be stored in an appropriate archive once they are fully anonymized7 and only in line with the consent forms signed by participants. Moreover, we will adhere to the recommendations of the selected FAIR repository regarding upload and licensing of the anonymized data.
[back to overview]
Section 4: Data sharing and reuse
4.1 How and where will the data be shared?
On which data repository do you plan to share your data?
ETH Zurich requires sharing of at least research data and programming code that forms the basis of published research output at the time of publication (see RDM Guidelines). Data should be made available in compliance with the FAIR data principles including assignment of a persistent identifier (e.g. DOI) and open access to the data with the exception of sensitive personal and confidential data that cannot be publicly shared. If possible, deposit your data in a well-established, trustworthy, non-commercial repository that implements the FAIR principles. The institutional FAIR data repository of ETH Zurich is the ETH Research Collection. Alternatively, a FAIR data repository can be selected that operates within your field of research. If such a repository exists, it might be more suitable regarding metadata community standards.
Data collected in this project will be released under a Creative Commons public domain dedication (CC0) [alternative: creative commons CC-BY licence] in the ETH Research Collection [alternatives: appropriate subject specific repository XY; Zenodo; others…] as a FAIR data repository. Data underlying publications will be shared at the point of publication of a journal article or book chapter, while all remaining data will be made available at the end of the project period.
This research project is an industrial collaboration. The data are owned by the collaborating company and constitutes a valuable resource in the highly competitive industry in which they operate. For this reason, the original data cannot be made publicly available. As far as contractual obligations with the industry partner permit, metadata-only entries that describe the datasets will be made available in the ETH Research Collection [alternatives: appropriate subject specific repository XY; Zenodo; others…] as a FAIR data repository. In that way, other researchers can find the dataset and get information about it without having direct access to the protected data.
Patients have been informed and provided consent with a signed consent form regarding the publication of their anonymized data in a public repository. The collected patient data will be fully anonymized8 before publication. The anonymized data will be released under the standard usage licence (rightsstatements.org/page/InC-NC/1.0/) in the ETH Research Collection [alternatives: appropriate subject specific repository XY; Zenodo; others…] as a FAIR data repository. Anonymized data underlying publications will be shared at the point of publication of a journal article or book chapter, while all remaining data will be made available at the end of the project period.
The collected data contains genetic information that could easily identify individual persons. Therefore, the respective data must be protected and cannot be published in a repository. As far as the metadata do not contain any confidential or personal information, metadata-only entries that describe the datasets will be made available in the ETH Research Collection [alternatives: appropriate subject specific repository XY; Zenodo; others…] as a FAIR data repository. In that way, other researchers can find the dataset and get information about it without having direct access to the personal data.
[back to overview]
4.2 Are there any necessary limitations to protect sensitive data?
- Under which conditions will you make the data publicly available?
Describe your restrictions for data sharing due to ethical or legal constraints, preparation for patent application, security constraints, contractual obligations, intended commercial purposes and copyright issues as outlined in the Guidelines for Research Data Management at ETH Zurich. Be aware that confidential and/or person-related research data (as defined in footnote 4) can only be published in completely anonymised9 form and in line with consent obtained from study participants. This purpose should already be considered when preparing consent forms for study participants.
The project does not involve usage of any sensitive data. Therefore, no special limitations to data use or reuse are necessary.
The data used in this project will be handled in line with the respective classification level [strictly confidential and/or confidential, see DMP section 2.2.] that has been selected in accordance with the Directive on “Information Security at ETH Zurich”. All data is aggregated, anonymized10 and processed to be compliant with data privacy laws. As described, the original data will nonetheless not be made available due to strict confidentiality. The data ownership lies with the partner company.
The data used in this project will be handled in line with the respective classification level [strictly confidential and/or confidential, see DMP section 2.2.] that has been selected in accordance with the Directive on “Information Security at ETH Zurich”. All data is aggregated, anonymized11 and processed to be compliant with data privacy laws. [Data that cannot be fully anonymized cannot be published. Anonymized data can only be published to the extent covered by informed consent.]
[back to overview]
1 “all items which, when combined, would enable the data subject to be identified without disproportionate effort, must be irreversibly masked or deleted” (Human Research Ordinance, Art 25)
2 see footnote 1 [definition of anonymization]
3 see footnote 1 [definition of anonymization]
4 “A person is identifiable if a third party having access to the data of the person is able to identify such person with reasonable effort. [This can refer to health or biomedical traits,] religious, ideological or trade union related views or activities; […] the intimate sphere or racial origin; social security measures; administrative or criminal proceedings and sanctions” (From the document Data Protection in Research Projects by ETH Zurich, accessed 15.10.2021).
5 in accordance with the Directive on “Information Security at ETH Zurich” (accessed 15.10.2021)
6 If you or the principal investigator of your project are not sure about the conditions at your ETH Zurich department, please check with your departmental IT services at ETH whether daily backups are ensured for your standard department servers. A list of contacts can be found here.
7 see footnote 1 [definition of anonymization]
8 see footnote 1 [definition of anonymization]
9 see footnote 1 [definition of anonymization]
10 see footnote 1 [definition of anonymization]
11 see footnote 1 [definition of anonymization]