This guide gives research administrators a worked, section-by-section outline for a data breach response plan covering research data specifically — the document an institution adapts to its own governance structure, legal counsel review, and IT security policies, not a plan to publish as-is. The structure below reflects the stages and notification lines described in CASRAI’s Data Breach Response Plan entry; this guide focuses on turning that conceptual structure into a document outline and a sample incident-log format a research office, IRB, or data governance committee can actually work from.
Illustrative composite — not a real institution’s plan. The section headings, severity tiers, roles, and sample log entries below are a synthesized composite pattern, not copied from or attributed to any specific university, hospital, or funder. No institution name, date, or figure in this guide refers to a real incident. Use it as a starting structure and have institutional counsel, IT security, and the IRB review and adapt every section before adoption.
Before drafting: confirm this is a research-data-specific plan, not a copy of the general IT plan
As explained in CASRAI’s Data Breach Response Plan entry, a general enterprise incident response plan — the kind required by ISO/IEC 27001:2022 Annex A controls A.5.24–A.5.28 — is a necessary foundation but does not by itself name the research-specific audiences a breach involving research data may need to reach: an IRB, a repository’s Data Access Committee, an export control office, or a funding agency under a mandatory-disclosure rule. This template is written as an annex or standalone plan that sits alongside, and cross-references, an institution’s general IT incident response plan rather than replacing it.
1. Purpose, scope, and ownership
State plainly what data and systems the plan covers (research data specifically — human-subjects data, controlled-access repository data, export-controlled technical data, data governed by a signed Data Use Agreement) and who owns it. A workable ownership model names a single accountable role — commonly the institution’s Chief Information Security Officer jointly with the research integrity or research data office — plus named contacts for the IRB, export control office, and sponsored-programs office who must be looped in once triage identifies their obligation applies.
2. Detection and internal reporting chain
List every channel an incident can enter through, and route all of them to one intake point rather than leaving discovery-to-report as an informal, ad hoc step:
- A researcher or staff member’s own observation (lost device, misdirected email, accidental public sharing of a restricted dataset)
- An automated security alert from IT (unusual access pattern, failed login spike, data-loss-prevention trigger)
- A help desk ticket or phishing report
- A collaborator, repository, or sponsor flagging unauthorized access on their end
Every channel should route to a single reporting mechanism — a dedicated email alias or ticketing category monitored by IT security — with a stated internal reporting deadline (commonly same-business-day or within 24 hours of discovery) so the regulatory notification clocks described in Section 5 start running from a documented point, not an undocumented one.
3. Initial triage and severity classification
A short triage step, ideally completed within hours of intake, sorts the report before full investigation begins. A simple three-tier classification keeps this fast:
- Tier 1 — Confirmed or likely exposure of regulated/restricted research data. Unsecured PHI, controlled-access repository data, export-controlled technical data, or DUA-governed data with no confirmed encryption or de-identification. Escalate immediately to the full response team.
- Tier 2 — Possible exposure, classification unresolved. The data type or de-identification status is not yet confirmed. Proceed directly to Section 5’s assessment step before deciding an external notification obligation exists.
- Tier 3 — No research data involved, or data was properly de-identified/encrypted. Handle under the general IT incident response process; log for internal recordkeeping.
4. Containment
Immediate technical steps to stop ongoing exposure, executed in parallel with triage rather than after it:
- Revoke or reset compromised credentials
- Isolate the affected system, device, or storage location from the network
- Suspend any active data-sharing feed, API connection, or shared-drive link involved
- Preserve evidence before remediation destroys it — system logs, access records, the original affected files — mirroring the evidence-collection discipline in ISO 27001 Annex A.5.28
5. Impact assessment and regulatory/contractual triage
This is the step that most distinguishes a research-data plan from a general IT one: determining which regulatory or contractual regime, if any, the affected data falls under before deciding what notification is owed. Work through these questions in order and document the answer to each:
- Was the data properly de-identified or encrypted? If yes under HIPAA’s Safe Harbor or Expert Determination standard, the data is not PHI and the HIPAA Breach Notification Rule does not apply — but check whether a specific Data Use Agreement defines “breach” more broadly than HIPAA does before concluding no obligation exists.
- Is the data unsecured PHI held by a covered entity or business associate? If yes, the HIPAA Breach Notification Rule (45 CFR Part 164, Subpart D) applies — see Section 6.
- Was the data obtained under a controlled-access repository’s data use certification (e.g., NIH dbGaP) or a bilateral Data Use Agreement? If yes, check that agreement’s own breach-notification clause independently — repository and DUA clocks are frequently shorter than any statutory deadline and run regardless of whether HIPAA applies.
- Does the data involve identifiable human subjects? If yes, assess whether this is a reportable unanticipated problem under the institution’s Federalwide Assurance and IRB procedures (codified for FDA-regulated research at 21 CFR §56.108(b)).
- Is the data export-controlled (EAR/ITAR) or otherwise research-security-sensitive? If yes, route to the export control office to evaluate a possible voluntary self-disclosure. See CASRAI’s Export Control (EAR/ITAR) and International Research Collaboration guide.
- Does the incident involve credible evidence of fraud, bribery, or a related federal crime, or a possible False Claims Act violation, connected to a federal award? If yes, the mandatory-disclosure rule at 2 CFR §200.113 applies independently of any breach-notification statute — route to sponsored programs and institutional counsel.
Document the answer to each question with a timestamp; several of the deadlines in Section 6 run from the discovery date, not from the date the triage step is completed, so a documented assessment trail matters if a deadline is later questioned.
6. Notification obligations, audiences, and timelines
Once Section 5 identifies which obligations apply, this table format keeps the response team from missing a shorter, less obvious clock in favor of a longer, more familiar one. See CASRAI’s Data Breach Response Plan entry for the full regulatory detail behind each row.
| Audience | Trigger | Typical deadline | Owner |
|---|---|---|---|
| Affected individuals | Unsecured PHI breach (HIPAA) | No later than 60 calendar days after discovery (45 CFR §164.404) | Privacy officer / covered entity |
| HHS Secretary | PHI breach affecting 500+ individuals: contemporaneous with individual notice; under 500: annual log (45 CFR §164.408) | 60 days (500+) / annually (under 500) | Privacy officer |
| Media (affected jurisdiction) | PHI breach affecting 500+ residents of one state/jurisdiction (45 CFR §164.406) | 60 days | Privacy officer / institutional communications |
| Repository Data Access Committee (e.g., NIH dbGaP) | Breach of data security or inadvertent release of controlled-access data | Commonly 24 hours to first notice, detailed written report within a few business days — confirm against the specific data use certification | PI / research data office |
| Data Use Agreement counterparty | Breach as defined by the specific bilateral DUA | Per the DUA’s own terms — do not assume it matches HIPAA’s clock | Sponsored programs / PI |
| IRB | Unanticipated problem involving risk to human subjects (21 CFR §56.108(b) for FDA-regulated research) | Per the institution’s written IRB procedures, typically prompt/within days | PI / research integrity office |
| Export control office | Possible unauthorized disclosure of EAR/ITAR-controlled technical data | Internal escalation immediate; external self-disclosure timing is a compliance-program decision | Export control officer |
| Federal awarding agency / agency OIG | Credible evidence of fraud, bribery, or related federal crime connected to the award (2 CFR §200.113) | Promptly, in writing | Sponsored programs / institutional counsel |
7. Remediation, documentation, and after-action review
Close the loop on every incident with three deliverables, not just the notifications above:
- Corrective action record — what was changed technically or procedurally to prevent recurrence
- Evidence preservation — retained per the institution’s records-retention schedule and any specific repository or DUA requirement to preserve documentation
- Written after-action report — several of the notification regimes above (dbGaP’s DAC report, for example) require a written report as a distinct deliverable from the initial notice itself; keep the two on separate tracked deadlines
8. Sample incident log format
A single running log, populated from the moment of intake through closure, is what lets a research office demonstrate it met every applicable deadline above. The row below is an illustrative composite entry showing the fields such a log should carry — not a real incident.
| Field | Example entry (illustrative) |
|---|---|
| Log ID | DBRP-2026-014 |
| Date/time reported | 2026-03-04, 09:15 (intake email) |
| Reported by | Research coordinator, [department] |
| Data type involved | PHI extract, active IRB-approved clinical study; unencrypted laptop |
| Initial tier | Tier 1 — confirmed regulated-data exposure |
| Containment action & time | Remote wipe initiated 09:40; VPN credentials reset 09:45 |
| Triage outcome (Section 5) | Unsecured PHI, covered entity; not de-identified; no export-control or DUA dimension |
| Notifications required & sent | IRB notified 2026-03-05 (unanticipated problem); privacy officer opened HIPAA 60-day clock 2026-03-04 |
| Written report(s) filed | After-action report filed 2026-03-18 |
| Status / closure date | Closed 2026-04-02 |
9. Roles and responsibilities
- IT security / CISO office — intake, containment, evidence preservation, ISO 27001-aligned incident management
- Research data office / research integrity office — Section 5 triage, coordination across research-specific notification lines
- Privacy officer — HIPAA determination and notification if PHI is involved
- IRB — unanticipated-problem determination for human-subjects data
- Sponsored programs / research administration — funder and DUA notification, 2 CFR §200.113 mandatory disclosure screening
- Export control office — EAR/ITAR self-disclosure evaluation
- Institutional counsel — review of every external notification before it is sent
Frequently asked questions
Is this template ready to adopt as-is?
No. It is an illustrative composite structure meant to be adapted — every severity tier, deadline, and role should be reviewed against the institution’s actual policies, applicable state law, and specific funder/repository agreements, and approved by institutional counsel and IT security before use.
Does every incident require notifying all of the audiences in Section 6?
No. Section 5’s triage step determines which obligations actually apply to a given incident; most incidents trigger only one or two of the rows in the Section 6 table, not all of them.
How is this different from the Data Breach Response Plan dictionary entry?
CASRAI’s Data Breach Response Plan entry defines the concept and the regulatory obligations behind it in depth. This guide turns that conceptual structure into a document outline and a sample incident-log format a research office can work from directly.
Who should own this plan at an institution?
Most research-intensive institutions assign joint ownership to IT security and the research data or research integrity office, with named points of contact for the IRB, export control, and sponsored programs who are looped in once triage identifies their specific obligation applies.
Related CASRAI resources
- Data Breach Response Plan — the conceptual definition and full regulatory detail behind this template
- ISO 27001 for Research Data Security — the general ISMS incident-management foundation this template extends
- Data Use Agreement (DUA)
- HIPAA Privacy Rule
- HIPAA in Clinical Research
- Export Control (EAR/ITAR) and International Research Collaboration
- Research Data Management — cluster hub
References
- 45 CFR Part 164, Subpart D — HIPAA Breach Notification Rule
- ISO/IEC 27001:2022, Annex A — Organizational controls A.5.24–A.5.28
- NIH dbGaP Data Use Certification Agreement — Data Access Committee breach/incident notification terms
- 2 CFR §200.113 — Mandatory disclosures (Uniform Guidance)
- 21 CFR §56.108(b) — IRB written procedures for prompt reporting of unanticipated problems
