Every researcher has lived some version of the same nightmare: the spreadsheet called "final_data_v2_REAL.xlsx" that nobody can explain six months later, the laptop that failed the week before submission, or the collaborator who cannot open a file because it depends on software nobody has any more. Research data management is the unglamorous discipline that prevents those failures. It is simply the habit of organising, documenting, storing, and sharing research data so that the data remain usable — by you, by your team, and by other researchers — long after the project ends.
Funders and journals increasingly require it. Many funding calls ask for a data management plan, and many journals ask authors to state where their data can be found. But even where nobody requires it, good data management pays for itself: it saves time during analysis, it makes collaboration smoother, and it protects you when a reviewer asks for a result to be checked. This guide covers the whole lifecycle, from planning before data collection to sharing after publication, and it connects with our guides on writing a methodology section and research ethics, consent, and animal welfare, because data handling and ethics are closely linked.
A data management plan, often called a DMP, is a short document written before data collection begins. It answers practical questions: what data will you collect, in what formats, how much of it, where will it be stored, who can access it, how will sensitive data be protected, and what will happen to it after the project? Writing the plan forces decisions that are painful to make later — for example, whether participant names can appear in a shared dataset, or which file format will still be readable in ten years.
Keep the plan short and living: a few pages, updated when the project changes, not a document written once and forgotten. Many institutions and funders provide DMP templates, and free online tools exist to help draft one. The value of the plan is not the document itself but the conversations it starts with your team and supervisor: agreeing on file structures, backup routines, and access rules before anyone has collected a single datapoint.
Good organisation starts with file names. A useful name describes the content, the date, and the version in a consistent order, using only letters, numbers, hyphens, and underscores — for example, "2026-03-15_survey-responses_v02.csv". Avoid spaces, special characters, and vague words such as "final", "new", or "updated", because there will always be a newer final version. Agree the pattern with your team at the start and write it in the data management plan, so that a new team member can follow it without asking.
Folders should mirror the project structure: separate folders for raw data, cleaned data, analysis scripts, and outputs, with raw data kept read-only so that the original is never accidentally overwritten. Version control matters as much as naming. For documents and code, keep dated versions or use a version-control system, and record what changed in each version. For datasets, never edit the raw file in place: clean a copy, keep the original, and document every cleaning step, so that any result can be traced back to the data it came from.
Documentation is what turns files into data someone else can use. A simple README file in each project folder should explain what the files are, how they were collected, what each variable means, and what software is needed to open them. For survey or experimental data, a data dictionary — a table listing every variable, its definition, its units, and its allowed values — is the single most useful document you can write. Without it, even your own data can become unreadable within a year, because the meanings of codes and abbreviations fade fast.
Storage is where good intentions most often fail, because a single copy on a single laptop is not storage — it is a risk. The widely used 3-2-1 rule is a practical minimum: keep three copies of important data, on two different types of storage, with one copy off site. In practice, that usually means the working copy on your computer, a copy on institutional or cloud storage, and a further copy on an external drive or a second service. Automatic, regular backups beat manual ones, because manual backups are forgotten precisely when work is busiest.
Choose storage that fits the sensitivity of the data. Personal data, clinical records, and commercially sensitive material need access controls, encryption, and storage approved by your institution — a personal cloud account may not meet those requirements. Check your institution's rules before collecting sensitive data, not after, and record the decision in the data management plan. Also think about formats: open, non-proprietary formats such as CSV for tables and plain text for documents remain readable far longer than proprietary formats tied to one company's software, and they make sharing much easier later.
Sharing data after publication lets other researchers verify your results, reuse your data for new questions, and build on your work — and it is increasingly expected by funders and journals. The usual route is a trusted repository: a service that stores the data, gives it a permanent identifier, and makes it findable. General repositories accept data from any field, while subject repositories specialise in particular kinds of data, such as clinical or genomic data. Check whether your funder, institution, or target journal recommends a particular repository, and deposit there where one is specified.
Before sharing, prepare the dataset for strangers: clean it, document it with a README and data dictionary, and remove or anonymise anything that could identify participants. Anonymisation is harder than it looks — combinations of seemingly harmless details, such as a rare diagnosis plus a small town, can identify a person — so follow your ethics approval and institutional guidance, and when in doubt, restrict access rather than sharing openly. A licence states what others may do with the data; permissive licences encourage reuse, while more restrictive licences may be needed for sensitive material. Choose the licence deliberately, not by default.
Timing matters too. Many researchers share data when the paper is published, or after an embargo period that lets them publish first. State the plan in your paper's data availability statement, which journals increasingly require: a sentence saying where the data are, under what terms, and how to access them. A clear statement helps reviewers and readers trust the work, and it makes your data citable, so that reuse of your data can be credited to you.
The costliest mistake is treating data management as something to do at the end of the project. By then, files are scattered, names are meaningless, and nobody remembers what a column meant. The second is keeping only one copy, usually on a laptop that travels, gets stolen, or fails. The third is sharing data without documentation, which produces datasets that nobody, including the original author a year later, can interpret. The fourth is ignoring consent: collecting data without permission to share it, then discovering at publication that sharing is impossible. All four are preventable by a short plan, agreed at the start, and a few habits followed during the project. Our guide on how to publish a research paper covers the publication stage where data availability statements matter, and our guide on writing results and discussion sections depends on data that are organised well enough to analyse honestly.
Data management gets harder the moment a second person, or a second site, joins a project, because every informal habit that worked for one researcher becomes a source of confusion for a team. The solution is agreement before collection begins: one shared folder structure, one naming pattern, one versioning rule, and one place where the authoritative copy of each dataset lives. Write those agreements into the data management plan and into a short team handbook that a new member can read on their first day, so that nobody has to guess how files should be named or where they should be saved.
Access control is the second discipline teams need. Not everyone on a project needs access to everything: sensitive data should be available only to the people whose work requires it, and access should be reviewed whenever someone joins or leaves the team. Shared drives and cloud folders make collaboration easy, but they also make accidental deletion and overwriting easy, so set permissions deliberately — read-only access to raw data for most team members, write access only where the work requires it — and keep an audit trail of who changed what. When data move between sites, use approved transfer routes rather than personal email or messaging apps, which leave no record and may breach institutional or ethics requirements.
Version conflicts are the most common team failure, and they usually appear at the worst moment: two people edit the same dataset in different copies, and nobody knows which version produced the published result. Prevent this by designating one master copy, by recording every change in a version log, and by freezing a copy of the data at each analysis milestone — the dataset behind each table or figure in a paper should be identifiable and retrievable. For code and documents, version-control systems solve the same problem more thoroughly, and teams that use them rarely return to emailing files back and forth.
Finally, plan the handover. Researchers leave projects, students graduate, and grants end, and data that only one person understands will effectively be lost when they go. Require that every dataset has documentation a stranger could follow, that passwords and access routes are transferred through proper channels, and that a departing member walks a remaining member through the data before leaving. A project whose data survive its original team is a project whose results can be checked, reused, and built upon — which is the whole point of managing data well in the first place.
| Stage | Key actions | Common failure |
|---|---|---|
| Planning | Write a DMP: data types, formats, storage, sharing | No plan, so decisions are improvised |
| Organizing | Consistent names, folders, versions, README, dictionary | Files nobody can interpret later |
| Storing | 3-2-1 backups, access controls, open formats | A single copy lost with a laptop |
| Documenting | Methods, variables, cleaning steps recorded | Results that cannot be traced to data |
| Sharing | Repository deposit, licence, availability statement | Data shared without consent or context |
These authoritative external resources explain the standards and guidance mentioned in this article:
What is a data management plan, and do I really need one?
A data management plan is a short document describing what data you will collect, how you will store and protect it, and what will happen to it afterwards. Many funders require one, but even where they do not, writing one prevents the most common data disasters.
How many backups do I need?
Follow the 3-2-1 rule as a minimum: three copies, on two different types of storage, with one copy off site. Automatic backups are better than manual ones, and you should test occasionally that a backup can actually be restored.
What file formats should I use?
Prefer open, non-proprietary formats where possible — CSV for tables and plain text for documents — because they remain readable far longer than formats tied to one company's software, and they make sharing easier.
Can I share data that involves human participants?
Only with appropriate consent and anonymisation, following your ethics approval and institutional rules. Combinations of details can identify people even when names are removed, so when in doubt, restrict access rather than sharing openly.
Where should I deposit my data?
In a trusted repository. General repositories accept data from any field, while subject repositories specialise in particular data types. Check whether your funder, institution, or target journal recommends a particular repository.
What is a data availability statement?
A sentence in your paper stating where the data can be found, under what terms, and how to access them. Journals increasingly require one, and it makes your data citable so that reuse can be credited to you.