Research Data Management for University Students

Research data management is the planned organisation, documentation, storage, protection and eventual preservation or disposal of material used or created during a project. For students, it prevents lost work and makes the path from collection to analysis and reporting easier to explain.

Data rules vary by institution, discipline, funder and project risk. Sensitive or identifiable material may require specific approved systems. Convenience services and personal devices should not be assumed suitable simply because they are easy to access.

Start while the project is still small. Naming, access and documentation decisions become much harder to repair after several people, devices and versions have already produced files.

Identify what counts as project data

List raw measurements, recordings, transcripts, survey exports, images, code, notes, derived files and documentation. Include material received from others and note licence or access conditions. Not every file should be managed in the same way.

Write a simple data-management plan

Record what will be created, formats, estimated volume, storage, backup, access, naming, documentation, sharing and final disposal or preservation. Update the plan when the project changes rather than leaving it as a proposal-stage document.

Classify sensitivity before storage

Identify personal, confidential, commercially restricted or otherwise sensitive material. Use the institution’s classification and ethics requirements. Removing direct names may not make a small or detailed dataset anonymous.

Use approved storage

Choose systems supported for the data class and project. Confirm geographic, access and retention constraints where relevant. Do not send research files through personal email or consumer tools unless the institution explicitly permits that route.

Apply the backup rule to active work

Keep managed copies in more than one approved location or service as instructed, and verify that recovery works. Synchronisation alone is not always a backup because deletion or corruption can propagate to every synced device.

Create a stable folder structure

Organise by project stage, data type or analysis workflow and document the logic. Separate raw, cleaned, analysed and output files so an edit cannot silently overwrite the original evidence.

Name files consistently

Use meaningful elements such as project, date, content and version in a consistent order. Avoid ambiguous labels such as final2. Use an unambiguous date format and keep names short enough to work across approved systems.

Control versions deliberately

Decide when to create a new version and who can approve changes. Code repositories may suit scripts, while controlled filenames and logs may suit other files. Never overwrite raw data simply to simplify the folder.

Document variables and decisions

Maintain a README, codebook or data dictionary explaining files, fields, units, missing values, transformations and software. Record exclusions and corrections so another authorised reader can reproduce the path to the reported result.

Separate identifiers where possible

Store the link between identities and research codes separately with tighter access when the approved design allows it. Limit collection of direct identifiers and avoid including names in filenames or free-text notes unnecessarily.

Manage team access

Give access according to role and remove it when no longer needed. Agree how team members transfer, edit and name files. Shared credentials make accountability and secure offboarding difficult.

Use suitable long-term formats

For material intended for preservation or sharing, consider widely supported, non-proprietary formats where discipline guidance permits. Keep the original when conversion could lose information and document the software and version used.

Plan sharing and publication early

Consent, licence, copyright, ethics and repository rules affect what can be shared. A funder or journal expectation does not override participant protection. Prepare a suitably documented public version only when permission and risk review allow it.

Close the project deliberately

Confirm what must be retained, for how long, where it will live and who remains responsible. Remove temporary copies through the approved method, archive documentation and record any access restrictions or future review date.

Protect the analysis workflow itself

Record scripts, software versions, parameters and manual steps that convert raw material into findings. Use repeatable procedures where possible and preserve logs of exclusions or corrections. A clean final table is not sufficient documentation if nobody can reconstruct how it was produced or which source file it used.

Prepare for equipment or account loss

Know how access can be restored if a device fails, an account expires or a team member leaves. Keep recovery information through the approved institutional route, not beside the encrypted data. Test restoration before a deadline and ensure ownership of shared folders or repositories can be transferred to the responsible person.

Schedule brief data audits

At agreed project points, check that expected files exist, backups are current, access lists remain correct and documentation matches the actual workflow. Record the audit date and any correction. Small regular checks are easier to act on than discovering near submission that a variable, recording or analysis version cannot be traced.

Final checklist

• All project data types, owners and restrictions are identified.
• Approved storage, backup and access controls match the data sensitivity.
• Raw, cleaned and analysed material remain distinguishable.
• File names, versions, variables and transformations are documented.
• Retention, sharing, preservation and secure disposal are planned.

Use the Univs programme catalogue, browse institutes on the platform and understand the Univs study journey. For research files, the university’s ethics, IT, library and data-protection policies remain the authoritative controls.