“FAIR” is often used as a description — a funder says data should be FAIR, a repository claims its holdings are FAIR. This guide skips the description and goes straight to the work: the concrete steps a researcher takes, dataset by dataset, to actually satisfy the FAIR Guiding Principles before deposit. For what each letter of FAIR means and where the principles came from, see CASRAI’s What is FAIR data? explainer — this page assumes that definition and picks up where it leaves off.
What “FAIR in practice” actually means
FAIR is not one requirement but fifteen. Wilkinson et al.’s 2016 paper in Scientific Data (DOI: 10.1038/sdata.2016.18) breaks Findable, Accessible, Interoperable, and Reusable into specific sub-principles (F1–F4, A1–A2, I1–I3, R1–R1.3), each of which is satisfiable or not — GO FAIR, the stakeholder initiative that maintains the canonical statement of the principles, publishes the same breakdown at go-fair.org/fair-principles. The five steps below map directly onto those sub-principles, so each one names which part of FAIR it satisfies rather than gesturing at FAIR generally.
Two things this guide deliberately does not cover in depth, because CASRAI already has a dedicated page for each: full repository-selection criteria (see How to Choose an Open Data Repository) and the licence decision in detail (see Creative Commons Licenses for Research Data). This guide links to both at the relevant step rather than repeating them.
Step 1 — Choose persistent identifiers before you choose anything else (F1, A1)
F1 requires that the data and its metadata carry a globally unique, persistent identifier. In practice this means a DOI, minted through the repository you deposit with (most academic repositories mint DOIs via DataCite at the point of deposit — you rarely register one yourself). A DataCite DOI resolves through the Handle System via the doi.org proxy, satisfying A1’s requirement that (meta)data be retrievable “using a standardised communications protocol” — an ordinary HTTPS request against the DOI resolver.
Two identifiers to attach alongside the dataset DOI, both free and both feeding directly into F1/I3/R1.2 further down this list:
- An ROR ID for every contributing institution — increasingly a required metadata field at deposit, and the identifier that lets a repository’s holdings later link back into an institutional CRIS.
- An ORCID iD for every contributing researcher — the identifier DataCite’s own schema treats as the standard way to express
creatorandcontributorunambiguously (a plain name string does not satisfy this; two researchers can share a name, an ORCID iD cannot).
Do this first, not last, because the DOI and ORCID/ROR identifiers you choose here are what steps 2 and 5 actually reference.
Step 2 — Write metadata that is rich enough to be findable and interoperable, not just present (F2, F3, I1–I3)
F2 requires “rich metadata” — a title and a one-line description satisfy almost nothing. F3 requires the metadata to explicitly carry the identifier from Step 1, so the record and the data can never become separated. I1–I3 require that metadata use a shared, formal vocabulary rather than free-text fields, and that it carry qualified references to related resources.
Concretely:
- Fill out the repository’s metadata form against a real schema rather than the minimum required fields. The DataCite Metadata Schema (currently v4.7) is the baseline most general-purpose repositories build on; discipline-specific repositories often layer a domain schema on top — check what your target repository actually implements before assuming DataCite’s minimum fields are enough.
- Where a controlled vocabulary or ontology exists for your field, use its terms in subject/keyword fields instead of free text — this is what I1/I2 mean by “formal, accessible, shared” language. FAIRsharing is the standards registry to check for an existing domain vocabulary or metadata schema before inventing your own field names.
- Cross-reference related resources with their own identifiers, not prose descriptions — the paper this data supports (its DOI), any code behind it (an archived identifier such as a Zenodo-minted DOI or a Software Heritage SWHID), and any prior or related dataset. This is I3’s “qualified references”: a machine-resolvable link, not a citation string a human has to go read.
- If you want the dataset to surface in Google Dataset Search specifically (a separate index from ordinary web search, built entirely from crawled schema.org
Datasetmarkup), the two fields Google treats as strictly required arenameand a substantivedescription(50–5,000 characters);creator,identifier,license, anddistributionare recommended and materially improve how the listing renders. Most DataCite-schema repositories generate this markup automatically from your deposit metadata — you don’t write it by hand — but a thin metadata record produces a thin (or absent) Dataset Search listing.
Step 3 — Deposit somewhere that keeps the data findable and accessible over time (F4, A1.1, A2)
F4 requires the (meta)data be registered or indexed somewhere searchable — an institutional file server or a personal website does not satisfy this even if the data itself is technically public. A2 requires the metadata to remain accessible even after the data itself is eventually removed or embargoed.
The full decision framework — discipline-specific versus generalist repositories, what a CoreTrustSeal or ISO 16363 certification actually verifies, and how a deposit propagates into an institutional CRIS — is covered in CASRAI’s repository-selection guide; use it for the actual decision. Two points specific to the FAIR angle, not repeated there:
- Use re3data.org, the registry of research data repositories, to check that a repository you’re considering is itself findable and indexed — a repository absent from re3data is a weak signal for F4-level discoverability of anything deposited in it.
- A2 is a certification question as much as a repository question: CoreTrustSeal’s 16 requirements specifically assess a repository’s continuity plan (what happens to metadata if the repository or the specific dataset is ever taken down) — this is the practical mechanism behind A2, not a separate concern from choosing a trustworthy host.
If your data is embargoed rather than immediately public (common ahead of publication), the metadata record should still be indexed and accessible even though the files aren’t yet — see CASRAI’s Embargo term for how that’s typically expressed in deposit metadata.
Step 4 — Attach a clear, machine-readable reuse licence (R1.1)
R1.1 requires “(meta)data are released with a clear and accessible data usage licence” — not a vague “available upon request,” and not silence (unlicensed data defaults to “all rights reserved” in most jurisdictions, which is the opposite of reusable). The two licences that actually satisfy the Open Definition’s non-discrimination principle for data are CC0 (a public-domain dedication, no attribution required) and CC BY (attribution required, otherwise unrestricted) — CC BY-NC and the ND variants fail the Open Definition by restricting commercial reuse or derivatives. See CASRAI’s Licence term for the general concept.
Which of the two to pick, and what real repositories/funders actually require or default to, is covered fully in Creative Commons Licenses for Research Data. Set this as a field in your reuse license metadata at deposit, not as a line buried in a README — R1.1 is about the licence being machine-discoverable, and a repository’s licence metadata field is what most downstream harvesters (including Google Dataset Search) actually read.
Step 5 — Document provenance and methods so the data is actually reusable, not just downloadable (R1, R1.2, R1.3)
R1 requires “a plurality of accurate and relevant attributes” — enough context that someone outside your lab can understand what the data is without asking you. R1.2 requires detailed provenance (who generated it, how, when, from what). R1.3 requires meeting domain-relevant community standards, which is often the difference between data that’s technically FAIR and data a specialist in your field will actually trust enough to reuse.
- Include a methods/README file in the deposit itself (not only in the paper) covering instrument/protocol version, processing steps applied to raw data, units, missing-value coding, and file-format specifics. This is what most reviewers actually mean by “documented” — a codebook or data dictionary, not prose.
- Where your field has a recognised reporting or metadata standard (a minimum-information checklist, an ontology, a file-format convention), follow it and say so explicitly in the metadata — this is R1.3. Check FAIRsharing for whether one already exists before assuming your field has none.
- If the dataset supports a specific publication, the publication’s own data availability statement is the R1/R1.2 handoff point between paper and deposit — CASRAI’s guide to writing one covers that half of the documentation separately, including what ICMJE, PLOS, and NIH’s Data Management and Sharing Policy actually require in it.
- Version the deposit rather than silently overwriting it if the dataset changes after initial publication — most DataCite-DOI repositories support versioned DOIs for exactly this reason, which preserves R1.2 provenance across revisions instead of erasing it.
Quick-reference checklist
| FAIR sub-principle | What it requires | Action |
|---|---|---|
| F1 | Globally unique, persistent identifier | Mint a DOI via the repository at deposit |
| F2 / F3 | Rich metadata that carries the identifier | Complete the full DataCite-schema (or discipline-schema) metadata form, not just the required minimum |
| F4 | Registered/indexed somewhere searchable | Deposit in a repository listed on re3data.org, not a personal/institutional file share |
| A1 / A1.1 | Retrievable via an open, standard protocol | Use a repository whose DOIs resolve via doi.org/HTTPS |
| A1.2 | Access control where necessary, not by default | Use the repository’s access-tier controls (open, embargoed, restricted) rather than withholding metadata too |
| A2 | Metadata persists even if data doesn’t | Choose a CoreTrustSeal/ISO 16363-certified repository with a stated continuity plan |
| I1 / I2 | Formal, shared vocabulary | Use controlled vocabulary/ontology terms (check FAIRsharing) instead of free text |
| I3 | Qualified references to related resources | Link the paper DOI, code identifier, and related dataset DOIs as metadata fields, not prose |
| R1 | Rich, accurate descriptive attributes | Include a methods/README file with the deposit |
| R1.1 | Clear, accessible usage licence | Set CC0 or CC BY as a metadata field (see the licensing guide) |
| R1.2 | Detailed provenance | Document how/when/by whom the data was generated; version the deposit on changes |
| R1.3 | Meets domain-relevant community standards | Follow your field’s reporting/metadata standard where one exists (check FAIRsharing) |
Beyond a single dataset
Everything above is scoped to one dataset at deposit time. Two adjacent situations this guide doesn’t cover, with somewhere real to go for each:
- Planning FAIR compliance across a whole project, in advance, in a funder-facing document — that’s what a data management plan is for. If your DMP needs to be machine-actionable (readable/validatable by a CRIS or funder portal, not just a PDF), CASRAI’s machine-actionable DMP implementation checklist covers that separately — it’s an institutional/CRIS-integration process, not a per-dataset one.
- Assessing how FAIR a dataset or a whole repository actually is, after the fact, with a scoring tool — that’s the institutional side of FAIR, using tools like F-UJI or the RDA FAIR Data Maturity Model rather than a researcher’s own checklist. CASRAI’s FAIR data assessment frameworks piece is written for institutional administrators and repository managers choosing among those tools — this guide and that one answer different questions for different audiences.
- Research software or code, rather than data, has its own version of these principles — FAIR4RS adapts FAIR specifically for software (different implementation details around, e.g., what “identifier” and “metadata” mean for a codebase).
- Indigenous data governance — FAIR does not address who has authority to control data about a people or community. The CARE Principles (Collective Benefit, Authority to Control, Responsibility, Ethics), published by the Global Indigenous Data Alliance in 2019, are designed to complement FAIR for exactly this gap, not replace it.
Frequently asked questions
Does making data FAIR mean it has to be open access?
No — this is the single most common misreading of the principles. Accessible (the “A” in FAIR) does not mean unrestricted; A1.2 explicitly allows “an authentication and authorisation procedure, where necessary.” Sensitive, controlled-access, or embargoed data can be fully FAIR as long as the metadata stays findable and accessible even when the underlying files require permission to retrieve. FAIR and open data are related but distinct concepts — “as open as possible, as closed as necessary” is the usual framing.
Do I need to do all five steps for every dataset, or just the one behind my published paper?
Funder and journal mandates typically apply to the dataset(s) underlying a specific publication, which is the practical trigger for most researchers. There’s no requirement that every dataset a lab ever generates be independently FAIR-processed the moment it’s created — but retrofitting FAIR metadata onto old, undocumented data is materially harder than doing it at the point of deposit, which is the main reason to treat this as a standard part of finishing a project rather than a one-off compliance task.
What’s the difference between this checklist and a data availability statement?
A data availability statement is what goes in the published paper — a short, human-readable pointer to where the data lives and under what conditions. The steps in this guide are what you do at the repository, before that statement can be written truthfully. CASRAI’s DAS guide covers the statement itself, including exact wording for common situations.
Is there a tool that scores how FAIR my dataset actually is?
Several exist — F-UJI, the RDA FAIR Data Maturity Model, FAIR-Aware, and others — but they’re generally built and used at the institutional/repository level rather than as a per-researcher self-check, and none is a universally adopted single standard. CASRAI’s overview of assessment frameworks compares them for readers choosing one to deploy institutionally.
Does any of this apply to code or software, not just data?
The same four letters apply, but the concrete actions differ enough that CASRAI covers it as its own topic — see FAIR4RS.
