Data Storage and Security in a Data Management Plan

By Dr. Zubair Khalid, DVM, MS, PhD · 2026-11-11

By the end of this article you will be able to write the data storage and security section of a data management plan (DMP), choose storage that matches the sensitivity of your data, describe encryption and access controls in language reviewers accept, and avoid the errors that get plans sent back for revision. You need nothing installed to read this, but the walkthrough uses three free tools you may want on hand: GnuPG for file encryption, rclone for cloud transfers, and any terminal with standard utilities such as sha256sum.

A data management plan is a document that describes how you will treat your data during a project and what happens to the data after the project ends. Most funders now require one as part of a research proposal, and reviewers may use it to judge the merit of the project. The storage and security section is where most researchers lose points, because it asks for concrete operational detail rather than general promises. This article walks through that section step by step, with real commands, a comparison table, and a list of the mistakes that appear most often.

What the Storage and Security Section Must Answer

A fundable storage and security section answers four questions in plain language:

1. Where will the data live during the project, and where will backup copies live?
2. How will the data be protected from unauthorized access, loss, and tampering?
3. Who can read, write, and delete each data type, and how is that enforced?
4. What happens at the end of the project, meaning which data are archived, which are shared, and which are destroyed?

A DMP covers the full data life cycle, from collection and organization through quality control, documentation, use, preservation, and sharing. Storage and security sit in the middle of that life cycle, but the decisions you write here constrain everything downstream. If you promise a repository deposit in your sharing section, the storage section must show that your format and documentation will survive the move.

Why Funders and Institutions Push Hard on This Section

The 2023 NIH Data Management and Sharing Policy made a detailed DMP mandatory for most NIH-funded research, and institutional studies show the gap between awareness and execution. In a survey of 155 researchers at an academic medical center, 67 percent understood the policy, yet only 47 percent felt comfortable developing a DMS Plan, only 29 percent had used DMPTool.org, and confidence in budgeting for data management activities sat at 38 percent [2]. The same study found that 68 percent of respondents perceived executing the plan as burdensome, and researchers asked for centralized consultation, discipline-specific templates, and clearer institutional guidance [2].

A needs assessment at a health sciences campus found a similar pattern. Researchers reported clear gaps in instruction on metadata design, data sharing, data security, and data storage and backup, and although almost all respondents held federal funding, only 38 percent planned to share their data at the end of the project. The lesson for anyone writing a plan is simple. Reviewers and research administrators expect specific, executable commitments about storage, backup, and security, and vague language signals that the work has not been thought through.

Step by Step: Writing the Storage and Security Section

Step 1: Classify your data by sensitivity

Before you name a storage location, sort every data type into a sensitivity tier. A useful three-tier model, drawn from data management work in smart-city systems, classifies data as sensitive, quasi-sensitive, or public, which allows different sharing rules for each class [3].

• Sensitive: identifiable human data, protected health information, genetic data, identifiable location traces, credentials. Highest controls required.
• Quasi-sensitive: de-identified but re-identifiable data, proprietary sequences, unpublished manuscripts, reviewer-confidential material.
• Public: published datasets, code, reference sequences, aggregate results.

Write the classification into your plan as a short table. Reviewers want to see that storage controls scale with risk, and classification is the mechanism that makes that scaling visible.

Step 2: Choose storage for each tier

The table below summarizes the standard options and what belongs in your plan for each one.

Researchers surveyed across five disciplines named security, stable infrastructure, metadata quality control, data traceability, and data use restrictions as the repository features they consider necessary before they will use a repository for the sharing part of their plans [4]. Name the repository in your plan and address those five features explicitly.

Step 3: Specify encryption

Encryption converts readable data into ciphertext that only holders of a key can read. In cloud storage, encryption is the primary countermeasure against unauthorized access, data leakage, and privacy disclosure, and surveys of cloud security identify data encryption technology as the core protection method for stored data [5]. Your plan should state what is encrypted, with what, and who holds the keys.

For files containing sensitive content, symmetric encryption with a passphrase is the fastest working option. With GnuPG installed, encrypt a file like this:

gpg -c --cipher-algo AES256 sequencing_ethics.csv

Expected output and result:

Enter passphrase:
Repeat passphrase:

The command produces sequencing_ethics.csv.gpg in the same directory. Decrypt it later with:

gpg -o sequencing_ethics.csv -d sequencing_ethics.csv.gpg

For stronger key management, hybrid schemes combine a fast symmetric cipher with an asymmetric cipher such as RSA. Work on hospital cloud databases combined an improved AES algorithm with RSA into a hybrid scheme, and reported fast encryption and decryption speed with high security when applied in a hospital information management system [6]. Research on cloud privacy has pushed further, proposing frameworks that combine conventional encryption with obfuscation and post-quantum cryptographic algorithms, decentralized key management, multi-factor authentication, and fine-grained role- and attribute-based access control, so that only authorized personnel can decrypt stored data [7]. You do not need to invent a custom scheme for a typical project. What reviewers want is a named algorithm, a statement about key custody, and a rule for key rotation when personnel change.

Step 4: Define access control

Access control decides who can read, write, and delete each data tier. Two mechanisms appear repeatedly in the security literature and belong in most plans:

• Multi-factor authentication (MFA), which requires a second proof of identity beyond a password, such as an authenticator app code.
• Role-based access control (RBAC), which grants permissions to roles such as principal investigator, analyst, and data entry staff, rather than to individuals. Advanced work extends this to attribute-based models for fine-grained control in cloud storage [7], and reinforcement-learning approaches have been applied to cloud access management as an adaptive layer of protection [8].

Write the access matrix into the plan. A line such as "raw identifiable interview files are readable only by the two named interviewers and the PI, from institutional machines, over the campus VPN" is worth more than a paragraph about commitment to security.

Step 5: Build the backup rule and verify it

The conventional pattern is the 3-2-1 rule, three copies, two different media, one off site. For most lab projects that translates to the working copy on the institutional server, a second copy on encrypted cloud storage, and a third on an encrypted external drive held in a different building.

Sync the second copy with rclone:

rclone copy /lab/project-data securecloud:project-backup --checksum

Expected output looks like:

2026/11/11 09:14:02 INFO  : 128 files copied, 0 failed

Then verify integrity with checksums. A checksum is a fixed-length fingerprint of a file, and any change to the file changes the fingerprint:

sha256sum sequencing_ethics.csv

Expected output:

7f3a9c...  sequencing_ethics.csv

Store the checksum list with the data and re-run it after every transfer. For projects with heavy storage demands, distributed architectures built on object storage with explicit disaster recovery, backup, and data labeling capabilities address the challenge of massive multi-format data [9]. Distributed storage research also tackles the reliability problem directly, using error-correcting schemes that let you configure the probability of information loss and data redundancy to match your workload and storage constraints [10]. Note in your plan how often backups run, where they live, and who verifies them.

Step 6: Plan deduplication and storage cost controls

Encrypted data resist the usual storage efficiency tricks, because encryption removes the duplicate patterns that deduplication relies on. Heterogeneous storage management schemes now handle this by offering both deduplication and access control across multiple cloud service providers, flexing with the sensitivity level of the data [11]. For a plan, this matters in one sentence: state whether large raw files, such as imaging or sequencing runs, are deduplicated before encryption or stored once under version control, and roughly how much storage the project needs. Funders increasingly expect data management costs, including storage, to appear in the budget [2].

Step 7: Write the end-of-project rule for every data type

For each tier, state the destination. Public data go to a repository with a persistent identifier. Quasi-sensitive data go to a controlled-access repository or remain under institutional custody. Sensitive identifiable data are either retained under the approved retention schedule or destroyed with a documented method. Researchers designing repository systems emphasized metadata quality control and training as persistent problem areas, so commit to depositing complete metadata, not just files [4]. Michener's rules for good data management plans emphasize that the plan must describe what happens to the data after the project ends, which is exactly where this step lands [1].

Choosing Between In-House and Entrusted Storage

A recurring decision in grant proposal planning is whether to keep data on infrastructure you control or entrust it to a vendor. Analytical work in the Industrial Internet of Things context modeled this choice explicitly, incorporating data security levels, data quality, breach probabilities, and cost coefficients into profit functions for in-house versus entrusted storage. The findings indicate that when an organization's own security and data quality are weak, entrusting storage to a specialized provider offers technical advantages and added data services, while different conditions favor keeping data in house [12]. Translate that logic to your plan. If your institution lacks a managed, backed-up, access-controlled environment, name the qualified provider and justify the choice. If your institution has strong infrastructure, say so, because reviewers read vendor defaults as a sign of unreadiness.

Healthcare and clinical settings face the same decision under higher stakes. The shift from paper records to cloud platforms removes provisioning burdens and improves diagnosis speed, but it demands new storage standards and security reforms, and analyses of medical cloud storage recommend structured data mining and modern storage practices to realize the full service potential of shared clinical data [13].

Security for Human and Clinical Data

If your project touches human health data, the security section carries extra weight. Big data healthcare systems face threats including man-in-the-middle attacks, distributed denial of service, botnets, correlation attacks, and risks around patient image sharing and authentication, despite years of security research [14]. Practical frameworks respond with layered cryptographic designs. One smart-healthcare security framework combined hyperchaotic encryption, DNA encoding, and lossless secret image sharing, producing noise-like cipher shares small enough for resource-constrained IoT-style storage, with strong resistance to attack [15]. A laboratory project will rarely implement those methods directly, but the plan should show awareness of the threat classes and name the controls that address them: encryption at rest and in transit, authenticated access, audit logs, and de-identification before analysis.

Integrity Assurance: What Blockchain Adds and When It Matters

Some funders and data providers now ask about integrity guarantees, meaning proof that stored data have not been altered. Blockchain provides one route. Its mechanisms, decentralization, hash functions, digital signatures, and consensus procedures such as Proof of Work and Proof of Stake, make recorded data practically impossible to alter after the fact, and smart contracts can automate rules that cannot be changed after creation. Blockchain-based storage management systems apply these properties to give storage that is unforgeable, traceable, open and transparent, and collectively maintained, and such systems have been demonstrated for trusted encrypted storage of metering assets [17]. For a typical research DMP, you usually satisfy integrity requirements more cheaply with checksums, version control, and audit logs. Mention blockchain only when a data provider or agreement genuinely requires tamper-evident provenance.

Tips for Grant Proposal Planning

These are the practical habits that separate plans that pass review from plans that return for revision.

• Write the security section while designing the study, not the week before the deadline. Plans written late tend to promise controls that do not exist.
• Use a plan template tool. Only 29 percent of surveyed researchers had used DMPTool.org, and 87 percent asked for tailored templates, which suggests the tool is underused relative to the demand for its output [2].
• Take a research grant writing course that includes a data management module. Data planning is now scored in review, and the survey evidence shows researchers want more training and consultation in exactly this area [2].
• Match every sensitive data type to a named control. One sentence per tier, naming the storage, the encryption, and the access rule.
• Name the responsible person. A plan without an owner is a plan nobody executes.
• State the budget line. Storage, repository fees, and personnel time for curation belong in the proposal budget, and funders expect the DMP and the budget to agree [2].

Common Mistakes and Limitations

• Naming a storage location without backup. A single institutional folder is one copy. Reviewers expect the 3-2-1 pattern or an equivalent institutional standard, plus a stated backup schedule.
• Claiming encryption without saying who holds the keys. If the vendor holds the keys, say so. If the lab holds the keys, describe custody and what happens when a key holder leaves.
• Treating de-identification as a storage control. De-identification changes the sensitivity tier, but quasi-sensitive data still need encryption and access control, because re-identification risk remains.
• Skipping checksums. Silent corruption during transfer is common, and without checksums you cannot prove the archived copy matches the working copy. The sha256sum workflow in Step 5 takes minutes.
• Promising a repository deposit without checking the repository. Researchers across disciplines listed security, stable infrastructure, metadata quality control, traceability, and data use restrictions as requirements they check before committing [4]. Verify access terms, file formats, and metadata standards before you name the repository.
• Leaving the budget out. Budgeting for data management activities is a documented weak point, with confidence at 38 percent in one institutional survey [2]. Put the storage and curation costs in the proposal.
• Overpromising security for human data. Reviewers with human-subjects expertise distrust absolute claims. Describe the controls and the failure plan, not perfection.
• Forgetting the exit. Many plans describe collection and storage in detail and go silent on deletion, retention, and handover. State the disposition of every data type.

One limitation applies to every plan. The right controls depend on your institution's policies, your data use agreements, and your funder's rules, so confirm the details with your institutional data officer or information security office before submitting.

Frequently Asked Questions

How detailed should the storage and security section be?

Specific enough that a new lab member could follow it. Name the storage systems, the encryption method, the access roles, the backup schedule, and the disposition of each data type. General statements such as "data will be stored securely" fail review because they cannot be executed or audited.

Do I need encryption if my data are on an institutional server?

Usually yes for sensitive tiers, at minimum through disk-level or file-level encryption plus access control. Encryption is the core protection method for stored data in cloud and server environments alike, and your plan should state what is encrypted and who holds the keys [5].

What is the simplest defensible backup strategy?

Three copies on two different media with one off site, verified with checksums. A working copy on the institutional server, an encrypted cloud copy synced with a tool such as rclone, and an encrypted external drive in a separate location covers most lab projects.

How do I write about human data in the security section?

Classify the data as sensitive, name the encryption and access controls, describe de-identification steps, state the audit logging approach, and give the retention or destruction rule. Reviewers expect awareness of healthcare-specific threats such as unauthorized access and re-identification when clinical data are involved.

What goes in the plan about cloud storage providers?

The provider name, the encryption state in transit and at rest, the account and multi-factor authentication policy, the backup arrangement, and the exit plan for retrieving or deleting data at project end. Cloud storage security surveys treat encryption and access countermeasures as the foundation of protection for outsourced data [5].

Is blockchain ever the right answer for a research DMP?

Rarely. Use checksums, version control, and audit logs for ordinary integrity needs. Consider blockchain-style tamper-evident storage only when a data agreement requires provable immutability and traceability, since those are the properties blockchain mechanisms deliver [16].

Should storage costs appear in the proposal budget?

Yes. Funders expect the DMP and the budget to be consistent, and budgeting for data management activities is one of the areas where researchers report the lowest confidence [2]. List storage, repository charges, and personnel time for curation and deposit.

What happens if my storage plan changes mid-project?

Update the DMP and document the change. Plans are living documents that may be revisited during performance reviews, so a dated note describing the new storage location, the data migration, and the verification of integrity after migration is the correct response.

Sources

1. Ten Simple Rules for Creating a Good Data Management Plan
2. Supporting researcher compliance: assessing institutional readiness for the 2023 NIH Data Management and Sharing Policy.
3. A Data Management System for Smart Cities Leveraging Artificial Intelligence Modeling Techniques to Enhance Privacy and Security
4. A focus groups study on data sharing and research data management
5. Data Security and Privacy Protection for Cloud Storage: A Survey
6. HYBRID ENCRYPTION ALGORITHMS FOR MEDICAL DATA STORAGE SECURITY IN CLOUD DATABASE
7. Optimizing User Data Privacy and Confidentiality in Cloud Storage Systems Through Advanced Obfuscrypt Encryption Methods for Enhanced Security and Efficient Data Protection
8. Access management based on deep reinforcement learning for effective cloud storage security
9. Research on the Method of Massive Data Storage Management
10. AR-RRNS: Configurable reliable distributed data storage systems for Internet of Things to ensure security
11. Heterogeneous Data Storage Management with Deduplication in Cloud Computing
12. Enterprise customer data storage strategies in the IIoT context: the impact of data security and quality
13. The Much Needed Security and Data Reforms of Cloud Computing in Medical Data Storage
14. A survey on techniques, methods and security approaches in big data healthcare
15. A Security Management Framework for Big Data in Smart Healthcare
16. Investigating Blockchain Security Mechanisms for Tamper-Proof Data Storage
17. Application of data storage management system in blockchain-based technology