Where to store research data under GDPR: cloud storage options for universities

"Where can I put my interview recordings?" is one of the most common questions research data stewards get. The GDPR does not name approved services, but it does set rules that rule some options out. This guide explains how universities classify research data, why a personal cloud account is not the same as the institution's tenant, what national research infrastructures in the Nordics and the Netherlands offer, and how to handle encryption and sharing links.

Published 7 October 2026 · Sources checked 7 October 2026

Prefer a tool built in the EU? Kahubi, from Avidemic AB in Sweden, covers an AI assistant for research work with EU hosting and, for institutions, only European subprocessors. See how Kahubi handles research data

1. What the GDPR actually requires

The GDPR does not list approved storage services. It sets four requirements that together decide which services are acceptable for personal data in research:

• Security appropriate to the risk (Article 32). Measures must reflect the state of the art, costs, the nature of the processing and the risk to individuals. Article 32(1) names pseudonymisation and encryption, confidentiality, integrity, availability and resilience, the ability to restore data after an incident, and regular testing of the measures.
• A processing agreement with any provider (Article 28). A cloud provider that stores data for the university is a processor. The university may use only processors providing "sufficient guarantees", under a contract with the content listed in Article 28(3), including rules on subprocessors.
• Rules on transfers (Chapter V). Article 44 allows transfers to third countries only under Chapter V conditions. The EDPB's Guidelines 05/2021 say that remote access from a third country (even just viewing data on a screen for support) and storage in a cloud outside the EEA can be transfers when the three criteria for a transfer are met.
• Research safeguards (Article 89(1)). Research processing needs technical and organisational measures, in particular for data minimisation, which may include pseudonymisation.

Special categories of data in Article 9 (for example health, genetic or biometric data, ethnic origin, political opinions or sexual orientation) raise the risk and therefore the required level of security. The EDPB's Guidelines 1/2026 on scientific research (a version for public consultation, adopted 15 April 2026) list safeguards that include setting up "a secure processing environment" or an access point through which researchers reach data "without any need for local storage", and, for genetic and biometric data, federated storage with access through secure processing environments and role-based access controls.

Validemic's analysis These are institutional obligations. The controller is normally the university, not the researcher, so a researcher choosing storage is applying the university's decision about which services meet Articles 28 and 32. That is why the practical answer to "where can I store this?" is almost always "in a service your institution has approved for this classification".

2. Step 1: classify the data

Most universities use a classification scheme with three or four levels. The University of Oslo's storage guide is a clear published example. It uses four classes:

The guide then marks every storage location as allowed or not allowed per class. Two of its rules travel well to other institutions. First, research data needs special attention to "linkage keys" and "consent forms", which should always be stored separately from the data they belong to. Second, at UiO only TSD is approved for storing and handling directly identifiable health information. UiO's research storage page also says research data may not be stored in the home directory or locally on your computer.

Your institution's scheme may use different names or levels. If you cannot find it, ask your research data steward, IT security team or data protection officer before choosing a service. A DPIA may be required for high-risk projects, and our DPIA screening tool helps decide.

3. Institutional or consumer cloud?

The same brand can be two very different services. A personal Dropbox, Google Drive or OneDrive account is contracted between the provider and you as an individual. An institutional tenant is contracted by the university, usually with a processing agreement, administrator controls, institutional login and audit logs.

UiO's storage guide shows the difference in practice:

• "Personal cloud service (Dropbox, Google Drive etc.)" is allowed only for open (green) data.
• UiO's own institutional Dropbox and Google Suite for Education are allowed for open and restricted (yellow) data, with notes in the guide.
• Microsoft 365 for UiO (Office, Teams, SharePoint, OneDrive) is allowed for restricted data. Red administrative data may be processed there under conditions, but the guide says: "It is not permitted to process red research data in Microsoft 365."
• TSD is allowed for all four classes, including black.

Other universities draw the lines differently, depending on their contracts, configuration and risk assessments. The point is that the decision attaches to the contracted service and its configuration, not to the product name.

Our fact sheets on the common platforms summarise what each vendor documents publicly about DPAs, data location and subprocessors, including for education and enterprise plans: OneDrive, Google Workspace, Dropbox, Box and Nextcloud.

Watch synchronised folders. UiO's guide warns that folders such as Desktop and Documents often synchronise to cloud storage, so saving a file "locally" may in fact put it in a cloud service not approved for that data.

Reviewing a vendor right now? Validemic checks the vendor's documents against GDPR and the EU AI Act and cites every finding. Try the demo workspace

4. National research infrastructure

Several countries run shared storage services for higher education. They are often operated by public bodies or sector organisations, hosted in the country, and integrated with the national academic login. That makes them a natural first option, but "national" does not mean "approved for everything". Each service, and each institution using it, decides what data may go there. The descriptions below come from the providers' own pages.

Sweden: Sunet Drive

Sunet, part of the Swedish Research Council, describes Sunet Drive as a storage and file sharing service located on Swedish servers, built on Nextcloud and Sunet's S3 storage in a private cloud. Login is through SWAMID, which Sunet says makes collaboration between organisations easier. Sunet says the organisation keeps full control over stored data and can manage it under its internal processes and the Archives Act, and it publishes external security assessment reports from 2024. Organisations order the service from Sunet and provide first-line support to their own users. The page does not state a data classification level; that is for each institution to decide.

Netherlands: SURFdrive and SURF Research Drive

SURF, which provides IT services to Dutch education and research, offers two sync-and-share services. SURFdrive is described as "the personal cloud storage service for Dutch education and research", based on Nextcloud, with 1 TB per user; institutions purchase it and manage access, and users log in through SURFconext. Research Drive is aimed at research teams that need more capacity and collaboration with national and international partners. SURF says users log in with SURFconext and multi-factor authentication, that it supports guests, groups, roles and public links, and that the service "complies with Dutch and European regulations". Institutions without their own environment can apply for a Community Edition with up to 5 TB.

Finland: CSC Allas, SD Connect and SD Desktop

CSC, the Finnish IT centre for science, runs Allas object storage. CSC's documentation says Allas "is not certified as high level security storage platform" and should not hold sensitive data in readable form, although sensitive data may be stored if properly encrypted before transfer. For sensitive data CSC generally recommends SD Connect, which encrypts files automatically on upload, supports multi-factor authentication and lets project members share data; files can be analysed in the isolated SD Desktop environment. CSC also notes that it does not back up SD Connect data, that data is deleted 90 days after project closure, and that SD Connect is unsuitable for data processed under Finland's Act on the Secondary Use of Health and Social Data, which has its own SD Desktop route.

Norway: TSD at the University of Oslo, and NIRD

TSD (Services for Sensitive Data) is run by the University of Oslo for researchers at UiO and other public research institutions, and UiO offers it to users outside UiO as well. UiO describes it as a platform to collect, store and analyse sensitive research data, with an integrated route for collecting data through Nettskjema and storage "up to black data". UiO's storage guide lists dedicated solutions in TSD for linkage keys and consent forms. UiO's research storage page also points to NIRD, provided through Norwegian Research Infrastructure Services (NRIS), a collaboration between Sigma2 and the universities NTNU, UiB, UiO and UiT; UiO's storage guide allows Sigma2 services for open and restricted data only.

Validemic's analysis Two patterns stand out. General sync-and-share services (Sunet Drive, SURFdrive, Research Drive) are convenient for collaboration but are configured and approved by each institution; dedicated sensitive data services (TSD, SD Connect with SD Desktop) trade convenience for isolation, separate keys and controlled import and export. For directly identifiable health data, institutions tend to point researchers to the second kind.

5. Comparison table

The table summarises what each provider's own documentation says. "Data level" reflects provider or host university statements only; your own institution's rules decide what you may store.

6. Encryption and keys

Article 32(1)(a) names "the pseudonymisation and encryption of personal data" among the measures to consider. Encryption also matters after something goes wrong: under Article 34(3)(a), communication of a breach to data subjects is not required if the affected data was protected by measures that make it unintelligible to anyone not authorised to access it, "such as encryption".

Three practical rules follow from the sources above:

1. Know who holds the key. SD Connect manages keys automatically; CSC's Allas guidance describes client-side encryption tools when you store sensitive data in Allas directly. With client-side encryption, losing the key means losing the data, so plan key storage and backup.
2. Encrypt portable copies. UiO allows red data on laptops only with a fully encrypted disk and on encrypted memory sticks or external drives, and not at all on privately owned computers.
3. Separate the keys from the data. This applies to pseudonymisation keys as well as encryption keys. UiO's guide says linkage keys and consent forms should be stored separately, and the EDPB lists barriers between identifiers and research data, for example by entrusting pseudonymisation to a trusted third party, as a research safeguard.

Validemic's analysis Provider-side encryption at rest is common in institutional cloud services and protects against stolen disks, but not against anyone the provider allows to access the data. For high-risk data, the questions that matter are who can decrypt, from which countries, and under what legal process. That is the territory of a transfer impact assessment.

7. Sharing links and collaboration

Validemic's analysis In day-to-day research the weak point is often not the data centre but the sharing: a link sent to the wrong person, a folder shared with "anyone with the link", or a former collaborator who still has access. Institutional rules address this directly. UiO's data sharing guide, for example:

• allows the Office 365 "share" button, Teams and OneDrive for open and restricted data, but not for red or black data;
• recommends encrypting confidential documents (for example with 7-Zip) and sending them through FileSender or UiO SafeShare;
• says passwords "should never be shared in the same channel as the content itself";
• allows only TSD for black data, which "should in principle not be shared".

SURF's Research Drive supports public links, guest accounts and group roles; this flexibility is useful, but it means the project needs its own rules on who may create links and for which folders.

When the collaborator is at another institution, the storage question becomes a contract question too. If you decide the study together, see our joint controller agreement guide; if you hand data over for the partner's own study, see the data sharing agreement guide. Both templates include a storage and security annex.

8. Checklist for researchers

1. Classify each type of data in the project using your institution's scheme. Different files may have different classes.
2. Find the services your institution has approved for each class (storage guide, data management plan support or the research data office).
3. Use the institutional tenant or national service, never a personal account, for anything above open data.
4. For sensitive data, use a dedicated sensitive data service if your institution offers one.
5. Keep pseudonymisation keys and consent forms separate from research data.
6. Encrypt laptops and any portable media; avoid local copies of high-risk data.
7. Check synchronised folders so that files do not end up in an unapproved cloud.
8. Share with named, authenticated people; no "anyone with the link" sharing of personal data; send passwords separately.
9. Review access at milestones and remove people who have left the project.
10. Record storage locations in the data management plan and the record of processing activities, and plan deletion or archiving at the end.
11. Before using a new tool (for example an AI transcription or analysis service), check it the same way. Our guide to GDPR and AI tools in research covers this.

Sources

1. Regulation (EU) 2016/679 (GDPR), Articles 9, 28, 32, 34, 44 and 89, Official Journal text (retrieved 7 October 2026).
2. EDPB Guidelines 05/2021 on the interplay between Article 3 and Chapter V, version 2.0 (retrieved 7 October 2026).
3. EDPB Guidelines 1/2026 on processing of personal data for scientific research purposes, version for public consultation, section 8 (retrieved 7 October 2026).
4. University of Oslo: Data storage guide (retrieved 7 October 2026).
5. University of Oslo: Data Sharing Guide (retrieved 7 October 2026).
6. University of Oslo: Storing research data (retrieved 7 October 2026).
7. University of Oslo: Services for sensitive data (TSD) (retrieved 7 October 2026).
8. Sunet: Sunet Drive (in Swedish, retrieved 7 October 2026).
9. SURF: SURFdrive (retrieved 7 October 2026).
10. SURF: Research Drive (retrieved 7 October 2026).
11. CSC: Store with Sensitive Data Connect (retrieved 7 October 2026).
12. CSC: Tools for client side encryption for Allas (retrieved 7 October 2026).
13. CSC: Analyse with SD Desktop (retrieved 7 October 2026).

About this page

Sources checked on 7 October 2026. Service descriptions come from the providers' and host universities' own pages; we did not test the services. Service terms, prices and approvals change, and your institution's rules take precedence over anything here. The classification examples and statements labelled as Validemic's analysis are our interpretation. This page is not legal advice. If you run one of these services, or you spot an error, please contact us and we will correct it.