Here is a Data Protection Impact Assessment (DPIA) Template specifically tailored for High-Performance Computing (HPC) environments.

Standard DPIA forms often confuse researchers with generic questions. This template translates compliance requirements into specific technical questions about jobs, schedulers, and storage subsystems.

DPIA Template: HPC & Research Workloads

Purpose: To identify and mitigate risks associated with processing sensitive data (GDPR, HIPAA, FERPA, CUI) on the [Organization Name] HPC Cluster.

Status: [Draft / Under Review / Approved]

1. Project Metadata & Classification

Project Title: ___________________
Principal Investigator (PI): ___________________
Technical Lead/Point of Contact: ___________________
Data Sensitivity Level:

[ ] Public: Open data, no restrictions.
[ ] Internal: Proprietary but not regulated.
[ ] Confidential/Regulated: (Check all that apply)

[ ] GDPR (Personal Data from EU)
[ ] HIPAA (Health Information)
[ ] FERPA (Student Records)
[ ] CUI/ITAR (Export Controlled)

2. Data Flow & Lifecycle

A. Ingest & Transfer

How will data enter the cluster?

[ ] Standard SCP/SFTP
[ ] Globus High Assurance / GridFTP
[ ] Physical Media (Hard Drive sneakernet)
[ ] Direct streaming from instrument (e.g., Sequencer, Microscope)

Checkpoint: Direct internet downloads (wget/curl) to the Secure Enclave are typically blocked. Describe your required ingest path:

___________________________________________________________________

B. Storage Locations

Where will the source data reside?

[ ] Project Home Directory (Backed up, lower speed)
[ ] High-Performance Scratch (Lustre/GPFS - Not Backed Up, Auto-purged)
[ ] Archive / Tape Storage

Where will output/results be written?

___________________________________________________________________

C. Temporary Data Handling (Crucial for HPC)

Does your code/application write temporary files to local disk (/tmp, /var/tmp, /dev/shm) on compute nodes?

[ ] Yes
[ ] No / Unsure

If Yes: How does the application handle cleanup? (Note: The scheduler Epilog script can be configured to force-wipe these locations if required).

3. Compute & Access Isolation

A. Access Control

List all specific users (NetIDs) who need access to this dataset:

___________________________________________________________________

Do non-project members need "read-only" access for verification?

[ ] Yes (Requires separate ACL group)
[ ] No

B. Job Execution & Node Sharing

Exclusive Mode: Does this workload require a full node (preventing other users from sharing the CPU/RAM)?

[ ] Yes (Required for side-channel protection in high-risk HIPAA/ITAR jobs)
[ ] No (Shared node is acceptable)

Containerization: Will you be using containers?

[ ] No, running bare binary.
[ ] Yes, Apptainer (Singularity).
[ ] Yes, Docker ( Note: Generally prohibited due to root daemon risks ).

4. Risk Assessment & Mitigation

Risk Scenario	Likelihood (L/M/H)	Impact (L/M/H)	Proposed Mitigation
Data Remanence: Residual data left on scratch disk after job failure.	Medium	High	Example: Automated Epilog script wipes scratch; User agrees to manual cleanup of project directory.
Privilege Escalation: User breaks out of container.	Low	High	Example: Use Apptainer in non-suid mode; Kernel patches up to date.
Unauthorized Export: Researcher accidentally moves sensitive data to a public folder.	Medium	High	Example: ACLs prevent writing to public folders; Outbound internet blocked on Secure Partition.