# How to Create a Data Sharing Plan That Includes Cloud Storage and ELNs By the end of this article you will be able to draft a complete data sharing plan for a research project, set up a three-tier storage system that combines local drives, cloud storage, and an electronic [lab notebook](/knowledge/molecular-biology/lab-notebook) (ELN), move data between those tiers with verified checksums, and choose a repository for the final public release. You will also get a free data sharing plan with cloud storage ELN template that you can copy and fill in. Before you start, have the following ready: - A computer where you can open a terminal (Terminal on macOS, PowerShell or Windows Terminal on Windows) - An account with a cloud storage provider your institution supports - An ELN account, or at minimum a decision about which ELN your group will use - Git installed for version-controlling the plan and analysis code - rclone installed for command-line transfers to cloud storage (free, works with most major providers) - Your funder's or journal's data policy, if one applies ## What a Data Sharing Plan Actually Does A data sharing plan is a short written document that states what data a project will produce, where each [type of data](/blog/data-analysis/types-of-data-nominal-ordinal-interval-ratio) lives during and after the project, who can access it, how it is protected, and where the final version will be published. In the research data sharing literature this document is often called a [Research Data Management Plan](/blog/careers/research-data-management-plan-from-file-naming-to-long-term-sharing) (RDMP). A university-level RDMP proposal from Indonesian researchers describes the core structure that works well for most labs: three levels of storage (offline working storage, offline backup storage, and online cloud backup storage located on a shared repository) plus two kinds of cloud repository, a dynamic repository for live data and a static repository for a copy of the final data [1]. That structure solves two recurring problems. First, researchers invest funding, time, and energy into collecting data but few put matching attention into managing it, which makes data sharing and reuse harder than it should be [1]. Second, a written plan turns vague intentions ("we will back things up") into checkable commitments ("raw flow cells are copied to cloud backup within 24 hours of acquisition and verified by SHA-256 checksum"). Your ELN is not a replacement for any of this. The ELN is where experimental context, protocols, and observations live. The data sharing plan describes how ELN content and raw data flow between your working storage, your backups, and public repositories. ## The Three Storage Tiers and Two Repositories Here is what each tier in the model means in practice, and what belongs in it. | Tier | Location | Contents | Access pattern | |--|--|--|--| | Offline working storage | Lab workstation, external SSD | Active raw files, ELN exports in progress | Daily reads and writes | | Offline backup storage | External hard drive or lab NAS, physically separate from the working drive | Full copies of raw data and metadata | Written weekly, rarely read | | Online cloud backup | Cloud storage shared with the group | Encrypted copies of everything above | Written continuously, read on restore | | Dynamic repository | Cloud repository or shared cloud folder | Live, changing data used by collaborators | Frequent updates during the project | | Static repository | Public archive with [persistent identifiers](/knowledge/bioinformatics/persistent-identifiers-in-bioinformatics-selection-criteria-and-implementation-workflow) | Final versioned dataset at publication | Frozen after deposit | Two rules keep this system honest. Data exists in at least two places at all times, and at least one copy is offline so ransomware or accidental deletion cannot touch everything at once. The cloud tier is where a data sharing plan with cloud storage earns its name, because the plan must specify how data reaches the cloud, in what format, and who holds the keys. ## Data Repository Comparison: Choosing Where Your Data Lives ![Decision path asking whether data is still changing, then whether policy or community format applies, ending at a named static archive.](/article-images/illustrations/data-sharing-plan-with-cloud-storage-eln-template-repository-choice.webp) A data repository comparison comes down to four realistic options, each with a different job. | Option | Best for | Access control | Persistence | |--|--|--|--| | Personal or lab cloud storage (Google Drive, OneDrive, Dropbox, provider of your choice) | Active collaboration, the dynamic tier | Per-folder sharing, group permissions | Tied to accounts and billing, not archival | | Institutional repository | Compliance with university policy, datasets tied to your institution | Managed by the library, usually supports embargo | Long term, institution-backed | | Disciplinary repository (for example sequence or protein archives in your field) | Community-standard formats that other researchers can reuse immediately | Public on deposit, often with controlled pre-release | Permanent with persistent identifiers | | Generalist repository (accepts any data type) | Mixed-format datasets, software, and files that fit no disciplinary archive | Public on deposit, optional restricted access | Permanent with persistent identifiers | The dynamic versus static distinction from the RDMP model maps cleanly onto this table. Dynamic repositories hold live data during the project. Static repositories keep a copy of final data after the paper is published [1]. Your plan should name a specific static repository for the final deposit, because "we will find a repository later" is the single most common reason datasets never get shared. ## Free Data Sharing Plan With Cloud Storage ELN Template Copy the block below into a file called `data_sharing_plan.md`. This is the template format used throughout the rest of the article. Every bracketed field gets filled in before the project starts. ```markdown # Data Sharing Plan: [Project title] ## 1. Project and people - Principal investigator: [name, email] - Data steward (day-to-day owner): [name, email] - Other contributors and roles: [names] - Start and end dates: [dates] ## 2. Data description - Data types produced: [e.g., raw sequencing reads, microscope images, assay plate reader exports, analysis scripts, ELN protocol records] - Estimated volume: [e.g., ~2 TB total, largest single file 40 GB] - File formats: [preferred open formats, e.g., FASTQ, TIFF, CSV, HDF5] - Metadata standard or description method: [e.g., a README per folder plus a sample sheet CSV] ## 3. Storage tiers - Working storage: [machine or path] - Offline backup: [device, schedule, physical location] - Cloud backup: [provider, bucket or folder, sync schedule] - Dynamic repository: [where live collaborative data lives] - Static repository: [named archive for the final dataset] ## 4. Electronic lab notebook - ELN system: [name] - What is recorded there: [protocols, run logs, sample IDs, decisions] - Export schedule and format: [e.g., monthly export to XML and PDF into eln_exports/] - Link between ELN and data: [sample ID convention shared by ELN entries, raw files, and the sample sheet] ## 5. Access control and security - Who has read access, who has write access, on which tier - Encryption at rest and in transit: [provider-managed keys, or client-side encryption before upload] - Key custody: [who holds passwords or key material, where key material is stored offline] - Group sharing method: [how collaborators are added and removed] ## 6. Version control and integrity - Checksum algorithm: [e.g., SHA-256] - Checksum schedule: [on every copy operation and before deposit] - What is version-controlled: [code, this plan, analysis notebooks] ## 7. Sharing and preservation - What will be made public, what will be restricted, and why - License for released data: [e.g., CC0 or CC BY 4.0] - Timeline: deposit on or before [date], ideally at publication - Persistent identifier expected: [DOI or accession from the static repository] ## 8. Responsibilities and review - Who executes each step above - Review dates: [e.g., re-read the plan every 6 months and at personnel changes] ``` ## Worked Example of the Filled-In Template Here is a data sharing plan with cloud storage ELN template example for a small [molecular biology](/blog/careers/molecular-biology) project, with the fields filled in. ```markdown # Data Sharing Plan: RNA-seq of heat-stressed yeast knockouts ## 1. Project and people - Principal investigator: Dr. A. Okafor, aokafor@example.edu - Data steward: J. Lin, postdoc, jlin@example.edu - Other contributors: two graduate students (library prep, analysis) - Start and end dates: 2026-03-01 to 2027-02-28 ## 2. Data description - Data types produced: raw FASTQ files from an Illumina-style sequencer, count matrices, R analysis scripts, ELN protocol records - Estimated volume: ~600 GB raw, ~5 GB processed - File formats: FASTQ (raw), TSV count matrices, R scripts, CSV sample sheet - Metadata: samples.csv with sample ID, strain, treatment, date, operator, ELN entry number ## 3. Storage tiers - Working storage: lab workstation D:\\projects\\rnaseq_2026 - Offline backup: 4 TB external drive in PI office, synced Mondays - Cloud backup: institutional OneDrive, rnaseq_2026 folder, synced nightly by script - Dynamic repository: OneDrive shared folder with the collaborator group, read-only for students - Static repository: generalist repository, deposit at publication ## 4. Electronic lab notebook - ELN system: the lab's institutional ELN - What is recorded: extraction and library protocols, run IDs, QC observations, deviations from protocol - Export schedule: first business day of each month, exported to XML and PDF into eln_exports/ - Link: every ELN entry cites the sample ID in samples.csv and the sequencing run ID in the filename ## 5. Access control and security - Read access: all four lab members on cloud backup - Write access: data steward and PI only - Provider-managed encryption in transit and at rest, plus client-side encryption of the samples.csv before upload because it contains collaborator names - Key custody: encryption passphrase in the department safe, not in email or chat - Group sharing: collaborator added by email invitation with read-only role, removed within one week of project end ## 6. Version control and integrity - Checksum algorithm: SHA-256, manifest regenerated on every copy - Code, the sample sheet, and this plan live in a private Git repository ## 7. Sharing and preservation - Public: raw FASTQ files, count matrices, scripts, sample sheet with collaborator names removed - Restricted: nothing, no human subjects data in this project - License: CC0 for data, MIT for code - Timeline: deposit within 30 days of manuscript acceptance ## 8. Responsibilities and review - J. Lin executes backups and checksums, A. Okafor approves the final deposit - Review: every 6 months and whenever anyone joins or leaves ``` ## Step-by-Step Walkthrough With Commands Follow these steps in order. The commands work in bash on macOS and Linux and in Git Bash or WSL on Windows. ### Step 1: Create the working structure ```bash mkdir -p rnaseq_2026/{raw_data,processed_data,code,metadata,eln_exports,documents} cd rnaseq_2026 ls # expected output: # code documents eln_exports metadata processed_data raw_data ``` Write a short `README.md` in `metadata/` explaining what each folder contains. A folder structure nobody can interpret six months later is functionally lost data. ### Step 2: Version-control the plan and the code ```bash git init git add data_sharing_plan.md metadata/README.md git commit -m "Initial data sharing plan draft" # expected output: # [main (root-commit) 3f2a1c9] Initial data sharing plan draft # 1 file changed, 84 insertions(+) ``` Raw data should not go into Git. Large binary files belong in the storage tiers from section 3 of your plan, while Git tracks everything a human typed. ### Step 3: Generate a checksum manifest A checksum is a fixed-length fingerprint of a file. If any byte changes, the fingerprint changes, so comparing checksums proves a copy is intact. ```bash find raw_data -type f -exec sha256sum {} \; > metadata/manifest_raw.sha256 head -2 metadata/manifest_raw.sha256 # expected output (two lines, hash then filename): # a3f1...b9c2 raw_data/sample01_R1.fastq.gz # 7e40...d118 raw_data/sample02_R1.fastq.gz ``` On macOS, `shasum -a 256` replaces `sha256sum` unless coreutils is installed. ### Step 4: Configure the cloud connection with rclone ```bash rclone config # choose n) New remote # name: lab_backup # storage type: pick your provider from the list # follow the prompts, paste the app password or token your # provider's security settings page generates rclone listremotes # expected output: # lab_backup: ``` ### Step 5: Copy to cloud backup and verify ```bash rclone copy . lab_backup:rnaseq_2026 --checksum SHA-1 --progress rclone check . lab_backup:rnaseq_2026 --checksum SHA-1 # expected final lines: # 0 differences found # 18 hashes could not be checked (some file types do not support # that hash on this provider) ``` The `-checksum` flag makes rclone compare file hashes rather than only size and modification time, so silent corruption gets caught. "Hashes could not be checked" for a few file types is normal, not an error. ### Step 6: Export the ELN on a schedule Use your ELN's export function to write entries to XML or PDF, place them in `eln_exports/`, then re-run the checksum command against that folder and sync again. Put the export date in the filename, for example `eln_export_2026-06-01.xml`, so exports sort chronologically. Monthly is a reasonable cadence for most projects. Schedule it as a recurring calendar task belonging to a named person, because unscheduled tasks do not happen. ### Step 7: Sync the offline backup tier ```bash rsync -av --checksum /mnt/external4tb/rnaseq_2026/ ./raw_data/ ./processed_data/ ./metadata/ ``` Run this weekly in the example plan. The `-checksum` flag makes rsync compare file contents, not just timestamps. ### Step 8: Deposit the final dataset in the static repository When the manuscript is accepted, assemble the public files, remove anything restricted, regenerate the manifest, upload to your named static repository, and record the persistent identifier the repository issues. Then update section 7 of the plan with the identifier and commit the change. ```bash git add data_sharing_plan.md git commit -m "Record dataset DOI in sharing plan" ``` ## Common Errors With Exact Messages and Fixes **`fatal: not a git repository (or any of the parent directories): .git`** when running git commands. You are outside the folder where you ran `git init`. Run `pwd` to see where you are, then `cd` into the project folder or run `git init` there. **`Failed to create file system: didn't find section in config file`** from rclone. The remote name is misspelled. Run `rclone listremotes` to see the exact configured name, including the trailing colon, and match it character for character. **`sha256sum: raw_data/sample03_R1.fastq.gz: No such file or directory`** when verifying. A file listed in the manifest was renamed or deleted. Do not hand-edit the manifest. Regenerate it with the `find` command from step 3 so it reflects reality, and investigate why the file moved. **A 403 Forbidden response from the cloud provider during upload.** The credential you configured lacks write scope, or the shared folder grants you read-only access. Regenerate the app password with write permission, or ask the folder owner to change your role. **`rsync: change_dir "/mnt/external4tb/rnaseq_2026" failed: No such file or directory (2)`.** The backup drive is not mounted or the path is wrong. Confirm the mount point with `ls /mnt/external4tb` before re-running. ## How the ELN Fits Into the Plan An ELN (electronic lab notebook) is a digital replacement for the paper notebook, where protocols, timestamps, observations, and deviations are recorded with automatic audit trails. In the data sharing plan, the ELN has three jobs. First, the ELN holds context that raw files cannot. A FASTQ file says nothing about which reagent lot was used or why the operator deviated from the protocol. Those facts belong in ELN entries linked by a shared sample ID convention. Second, the ELN exports become part of the preserved record. The monthly export in step 6 goes into the same backup tiers as the data, so a future reader can reconstruct what happened, not just what was measured. Third, in group cloud environments, accountability matters as much as confidentiality. Work on auditable cloud sharing shows that shared systems need a balance between anonymity and traceability, so authorized entities can identify who did what when necessary, with authentication mechanisms ensuring controlled access [2]. Your plan should state plainly who is allowed to modify shared ELN sections and how changes are attributed. ## Security and Access Control for Cloud Sharing ![Four cards naming encryption, download access rules, key custody and membership removal as required security decisions.](/article-images/illustrations/data-sharing-plan-with-cloud-storage-eln-template-security-controls.webp) Encryption alone does not make cloud sharing safe. Work on dual access control for cloud-based storage argues that encrypting data, for example with AES, cannot by itself meet practical [data management](/blog/guides/data-management-basics-principles-processes-and-best-practices) needs, and that strong access control over download requests is also required to protect confidentiality and to block abuse such as Economic Denial of Service attacks aimed at preventing users from reaching the service [3] [4]. Translated into plan language, your security section needs two independent answers: how files are protected (encryption) and who is allowed to pull them (access rules), and those answers must be written down before data exists. Several established techniques map to common lab situations: - **Attribute-based encryption (ABE)** ties decryption rights to user attributes such as role or group membership. The dual access control work builds on attribute-based encryption to control both access requests and download requests [4]. Use it when people outside your core group need partial access. - **Key-aggregate cryptography** lets a data owner issue one compact key that decrypts only a chosen subset of files. Key-aggregate cryptosystems for scalable cloud sharing were developed so a single delegation does not expose the whole store [5] [6], and key-aggregate searchable encryption (KASE) extends this to group sharing with search over encrypted content [7] [8] [9]. Use this pattern when collaborators should see one project folder but never the entire lab archive. - **Revocable-storage identity-based encryption** addresses group membership changes, a problem that appears whenever students rotate through a lab [10]. - **Client-side encryption before upload** keeps the provider unable to read your files. A study of secure file storage on cloud services proposes encrypting files rather than storing them in plain form, so attackers who reach the stored data cannot read, delete, or manipulate it [11]. Apply this to any file containing human subject identifiers, unpublished results, or third-party confidential material. - **Secret sharing for non-technical users.** The dCloud tool splits a file across multiple public cloud providers using Rabin's IDA, disperses the key with Shamir's secret sharing scheme, verifies integrity with a hash of the original file, and stores the authentication key in a local secure key-store, so an ordinary non-technical user can store and retrieve files securely without understanding the cryptography [12]. This is a strong fit for labs with no dedicated IT staff. - **User-held keys and searchable encryption.** In cloud-edge collaborative storage, letting users generate their own public-private key pairs and control their own private keys, combined with searchable public key encryption, prevents a single point of breach and reduces the overhead of generating search trapdoors compared with schemes where edge servers hold user keys [13]. - **Multi-level privacy for connected instruments.** For projects where benchtop or field devices feed the cloud directly, a blockchain-based scheme using lightweight algorithms such as PRESENT and ECC, with attribute-based encryption enforced through smart contracts and hashes anchoring off-chain cloud storage, provides fine-grained access control by user role on resource-limited devices [14]. - **Multiuser efficiency and auditing.** For labs where many members share one store, schemes built on identity-based encryption with third-party auditing of public integrity reduce the computation and communication cost of verifying that stored data remains intact [15]. You do not need to implement most of this yourself. The point for the plan is to name the mechanism for each decision: what is encrypted, by whom the keys are held, who can request downloads, and how a departing member loses access. If your project handles confidential human data, note that individual institutional policies apply, and your IRB or data protection office overrides anything written here. ## Common Mistakes and Limitations - **One copy on one cloud drive.** A single cloud account is a single point of failure. The three-tier model exists precisely to prevent this. - **Encryption without access control.** Encrypting files while letting anyone with the link download them defeats the purpose. Security research consistently treats access control over downloads as a requirement in its own right [3] [4]. - **Keys stored next to the data.** The dCloud design deliberately keeps the authentication key in a local secure key-store separate from the cloud providers. A passphrase emailed to the whole lab, or saved in the same cloud folder as the ciphertext, protects nothing. - **The ELN treated as the archive.** ELN content that is never exported survives only as long as the vendor's contract and your subscription. Export on a schedule. - **A plan written once and never revised.** Personnel changes break access assumptions. Tie plan reviews to onboarding and departure dates. - **No named data steward.** "The lab" does not run backups. A person does. - **Overcomplicated schemes.** A cryptographic design only protects data if people can actually use it. Tools aimed at ordinary non-technical users exist because complexity itself causes data loss. - **Trusting every component equally.** Analyses of cloud-edge collaborative storage show that schemes assuming all servers are trusted collapse if any one server is compromised, which is why designs that let users hold their own keys and avoid a single point of breach are preferred [13]. One general limitation applies: this template reflects a common structure from the research data management literature and standard practice, but your institution's data policy, your funder's terms, and your field's repository norms take precedence over anything written here. Check those documents first. ## Frequently Asked Questions ### What is a data sharing plan with cloud storage and an ELN? It is a written document that specifies what data a project produces, how it moves through working storage, offline backup, cloud storage, and repositories, what the electronic lab notebook records, and who can access each tier. It converts good intentions into checkable commitments. ### Is there a free data sharing plan with cloud storage ELN template I can copy? Yes, the markdown template in this article is free to copy and adapt, and the worked example shows every field filled in for a realistic RNA-seq project. ### What should the template format contain? Eight sections covering project people, data types and formats, the storage tiers, ELN use and export schedule, access control and encryption, version control and checksums, sharing and preservation, and named responsibilities with review dates. ### How do I compare data repositories? Match the repository type to the job. Personal cloud storage handles active collaboration, institutional repositories handle policy compliance, disciplinary repositories handle community-standard formats for immediate reuse, and generalist archives accept mixed formats. Final published data belongs in a static repository with a persistent identifier [1]. ### How secure is cloud storage for research data? Secure when two controls are combined. Encryption protects file contents, and access control over download requests protects against unauthorized retrieval, which research on cloud storage identifies as a requirement beyond encryption alone [3] [4]. Client-side encryption before upload additionally keeps the provider unable to read your files [11]. ### Can an ELN replace a data repository? No. The ELN records experimental context and protocols, while repositories provide long-term preservation and public access with persistent identifiers. The plan should schedule regular ELN exports into your backup tiers so notebook content survives alongside the data. ### How often should I update the plan? Review it every six months and whenever someone joins or leaves the project, since access control assumptions are the first thing personnel changes break. ### What do funders and journals look for in a data sharing plan? They look for named data types, a specific repository for the final dataset, a timeline tied to publication, a stated license, and clear responsibility for each step. Vague promises like "data will be available on request" are the weakest possible answer. ## Sources 1. [Promoting data sharing among Indonesian scientists: A proposal of generic university-level Research Data Management Plan (RDMP)](https://doi.org/10.3897/RIO.4.E28163) 2. [Enhancing Cloud Security: Secure and Auditable Data Sharing and its Implementation](https://doi.org/10.1109/ICNWC60771.2024.10537314) 3. [Enhancing Security for Dual Access Control for Cloud based Data Storage and Sharing](https://doi.org/10.1109/ICCDS60734.2024.10560374) 4. [DUAL ACCESS CONTROL FOR CLOUD BASED DATA STORAGE AND SHARING](https://doi.org/10.55041/ijsrem18918) 5. [Cryptosystem Using Key Aggregate for Scalable Data Sharing In Secure Cloud Storage](https://www.semanticscholar.org/paper/3d8d7ef68d7874c27f426eb1a9bd9dbf8a29a0b6) 6. [Cryptoshare : Cryptosystem for Scalable Data Sharing in Cloud Storage Ghilby](https://www.semanticscholar.org/paper/27b3a21de9243151537db4b981cf9fd31f32ca12) 7. [Secure Group Data Sharing In Cloud Storage Using Key Aggregate Searchable Encryption](https://www.semanticscholar.org/paper/764018cf8fa5659dea3bbca9e3470411fbfdf2fd) 8. [Key-Aggregate Searchable Encryption (KASE) for Group Data Sharing via Cloud Storage](https://www.semanticscholar.org/paper/34dbe5230716d8263eddb8d86d5d67ec1d8aedaa) 9. [Data sharing among groups in Cloud Storage using KASE Methodology](https://www.semanticscholar.org/paper/c48af3024a5df8b8992671707c5f0d7f06dea4ac) 10. [Secure Data Sharing In Cloud Computing Using Revocable-Storage Identity-Based Encryption](https://www.semanticscholar.org/paper/8835c6c777a0b048ae11ab80a0580ca734bc6ba3) 11. [Secure File Storage & Sharing on Cloud Using Cryptography](https://doi.org/10.47760/IJCSMC.2021.V10I05.005) 12. [A Seamless Secret Sharing Scheme Implementation for Securing Data in Public Cloud Storage Service](https://doi.org/10.1109/INCAE.2018.8579388) 13. [Secure Data Sharing and Search for Cloud Edge Collaborative](https://doi.org/10.22214/ijraset.2023.50400) 14. [A SECURE AND RELIABLE BLOCKCHAIN-BASED DATA SHARING SCHEME USING LIGHTWEIGHT HOMOMORPHIC CRYPTOGRAPHIC ALGORITHM FOR MULTI-LEVEL PRIVACY PROTECTION IN IOT-CLOUD SYSTEMS](https://doi.org/10.12732/ijam.v38i5.1117) 15. [An optimized and efficient multiuser data sharing using the selection scheme design secure approach and federated learning in cloud environment](https://doi.org/10.1108/ijpcc-02-2022-0047)