Research Data Security

What makes this chapter different from everything else in the book: the clocks are statutory. Most security work runs on a cadence you choose. Here, some deadlines are measured in hours and set by law.

The clocks you're already on¶

Every other chapter here describes work you schedule. This one describes deadlines that schedule you.

Two things follow, and they're the reason this is an operations chapter rather than an architecture one.

"Aware" is earlier than you think. The GDPR clock starts on awareness of a likely breach, not on completion of your investigation. A weekend spent confirming severity is a weekend of the 72 hours. Plan to notify on partial information, because that is what the deadline actually contemplates.

You cannot design your way out of a deadline. Perfect tiering and flawless anonymization don't help at hour 40. What helps is knowing, immediately, whose data it was, how many people, which categories, and who at your institution needs to be told. That's inventory and rehearsal — both runtime work.

Classification decides which clocks apply¶

Classification isn't paperwork. It's the lookup that tells you which of the above deadlines you're subject to, which is why getting it wrong is expensive in a very specific way.

HIPAA (health data), FERPA (student records), GDPR (EU personal data — including EU subjects in a US study), IRB protocols, and export controls each attach their own obligations. If you're unsure what applies, ask. Your institution has compliance officers for exactly this, and asking early is free.

The failure mode worth naming: data that was correctly classified at collection and then quietly changed class. A dataset gets joined with another and becomes re-identifiable. An "anonymized" extract turns out to be unique on three columns. Nothing was reclassified because reclassification isn't an event anyone is watching for.

What are you holding right now?¶

The question that's hard to answer and shouldn't be.

Research environments accumulate data the way attics accumulate boxes. A study ends and the extract stays on the share. A grad student graduates and their scratch directory persists for six years. A collaborator sends a "quick sample" that turns out to be full PHI, over email, once, in 2021.

Every one of those is live liability with a live clock, and none of them are in anyone's notes.

That last row is the one that surprises people. Deleting data from a live system does not delete it from your backups. If you have a GDPR erasure obligation or a protocol-mandated destruction date, you need an answer for backup media, and "our retention is 90 days so it ages out" is an answer — but only if you've verified it and can say so.

Access control: granting is a gate, reviewing is a monitor¶

Provisioning access is a one-time decision. Whether that decision is still correct is a continuous one, and access is the control that decays fastest in research environments because the population turns over constantly.

Least privilege, as a starting layout:

CREATE ROLE analyst;
GRANT SELECT ON analysis_schema.* TO analyst;
GRANT analyst TO researcher@university.edu;

Use column-level security to keep identifiers away from analysis data, and row-level security where researchers should only see their own study's rows.

Then recertify on a schedule. Quarterly for restricted data:

• List everyone with access, from the system — not from your records
• Confirm each still needs it, with the PI or data steward
• Remove everyone who left, finished, or moved projects
• Check service accounts and API tokens, not just humans
• Record who reviewed it and when

The gap between "who we think has access" and "who has access" is where this goes wrong, and it only ever widens. Reading the list from the system is the entire trick.

Audit trails: collect, and then actually read them¶

You need to know who accessed what, when, and why.

Log: access events, data exports, schema changes, permission changes, and authentication events (especially failures).

{
  "timestamp": "2026-01-15T10:30:00Z",
  "user": "researcher@university.edu",
  "action": "query",
  "resource": "patient_records",
  "row_count": 150,
  "columns_accessed": ["diagnosis", "treatment", "outcome"],
  "ip_address": "192.168.1.50"
}

Never log the data itself. Log that a query returned 150 rows, not the 150 rows. An audit log containing PHI is a second copy of your most sensitive data, in a system with weaker controls and wider access — you've built a breach, not a control.

Protect integrity with append-only storage and permissions separate from the production system, and retain per your regulatory requirement, commonly 6 months to 7 years.

Database-side, pgAudit for PostgreSQL is the mature option; MySQL's general log is a blunt instrument and belongs behind a proxy for real use.

When data walks¶

1. Preserve first. Do not delete, re-image, or "clean up." You need logs, access records, and the system state to answer how many people and which data categories — the two facts every notification requires.
2. Notify internally, immediately. Privacy officer, IRB, counsel. The 72-hour clock is already running and it is not yours to manage.
3. Scope with the audit trail. Which records, which subjects, which categories, over what window. This is the moment the logging pays for itself or doesn't.
4. Contain. Revoke access, rotate credentials, close the path. See Secrets Management for the rotation order.
5. Do not decide the notification question yourself. Whether it's reportable is a legal determination. Your job is complete, fast, accurate facts.
6. Write it down as you go. You will be asked to reconstruct a timeline, possibly by a regulator, and memory will not survive the week.

A note on the honest version: the pressure to under-report is real, and it usually arrives as a suggestion that you're not certain yet. Uncertainty is what the deadline is designed for. Report it and let the people whose job it is decide.

Notebooks and interactive compute¶

Research runs on notebooks, and notebooks leak in ways ordinary applications don't.

• Outputs are saved. A dataframe head with real identifiers is now in the .ipynb, in git, and in whatever you emailed. jupyter nbconvert --clear-output --inplace before sharing, and enforce it with a pre-commit hook rather than discipline.
• Kernels outlive attention. A kernel holding restricted data in memory sits on a shared host indefinitely. Set idle culling on JupyterHub.
• Home directories are the real datastore. Whatever your architecture says, restricted data ends up in ~/scratch. Assume it and scan for it rather than assuming policy prevented it.
• Shared JupyterHub is multi-tenant. Per-user isolation, resource limits, no shared scratch for restricted data.

Quick Reference¶

Know before you need it¶

• Privacy officer, IRB, and counsel contacts — including out-of-hours
• Inventory of restricted datasets, including copies and backups
• Retention and deletion date for each
• Which regulation applies to which dataset
• Current access list, read from the system

Recurring¶

If it walks¶

1. Preserve — don't clean up
2. Notify internally now — the clock started on awareness
3. Scope from the audit trail: how many people, which categories
4. Contain and rotate
5. Let counsel decide reportability
6. Document as you go