Data Management Plan Phd Example

Standard Operating Procedure: Research Data Management Plan (DMP) Architecture for Doctoral Candidates

---

1. Executive Summary & Purpose

This Standard Operating Procedure (SOP) defines the operational, technical, and governance requirements for designing, implementing, and maintaining a Data Management Plan (DMP) for doctoral (PhD) research. The purpose of this document is to ensure end-to-end data integrity, reproducibility, security, and long-term institutional archiving in compliance with funding agency mandates (e.g., NSF, NIH, UKRI) and university data policies. Failure to adhere to this protocol introduces catastrophic risks of data loss, non-reproducibility, and non-compliance.

---

2. Scope & Prerequisites

2.1 Scope

This SOP applies to all doctoral candidates operating under Template Registry oversight, spanning quantitative, qualitative, and mixed-methods computational and empirical research.

2.2 Prerequisites & Toolchain

• Version Control: Git (Core) paired with GitHub Enterprise or GitLab.
• Compute Environments: Python 3.10+, R 4.2+, or equivalent containerized runtimes (Docker).
• Storage Infrastructure: Institutional Tier-1 secure storage (e.g., encrypted NAS, AWS S3 Institutional Buckets with object locking).
• Metadata Standards: Dublin Core, DDI (Data Documentation Initiative), or schema.org dependent on domain.

---

3. Roles & Responsibilities

---

4. Step-by-Step Procedure

Phase 1: Data Collection & Architecture Planning

• 1.1 Classify data sensitivity (Public, Internal, Confidential, Restricted/PII) in alignment with institutional IRB/ethics board approvals.
• 1.2 Define file-naming conventions using an immutable schema: YYYYMMDD_[ProjectID]_[DatasetID]_[Version].[ext].
• 1.3 Establish the directory structure locally and remotely using the Template Registry Research Standard (e.g., /data/raw, /data/processed, /scripts, /docs, /outputs).

Phase 2: Version Control & Storage Infrastructure Setup

• 2.1 Initialize a local Git repository and link to a private remote repository on the institutional GitLab/GitHub server.
• 2.2 Configure .gitignore to strictly exclude raw data files containing PII, large binary files (>100MB), and local environment secrets (.env, credentials).
• 2.3 Provision primary storage on the institutional secure cloud tier, ensuring AES-256 encryption at rest and TLS 1.3 in transit.

Phase 3: Active Data Processing & Documentation

• 3.1 Implement automated data ingestion pipelines using deterministic scripts (Python/R) to eliminate manual transformation errors.
• 3.2 Update the README.md and metadata codebooks synchronously with every schema change or data cleaning iteration.
• 3.3 Execute the 3-2-1 backup rule daily: 3 total copies of data, across 2 different media types, with 1 copy stored off-site (cloud/institutional backup).

Phase 4: Archiving, Preservation, & Publication

• 4.1 Freeze the dataset upon dissertation defense submission, generating a final immutable release tag in Git (v1.0.0-final).
• 4.2 Deposit finalized, anonymized data packages into an approved institutional or disciplinary repository (e.g., Zenodo, Figshare, Dryad) to secure a persistent DOI.
• 4.3 Retain all raw data, code, and documentation in the institutional archive for the mandated retention period (typically 5–10 years post-graduation).

---

5. Quality Assurance & Pro-Tips

Best Practices

• Treat Data as Code: Apply software engineering best practices to data generation. If a dataset cannot be programmatically recreated from raw sources using documented scripts, the pipeline is non-compliant.
• Automate Checksums: Generate SHA-256 checksums (sha256sum) for all raw datasets immediately upon download or capture to verify bit-rot and transmission integrity over time.

Common Pitfalls

• The "Local Drive" Trap: Storing active data exclusively on a local laptop hard drive without cloud sync or version control. Hard drive failure will halt research progression.
• Undocumented Variables: Failing to maintain a live data dictionary, rendering qualitative codes or column headers opaque to future reviewers and external examiners.

Metric Thresholds

• Backup Latency: RPO (Recovery Point Objective) must not exceed 24 hours.
• Recovery Time: RTO (Recovery Time Objective) for restoring a corrupted pipeline environment from source control must not exceed 4 hours.

---

6. Frequently Asked Questions

Q1: What should I do if my dataset contains un-anonymized Protected Health Information (PHI) or Personally Identifiable Information (PII)?

A: PII/PHI must never be committed to public or standard cloud repositories. It must reside strictly in an IRB-approved, air-gapped or fully encrypted institutional secure enclave. Apply cryptographic hashing or tokenization for identifiers during analysis phases.

Q2: How do I manage datasets that exceed standard Git file-size limits (e.g., >100MB raw files)?

A: Do not track large binaries via standard Git. Implement Git Large File Storage (Git LFS) or store raw data files in an immutable, versioned object storage bucket (e.g., AWS S3 with versioning enabled) while referencing the object URI within your documentation scripts.