Security incident procedures: three questions, answered before you need them

Ask a clinic what happens when someone suspects a security incident, and the honest answer is often “I’m not sure, probably tell someone.” That answer is the failure this standard exists to prevent, and it is a Required one, with no addressable version to fall back on.

What the rule actually requires

Security incident procedures is a Required standard: implement policies and procedures to address security incidents (45 CFR 164.308(a)(6)).

One implementation specification, also Required: identify and respond to suspected or known security incidents, mitigate to the extent practicable any harmful effects that are known, and document security incidents and their outcomes (164.308(a)(6)(ii)).

The definition is broader than people assume

Remember how broadly “security incident” is defined: the attempted or successful unauthorized access, use, disclosure, modification, or destruction of information, or interference with system operations (45 CFR 164.304). Notice the word attempted. This standard does not wait for a successful breach to apply.

The phishing email an RBT reported, and clicked nothing, is an incident under this definition. A failed login attempt pattern that looks automated is an incident. A lost device that was recovered before anyone could confirm access is an incident. None of these need to result in actual PHI exposure to trigger the obligation to identify, respond to, and document them.

“The phishing email an RBT reported is an incident. The procedure answers three questions in advance.”

Three questions, answered before you need them

A real procedure answers three questions in advance, so that nobody is figuring them out for the first time during an actual incident:

• Who does staff tell? One clear path, not “whoever seems available.”
• Who decides what it is? A specific person makes the call on severity and next steps, not a group discussion that happens after the moment has passed.
• Where is it written down? A record that exists from the moment of report, not reconstructed afterward from memory.

Why documentation matters twice over

The documentation requirement is not just record-keeping for its own sake. If an incident turns out to be a breach, the notification clock and the evidence trail both start at discovery, the moment someone first knew or should have known, not at the moment someone got around to writing it down. A clinic that identifies an incident on Monday and documents it the following week has not moved its clock. It has created a gap between when the clock started and when the record shows anyone noticed, which is exactly the kind of gap an investigator looks for.

What a real procedure looks like, next to what most clinics have

	What the rule requires	What most clinics actually have
Reporting path	One clear, known path for any staff member	“Tell someone,” undefined
Decision owner	A specific named person	Ad hoc, whoever is around
Scope of what counts	Attempted incidents too, not just confirmed breaches	Only things that clearly “went wrong” get mentioned
Documentation timing	Starts at the moment of report	Reconstructed later, if at all

The gap that matters most is the last one. A clinic that handled every incident well but wrote nothing down is, from an investigator’s perspective, difficult to distinguish from a clinic that never noticed anything at all.