HIPAA security incident vs breach: which duty applies

What separates a HIPAA security incident from a breach

Every HIPAA breach starts as an event that may also be a security incident. Under 45 CFR 164.304, a security incident is the attempted or successful unauthorized access, use, disclosure, modification or destruction of information, or interference with system operations in an information system. That definition is broad, and it triggers the Security Rule's response and documentation duties under 45 CFR 164.308(a)(6). A breach is narrower: it is an acquisition, access, use or disclosure of protected health information that the Privacy Rule does not permit and that compromises its security or privacy, and it triggers the notification duties in 45 CFR Part 164 Subpart D. An event can be a security incident without being a breach, so the two findings must be made separately and recorded separately.

The answer depends on the facts of each event. The first question is whether ePHI was actually acquired, accessed, used or disclosed in a way the Privacy Rule does not allow. The second is whether a documented risk assessment shows a low probability that the PHI has been compromised. Under 45 CFR 164.402, an impermissible use or disclosure is presumed to be a breach unless that assessment supports the lower-probability finding, so the burden of proof sits with the organization. Confirm with counsel which PHI elements, systems and access logs your environment can actually establish, because a finding without evidence will not hold up.

The organization owns this decision and the record that supports it. An independent auditor, assessor or counsel can review the reasoning, and an implementation partner can help prepare the incident response procedure, decision checklist, logging and evidence templates that the team uses when an event occurs. None of those parties can make the determination for you. Before an incident happens, assign who classifies events, who signs the breach determination, and where the file is kept, and confirm that the business associate contracts require vendors to report incidents to you in time to make that call.

Which duty each event triggers

Each HIPAA duty starts from a different event, so the first question is always which event occurred and who is responsible for it. The cards below separate the Security Rule response duty, the business associate reporting duty, the breach notification duty and the documentation that carries a no-breach decision.

Security Rule response for any incident

Any attempted or successful unauthorized access, use, disclosure, modification or destruction of ePHI, or interference with system operations, is a security incident under 45 CFR 164.304. The covered entity or business associate must identify and respond to it, mitigate known harm to the extent practicable, and document the incident and its outcome. The duty applies whether or not PHI was exposed, so the incident log must record every event, including those closed as non-breaches. Check that the log has a timestamp, scope, containment steps and a named owner.

Business associate incident reporting

Under 45 CFR 164.314(a)(2)(i)(C), a business associate contract must require the business associate to report security incidents it becomes aware of to the covered entity, including breaches of unsecured PHI. The duty is owned by the business associate and enforced through the contract, so the covered entity must confirm the reporting terms exist before an incident occurs. Evidence includes the executed agreement, the vendor's incident procedure and a record of each report received. Ask vendors how quickly they escalate and who receives the notice.

Breach notification for unsecured PHI

A breach under 45 CFR 164.402 is an acquisition, access, use or disclosure of PHI not permitted by the Privacy Rule that compromises its security or privacy. An impermissible use or disclosure is presumed to be a breach unless a documented risk assessment shows a low probability that the PHI has been compromised. Notification duties then run under Subpart D of Part 164, and they apply only to unsecured PHI. The covered entity owns this duty; evidence is the risk assessment, the notice copies and the dates of discovery.

Documenting a no-breach decision

When an event is judged not to be a breach, the organization still owes a record of the reasoning. The presumption of breach means a finding of low probability of compromise must rest on a documented assessment of the four factors, not on a belief that nothing was taken. Auditors and OCR investigators ask for this file first. Keep the assessment, the evidence reviewed, the approver and the date, and keep it with the incident record so the two can be reconciled.

Ransomware and malware as incidents

HHS's July 2016 ransomware fact sheet states that the presence of ransomware or any malware on systems holding ePHI is a security incident under the Security Rule. That classification triggers the response and documentation duty even before anyone confirms data was copied or exfiltrated. Whether the encryption itself is a breach is a separate question that requires a risk assessment. Confirm that your playbook starts with the security incident process and that malware detections feed the same log.

What the Security Rule incident duty requires every day

The required response and reporting implementation specification in 45 CFR 164.308(a)(6)(ii) asks for three things on an ongoing basis: identifying and responding to suspected or known security incidents, mitigating the harmful effects of known incidents to the extent practicable, and documenting security incidents and their outcomes. The duty applies to every security incident as defined in 164.304, which covers attempted as well as successful unauthorized access, use, disclosure, modification or destruction of information, and interference with system operations. Most of those events will never become a breach. A blocked phishing login, a port scan that hits a firewall rule, or malware quarantined on one workstation all still require a response and a record. The compliance question is not only whether a breach happened, but whether the organization can show that it noticed, triaged and acted on what its systems reported.

Because the Security Rule does not require a certification, the evidence an assessor or OCR investigator asks for is the organization's own incident record. In practice that means the alert or log entry that started the event, the ticket with timestamps, the triage notes that explain why an event was classified as a security incident or dismissed, the containment and eradication steps, and a root-cause record for anything confirmed. Decisions to escalate, to consult counsel, or to conclude that no breach occurred should appear in the same trail. Before any engagement, confirm who owns the security incident log, where it is retained, how long it is kept, and whether its entries can be exported in a form a reviewer can read without the responder's help. Gaps in this record are often the first thing an investigation finds, even when the underlying response was sound.

Your practical next step is to test the record, not the policy. Pick a recent event that was closed without any notification, then trace it from the first log line to the closing note. If the trail cannot show who reviewed the event, what was decided and why, the duty is not being met in a form that can be defended. Ask your managed service or implementation partner to confirm which systems feed incident tickets, whether detection tools such as endpoint and network monitoring write to the same case record, and whether business associates are required to share their own incident records with you. The Security Rule's documentation expectations also apply to the incident procedures themselves, so the written plan and the logged events should match.

How a security incident becomes a breach decision

This sequence turns a suspected event into one of two documented outcomes: a Subpart D notification duty or a written no-breach determination. Each phase produces a record that the next phase depends on, so the decision can be defended later to OCR or a covered entity.

Detect and log the suspected event
Security operations or the workforce member who noticed the activity opens an incident record with the time of discovery, the systems involved and the observed behavior. Detection sources usually include endpoint alerts, audit logs, help desk tickets and reports from staff or vendors. The step is complete when the log entry exists, is timestamped and is assigned to a named incident lead. Ask your team how logs are protected from alteration, because the record will be examined later.
Classify the event as a security incident
The incident lead decides whether the activity is an attempted or successful unauthorized access, use, disclosure, modification or destruction of information, or interference with system operations, as defined in 45 CFR 164.304. Malware and ransomware on covered entity or business associate systems count as security incidents under HHS's ransomware fact sheet, so they enter the response procedure immediately. The output is a classification entry in the record, even when the conclusion is that nothing occurred.
Contain the incident and mitigate harm
The response team isolates affected systems, revokes credentials, preserves evidence and takes steps to limit harmful effects of known incidents, to the extent practicable, as the response and reporting standard requires. Containment actions are recorded with who performed them and when. The step is complete when the team can state what was contained and what remains open. Where the incident is at a business associate, the business associate notifies the covered entity under its contract terms.
Identify whether PHI was involved
The team determines which systems and data sets were affected and whether they held electronic protected health information. It then asks whether the PHI was unsecured, meaning not rendered unusable, unreadable or indecipherable to unauthorized persons through an approved method. Encryption status, key custody and whether keys were exposed are recorded with evidence, such as configuration exports or key management logs. The output is a data inventory for the incident with an encryption determination for each affected set.
Apply the presumption of breach
Under 45 CFR 164.402, an acquisition, access, use or disclosure of PHI not permitted by the Privacy Rule is presumed to be a breach unless a risk assessment shows a low probability that the PHI has been compromised. The incident lead records whether an impermissible use or disclosure occurred at all. If nothing impermissible happened, the analysis may end with a documented finding that no breach occurred. If something did, the presumption applies and the team moves to the risk assessment.
Run the four-factor risk assessment
The team evaluates the nature and extent of the PHI, the unauthorized person who used or received it, whether the PHI was actually acquired or viewed, and the extent to which the risk has been mitigated. The three exceptions and the encryption and destruction safe harbors are checked at this point. This phase is covered in full on the sibling page on the four-factor test, so this step only confirms that the assessment was performed and that its inputs are attached to the incident record.
Record the breach decision and rationale
The decision maker writes a rationale that links the facts, the presumption, each factor and any exception or safe harbor to the conclusion. The decision is signed or approved by a named person with authority. The output is either a breach determination that starts Subpart D duties or a documented no-breach determination. Ask counsel and your privacy officer to review the template in advance, so the rationale holds up when an auditor or OCR reads it.
Notify under Subpart D or close with documentation
If the decision is a breach, the covered entity moves into the notification duties in 45 CFR Part 164 Subpart D, including individual, media and HHS notice where they apply. If the decision is no breach, the record is closed with the classification, containment actions, the risk analysis and the rationale retained with the security incident documentation. Either way, the incident outcome is documented, because the response and reporting standard requires documenting security incidents and their outcomes. Confirm retention periods with your compliance lead before closing.

What covered entities and business associates each owe

Covered entities (health plans, health care clearinghouses and covered health care providers) own the security incident duty for every system that holds their ePHI, including systems that vendors operate for them. Under 45 CFR 164.308(a)(6)(6)), the entity must identify and respond to suspected or known security incidents, mitigate their harmful effects to the extent practicable, and document incidents and their outcomes. The duty applies to intrusions, misconfigurations and malware events alike, even when no patient record was reached.

Detection and response procedures: Written steps for spotting suspected incidents, assigning an owner, containing the event and escalating it. Confirm that the plan names who acts after hours and how alerts reach that person.
Mitigation: Actions that reduce harm from a known incident, such as revoking credentials, isolating affected hosts and restoring from clean backups.
Breach determination and individual notice: The covered entity runs the risk assessment that decides whether an impermissible use or disclosure is a breach, and it holds the individual notification duty unless the contract delegates that duty to a business associate.
Notices to HHS and the media: The Breach Notification Rule sets separate notices to the HHS Secretary and, for larger breaches, to the media. These notices depend on the outcome of the entity's own assessment.
Documentation: Incident logs, investigation notes, risk assessment records, mitigation steps and outcomes, plus proof that the written procedures were followed.

Check whether your incident log can show, for any event, when it was detected, who responded, what was done and how it was closed.

How business associate contracts set incident reporting terms

Under 45 CFR 164.314(a)(2), a business associate contract must require the business associate to report to the covered entity any security incident it becomes aware of, including breaches of unsecured PHI. The contract wording therefore decides how quickly the covered entity learns that something happened. A clause that says "promptly" without a defined trigger leaves both parties guessing about when the clock starts. Before signing or renewing, check four things: the reporting trigger (awareness of an attempted incident, a confirmed one, or only a suspected one), the content the report must include, the named point of contact with a backup, and how investigation and notice work are divided between the parties. Confirm each term with counsel, because the regulation sets the minimum and your risk appetite determines how much more to ask for.

The division of labor deserves the most attention. Decide in writing who investigates, who preserves logs and forensic images, who decides whether an event is a breach that needs notice to individuals, and who sends that notice. Many disputes start here, not with the reporting deadline. The contract should also say how the business associate will share its incident records, such as the incident log entries, containment actions and root-cause findings, when the covered entity asks for them during vendor assessment. Those records show whether the vendor actually documents incidents as 164.308(a)(6)(ii) requires, so request a sample redacted log during due diligence rather than accepting a general assurance.

Expect the business associate's own incident records to be one of the first things a covered entity requests during vendor assessment, and ask for them before a contract is signed. The detailed duties a business associate carries once a breach occurs, including timing from discovery and delegation of individual notices, are covered on the sibling page on business associate breach notification duties. Use this section to fix the reporting terms in the contract. Use that sibling page to plan what happens after the report arrives.

What to have in place before an incident happens

A team separates a Security Rule security incident from a Breach Notification Rule breach quickly only when the groundwork exists before anything happens. The items below are the components that let staff classify an event, assign a decision owner and start the clock on the right duties. The organization owns every item, and an implementation partner can help build and test them.

Written incident response procedure

The Security Rule requires identifying and responding to suspected or known security incidents, mitigating harm and documenting outcomes. A written procedure turns that duty into steps staff can follow at 2 a.m. Check it with a tabletop exercise: walk a hypothetical lost-laptop event through the procedure and confirm each step names a role, a tool and a record that gets written down.

Named decision owner and escalation path

Someone must decide whether an event is a security incident only, a possible breach, or both, and that decision drives notification duties. Record a named primary and backup owner, plus the escalation路径 to privacy, legal and executive leadership. Check the path by confirming that each named person can be reached outside business hours and knows they hold the classification decision.

Logging and retention for ePHI access

Reconstructing who touched ePHI, and when, is the evidence that separates an unsuccessful attempt from an impermissible access. Confirm that audit logs cover systems holding ePHI, are protected from alteration, and are kept long enough to cover the look-back period your investigation needs. Check by pulling logs for a sample user and confirming you can answer who accessed which record and when.

Inventory of where ePHI lives

Scoping an incident depends on knowing which systems, backups, endpoints and vendor platforms hold ePHI. An inventory that is current and mapped to owners lets the team answer scope questions in hours rather than days. Check it by picking one application, tracing its database, backups and exports, and confirming each location appears in the inventory.

Documented four-factor assessment method

When an impermissible use or disclosure occurs, the presumption of breach holds unless a documented risk assessment shows a low probability of compromise. A written method for weighing the nature of the PHI, the unauthorized person, whether PHI was actually acquired or viewed, and mitigation keeps those judgments consistent. Check it by running a sample event through the method and confirming a reviewer reaches the same conclusion.

Incident record template and vendor contacts

A standard incident record captures facts, decisions, dates and outcomes, which supports the documentation duty and any later OCR inquiry. Pair it with a contact list drawn from business associate agreements, since those contracts set how and when vendors must report incidents to you. Check the list by confirming each vendor contact is current and that the agreement's reporting terms match your procedure.

What the proposed incident response plan rule would change

HHS's January 6, 2025 proposed Security Rule revision (90 FR 898, RIN 0945-AA22) would require covered entities and business associates to maintain written security incident response plans and to review and test them at least once every 12 months. This is a proposal. As of October 2026, no final rule has been published, and the latest Unified Agenda lists final action as projected for July 2027. Treat the requirement as pending until you have checked the Federal Register and reginfo.gov yourself, because the final text may differ from what was proposed, including the review interval, the testing expectations and what the plan must cover.

You do not need to wait for a final rule to act. The current Security Rule already requires you to identify and respond to suspected or known security incidents, mitigate their harmful effects to the extent practicable, and document incidents and their outcomes. A written plan that names the incident response lead, sets out how a suspected incident is triaged and classified as a security incident or a possible breach, and records who decides on notification gives you a document you can produce for an OCR investigation today. Tabletop exercises and a dated record of each review will show that the plan works in practice, and they will carry over into whatever the final rule requires.

Confirm the status before you commit budget or contract language to a specific interval. Check whether the final rule has been published, read the adopted text against the proposal, and ask your counsel which obligations apply to your entity type and to your business associates. Ask any outside assessor or consultant to map its recommendations to the current rule first, and to flag separately which items depend on the pending revision. Plans written now should be easy to update, with version history, an owner and a review date recorded in the document itself.

Questions buyers ask about incidents and breaches

Is ransomware always a HIPAA breach?

No. Ransomware is a security incident under the Security Rule, and HHS states that its presence on a covered entity's or business associate's systems triggers the security incident response and reporting procedures. Whether it is also a breach depends on the Breach Notification Rule. An impermissible use or disclosure of PHI is presumed to be a breach unless a documented risk assessment shows a low probability that the PHI has been compromised. Your analysis should establish what data the malware touched, whether that data was secured in a way that made it unusable, and what the logs show about access and copying. HHS's 2016 ransomware fact sheet is the starting point for the Security Rule side of this decision. Confirm how the presumption applies to your facts with counsel before you close the file.

Does a security incident that is not a breach still need documentation?

Yes. The Security Rule requires you to identify and respond to suspected or known security incidents, mitigate their harmful effects to the extent practicable, and document each incident and its outcome. That duty applies whether or not the event later turns out to be a breach. A documented incident you decide is not reportable still needs a complete record: what happened, which systems and data were involved, the response steps taken and the reasoning behind the decision. Notification under the Breach Notification Rule is a separate question that turns on whether unsecured PHI was impermissibly accessed, used or disclosed. Keep the file detailed enough that an OCR investigator could follow your decision from start to finish.

Who decides whether an incident is a HIPAA breach?

The covered entity makes the breach determination and carries the notification duties. A business associate must report security incidents it becomes aware of to the covered entity, including breaches of unsecured PHI, and the business associate contract must require that reporting under 45 CFR 164.314(a)(2)(i)(C). When a business associate discovers the event first, the contract and the covered entity's arrangements determine who runs the risk assessment, who notifies individuals and who reports to HHS. The decision belongs to the entity that holds the legal duty, must be documented, and must rest on that entity's own analysis. Check how your business associate agreement divides these tasks, and confirm the split with counsel.

Can a consultant make the HIPAA breach decision for us?

A consultant can run the analysis, gather the evidence and draft the documentation, but the decision and the legal duties stay with your organization. The entity with the obligation makes the call and owns any notifications that follow. A capable outside team will ask for logs, the data inventory, access records and a timeline, then show how each factor applies to your facts. Ask any provider how the work is divided, who signs the determination and who is accountable if the conclusion is challenged. DeployOpen plans and implements self-hosted open-source platforms, prepares systems, controls and evidence for compliance assessments, and runs security testing. It does not make breach determinations, issue reports or issue certifications. Confirm the division of responsibility with counsel before work begins.

Can we handle HIPAA incident classification in house?

Yes, if you have the people, written procedures and evidence trail to support each decision. Many organizations split the work: security operations triages the event, a privacy or compliance owner runs the four-factor assessment, and counsel reviews the notification path. Most of the cost is staff time, and it recurs with every incident. Outside forensic or legal support adds cost during a serious event, and the bill grows when logging is thin, when the data inventory is out of date or when the team must rebuild timelines after the fact. Before you decide, ask whether your team could produce a complete record within the deadlines your counsel confirms, and whether the same people can also cover normal operations during the response.

What does an incident response team need from our staff?

The work needs a named team with defined roles before an incident occurs:

A security lead who can preserve evidence and direct containment
A privacy or compliance owner who documents the risk assessment and tracks deadlines
Engineers who can pull authentication, access and audit logs for affected systems
A current inventory of where ePHI lives, including cloud services and vendors
Counsel who can confirm notification timing

The response procedure should also be written, reviewed and rehearsed. HHS's January 2025 proposed rule would require written incident response plans reviewed and tested at least once every 12 months. That change was proposed, not finalized, as of October 2026, so confirm the current obligations in the regulation text.

Does a third-party review prove our breach decision was correct?

No. An independent review can show that your process was sound, the evidence was complete and the reasoning was documented. It cannot guarantee the conclusion, and it does not bind OCR. HHS states that it does not endorse or recognize private organizations' certifications and that such certifications do not prevent it from later finding a violation. A review of an incident decision follows the same logic: it assesses your reasoning and does not rule on the outcome. Its value lies in a second look at the four factors, the logs and the timing before a regulator asks questions. Scope the review in writing, ask the reviewer what it will and will not conclude, and keep the report with the incident file.

How DeployOpen prepares incident response evidence

DeployOpen helps organizations build the incident intake, classification and documentation trail that lets them show how each event was judged as a security incident, a breach or neither. Your organization owns the determinations, and an independent assessor or auditor decides what the evidence proves.

How we scope

The written scope names which systems, logs and ePHI environments the incident response workflow covers.
Scope records who classifies events, who documents outcomes and who approves each determination.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We configure self-hosted open-source platforms in your infrastructure to log, track and timestamp suspected incidents.
We set up classification fields that separate a security incident from a potential breach requiring a four-factor assessment.
We test the workflow with tabletop exercises and recorded sample events so gaps surface before a real incident.

How we hand over

You receive the incident response procedure, classification criteria and documentation templates written for your environment.
Handover includes records showing how each test event moved from detection through documentation and closure.
You receive runbooks for business associate reporting terms so contract obligations are traceable to your workflow.

How we support

Ongoing support and upgrades of the incident tooling are available as a retainer after handover.
Retainers can include periodic review of the response plan as the proposed rule changes move toward finalization.
Confirm with your counsel and assessor which determinations, notices and records your organization must retain.

HIPAA security incident vs breach: what triggers which duty