eduKate Singapore

VIEW THIS AS

Auto mode follows the Route Engine until you choose a viewpoint.

YOU ARE HERE

ROUTE CHECK

CONNECTED TO

WHAT NEXT

Use the canonical route for this room, or HELP if you are unsure.

Next useful routeCanonical hubHELP

Why English? | Writing a Research Data Management Plan Through Data Types, Storage, Access, Security, Retention, Sharing and Responsibilities

—

by

eduKate Asia
Three learners review open books together at a classroom table, with stacks of textbooks, stationery and a whiteboard in the bright room.

WHY ENGLISH? · PRACTICAL WRITING

Write a research data management plan that follows information from collection to responsible reuse or disposal

Writing a research data management plan is practical English for university students, research assistants, laboratory teams and project leaders. The plan should identify the data a project will create or receive, describe formats and documentation, name approved storage and backup, control access, protect sensitive information, set retention and disposal rules, and explain whether and how data can be shared.

People searching data management plan example, DMP template, research data storage, data sharing plan or how to manage research data need a lifecycle document, not a generic promise that files will be kept safely. Every section should connect a data type to a system, person, rule, time period and review point.

Current NTU guidance says a DMP records how research data will be managed, used and shared and must be submitted through RISE at the start of each new project. NUS guidance links good research data management with research integrity, validation and future research, while its library guidance points researchers to planning tools and institutional storage options. Requirements differ by institution, funder, discipline, ethics approval and data type, so the live policy and approved protocol control the project.

ROUTE 1Scope the data
define the project, data inventory, formats and rolesROUTE 2Store and protect
design storage, backup, access and security controlsROUTE 3Document and assure
document files, versions, metadata and quality checksROUTE 4Govern and retain
align consent, ethics, contracts and retention rulesROUTE 5Share and preserve
plan sharing, repositories, licences and justified restrictions

Open the complete chapter index · Visit the English Learning Hub

Complete guide index

A useful DMP is a living decision record. It says what will happen to each important data class, who is responsible and how the plan changes when the project changes.

Scope the data
  1. Start from the research question, protocol and obligations
  2. Inventory every important data class
  3. Choose sustainable formats and conversion rules
  4. Assign roles and decision authority
Store and protect
  1. Choose approved active storage
  2. Design backup, recovery and integrity checks
  3. Control access through the project lifecycle
  4. Plan incident detection and response
Document and assure
  1. Create naming, folder and version conventions
  2. Write metadata, codebooks and README files
  3. Record quality assurance and transformations
Govern and retain
  1. Align consent, ethics, privacy and contracts
  2. Set retention triggers and defensible disposal
Share and preserve
  1. Decide what can be shared and under which access model
  2. Select repositories, licences and persistent identifiers
  3. Review the DMP as a living project record

CHAPTER 1 OF 16 · Scope the data

1. Start from the research question, protocol and obligations

Back to contents

The DMP serves a real project

Summarise the research purpose, methods, institutions, funders, ethics status and agreements that shape the data lifecycle. Identify the authoritative documents and responsible project lead.

This opening prevents the plan from becoming a generic storage essay. Requirements may arise from the institution, funder, ethics committee, collaborator, data provider, contract or law, and conflicts need authorised resolution.

Practical example. A health interview project records its ethics reference, hospital agreement and funder sharing condition before choosing a repository.

Use purpose–method–obligation–owner

Write a short scope paragraph and an obligations register with links, owners and review dates.

  • Name project.
  • Name method.
  • List obligations.
  • Name owner.
Did You Know? A technically possible data action may still be prohibited by consent or contract.
Important limit. Do not interpret a policy in isolation when the approved protocol or agreement is more specific.

How this skill transfers

Scope mapping supports proposals and laboratory planning.

Researchers can maintain a decision log beside the document: source requirement, local choice, responsible person and review date. Supervisors and data stewards can challenge gaps, but the project team remains responsible for matching the plan to the protocol, ethics approval, funder terms, institutional policy and actual systems.

CHAPTER 2 OF 16 · Scope the data

2. Inventory every important data class

Back to contents

Different files need different decisions

List data created, received or derived, including identifiers, raw instrument files, recordings, notes, code, models, processed tables, documentation and administrative records.

For each class, record format, estimated volume, sensitivity, collection source, owner and relationship to other classes. Include physical samples or paper records where relevant.

Practical example. The inventory distinguishes raw microscope images, calibration logs, segmentation masks, analysis code and published figures.

Use class–format–volume–sensitivity

Create one row per meaningful class and avoid the catch-all word data when decisions differ.

  • Name class.
  • Name format.
  • Estimate volume.
  • Classify sensitivity.
Did You Know? Derived data can be more sensitive than a single raw file when sources are combined.
Important limit. Do not omit temporary exports or local working copies that create real risk.

How this skill transfers

Inventory skills support digital projects and archives.

Researchers can maintain a decision log beside the document: source requirement, local choice, responsible person and review date. Supervisors and data stewards can challenge gaps, but the project team remains responsible for matching the plan to the protocol, ethics approval, funder terms, institutional policy and actual systems.

CHAPTER 3 OF 16 · Scope the data

3. Choose sustainable formats and conversion rules

Back to contents

Formats affect access and preservation

Identify native working formats, preferred preservation or exchange formats and any conversion needed. Record software, versions and validation steps.

Open or widely documented formats can support reuse, but discipline-specific formats may preserve essential information. The plan should explain the choice rather than apply one rule blindly.

Practical example. The team retains native instrument files and creates validated TIFF exports plus a checksum manifest.

Use native–exchange–preservation–validation

For each class, state which format is authoritative and how conversions are checked.

  • Name native.
  • Name exchange.
  • Name preservation.
  • Validate conversion.
Did You Know? A smaller file is not necessarily a more trustworthy preservation file.
Important limit. Do not discard metadata or measurement precision during conversion.

How this skill transfers

Format literacy supports media and technical work.

Researchers can maintain a decision log beside the document: source requirement, local choice, responsible person and review date. Supervisors and data stewards can challenge gaps, but the project team remains responsible for matching the plan to the protocol, ethics approval, funder terms, institutional policy and actual systems.

CHAPTER 4 OF 16 · Scope the data

4. Assign roles and decision authority

Back to contents

Data work needs named people

Name the principal investigator, data steward, analysts, system owner, security contact and repository depositor, and describe who approves access, changes and final disposition.

Roles may change as students graduate or collaborators leave. Include handover and succession arrangements so no critical key, codebook or account depends on one person.

Practical example. The lab manager owns the storage space; the PI approves access; the analyst maintains the codebook; the librarian advises repository deposit.

Use task–owner–approver–backup

Build a responsibility table with a primary person, backup and handover trigger.

  • Name task.
  • Name owner.
  • Name approver.
  • Name backup.
Did You Know? A shared folder can still have no real owner if responsibility is assumed rather than written.
Important limit. Do not assign security or legal authority to someone who does not hold it.

How this skill transfers

Role clarity supports group projects and careers.

Researchers can maintain a decision log beside the document: source requirement, local choice, responsible person and review date. Supervisors and data stewards can challenge gaps, but the project team remains responsible for matching the plan to the protocol, ethics approval, funder terms, institutional policy and actual systems.

CHAPTER 5 OF 16 · Store and protect

5. Choose approved active storage

Back to contents

Location is part of the control

Name the institutional system for each class, its region or service boundary where relevant, and why it fits sensitivity, volume, collaboration and performance needs.

Avoid vague phrases such as secure server. The plan should identify the approved environment without publishing sensitive configuration details.

Practical example. Identifiable interview audio stays in an approved restricted project space; de-identified analysis tables use a controlled collaboration folder.

Use class–system–fit–owner

Match every inventory row to an approved storage location and accountable service owner.

  • Match class.
  • Name system.
  • Explain fit.
  • Confirm owner.
Did You Know? Convenient consumer storage can create unauthorised copies even when the link is never shared.
Important limit. Do not publish credentials, security architecture or personal data inside the DMP.

How this skill transfers

Storage choices support workplace information governance.

Researchers can maintain a decision log beside the document: source requirement, local choice, responsible person and review date. Supervisors and data stewards can challenge gaps, but the project team remains responsible for matching the plan to the protocol, ethics approval, funder terms, institutional policy and actual systems.

CHAPTER 6 OF 16 · Store and protect

6. Design backup, recovery and integrity checks

Back to contents

Copying is not the same as recoverability

State backup frequency, separation, retention, restoration testing and integrity checks such as checksums where appropriate. Distinguish service backup from version history and personal synchronisation.

Recovery objectives should match the cost of recreating data and project timing. Test that an authorised person can actually restore a file.

Practical example. The team performs a quarterly restore test of a sample dataset and records the result in the project log.

Use risk–backup–restore–test

For critical classes, write the failure scenario, recovery source, responsible person and test date.

  • Name risk.
  • Name backup.
  • Plan restore.
  • Test recovery.
Did You Know? A backup that has never been restored is an assumption, not verified recovery.
Important limit. Do not create unmanaged copies simply to feel safer.

How this skill transfers

Recovery planning supports school and business projects.

Researchers can maintain a decision log beside the document: source requirement, local choice, responsible person and review date. Supervisors and data stewards can challenge gaps, but the project team remains responsible for matching the plan to the protocol, ethics approval, funder terms, institutional policy and actual systems.

CHAPTER 7 OF 16 · Store and protect

7. Control access through the project lifecycle

Back to contents

Access should follow role and need

Define who can see, edit, export or approve each class, how access is authorised, reviewed and removed, and how guests or service providers are handled.

Use least-necessary access and record exceptions. Review permissions when roles change rather than waiting for project close.

Practical example. A transcription provider receives only assigned audio through the approved transfer route and loses access after verified delivery.

Use role–permission–approval–removal

Create an access register tied to the data inventory and review it on a set schedule.

  • Name role.
  • Set permission.
  • Record approval.
  • Remove access.
Did You Know? Edit permission, download permission and permission to share onward are not the same thing.
Important limit. Do not promise anonymity simply because names are removed from a user interface.

How this skill transfers

Access literacy supports teamwork and privacy.

Researchers can maintain a decision log beside the document: source requirement, local choice, responsible person and review date. Supervisors and data stewards can challenge gaps, but the project team remains responsible for matching the plan to the protocol, ethics approval, funder terms, institutional policy and actual systems.

CHAPTER 8 OF 16 · Store and protect

8. Plan incident detection and response

Back to contents

Controls can fail

Name the authorised route for lost devices, mistaken sharing, malware, unauthorised access or integrity concerns, and state immediate containment and preservation steps at an appropriate level.

The DMP should point to institutional incident procedures rather than inventing a parallel investigation. Team members need to know whom to contact and how quickly.

Practical example. A researcher who sends a restricted file to the wrong address stops further sharing and contacts the institutional security and research leads immediately.

Use event–contain–report–record

Write a short team instruction using current institutional contacts and avoid speculative blame.

  • Recognise event.
  • Contain safely.
  • Report promptly.
  • Preserve record.
Did You Know? Fast, honest reporting can reduce harm and help specialists respond effectively.
Important limit. Do not erase evidence, negotiate privately or promise affected people an outcome before the authorised response.

How this skill transfers

Incident language supports digital citizenship.

Researchers can maintain a decision log beside the document: source requirement, local choice, responsible person and review date. Supervisors and data stewards can challenge gaps, but the project team remains responsible for matching the plan to the protocol, ethics approval, funder terms, institutional policy and actual systems.

CHAPTER 9 OF 16 · Document and assure

9. Create naming, folder and version conventions

Back to contents

Files need stable identity

Define filenames, dates, identifiers, folder purposes, version labels and rules for final or authoritative copies. Use conventions that work across operating systems and teams.

Keep names concise but meaningful. Separate raw, interim, processed and released materials so a polished file is not mistaken for the source record.

Practical example. A dataset uses projectID_class_YYYYMMDD_version, while a manifest records the human-readable description and checksum.

Use identity–date–version–state

Publish the convention in the README and test it with real examples before collection expands.

  • Name identity.
  • Add date.
  • Add version.
  • Mark state.
Did You Know? The word final often multiplies because it does not say who approved or when.
Important limit. Do not rename raw files in a way that breaks instrument links or provenance.

How this skill transfers

Version control supports writing and coding.

Researchers can maintain a decision log beside the document: source requirement, local choice, responsible person and review date. Supervisors and data stewards can challenge gaps, but the project team remains responsible for matching the plan to the protocol, ethics approval, funder terms, institutional policy and actual systems.

CHAPTER 10 OF 16 · Document and assure

10. Write metadata, codebooks and README files

Back to contents

Context makes data intelligible

Record variable definitions, units, codes, collection conditions, instruments, missing-value meanings, processing history and folder structure. Use disciplinary standards where appropriate.

Documentation should be created during work, not reconstructed entirely at the end. Include decisions that affect interpretation, not merely a list of filenames.

Practical example. The codebook distinguishes missing by design, participant refusal and technical failure rather than using one blank value.

Use item–meaning–unit–provenance

Ask whether an authorised colleague can interpret one file and reproduce one transformation using the documentation.

  • Define item.
  • State unit.
  • Explain missingness.
  • Record provenance.
Did You Know? A value can be numerically precise and still be meaningless without units and collection context.
Important limit. Do not put confidential participant details into public metadata.

How this skill transfers

Metadata thinking supports note-taking and archives.

Researchers can maintain a decision log beside the document: source requirement, local choice, responsible person and review date. Supervisors and data stewards can challenge gaps, but the project team remains responsible for matching the plan to the protocol, ethics approval, funder terms, institutional policy and actual systems.

CHAPTER 11 OF 16 · Document and assure

11. Record quality assurance and transformations

Back to contents

Results depend on a visible chain

Describe validation, calibration, transcription checking, cleaning, exclusion, recoding and analysis steps, including who performed and reviewed them.

Preserve raw or source records where policy allows and keep scripts or decision logs that show how processed data were produced.

Practical example. A survey script flags out-of-range values, while the analyst log records every manual correction with reason and reviewer.

Use source–check–change–review

For each major transformation, identify input, method, output, exception rule and reviewer.

  • Name input.
  • Run check.
  • Record change.
  • Review output.
Did You Know? Manual cleaning is not automatically wrong; invisible manual cleaning is difficult to verify.
Important limit. Do not overwrite the only copy of source data with cleaned values.

How this skill transfers

Provenance supports science and auditing.

Researchers can maintain a decision log beside the document: source requirement, local choice, responsible person and review date. Supervisors and data stewards can challenge gaps, but the project team remains responsible for matching the plan to the protocol, ethics approval, funder terms, institutional policy and actual systems.

CHAPTER 12 OF 16 · Govern and retain

12. Align consent, ethics, privacy and contracts

Back to contents

Permission has boundaries

Compare planned collection, access, linkage, retention, sharing and future use with consent materials, ethics approval, privacy obligations and agreements. Resolve mismatch before action.

De-identification should be described accurately, including any retained key and residual re-identification risk. Do not use anonymous as a casual synonym for coded.

Practical example. Consent permits research-team access to transcripts but not public audio release, so the sharing plan excludes audio.

Use promise–plan–mismatch–resolution

Build a crosswalk from participant or provider promises to each relevant DMP section.

  • Quote promise.
  • Find plan.
  • Mark mismatch.
  • Seek approval.
Did You Know? A new repository deposit can be a new use even when the research question is unchanged.
Important limit. Do not expand future use through wording alone; obtain the required authority.

How this skill transfers

Promise checking supports trust and compliance.

Researchers can maintain a decision log beside the document: source requirement, local choice, responsible person and review date. Supervisors and data stewards can challenge gaps, but the project team remains responsible for matching the plan to the protocol, ethics approval, funder terms, institutional policy and actual systems.

CHAPTER 13 OF 16 · Govern and retain

13. Set retention triggers and defensible disposal

Back to contents

Time periods need a starting event

State which data must be retained, the period or review rule, the trigger that starts the clock and any hold, archive or exception. Describe approved disposal for digital and physical materials.

Different classes may have different requirements. Preservation of verification data does not mean every temporary copy must remain indefinitely.

Practical example. The plan retains final research data from project completion under institutional policy while deleting temporary transfer copies after verified ingestion.

Use class–trigger–period–disposition

Tie each inventory row to a retention decision and named approval owner.

  • Name class.
  • Name trigger.
  • Set period.
  • Name disposition.
Did You Know? “Keep for ten years” is incomplete unless the plan states ten years from which event.
Important limit. Do not destroy data subject to an investigation, audit, legal hold or other authorised requirement.

How this skill transfers

Retention language supports records management.

Researchers can maintain a decision log beside the document: source requirement, local choice, responsible person and review date. Supervisors and data stewards can challenge gaps, but the project team remains responsible for matching the plan to the protocol, ethics approval, funder terms, institutional policy and actual systems.

CHAPTER 14 OF 16 · Share and preserve

14. Decide what can be shared and under which access model

Back to contents

Open is a goal with ethical limits

Classify outputs as open, controlled, restricted or not shareable, and explain the reason. Consider consent, confidentiality, security, contracts, intellectual property and community interests.

Where full release is inappropriate, consider metadata, code, synthetic data, aggregate results or controlled access if authorised.

Practical example. The team shares analysis code openly, deposits de-identified data under controlled access and explains why raw audio is unavailable.

Use value–risk–model–justification

Document the benefit of sharing, residual risk, chosen access model and approving authority.

  • Name benefit.
  • Assess risk.
  • Choose model.
  • Record approval.
Did You Know? Responsible restriction can support trust and future participation in research.
Important limit. Do not promise open data simply to satisfy a generic template.

How this skill transfers

Sharing decisions support citizenship and careers.

Researchers can maintain a decision log beside the document: source requirement, local choice, responsible person and review date. Supervisors and data stewards can challenge gaps, but the project team remains responsible for matching the plan to the protocol, ethics approval, funder terms, institutional policy and actual systems.

CHAPTER 15 OF 16 · Share and preserve

15. Select repositories, licences and persistent identifiers

Back to contents

The destination shapes reuse

Choose an institutional or disciplinary repository that supports the file types, access controls, metadata, preservation and identifier needs. State the licence or terms for shareable materials.

Check deposit timing, embargo, version, cost and responsibility. A personal webpage is not automatically a preservation repository.

Practical example. The final code and documentation receive a persistent identifier, while controlled data use an application process managed by the institution.

Use material–repository–access–licence

Match each shareable class to a destination and verify the deposit requirements early.

  • Choose material.
  • Check repository.
  • Set access.
  • Choose licence.
Did You Know? A persistent identifier helps citation, but it does not guarantee that every file is legally reusable.
Important limit. Do not apply a licence broader than the rights the project actually holds.

How this skill transfers

Repository literacy supports portfolios and open scholarship.

Researchers can maintain a decision log beside the document: source requirement, local choice, responsible person and review date. Supervisors and data stewards can challenge gaps, but the project team remains responsible for matching the plan to the protocol, ethics approval, funder terms, institutional policy and actual systems.

CHAPTER 16 OF 16 · Share and preserve

16. Review the DMP as a living project record

Back to contents

Plans must follow change

Set review dates and triggers for new methods, systems, collaborators, data classes, risks, agreements, incidents and sharing decisions. Record versions and approvals.

At project close, verify access removal, documentation, repository deposit, retention, unresolved restrictions and handover. Archive the approved final plan with the project record.

Practical example. A new international collaborator triggers a review of access, transfer, agreements and repository plans before data are shared.

Use trigger–change–approval–version

Maintain a concise change log explaining what changed, why, who approved and which sections were updated.

  • Set triggers.
  • Review plan.
  • Seek approval.
  • Version record.
Did You Know? A DMP can reveal project change earlier than the methods section because it follows systems and responsibilities too.
Important limit. Do not update the document after the fact to make unapproved actions look planned.

How this skill transfers

Living plans support projects and lifelong learning.

Researchers can maintain a decision log beside the document: source requirement, local choice, responsible person and review date. Supervisors and data stewards can challenge gaps, but the project team remains responsible for matching the plan to the protocol, ethics approval, funder terms, institutional policy and actual systems.

A worked example: planning the lifecycle of interview, survey and analysis data

The inventory

A mixed-methods student project will create consent records, audio interviews, transcripts, survey exports, a codebook, analysis scripts and figures. The plan treats these as different data classes because they carry different identifiers, formats, access needs and sharing possibilities.

The inventory records estimated volume, file format, collection system, sensitivity and owner. It distinguishes raw audio from de-identified transcripts and final aggregate results instead of referring to everything as “research data.”

The secure workflow

Audio moves from the approved recorder to institutional encrypted storage, where access is limited to named team members. Transcription occurs under the approved arrangement. The linkage key is stored separately, while analysis uses coded identifiers.

The plan states who grants and removes access, how devices are cleared, how backups are tested and where incidents are reported. “Password protected” alone is not treated as a complete security design.

The documentation layer

The team uses a file-naming convention, versioned code, a variable dictionary and a README explaining folder structure and processing steps. Quality checks record missing values, recoding decisions and transcript corrections.

This documentation helps another authorised researcher understand how raw records became results. It also helps the original team return to the project months later without relying on one person’s memory.

The sharing decision

Consent permits de-identified quotations but not public release of audio. The team plans to preserve the codebook, analysis script and a controlled-access de-identified dataset if risk assessment and institutional approval allow. Restrictions are explained rather than hidden behind “data not available.”

The final DMP identifies the repository, access conditions, licence for shareable materials, retention period and review owner. It does not promise open data where consent, confidentiality, law or contracts require limits.

A data-class decision card

Identity

Name the data class precisely: raw instrument file, identifier key, transcript, processed table, code, image, model or administrative record.

Lifecycle

State collection or receipt, transfer, active storage, backup, processing, preservation and disposal steps in order.

Control

Name the owner, approved users, access method, security classification and incident route.

Documentation

List format, naming, metadata, version and quality records that make the class understandable.

End state

State the retention trigger, repository or archive, sharing condition, licence or access rule, and approved disposal method.

Research-team workshop: test the plan against a real file

Trace one raw file

Follow a sample from creation to final state and note every system, handoff and decision.

  • Create
  • Transfer
  • Process
  • Preserve

Test an access change

Simulate a researcher joining or leaving and confirm who updates permissions and records the change.

  • Approve
  • Grant
  • Review
  • Remove

Run a reuse test

Ask whether an authorised future researcher could understand a file, variable and transformation without calling the original analyst.

  • README
  • Codebook
  • Version
  • Provenance

Advice for students, parents, mentors and professionals

Students can begin small: inventory the data classes before writing policy language. The inventory makes storage, privacy, documentation and sharing questions concrete.

Supervisors should review the DMP alongside the protocol, ethics materials, consent language, contracts and actual technical environment. A beautiful plan that contradicts any one of those controls is not ready.

Parents and younger students can transfer the principle to school projects: keep originals, name versions clearly, record sources and do not publish classmates’ personal information without authority.

Frequently asked questions

Is a DMP only for large grants?

Requirements vary. Some institutions or funders require a DMP for defined projects, while smaller projects still benefit from lifecycle planning. Check the live rule.

Is cloud storage automatically approved?

No. Use institution-approved systems and match them to the data classification, contracts, ethics approval and applicable privacy requirements.

Can I promise to anonymise data?

Only if the planned process and residual re-identification risk justify that claim. Pseudonymised or coded data may still be personal or sensitive.

Must all research data be open?

No. Sharing may be limited by consent, confidentiality, law, security, contracts, intellectual property or ethical risk. Explain justified restrictions and possible controlled access.

When should the DMP be updated?

Review it when methods, data classes, systems, collaborators, agreements, risks or sharing plans change, and before project close.

Does a DMP replace ethics approval?

No. It should align with the approved protocol and other requirements, but it does not grant ethical, legal, security or contractual permission.

Useful next reading and primary sources

These current primary sources were checked on 8 November 2026. The live institution, journal, employer or authorised case record controls a real decision.

Continue through eduKate

A strong DMP makes responsible research easier to carry out

The document is valuable when it changes real behaviour: files go to the right system, access is reviewed, transformations are recorded, restrictions are understood and final materials remain verifiable.

English matters because research data move through people, systems and time. Precise language connects each file to a responsibility, each risk to a control and each promise to a feasible action.