Data Security, Storage, Backup and Archiving

Overview

Research data must remain confidential when required, protected from unauthorised or accidental alteration, and available to authorised users for as long as the scientific and governance purpose requires. These goals are commonly described as confidentiality, integrity and availability. Modern cybersecurity frameworks such as NIST CSF 2.0 provide a broad risk-management structure, while research guidance such as ICH E6(R3) emphasises secure retention and traceability of essential records.[1,2]

Security is not the same as secrecy. A dataset can be highly confidential but scientifically unusable because files are lost, corrupted or undocumented. Conversely, a well-backed-up dataset can still violate privacy if too many people can access direct identifiers. Research data governance must address the full lifecycle.

Why this matters

Health data can cause harm if disclosed inappropriately. At the same time, excessive restriction can impede authorised quality review, analysis and reproducibility. The objective is proportionate control: understand the data’s sensitivity, the threats, the research purpose and the institutional environment, then design safeguards that reduce risk without making legitimate research impossible.

A copied file is not necessarily a backup; a password is not a complete access-control strategy; and “de-identified” does not guarantee that re-identification is impossible.

Confidentiality, integrity and availability

Confidentiality means information is not disclosed to unauthorised people or processes. Integrity means data remain accurate and protected against unauthorised or undocumented alteration. Availability means authorised users can access data when required.

A good system balances all three. Encrypting the only copy and then losing the key protects confidentiality but destroys availability. Storing many unprotected copies improves apparent availability while undermining confidentiality and version control.

Classify data before choosing controls

Not all files carry the same risk. A study may contain:

• direct identifiers such as names and contact details;
• linkage keys connecting identifiers to study IDs;
• coded participant-level clinical data;
• free-text notes that may contain indirect identifiers;
• aggregate reports;
• analysis code and documentation; and
• public metadata.

Classify sensitivity and determine which roles need each class. This supports data minimisation and avoids applying either too little or unnecessarily burdensome protection.

Separate identifiers from analytical data

Where feasible, keep the re-identification key separate from the main study dataset. Use a study identifier to link records. Restrict the key to personnel who need re-identification for follow-up, source verification or other approved purposes.

Removing obvious names is not enough. Exact dates, rare diagnoses, small geographic areas and free text can make individuals recognisable when combined. De-identification should consider the released dataset and its context, not only one column.

Access control

Use role-based or least-privilege access: users receive the permissions required for their responsibilities and no more. Important practices include:

• individual user accounts;
• strong authentication appropriate to risk;
• timely removal of access when roles change;
• separate privileges for viewing, editing, exporting and administering systems;
• review of access to highly sensitive files; and
• avoiding shared credentials.

Access decisions should be documented sufficiently to reconstruct who was authorised. Current electronic-record guidance also emphasises trustworthy system use and authorised access in regulated investigations.[3]

Storage locations

Prefer institutionally managed storage that provides appropriate security, backup, access administration and support. Personal laptops, consumer cloud drives and removable media can create uncontrolled copies and unclear responsibility.

When local devices are necessary for fieldwork, define encryption, synchronisation, loss reporting and secure deletion. Do not retain identifiable exports on portable devices merely because the collection application is secure.

Secure transfer

Data may move between sites, laboratories, devices and central servers. Use approved encrypted transfer mechanisms appropriate to institutional policy. Verify recipients and minimise the data included.

Avoid sending passwords in the same channel as encrypted files. Avoid routine email attachments containing identifiable participant data unless the approved environment and protections explicitly support it. Keep a record of transfers when this is important for governance or traceability.

Encryption

Encryption can protect data at rest and in transit, but it requires key and credential management. NIST implementation guidance includes protecting stored data and using encryption as one of the available safeguards.[1]

Encryption is not a substitute for access control. An authorised user who exports decrypted data to an insecure location can still create a breach. Security depends on the complete workflow.

Backups are for recovery

A backup is an independent recoverable copy maintained so data can be restored after deletion, corruption, ransomware, hardware failure or other incident. NIST guidance explicitly includes creating, protecting, maintaining and testing backups.[1]

A robust backup plan specifies:

• what is backed up;
• how often;
• where copies reside;
• whether backups are encrypted;
• who is responsible;
• retention of backup versions;
• how restoration is requested; and
• how restoration is tested.

A synchronised cloud folder is useful but may replicate accidental deletion or encryption to every synchronised location. Backup architecture should consider common-mode failure.

PROTOCOL CHECKLIST

Research data security and continuity plan

• Data sensitivity classification.
• Approved storage locations.
• Role-based access and account management.
• Separation of identifiers and linkage keys where feasible.
• Secure transfer procedures.
• Encryption requirements for devices and transfers.
• Backup frequency, location and restoration testing.
• Incident reporting and response route.
• Retention and archiving period by record type.
• Final access, sharing and secure-disposal procedures.

Version control and integrity

Security also means protecting scientific integrity. Keep authoritative versions distinguishable from working copies. Avoid filenames such as final.xlsx, final2.xlsx and reallyfinal.xlsx as the only version system.

For analysis code and non-sensitive documentation, version-control systems can provide detailed histories. For participant-level datasets, use institutionally approved mechanisms and avoid uploading confidential data to public code repositories.

Checksums can help confirm file integrity during transfer or archiving, but they do not prove that the underlying data were correct when the checksum was created.

Incident response

Plan what happens if a laptop is lost, an account is compromised, data are emailed to the wrong recipient or a database becomes unavailable. Personnel should know whom to contact promptly. The response may involve containment, password reset, access suspension, forensic review, participant or authority notification, and restoration from backup depending on the incident and applicable requirements.

Do not create local promises about notification timelines unless they are verified against the governing institution and jurisdiction.

Retention and archiving

Retention periods differ by study type, sponsor, funder, institution and jurisdiction. Therefore, the protocol or data-management plan should identify the governing requirement rather than inventing one universal number. ICH E6(R3) requires secure retention of essential records for applicable clinical trials, with records remaining complete, readable and retrievable.[2]

Archiving should preserve not only the participant data but also enough context to interpret them: protocol, data dictionary, form versions, codebooks, derivation specifications, key correspondence or decisions, analysis code and relevant metadata.

WORKED EXAMPLE

Designing the postpartum study archive

During active follow-up, identifiers are stored in a restricted contact table linked by study ID. The central research dataset contains coded participant data. The statistician receives an analysis export excluding names, telephone numbers and the linkage key.

At study close, the team:

1. resolves outstanding critical data queries;
2. creates a documented final data release;
3. archives the data dictionary, form metadata, protocol and analysis code with the dataset;
4. stores the linkage key under a more restricted permission set for the approved retention period;
5. records the governing retention requirement; and
6. documents the process for authorised future access or secure disposal.

This archive supports both confidentiality and reproducibility.

Data sharing

Modern research policies increasingly expect researchers to plan data management and sharing, but sharing is not identical to open public release. NIH, for example, requires applicable funded research to address data management and sharing through its policy framework, including privacy and repository considerations.[4]

FAIR principles likewise support discoverability and reuse while allowing access conditions.[5] For sensitive health data, a controlled repository or data-use process may be more appropriate than an unrestricted download.

Documentation and data-management plans

A good data-management plan identifies responsibilities for naming, documentation, storage, backup, access, sharing and preservation.[6] Keep the plan operational: name the approved system or responsible role where known, but avoid hard-coding personal names that become obsolete.

Review the plan when systems, collaborators or study phases change. Data security is not a one-time ethics-form paragraph.

DECISION GUIDE

Choose safeguards proportionate to risk

1. What information could identify or harm participants if disclosed?
2. Which users genuinely need identifiable or sensitive data?
3. Where will authoritative data be stored?
4. How will data move between systems or sites?
5. How will accidental loss or corruption be recovered?
6. What must be retained for reproducibility and governance?
7. What access or sharing is authorised after the primary study ends?

Threat modelling for research projectsMMed extension

A simple threat model asks what assets need protection, who or what could compromise them, how compromise could occur, and which controls reduce the most important risks. Threats include more than malicious hacking: accidental deletion, device loss, misdirected email, excessive permissions, ransomware, expired accounts and undocumented manual copies are common operational risks.

The NIST CSF 2.0 functions—Govern, Identify, Protect, Detect, Respond and Recover—provide a useful organising framework for institutional cybersecurity planning.[1] A research protocol need not reproduce an enterprise cybersecurity framework, but it should align with the institution that implements these controls.

Apply defence in depth

No single safeguard is sufficient. Defence in depth combines controls so that one failure does not immediately expose or destroy the data. For example, an institutionally managed laptop may use device encryption, individual authentication, limited local storage, secure network transfer and centrally managed backup. If the laptop is lost, encryption limits disclosure while central storage protects availability.

The exact controls depend on institutional systems and risk, but the principle is general: avoid relying on one password, one copy or one person’s memory.

Distinguish working storage from the authoritative record

Research teams often accumulate downloads in email folders, desktops and shared drives. Define which location is authoritative for active data and which copies are temporary. Temporary exports should have an explicit purpose and disposal plan.

For analysis, consider whether analysts work from a controlled read-only source release and create code-derived outputs elsewhere. This reduces the risk of accidentally altering the authoritative dataset and makes analyses easier to reproduce.

Test restoration, not only backup completion

Backup dashboards may report success while restoration fails because credentials, encryption keys or application dependencies are missing. Periodic restoration testing should demonstrate that the study can recover usable data within an acceptable time.

For complex systems, recovery planning may include not only raw database files but configuration, metadata, codebooks and software dependencies. A backup that restores values without their schema may not restore a usable research system.

Plan close-out access deliberately

At study close, access needs change. Staff who no longer have follow-up duties may no longer need identifiers. External collaborators may require only a controlled analytical dataset. System administrators may retain technical access while scientific access becomes restricted to custodians.

Document the custodian responsible for future authorised requests. Long-term stewardship is weakened when everyone assumes somebody else owns the archive.

Secure disposal

When records reach the end of an approved retention period and no further authorised purpose exists, use institutional secure-disposal procedures appropriate to the medium. Deleting a shortcut or moving a file to a recycle bin is not necessarily secure destruction. Paper identifiers, removable media and old local exports may require different processes.

Before disposal, confirm that litigation holds, sponsor requirements, research-integrity investigations or other governing obligations do not require continued retention.

APPRAISAL CHECKLIST

Appraise research data security and archiving

• Is the authoritative storage location defined?
• Are multiple layers of protection used for sensitive data?
• Are temporary exports and local copies controlled?
• Are backups independent enough to survive plausible common failures?
• Has restoration actually been tested?
• Are access rights reviewed when roles or study phases change?
• Is a long-term data custodian identified?
• Are retention and disposal rules tied to verified governing requirements?

Common mistakes

Knowledge check

What is the difference between confidentiality and availability?

Answer and reasoning

Confidentiality limits information to authorised access. Availability ensures authorised users can obtain the data when needed. A secure research system must manage both rather than maximising one at the expense of the other.

Why is a synchronised folder not necessarily a complete backup strategy?

Answer and reasoning

Deletion, corruption or ransomware can synchronise to every copy. A backup should provide recoverable versions protected from the same failure and should be tested through restoration.

Should an analyst routinely receive the participant linkage key?

Answer and reasoning

Not if the analysis can be performed with study IDs alone. Least-privilege access reduces disclosure risk while preserving the functions required for the analyst’s role.

Does FAIR require confidential participant data to be openly downloadable?

Answer and reasoning

No. FAIR accessibility can include governed or controlled access. Metadata can be public or discoverable while access to sensitive data remains appropriately restricted.

Key take-home messages

SUMMARY

Key take-home messages

• Protect confidentiality, integrity and availability across the complete research-data lifecycle.
• Classify data, minimise identifiers and use role-based access rather than universal permissions.
• Treat secure transfer, encryption and device management as parts of one workflow.
• Maintain recoverable backups and test restoration rather than assuming copies are sufficient.
• Archive data together with the metadata and documentation required for interpretation and reproducibility.
• Base retention, sharing and incident procedures on verified institutional, funder, sponsor and jurisdictional requirements.

References

1. Pascoe C, Quinn S, Scarfone K. The NIST Cybersecurity Framework (CSF) 2.0. Gaithersburg (MD): National Institute of Standards and Technology; 2024. NIST CSWP 29. https://doi.org/10.6028/NIST.CSWP.29
2. International Council for Harmonisation of Technical Requirements for Pharmaceuticals for Human Use. ICH harmonised guideline: Good Clinical Practice E6(R3). Step 4. 6 January 2025. https://database.ich.org/sites/default/files/ICH_E6%28R3%29_Step4_FinalGuideline_2025_0106.pdf
3. US Food and Drug Administration. Electronic systems, electronic records, and electronic signatures in clinical investigations: questions and answers. Guidance for industry. Silver Spring (MD): FDA; 2024. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/electronic-systems-electronic-records-and-electronic-signatures-clinical-investigations-questions
4. National Institutes of Health. Data Management and Sharing Policy. Bethesda (MD): NIH. https://sharing.nih.gov/data-management-and-sharing-policy
5. Wilkinson MD, Dumontier M, Aalbersberg IJ, Appleton G, Axton M, Baak A, et al. The FAIR Guiding Principles for scientific data management and stewardship. Sci Data. 2016;3:160018. https://doi.org/10.1038/sdata.2016.18
6. Michener WK. Ten simple rules for creating a good data management plan. PLoS Comput Biol. 2015;11(10):e1004525. https://doi.org/10.1371/journal.pcbi.1004525