Security incident

Editorial approval scope: The team checked current source fidelity, scope boundaries, dates, arithmetic, reader usefulness, practical workflow, and general-information limitations.

The HIPAA definition includes attempts

Current 45 CFR 164.304 expressly includes attempts and interference with information-system operations. Confirmed data theft is only one possible incident.

Examples include malware, unauthorized record changes, cloud exposure, log deletion, or interference with scheduling or clinical records. Repeated credential-stuffing against a BCBA's portal account is a security incident even when multifactor authentication blocks every login. A monitoring alert is a signal, not a classification. Open a case at the practice's threshold and mark it suspected, confirmed, or false positive as evidence develops.

The HHS Security Rule page applies to ePHI held by covered entities and business associates and still labels the January 2025 update as proposed. This article uses current eCFR text. Privacy incident is an internal workflow label, not a universal HIPAA category; it can include paper or verbal PHI beyond the Security Rule's ePHI boundary.

Incident, privacy event, and breach are separate states

A security incident can exist without a HIPAA breach. A blocked login attack may involve no PHI access. A wrong-recipient paper fax may require Privacy Rule and breach analysis even though the Security Rule protects ePHI rather than paper PHI.

Use separate fields for:

The HHS Breach Notification Rule page describes a separate determination and notice process. Impermissible PHI use or disclosure is presumed to be a breach unless an exception or documented low-probability assessment applies. Contain the incident while qualified privacy or legal review classifies it.

Make the first response safe and repeatable

45 CFR 164.308(a)(6) requires regulated entities to implement procedures to address security incidents. The required response-and-reporting specification covers identifying and responding to suspected or known incidents, mitigating harmful effects to the extent practicable, and documenting incidents and outcomes.

Give every workforce member a short reporting route and clear boundaries. A useful first-response card can say:

1. Protect immediate client, workforce, and physical safety.
2. Record the detection time, device or system, visible symptom, and reporter.
3. Contact the named incident route immediately.
4. Follow trained containment instructions, such as isolating a device or revoking a session, when ongoing harm requires it.
5. Preserve volatile facts, messages, logs, screenshots, files, devices, and timestamps when safe, and record each action.
6. Move care, scheduling, documentation, and payroll to approved downtime paths when needed.

Containment and preservation run together. Urgent containment should not wait for a perfect forensic image; reimaging, wiping, or returning equipment should wait for the response lead. Staff should not forward suspicious attachments, interrogate suspected actors, or improvise an investigation. The lead coordinates technical, privacy, clinical, legal, insurer, communications, workforce, vendor, and law-enforcement roles as applicable.

Investigate scope before declaring recovery

The HHS ransomware fact sheet recommends scoping affected systems, origin, timing, ongoing activity, propagation, methods, and vulnerabilities, followed by containment, eradication, recovery, legal analysis, and lessons learned.

Maintain one sourced timeline. Record affected identities, systems, vendors, data types, unique people potentially affected, access or change evidence, actions, owners, service impact, communications, and uncertainty. Distinguish facts from hypotheses.

System availability is one recovery milestone. Set acceptance criteria for data integrity, access, malicious persistence, logs, backups, interfaces, clinical records, schedules, authorizations, claims, payroll, vendors, and monitoring. A qualified clinician decides whether care can safely resume; technical restoration alone does not.

Vendors and clocks need named owners

A vendor incident can trigger duties for several parties. The current HHS cloud-provider FAQ says a business associate must report security incidents involving its customer's ePHI of which it becomes aware. The agreement may set detail, frequency, format, and faster handling for serious events or patterns of attempts. Breach reporting has separate requirements.

For a business associate, 45 CFR 164.410 treats a breach as discovered when it is known or would have been known with reasonable diligence. Notice to the covered entity is due without unreasonable delay and no later than 60 calendar days after discovery. HHS describes corresponding covered-entity duties; contracts, state law, payers, insurers, and licensing rules may be shorter. Sixty days is an outer limit, not a waiting period. A qualified owner should log possible discovery dates and track each clock while containment and forensics continue.

Contract language should identify the trigger, recipient, deadline, content, cooperation, evidence preservation, subservice providers, containment authority, and update cadence. Faster contract reporting does not replace either party's legal duties.

A fictional incident queue shows the measures

A fictional ABA practice has 15 alerts that meet its predeclared triage criteria and are due during the month. Twelve are triaged by the deadline and three are overdue, so alert-triage timeliness is 12 of 15, or 80%. Confirmed false positives remain in this denominator because the measure concerns triage work.

Eight events meet the section 164.304 definition, including two blocked login attacks. Six meet the containment target and two miss it, so timely incident containment is 6 of 8, or 75%. Using all 15 alerts as the incident denominator would mix two different cohorts; excluding the unsuccessful attacks would undercount defined incidents.

The practice also attempts six recovery exercises during the quarter. Five meet every stated acceptance criterion, while one restores the database but fails an interface-reconciliation check. Recovery acceptance is 5 of 6, or 83.3%. Calling all six “restored” would hide the incomplete evidence.

These rates measure the defined work. They do not show that every alert was detected, no breach occurred, response caused an outcome, or the practice complies with HIPAA.

Measure response and correction

Useful measures include incidents triaged by target divided by incidents due, systems meeting recovery criteria divided by systems due, communications on time divided by communications due, and corrective actions validated by target divided by actions due.

Track detection-to-triage, containment time, disruption, evidence gaps, repeat causes, open age, and failed recovery checks. Define each duration's endpoints and each percentage's cohort, numerator, denominator, period, exclusions, and maturity rule.

NIST SP 800-61 Revision 3, finalized in April 2025, supersedes Revision 2 and integrates incident response across all six CSF 2.0 functions: Govern, Identify, Protect, Detect, Respond, and Recover. It is general cybersecurity guidance. HIPAA, state law, contracts, and role-specific clinical and legal authority still control the practice's duties and decisions.