Data Management Plan Example in Research

STANDARD OPERATING PROCEDURE: RESEARCH DATA MANAGEMENT PLAN (RDMP) LIFECYCLE EXECUTION

Document ID: SOP-TR-RDMP-2024-V1
Effective Date: October 24, 2024
Version: 1.0.0
Review Cadence: Annual / Post-Project Audit
Author: Julian Vance, Chief Architect, Template Registry

---

1. EXECUTIVE SUMMARY & PURPOSE

This Standard Operating Procedure (SOP) defines the institutional requirements for authoring, executing, auditing, and archiving a Research Data Management Plan (RDMP) within Template Registry. The purpose of this document is to ensure end-to-end data integrity, reproducibility, security compliance, and adherence to FAIR (Findable, Accessible, Interoperable, Reusable) data principles across all quantitative and qualitative research pipelines.

---

2. SCOPE & PREREQUISITES

2.1 Scope

This SOP applies to all research personnel, principal investigators (PIs), data engineers, and systems administrators handling data assets under Template Registry governance.

2.2 Prerequisites & Toolchain

• Version Control: Git (Enterprise GitHub instance)
• Data Storage Infrastructure: AWS S3 (Cold/Warm tiers) / Secure On-Premises SAN
• Metadata Standard: Dublin Core / DDI-Lifecycle
• Access Control: Role-Based Access Control (RBAC) via Okta/Active Directory
• Documentation Platform: Template Registry Core Markdown Engine

---

3. ROLES & RESPONSIBILITIES

The following RACI matrix outlines institutional accountability for the RDMP lifecycle:

---

4. STEP-BY-STEP PROCEDURE

Phase 1: Pre-Acquisition & Plan Initialization

• 1.1 Initialize a new RDMP repository from the standard institutional template (TR-RDMP-CORE-v1.0).
• 1.2 Define data classification levels (Public, Internal, Confidential, Restricted) based on institutional data governance policies.
• 1.3 Identify all external data dependencies, licensing constraints, and third-party usage agreements.

Phase 2: Active Data Collection & Ingestion

• 2.1 Establish secure ingress pipelines utilizing TLS 1.3 for data transfer into designated staging buckets.
• 2.2 Enforce immutable logging for all data ingestion events, capturing checksums (SHA-256) at the point of origin.
• 2.3 Populate the project metadata schema repository with variable definitions, collection methodologies, and instrumentation details.

Phase 3: Processing, Quality Assurance, & Versioning

• 3.1 Execute automated data cleaning scripts within containerized environments (Docker/Kubernetes).
• 3.2 Commit all transformation code and pipeline configurations to the version-controlled repository.
• 3.3 Perform anomaly detection sweeps and document data cleaning anomalies in the master quality log.

Phase 4: Archival, Preservation, and FAIR Compliance

• 4.1 Migrate processed datasets from active working storage to long-term immutable storage (WORM - Write Once, Read Many).
• 4.2 Mint persistent identifiers (e.g., DOI, ARK) for the dataset release package.
• 4.3 Publish machine-readable metadata records to the institutional data catalog to guarantee discoverability.

---

5. QUALITY ASSURANCE & PRO-TIPS

5.1 Best Practices

• Early Integration: Draft the RDMP prior to grant submission or project kick-off to prevent structural data siloing.
• Automated Validation: Implement CI/CD pipelines to validate metadata schema compliance automatically upon pull request submission.

5.2 Common Pitfalls

• Ignoring Data Decay: Relying on undocumented proprietary formats without exporting to open, non-proprietary equivalents (e.g., CSV, Parquet, JSON).
• Insufficient Granularity: Failing to map individual variables to standardized ontologies, reducing downstream interoperability.

5.3 Metric Thresholds

• Metadata Completeness Score: Must exceed 98% conformance against the DDI-Lifecycle standard prior to archival sign-off.
• Data Integrity Verification: 100% hash-match validation required between ingestion and staging milestones.

---

6. FREQUENTLY ASKED QUESTIONS

Q1: What should be done if sensitive personal data (PII) is inadvertently ingested into an open-tier storage bucket?
A: Immediately isolate the storage tier by revoking access control lists (ACLs). Notify the Compliance & Security Officer within 1 hour, initiate the institutional data sanitization protocol (SOP-SEC-04), and document the incident in the security log.

Q2: How are large-scale binary datasets (>10TB) handled within the version control framework?
A: Binary assets must never be committed directly to Git. Use Git LFS (Large File Storage) pointers or reference the immutable object storage URI directly within the metadata configuration file.