Data Breach Response Plan

A data breach response plan for research data is a documented, pre-established procedure specifying how an institution or research team will detect, contain, assess, and report a security incident involving research data — particularly data subject to a specific regulatory, contractual, or funder obligation, such as HIPAA-covered protected health information (PHI), export-controlled technical data, or data governed by a signed Data Use Agreement (DUA). It differs from a general enterprise IT incident response plan in one specific way: it names, in advance, which additional parties — an IRB, a funding agency, a data repository’s Data Access Committee, an export control office — must also be notified, on what timeline, and under whose authority, on top of whatever an institution’s central IT security office already does for any security incident.

What makes a plan a “data breach response plan” for research data specifically

Every organization with an information security program has some form of incident response capability — ISO/IEC 27001:2022, the general-purpose information security management system (ISMS) standard research institutions and their vendors increasingly hold or are asked to hold, requires exactly this under its Annex A organizational controls: A.5.24 (incident management planning and preparation), A.5.25 (assessment and decision on information security events), A.5.26 (response to incidents), A.5.27 (learning from incidents), and A.5.28 (collection of evidence). A generic ISO 27001-aligned incident response plan satisfies those five controls for information security generally — but it does not, by itself, satisfy the research-specific reporting obligations described below. A data breach response plan for research data is not a separate technology or a competing standard; it is the same ISMS incident-management discipline extended with a decision tree that routes a given incident to the right external notification obligations based on what kind of data and which sponsor, repository, or oversight body is actually attached to it.

Core components

Most institutional data breach response plans for research data cover four stages, regardless of which specific regulation ultimately applies to a given incident:

• Detection and containment. How a suspected incident is identified and reported internally (a helpdesk ticket, an automated alert, a researcher’s own observation that a laptop or drive was lost), and the immediate technical steps to stop ongoing exposure — revoking credentials, isolating a system, suspending a data-sharing feed.
• Impact and risk assessment. Determining what data was actually involved, whether it was encrypted or otherwise rendered unusable, how many individuals or records are affected, and — the step that most distinguishes a research-data plan from a general IT one — which regulatory or contractual regime the affected data falls under. The same underlying incident (a misconfigured cloud storage bucket, for example) can trigger no external notification duty at all if the exposed data was properly de-identified, or a strict 60-day statutory deadline if it was unsecured PHI, or a repository-specific 24-hour notice if it was NIH controlled-access genomic data — and a plan that does not build this triage step in explicitly will default to the slowest or narrowest track and risk missing a shorter one.
• Notification. Who must be told, in what order, and by when — internal leadership and legal counsel, affected individuals, a regulator, a funding agency, a data repository, an IRB, an export control office, and, for large enough incidents, the media. See the next section for the specific obligations that most commonly apply to research data.
• Remediation and documentation. Corrective action, evidence preservation (mirroring ISO 27001 Annex A.5.28), and a written after-action record — several of the reporting regimes below require the written report itself, not just the notification, as a distinct deliverable.

Notification obligations: why the timeline and audience change by data type

A generic enterprise incident response plan typically ends its notification step at “inform affected individuals and, if required, a state attorney general or regulator.” A research data breach response plan has to route to a wider, more specific set of audiences:

• HIPAA-covered PHI. If the exposed data is unsecured protected health information held by a covered entity or business associate, the HIPAA Breach Notification Rule (45 CFR Part 164, Subpart D) applies: notice to affected individuals is required without unreasonable delay and no later than 60 calendar days after discovery (45 CFR §164.404); notice to the HHS Secretary is required contemporaneously with individual notice for breaches affecting 500 or more people, or via an annual log for smaller breaches (45 CFR §164.408); and for breaches affecting more than 500 residents of a single state or jurisdiction, notice to prominent local media is also required, on the same 60-day clock (45 CFR §164.406). Data that meets HIPAA’s Safe Harbor or Expert Determination de-identification standard falls outside PHI entirely, and outside this notification duty as a result — which is why the impact-assessment step above has to determine de-identification status before the notification clock can even be set. See CASRAI’s HIPAA Privacy Rule and HIPAA in Clinical Research entries for how PHI enters a research project in the first place.
• Controlled-access data repositories. Funder- and repository-level data use agreements frequently impose their own, shorter reporting clocks that run independently of any statutory deadline. NIH’s dbGaP Data Use Certification Agreement, for example, requires the requesting investigator to notify the relevant Data Access Committee of any breach of data security or inadvertent data release within 24 hours of identifying the incident, followed by a detailed written report — covering the nature of the event, remediation actions, and prevention plans — within a few business days. A plan built only around HIPAA’s 60-day clock will structurally miss a repository obligation this much shorter.
• Data Use Agreement-specific terms. Where research data was obtained under a bilateral Data Use Agreement rather than a public repository’s standard terms, the DUA itself is often the actual source of the breach-notification obligation — institutions should treat “what does this specific DUA require on breach” as a standing item in the impact-assessment step, not assume a house-standard timeline applies.
• IRB / human-subjects reporting. A breach involving identifiable human-subjects data can separately trigger an obligation to report the incident to the IRB as an unanticipated problem involving risks to subjects — a duty that exists under an institution’s Federalwide Assurance and the IRB’s own written procedures, and that is codified directly for FDA-regulated research at 21 CFR §56.108(b). This reporting line runs to the IRB and institutional officials, not to a security team, and is easy for an IT-only incident response plan to miss entirely.
• Export-controlled and research-security data. A breach or unauthorized disclosure involving export-controlled technical data (EAR- or ITAR-controlled) or other research-security-sensitive material raises a separate question — whether the institution’s export control compliance program should evaluate a voluntary self-disclosure to the Bureau of Industry and Security or the State Department’s Directorate of Defense Trade Controls — that sits outside a standard data-breach notification process and needs its own named owner in the plan. See CASRAI’s Export Control (EAR/ITAR) and International Research Collaboration guide.
• Mandatory disclosure to the funding agency. Separately from any breach-specific notice above, if a research-data incident involves credible evidence of a violation of federal criminal law — fraud, bribery, or a related offense under Title 18, or a civil False Claims Act violation — in connection with a federal award, the recipient institution has an independent mandatory-disclosure obligation to the awarding agency and its Office of Inspector General under 2 CFR §200.113. This applies to a narrower set of incidents than a routine data breach, but a plan should flag it as a possibility the impact-assessment step needs to screen for, not assume every breach is purely a security matter.

Why this needs to be a distinct plan, not just the enterprise IT plan

Institutional IT security teams reasonably build incident response around the obligations they encounter most often — typically state breach-notification statutes and, where applicable, HIPAA. A plan written from that vantage point alone will miss the research-specific reporting lines above almost by construction, because none of them are visible from a general IT security office’s normal caseload: repository Data Access Committees, IRBs, export control offices, and federal award terms are not audiences a hospital’s or bank’s incident response plan would ever need to route to. Building a research-data-specific annex or standalone plan — owned jointly by the research office, IRB, export control office, and IT security — is what closes that gap, and is the reason research-intensive institutions maintain one distinct from, though coordinated with, their general enterprise incident response plan.

Worked examples

PHI exposure with a clear notification path. A research coordinator’s laptop, containing an unencrypted extract of PHI for an active clinical study, is stolen. Because the data was PHI, unsecured, and held by a covered entity, the HIPAA Breach Notification Rule’s 60-day clock to individuals and HHS starts running from discovery, and the institution’s IRB also needs notice as an unanticipated problem — a properly scoped research data breach response plan routes both notifications in parallel rather than sequentially, once the assessment step confirms the data was PHI and identifiable.

Controlled-access genomic data, no HIPAA trigger. A postdoctoral researcher inadvertently shares a dbGaP-derived, controlled-access genomic dataset with a collaborator who was never approved by the study’s Data Access Committee. The data was not PHI held by a covered entity, so HIPAA’s Breach Notification Rule does not apply — but the dbGaP Data Use Certification Agreement’s own 24-hour DAC-notification requirement does, on a much shorter clock than any statutory deadline in play. A plan tuned only to HIPAA would miss this obligation entirely.

Not a data breach response plan for research data

A university’s standard enterprise incident response plan — covering, say, a phishing compromise of a staff member’s email account that never touched any research dataset, PHI, export-controlled material, or DUA-governed data — is a legitimate, ISO 27001-aligned incident response plan, but it is not a data breach response plan for research data specifically, because there is no research data in scope and none of the research-specific notification lines above are triggered. The distinction matters operationally: an institution should not assume its general IT incident response plan already covers a research-data incident just because both are “incident response” in a broad sense.

Frequently asked questions

How long do you have to report a HIPAA breach involving research data?

Generally no later than 60 calendar days after discovery for both individual notice (45 CFR §164.404) and, for breaches affecting 500 or more people, notice to the HHS Secretary (45 CFR §164.408) and to the media (45 CFR §164.406). Smaller breaches (fewer than 500 affected) are logged and reported to HHS annually rather than individually within 60 days. These deadlines apply only when the data was unsecured PHI held by a covered entity or business associate.

Does a data breach involving research data have to be reported to the funder?

Not automatically, but often yes through more than one route: a controlled-access repository’s own data use agreement (dbGaP’s, for example) can impose a short, independent notification clock to its Data Access Committee; and separately, if the incident involves credible evidence of fraud or a related federal crime connected to the award, the mandatory-disclosure rule at 2 CFR §200.113 applies regardless of whether any breach-notification statute is also triggered. Check the specific award terms and any data use agreement rather than assuming one rule covers every case.

Is an IT department’s incident response plan enough, or does research data need its own plan?

A general IT incident response plan (the kind ISO/IEC 27001’s Annex A.5.24–A.5.28 controls require) is a necessary foundation but is not, by itself, sufficient for research data. It rarely names the IRB, a repository’s Data Access Committee, an export control office, or a specific funder’s mandatory-disclosure rule as required notification points, because those obligations are specific to research data and not part of a typical enterprise incident response caseload.

Does de-identifying research data eliminate breach-notification obligations?

For HIPAA specifically, yes: data that meets the Safe Harbor or Expert Determination de-identification standard is no longer PHI and falls outside the Breach Notification Rule. It does not necessarily eliminate obligations under a specific Data Use Agreement or repository data use certification, which can define “breach” more broadly than HIPAA does — the underlying agreement’s own text should be checked rather than assumed to track HIPAA’s definition.

Related CASRAI resources

• ISO 27001 for Research Data Security — the general ISMS standard whose Annex A incident-management controls underpin any research data breach response plan
• De-identification — how removing identifiers can take data outside HIPAA’s breach-notification scope entirely
• HIPAA Privacy Rule
• HIPAA in Clinical Research
• Data Use Agreement (DUA) — frequently the actual source of a repository- or partner-specific breach-notification clock
• Export Control (EAR/ITAR) and International Research Collaboration
• Research security — domain hub
• Research Data Management — cluster hub

References

• 45 CFR Part 164, Subpart D — HIPAA Breach Notification Rule (§164.404 notification to individuals, §164.406 notification to media, §164.408 notification to the Secretary)
• ISO/IEC 27001:2022, Annex A — Organizational controls A.5.24–A.5.28 (information security incident management)
• NIH Data Use Certification Agreement (dbGaP) — 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