How Researchers Can Protect Confidential Data and Satisfy Funder Requirements (2026)

Most funders now ask two things that can feel contradictory: share your data openly, and protect any data that is sensitive. If you handle interview transcripts, patient records, genomic data, unpublished results, or anything covered by a confidentiality agreement, you are the person who has to reconcile those two demands. This guide explains what funders actually require, what "protecting" research data means in practice, and the concrete steps that keep you compliant without turning your work into a security project.

This is a practical guide, not legal advice. For anything involving human subjects, patient data, or an institutional data protection officer, confirm the specifics with your institution and, where relevant, your ethics board.

Quick Answer

Funders rarely require a specific product. They require a credible plan: a Data Management Plan (DMP) that says where data lives, who can access it, how it is protected, how long it is kept, and what gets shared versus what stays restricted. For confidential data, the two expectations that matter most are access control (only authorized people can read it) and encryption (the data is unreadable to anyone else, including a hosting provider or a thief). The strongest setup for sensitive files is client-side, zero-knowledge encryption, where data is encrypted on your own machine before it ever reaches a server, so a breach of the storage provider exposes unreadable ciphertext rather than your participants' records. Open sharing applies to the non-sensitive, de-identified portion of your data, not to the confidential raw material.

Why this keeps researchers up at night

The pressure comes from several directions at once.

Funder mandates have tightened. Horizon Europe expects a Data Management Plan and applies the principle "as open as possible, as closed as necessary." The NIH Data Management and Sharing Policy, in force since 2023, requires a DMS plan for most funded research. UKRI and many national agencies have comparable expectations. None of these force you to publish sensitive data, but all of them force you to say, in writing, how you handle it.

Human-subject data carries legal weight. If your dataset contains personal data about people in the EU, GDPR applies regardless of where you process it. That means a lawful basis, data minimization, and "appropriate technical and organizational measures" to secure it. Special categories (health, genetic, biometric, data revealing ethnicity or political views) carry stricter conditions. Breaching participant confidentiality is not just an ethics-board problem; it can be a reportable data breach.

The practical environment is messy. Research data lives on laptops, lab shares, personal cloud drives, USB keys left in drawers, and email attachments sent to co-authors in three time zones. Collaboration crosses institutions and borders. The gap between the clean DMP you wrote for the grant and the reality on your disk is where most incidents happen.

The stakes are concrete: a lost laptop with unencrypted interview recordings, a shared Dropbox folder with permissions nobody audited, a cloud provider subpoenaed under foreign law, or unpublished results scraped from an under-secured server before you could publish. Any of these can end a collaboration, trigger a breach notification, or compromise participants who trusted you.

What funders actually ask for

Strip away the acronyms and most funder data policies reduce to a small set of questions you must answer in your DMP.

• What data will you collect or generate, and in what formats? Funders increasingly favor open, non-proprietary formats so data stays readable in ten years.
• How will you store and back it up during the project? They want to see that data survives a disk failure and is protected against unauthorized access.
• How will sensitive or personal data be protected? This is where encryption, access control, and anonymization or pseudonymization come in.
• What will you share, and what will stay restricted? The FAIR principles (Findable, Accessible, Interoperable, Reusable) are often misread as "make everything public." "Accessible" explicitly allows controlled access. Metadata can be open even when the data itself is not.
• How long will you keep the data, and what happens at the end? Retention periods are often set by the funder, your institution, or the field (clinical data in particular can carry long mandatory retention).

Notice what is not on the list: a brand name. Funders assess whether your plan is coherent and whether your safeguards match the sensitivity of the data. That gives you freedom to choose tools, but it also puts the responsibility on you to choose ones that genuinely deliver the protection you claim.

Protecting confidential data: the controls that matter

Think in layers. No single measure is sufficient, but a few high-leverage controls cover most of the risk.

1. Encryption, and the difference that actually matters

"Encrypted" is doing a lot of work in most policies, and the differences are not cosmetic. There are three meaningfully different levels, and funders and DPOs increasingly understand them:

Level	What it protects against	What still leaks
Encrypted at rest (server-side)	A thief who steals the physical disk from the data center	The provider can read your data; a subpoena or breach of the live system exposes it
End-to-end encrypted	Interception in transit and the provider reading content	Depends on the design; metadata often remains visible
Zero-knowledge	The provider reading your data at all, ever	Metadata and access patterns, depending on implementation

Most mainstream cloud storage gives you only the first level. That is fine for public data, but for confidential research material it means the provider holds the keys and can, in principle, read everything. If you want the storage layer to be genuinely unable to read participant data, you need client-side encryption, where files are encrypted on your machine before upload. I walk through these distinctions in more depth in the concrete differences between encrypted-at-rest, end-to-end, and zero-knowledge, and it is worth being precise about them in your DMP because reviewers notice vague claims.

The reason this matters so much for a breach is simple: when data is encrypted client-side with keys you control, a compromise of the storage provider leaks unreadable noise rather than readable records. That single property changes what you have to report and who is exposed. I spelled out exactly what changes in a data breach between classic cloud and local encryption if you want the full comparison.

2. Access control and the principle of least privilege

Encryption protects data from outsiders. Access control protects it from the wrong insiders. For each dataset, decide who genuinely needs access, grant exactly that, and review it when people join or leave the project. The most common real-world failure is not a sophisticated attack; it is a shared folder whose permissions were set once, at the start, and never revisited while five collaborators and two students came and went.

3. Minimization, pseudonymization, and anonymization

The safest confidential data is the data you never collected. Collect only what your research question requires. Where you can, separate direct identifiers from the research variables and store the key (the link between participant codes and identities) separately and more tightly than the dataset itself. Truly anonymized data (where re-identification is not reasonably possible) often falls outside GDPR entirely, which is why it is the portion you can share openly. Pseudonymized data still counts as personal data.

4. Backups that do not undo your encryption

Funders want your data to survive disaster, which means backups. But a careless backup can quietly become the weakest link: an encrypted working copy copied in cleartext to a second drive defeats the whole point. The rule is to back up the encrypted form, or to encrypt the backup itself, so copies survive a failure without becoming new exposure points. I covered this specific trap in how to back up encrypted data without breaking zero-knowledge.

5. Knowing where your data physically sits

If your dataset includes EU personal data and your storage provider hosts it outside the EU, you are making a regulated international transfer. It is not automatically forbidden, but it has conditions, and foreign-access laws such as the US CLOUD Act are part of the risk picture. If the data is encrypted client-side and the provider only ever holds opaque ciphertext, the transfer risk is substantially reduced because there is nothing readable to hand over. I unpacked whether hosting data outside the EU is a GDPR risk and how to limit it separately; for research with human participants it is worth reading before you pick a provider.

What this means concretely: a researcher's checklist

• Write your DMP so that the sensitivity of each data category is matched to a specific safeguard. Reviewers reward specificity.
• Encrypt confidential files client-side, so the storage layer never sees plaintext. Prefer standard, documented cryptography over vague "military-grade" claims. (If you want to understand what "AES-256" actually guarantees, here is what AES-256-GCM means.)
• Keep a tightly controlled master list linking participant codes to identities, stored separately from the dataset and accessible to the fewest people possible.
• Audit access whenever the team changes. Put it on the calendar, not in your memory.
• Keep at least one offline, encrypted backup so ransomware or a cloud outage cannot take your only copy.
• De-identify early and keep an open, well-documented version of the shareable subset so you can satisfy FAIR without exposing anyone.
• Document retention and end-of-project deletion, and actually do it when the time comes.
• Record your choices. If a reviewer or DPO asks why you stored data a certain way, a short written rationale is worth more than a tool name.

Where Filarr can help (and where it cannot)

Filarr is a local-first encrypted workspace: notes, files, and a graph that links them, with everything encrypted on your own disk. For a researcher, that maps onto a few of the controls above fairly directly.

What it does: every file is encrypted individually with AES-256-GCM, each file getting its own key, which is in turn wrapped by a key derived from your password (PBKDF2-SHA512 at 600,000 iterations, with Argon2id available as an option). Data lives encrypted on your machine and works fully offline, so your working copy is never sitting in plaintext on someone else's server. Cloud sync is optional, and when you use it the server stores only opaque encrypted blobs; the design is zero-knowledge, meaning your key never reaches the server in cleartext (you can read how the optional sync stays zero-knowledge, it is open about what the server can and cannot see). If your institution requires data to stay in a specific bucket or region, Filarr supports bring-your-own-storage with any S3-compatible provider, so you can point it at infrastructure you or your institution control; here is how to set up BYOS S3 sync. Recovery uses a 24-word BIP-39 phrase, which matters because an encrypted dataset you can no longer open is a different kind of data loss. Because it holds notes and files together with a linking graph, it also suits the reality of research, where a PDF, a transcript, and your analysis notes belong to the same thread; that workflow is described in organizing notes and files together with a graph.

What it does not do: Filarr is an encryption tool, not a compliance certification. It does not make your project GDPR compliant on its own, it is not a certified health-data host (in France, sensitive patient data often requires an HDS-certified host, which is a separate requirement), and it does not replace your ethics approval, your consent process, or your institution's rules. It also does not, today, give you fine-grained multi-user access control for a large team; it is strongest as the encrypted workspace for an individual researcher or a small group, not as a managed institutional repository. The desktop client is open source under BSL 1.1, which means you (or your IT department) can inspect exactly how the cryptography works rather than taking a marketing claim on trust, and a mobile app is still maturing. Be honest about these limits in your DMP; overstating a tool's guarantees is itself a compliance risk.

In short: Filarr can be the encrypted, under-your-control workspace where your confidential raw data lives and syncs, which covers the encryption and ownership parts of what funders ask. It is one piece of a plan, not the whole plan.

FAQ

Do funders require me to make all my research data public? No. The guiding principle in Horizon Europe and similar policies is "as open as possible, as closed as necessary." FAIR's "Accessible" explicitly permits controlled or restricted access, and metadata can be open even when the underlying data stays private. You share the non-sensitive, de-identified portion and justify what you keep restricted.

Is encryption enough to be GDPR compliant with participant data? No. Encryption is one of the "appropriate technical measures" GDPR expects, and a strong one, but compliance also depends on your lawful basis, consent, minimization, retention, transfer arrangements, and more. Encryption dramatically reduces the harm of a breach; it does not by itself make a project compliant.

Where should I physically store EU participant data? Ideally on infrastructure in the EU, or on storage you control, and if it is encrypted client-side the physical location matters far less because the provider only holds unreadable ciphertext. If you use a provider outside the EU, treat it as a regulated international transfer and check the conditions and foreign-access-law exposure before committing.

What is the difference between encrypted and zero-knowledge storage, and why should I care? Encrypted-at-rest usually means the provider holds the keys and can read your data; zero-knowledge means the data is encrypted before it leaves your device and the provider cannot read it at all. For confidential research data, that difference decides whether a breach of your provider exposes your participants or just exposes noise. The plain-language explanation of zero-knowledge encryption is a good starting point if you need to explain it to a co-investigator or a DPO.

How do I back up sensitive data without creating a second leak? Back up the encrypted form, or encrypt the backup itself, and keep at least one copy offline. The failure to avoid is copying a decrypted working version somewhere convenient and forgetting it exists. A practical walkthrough of safe tooling choices is in how to encrypt your notes and files.