Incident Response and Breach Notification

This is engineering guidance, not legal advice. Confirm specifics with qualified counsel.

Why this matters

A breach is not an "if" for a telemedicine product — it is a "when," and the difference between a controlled response and a regulatory disaster is whether you built the plan in advance. The largest healthcare breach on record, the 2024 Change Healthcare attack, was estimated in January 2025 to affect roughly 190 million people, and regulators now watch this space closely. This article is for founders, product managers, engineering leads, and compliance officers who need to understand the notification clock well enough to set up logging, contracts, and an on-call process that will hold up under an actual incident. Getting it wrong is expensive twice: once from the breach itself, and again from missing a deadline that turns a manageable event into an enforcement action.

Two different words: a security incident is not always a breach

The first thing to get right is vocabulary, because the law treats two similar-sounding events very differently and starts different clocks for each.

A security incident is the broad category. The HIPAA Security Rule defines it as the attempted or successful unauthorized access, use, disclosure, modification, or destruction of information, or interference with system operations (45 CFR §164.304). A failed login storm, a port scan, a phishing email someone reported and deleted — these are security incidents. Most never touch patient data and most are never reported to anyone outside your team.

A breach is the narrower, regulated event. Under the Breach Notification Rule, a breach is the acquisition, access, use, or disclosure of protected health information in a way the Privacy Rule does not permit, which compromises the security or privacy of that information (45 CFR §164.402). Protected health information — PHI — is any health detail tied to an identifiable person, the same definition we use throughout this section. A breach is the subset of security incidents that reaches PHI and clears the bar for compromise.

The relationship matters because your response branches here. Every security incident should trigger your internal runbook — investigate, contain, document. Only the subset that turns out to be a breach triggers the external notification clock. An analogy: a security incident is any time the building alarm goes off; a breach is the subset where someone actually got inside and took something. You respond to every alarm, but you only file a police report for the break-ins.

Figure 1. Every security incident enters your runbook; only the branch that reaches unsecured PHI and fails the risk assessment becomes a reportable breach.

The encryption safe harbor: secured PHI is off the clock

Before the notification clock can start, the data has to be unsecured PHI. This is the single most valuable exemption in the rule, and it is worth understanding precisely.

The Breach Notification Rule only applies to unsecured protected health information — PHI that has not been made "unusable, unreadable, or indecipherable to unauthorized persons" through a method the Secretary of Health and Human Services has specified (45 CFR §164.402). In practice, that method is encryption to the federal standard, or secure destruction. If a laptop holding only properly encrypted PHI is stolen, and the decryption key was not taken with it, there is no breach of unsecured PHI — and no notification duty.

This is the one place where "encrypted" genuinely does change your legal exposure. But keep the section's standing rule in mind: encryption is necessary, not sufficient, for compliance overall. Encryption earns you the breach safe harbor only when it is done to the specified standard and the keys stay protected. Encrypted data with the key sitting next to it is not secured, and a vendor handling even encrypted PHI still needs a signed Business Associate Agreement — the contract that lets an outside vendor handle patient data and binds it to HIPAA's rules. The safe harbor is about notification, not about skipping the rest of HIPAA.

Is it a breach? The four-factor risk assessment

Suppose unsecured PHI was involved. You are not automatically required to notify — but the law starts from the assumption that you are. This is the part teams misread most often.

Under 45 CFR §164.402, any impermissible use or disclosure of unsecured PHI is presumed to be a breach unless you can demonstrate a "low probability that the protected health information has been compromised." You demonstrate that through a documented risk assessment of at least four factors. The presumption is the key word: the default is "notify," and the risk assessment is how you earn your way out of it.

Factor	The question it answers	What you document
1. Nature and extent of the PHI	How sensitive and re-identifiable is the data?	Types of identifiers (name, SSN, diagnosis), and how easily the data ties back to a person
2. The unauthorized recipient	Who got it, and can they misuse it?	Whether the recipient is another HIPAA-covered party, an outsider, or unknown
3. Actually acquired or viewed	Was the PHI really accessed, or just exposed?	Forensic evidence of whether anyone opened, read, or copied the data
4. Extent of mitigation	How well was the risk reduced afterward?	Retrieval, confirmed deletion, attestations, system lockdowns

No single factor decides it; you weigh all four together and write down your reasoning. Two honest cautions. First, the conclusion has to be defensible — "low probability" is a real evidentiary standard, not a checkbox, and "we assumed it was fine" is not an assessment. Second, three narrow exceptions exist where an event is not a breach at all: a good-faith, in-scope accidental access by your own workforce; an inadvertent disclosure between two authorized people at the same organization; and a disclosure where you have a good-faith belief the unauthorized recipient could not reasonably have retained the information (45 CFR §164.402(1)).

Whatever you conclude, document it. The rule places the burden of proof on you: in any dispute, the covered entity or business associate must show that all required notifications were made, or that the event was not a breach (45 CFR §164.414(b)). And keep that documentation for six years, the standard HIPAA retention period. A risk assessment that lives only in someone's memory is, for legal purposes, an assessment that never happened.

The 60-day clock: when it starts and what "discovery" means

Here is the rule everyone has heard and many get slightly wrong. If an event is a breach, you must notify affected individuals without unreasonable delay and in no case later than 60 calendar days after discovery (45 CFR §164.404(b)).

Two parts of that sentence carry real weight. "Without unreasonable delay" means 60 days is the ceiling, not a budget you are entitled to spend — if you can notify in two weeks, sitting on it for 58 more days is itself a violation. And "60 calendar days," not business days, so weekends and holidays count.

The clock starts on discovery, and discovery is defined more aggressively than teams expect. A breach is treated as discovered on the first day it is known to your organization — or the first day it would have been known had you exercised reasonable diligence (45 CFR §164.404(a)(2)). You are deemed to know what any workforce member or agent (other than the person who caused the breach) knows or should have known. Let us show the arithmetic the way it actually plays out:

• Day 0: An engineer notices anomalous database access on a Tuesday. That is discovery — the clock starts now, not when leadership is briefed three days later.
• Day 0 + 60: the absolute deadline for individual notices, landing 60 calendar days later.
• Practically, your investigation, risk assessment, and notice drafting all have to fit inside those 60 days, which is why teams that start the runbook on Day 30 are already in trouble.

The "reasonable diligence" standard is why logging and monitoring are a notification issue, not just a security one. If your systems would have surfaced the intrusion weeks earlier but no one was watching, regulators can treat the earlier date as your discovery date. Good detection does not just stop breaches; it controls when your clock starts.

Who you must tell, and when

A confirmed breach can trigger up to three audiences. Which ones depend almost entirely on a single number: 500.

Affected individuals — always. Written notice by first-class mail, or by email if the person agreed to electronic notice, within the 60-day limit (45 CFR §164.404). The notice must be in plain language and contain five things: what happened and the relevant dates; the types of PHI involved; steps the person should take to protect themselves; what you are doing to investigate and mitigate; and how to contact you, including a toll-free number. If you lack current contact details for 10 or more people, you owe substitute notice — a conspicuous posting on your home page for 90 days, or notice in major media, plus a toll-free line (45 CFR §164.404(d)).

The media — only at 500+ in one state or jurisdiction. A breach affecting more than 500 residents of a single state requires notice to prominent media outlets serving that area, with the same content and the same 60-day deadline (45 CFR §164.406). This is not a press release for goodwill; it is a regulatory notice.

The Secretary of HHS — always, but the timing splits on 500. For breaches affecting 500 or more individuals, you must notify the government contemporaneously with the individual notices — without unreasonable delay and within 60 days (45 CFR §164.408(b)). These large breaches are posted publicly on the HHS Office for Civil Rights breach portal, the list the press calls the "Wall of Shame." For breaches affecting fewer than 500 people, you may log them and report annually, no later than 60 days after the end of the calendar year in which they were discovered (45 CFR §164.408(c)).

Figure 2. One discovery date, one 60-day ceiling, three audiences — and the number 500 decides whether the government and the media hear about it now or in an annual log.

One narrow pause exists: if a law-enforcement official states in writing that notice would impede a criminal investigation or harm national security, you delay for the stated period; an oral request buys only a documented 30-day delay (45 CFR §164.412). This is the exception, not a general extension.

If you are a vendor: the business associate clock

Most telemedicine platforms are business associates — vendors that handle PHI on behalf of the clinics, hospitals, or health plans that are their customers (the "covered entities"). If that is you, the rule routes through you differently, and it is easy to underestimate the urgency.

When a business associate discovers a breach, it must notify the covered entity without unreasonable delay and no later than 60 days after discovery (45 CFR §164.410). Critically, the covered entity's own 60-day clock to notify patients generally starts when the business associate discovered the breach (where the business associate is the covered entity's agent), not when the covered entity finally hears about it. So a vendor that uses its full 60 days can leave its customer with almost no time to reach patients — which is exactly why well-written Business Associate Agreements routinely shorten the vendor's window to something like 5, 10, or 30 days, and specify exactly what details the vendor must hand over.

This is a place where the proposed 2026 HIPAA Security Rule update would tighten things further. As of June 2026 the update is still a proposed rule (a Notice of Proposed Rulemaking, RIN 0945-AA22, published January 2025) and has not been finalized, so treat it as a direction of travel rather than current law. Among its proposals: business associates would have to notify covered entities within 24 hours of activating their contingency plan, sharply compressing the timeline above. If you build a telemedicine platform, assume your contracts will demand fast vendor notification regardless of where the rule lands, and design your detection to support it.

Not covered by HIPAA? The FTC has its own breach rule

A common and dangerous assumption: "we are a health app, so HIPAA covers our breaches." It often does not. HIPAA applies to covered entities and their business associates. A direct-to-consumer wellness or telehealth app that sells straight to users, with no covered-entity customer behind it, may fall entirely outside HIPAA — and straight into the Federal Trade Commission's jurisdiction instead.

The FTC's Health Breach Notification Rule (16 CFR Part 318) covers vendors of personal health records and related entities that are not regulated by HIPAA. The FTC finalized amendments effective July 29, 2024 that explicitly bring many health apps and connected devices into scope, and broaden "breach of security" to include not just hacks but unauthorized disclosures — such as sharing or selling users' health data to third parties in a way that contradicts what the app told them. The notification shape rhymes with HIPAA: notify affected individuals and the FTC without unreasonable delay and within 60 calendar days; for breaches involving 500 or more people, notify the FTC within 10 business days.

The practical lesson is to find out which regime you are in before you have an incident. Some telemedicine products sit under HIPAA for their clinical service and under the FTC for a consumer wellness feature. The runbook has to name the right regulator for each data flow, because notifying the wrong agency on the right timeline still leaves you non-compliant.

Before it happens: the incident-response runbook

Everything above is reactive. The work that determines whether you hit those deadlines is done in advance, and HIPAA actually requires the plan.

The Security Rule mandates two relevant pieces: security incident procedures to identify and respond to suspected or known incidents (45 CFR §164.308(a)(6)), and a contingency plan — data backup, disaster recovery, and emergency-mode operations — so you can keep protecting and accessing PHI when systems go down (45 CFR §164.308(a)(7)). A runbook turns those requirements into named steps and named people.

For the response process itself, the widely used reference is the National Institute of Standards and Technology's incident-handling guide, NIST SP 800-61. It frames incident response as a continuous lifecycle: preparation; detection and analysis; containment, eradication, and recovery; and post-incident activity that feeds lessons back into preparation. You do not need to reinvent this; you map your HIPAA duties onto it. Detection is where your discovery date is set. Containment is where you stop the bleeding. Post-incident activity is where the risk assessment, the notifications, and the "what we changed" review live.

Figure 3. Map the NIST incident-response lifecycle onto your HIPAA duties: detection sets the clock, containment limits harm, and post-incident work runs the risk assessment and the notifications.

The proposed 2026 Security Rule update would make this more prescriptive. As noted above it is not yet final, but its direction is clear: require written incident-response and disaster-recovery plans, and require organizations to restore critical systems and data within 72 hours of an incident. Even before any rule lands, a 72-hour restoration target and a written, tested plan are simply good engineering for a clinical service patients depend on.

A runbook a telemedicine team can actually use names, at minimum: who is on call and how they are reached; the severity levels and what each triggers; the first containment steps for the most likely incidents; who owns the four-factor risk assessment; who drafts and sends notices; which regulator applies to which data flow; and the contract clocks for every business associate. We have turned this into a one-page breach-response runbook template you can download below and adapt.

A common-mistakes checklist

Telemedicine teams trip on the same few things. Watch for these:

• Starting the clock late. Treating "discovery" as the day leadership was briefed, not the day a workforce member first knew or should have known. The earlier date usually governs.
• Skipping the written risk assessment. Concluding "it wasn't really a breach" without documenting the four factors. With the burden of proof on you, an undocumented decision is a lost argument.
• PHI hiding in logs and analytics. Application logs, crash reports, and un-BAA'd analytics tools quietly collect PHI, so a breach of a "non-clinical" system is still a breach. Map where PHI actually flows.
• Trusting a 60-day vendor clock. If your Business Associate Agreement lets a vendor take the full 60 days, your own patient-notice deadline can expire before you even hear. Shorten vendor windows by contract.
• Naming the wrong regulator. Assuming HIPAA when a consumer feature actually sits under the FTC Health Breach Notification Rule, or vice versa.

Where Fora Soft fits in

Telemedicine is one of the verticals Fora Soft has built since 2005, alongside video conferencing, streaming, e-learning, and surveillance, and incident readiness is where our real-time-video engineering meets the compliance layer. We design for the requirement first: detection and audit logging that establish a defensible discovery date, a PHI data map so you know which systems and which logs are in scope, contingency and backup that support a fast restoration target, and Business Associate Agreement terms that compress vendor notification rather than absorbing the full 60 days. The aim is a platform where, if an incident happens, the runbook names the people, the clocks, and the regulator — and the team executes instead of improvising.

What to read next

• The HIPAA readiness checklist and audit-prep guide — how breach readiness fits the broader audit picture.
• Audit logging and access controls for clinical video — the detection layer that sets your discovery date.
• Threat modeling a telemedicine platform — finding the incidents before they become breaches.

Call to action

• Talk to a telemedicine engineer — book a 30-minute scoping call to talk through your breach notification 60 day rule plan.
• See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
• Download the Breach-Response Runbook Template — One page, two columns: the first-hour response (detect, contain, preserve, convene) and the 60-day clock (four-factor risk assessment, who to notify at 500+, business-associate and FTC paths), plus the one test to settle before launch.

References

1. 45 CFR §164.402, Definitions (Breach Notification Rule) — defines "breach," the four-factor risk-assessment presumption, the three exceptions, and "unsecured protected health information." https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-D (Tier 1 — CFR)
2. 45 CFR §164.404, Notification to individuals — the 60-calendar-day ceiling, the "discovery"/reasonable-diligence standard, required content, and substitute notice. https://www.ecfr.gov/current/title-45/section-164.404 (Tier 1 — CFR)
3. 45 CFR §164.406, Notification to the media — media notice for breaches involving more than 500 residents of a state or jurisdiction, within 60 days. https://www.ecfr.gov/current/title-45/section-164.406 (Tier 1 — CFR)
4. 45 CFR §164.408, Notification to the Secretary — contemporaneous notice for 500+ breaches; annual log for breaches under 500. https://www.ecfr.gov/current/title-45/section-164.408 (Tier 1 — CFR)
5. 45 CFR §164.410, Notification by a business associate — a business associate must notify the covered entity within 60 days of discovery, with the identification of affected individuals. https://www.ecfr.gov/current/title-45/section-164.410 (Tier 1 — CFR)
6. 45 CFR §164.412 and §164.414, Law enforcement delay and Administrative requirements and burden of proof — the limited delay and the rule that the covered entity/business associate bears the burden of proof. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-D (Tier 1 — CFR)
7. 45 CFR §164.308(a)(6) and (a)(7), Security incident procedures and Contingency plan (HIPAA Security Rule) — the requirement to identify/respond to incidents and to maintain backup, disaster-recovery, and emergency-mode plans. https://www.ecfr.gov/current/title-45/section-164.308 (Tier 1 — CFR)
8. HHS Office for Civil Rights, Breach Notification Rule — the agency's plain-language summary of the individual/media/Secretary duties and the public breach portal. https://www.hhs.gov/hipaa/for-professionals/breach-notification/index.html (Tier 1 — agency guidance)
9. HHS, HIPAA Security Rule NPRM to Strengthen Cybersecurity for ePHI (RIN 0945-AA22, published January 2025; not finalized as of June 2026) — proposed written incident-response/disaster-recovery plans, 72-hour critical-system restoration, and 24-hour business-associate contingency-activation notice. https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/factsheet/index.html (Tier 1 — agency rulemaking, proposed)
10. NIST Special Publication 800-61, Computer Security Incident Handling Guide — the incident-response lifecycle (preparation; detection and analysis; containment, eradication, and recovery; post-incident activity). https://csrc.nist.gov/pubs/sp/800/61/r2/final (Tier 1 — NIST standard)
11. Federal Trade Commission, Health Breach Notification Rule (16 CFR Part 318; final amendments effective July 29, 2024) — breach notice for non-HIPAA health apps and personal-health-record vendors: individuals and FTC within 60 days, FTC within 10 business days for 500+. https://www.ftc.gov/legal-library/browse/rules/health-breach-notification-rule (Tier 1 — federal rule)
12. HHS Office for Civil Rights / UnitedHealth Group, Change Healthcare breach — estimated ~190 million individuals affected (January 2025), the largest US healthcare breach on record, illustrating scale and enforcement attention. https://www.hhs.gov/hipaa/for-professionals/breach-notification/index.html (Tier 2 — agency portal / company disclosure)

Where popular guidance disagreed with the rule, the rule won. Many vendor pages describe the 60-day window as a comfortable budget; the rule text requires notice "without unreasonable delay" and within 60 days, so the earlier feasible date governs (refs 1–2). Several "health app = HIPAA" explainers overlook that direct-to-consumer apps often fall under the FTC rule instead (ref 11). The 2026 Security Rule items are cited as proposed, not current law (ref 9).