PlagiatScanner.de
Integrity · research data

Retaining primary data: what students should document

Keep the unchanged original state, its provenance, permitted use and route to processed versions separate. The minimum package depends on the method. Privacy, consent and university rules determine which data you may retain and when deletion is required.

INT-09 · Checked 4 September 2026

What counts as primary data

Primary data are the original materials on which analysis relies: completed questionnaires, instrument output, audio, field notes, images, a document corpus or software logs. Meaning varies by discipline. Published papers are not data collected by the author of an ordinary literature dissertation, but exported search results, screening decisions and notes are primary records of that research process.

Distinguish original, working copy and analytical product. The original remains unchanged. A working copy may be cleaned, pseudonymised or reformatted. The analytical product contains models, codes, categories or tables. An error in processing can only be examined if the starting state and transformation route survive, subject to rights and privacy duties.

Minimum package by method

Practical components that must be checked against local rules
Method Original state Supporting records Special boundary
Online survey dated raw export questionnaire, variables and export notes identifiers and platform terms
Interview recording or authorised source state consent, guide, transcription and pseudonym rules voice and content may identify
Experiment instrument output and protocol setup, calibration, parameters and exclusions proprietary formats and safety
Observation timely field notes schedule, context and role reflection data about bystanders
Literature review exported result sets queries, filters, screening and exclusions database licences and full texts
Software project source and test state environment, dependencies, inputs and known defects credentials, third-party code and licences
Secondary analysis obtained version or stable identifier licence, dictionary, selection and transformations redistribution may be prohibited

Folders and versions that explain themselves

A compact structure can separate `01_original`, `02_processing`, `03_analysis`, `04_documentation` and `05_submission`. Apply read-only protection to originals where available. A readme names the project, responsible people, formats, time zone, pseudonym logic, software and folder relationships. Avoid personal names in filenames unless identity is genuinely required.

The processing log connects each material step to the next version. Record input, output, rule, tool, date and reason. A change matrix may cover manual work; code should match the version actually executed. Checksums help identify an unchanged file, but do not prove that data collection was valid.

Preserve usable formats

Where proprietary formats are necessary, document software and version. If appropriate and lawful, add an open export such as CSV or text and verify labels, encoding, decimal symbols and times. Keep the source format too. Images, audio and complex measurements need technical metadata and processing notes.

Test reopening on another system or with another authorised person. A backup that cannot be read is weak evidence. Record failed tests, such as a missing dictionary, damaged file or platform that cannot export. State the resulting limitation instead of pretending the record is complete.

Back up without multiplying risk

Use approved storage only. Encryption, access restriction and backup should match sensitivity. Personal cloud accounts and unencrypted drives may be prohibited. Keep linkage keys separately. Share material only with people whose access is covered by the project and consent.

More copies do not necessarily mean safety; they increase exposure and make deletion harder. Maintain a storage register: location, authorised users, backup and end of purpose. Remove temporary exports in a controlled way. Record deletion without reproducing the sensitive content in the deletion log.

Retention, archiving and deletion

Identify authoritative requirements in the examination rules, research-data policy, ethics approval, contract and consent. The DFG Code provides a general framework for retaining research data and central materials but should not be treated as an identical deadline for every student file. Privacy may require deletion while verification requires specified records. Competent institutional services must resolve that tension.

Archiving is more than abandonment. Select a suitable repository or institutional store, describe version, rights and access, and retain a persistent identifier where issued. re3data helps discover repositories, but suitability for confidential data and the discipline still requires individual assessment.

Close-out and handover review

  1. Originals are separate from processing and clearly identified.
  2. Provenance, licence, consent and permitted use are documented.
  3. A transformation route connects original and reported result.
  4. Formats reopen and exports have been sampled for accuracy.
  5. Access, backup, deletion trigger and source of the retention rule are named.
  6. The submission cites the correct data or material version.

Never hand over an unexplained data dump. An authorised person should understand the readme without opening sensitive areas unnecessarily. Assign ownership for administration, access decisions and due deletion. If a university account will close, agree the destination before the project ends.

Before close-out, reconstruct one reported table from the archived package. Locate the correct original, follow recorded processing, open the analysis and match its output to the dissertation. The exercise need not rerun everything; it tests names, formats, dependencies and instructions. Record discrepancies and improve the readme without altering the preserved original.

Quality sample: For tabular research, trace several cases from original record to reported table, comparing identifier, input, cleaning rule and analysed value. For interviews, follow one protected passage from recording or source note through transcript and coding to quotation where consent permits. For software, follow one test case through input, version and output. This sample cannot prove the whole collection error-free, but it tests whether the evidence chain works in practice. Record selection, outcome and correction without multiplying confidential content. If differences appear systematic, widen the review for a stated reason and notify the responsible supervisor.

Privacy boundary: Do not keep everything “just in case”. Lawfulness, purpose limitation and local deadlines are part of good research practice.

Sources

  1. DFG Code of Conduct, documentation and archiving.
  2. re3data: Registry of Research Data Repositories.
  3. UK Data Service: Research data management.