Security Incident Procedures

HIPAA’s Security Incident Procedures requirement means you must have written, workable procedures to identify, respond to, mitigate, document, and communicate security incidents that affect ePHI, and you must be able to prove you follow them in practice. Build an incident program with clear roles, escalation paths, and evidence capture aligned to your systems and third parties. (45 CFR Parts 160, 162, 164)

Key takeaways:

• You need documented procedures for handling security incidents involving ePHI, not just an “IR policy.” (45 CFR Parts 160, 162, 164)
• Auditors look for operational proof: tickets, timelines, decisions, and post-incident improvements tied to specific events.
• Third-party and cloud incidents must flow through your process with defined notification triggers and evidence retention.

45 CFR § 164.308(a)(6)(i) is a deceptively short requirement: “Implement policies and procedures to address security incidents.” (45 CFR Parts 160, 162, 164) For a Compliance Officer, CCO, or GRC lead, the operational meaning is specific: you must be able to detect and triage suspected incidents that could affect ePHI, coordinate a response across security, IT, privacy, legal, and operations, and document what happened and what you did about it.

This requirement is not satisfied by a generic playbook copied from another industry. Your procedures need to match your environment: EHR and clinical applications, endpoints used by workforce members, cloud services, identity providers, and the third parties that create, receive, maintain, or transmit ePHI on your behalf. Covered Entities and Business Associates both need this capability, and Business Associates often fail by assuming the Covered Entity “handles incidents.”

Treat this page as an implementation runbook. It tells you what to write, how to run it, what evidence to save, what auditors ask, and how to roll the program out quickly without guessing what “good” looks like. (45 CFR Parts 160, 162, 164)

Regulatory text

Requirement (verbatim): “Implement policies and procedures to address security incidents.” (45 CFR Parts 160, 162, 164)

Operator interpretation: You must define, document, and run repeatable procedures for handling security incidents that involve electronic protected health information (ePHI). “Address” is broader than “respond.” Your procedures should cover:

• How you identify and report suspected incidents internally
• Who triages and declares an incident
• How you contain and mitigate impact to ePHI
• How you communicate and escalate (including to relevant stakeholders and third parties)
• How you document actions and outcomes so you can demonstrate compliance (45 CFR Parts 160, 162, 164)

Plain-English interpretation (what the rule expects in practice)

A security incident is any event that could compromise the confidentiality, integrity, or availability of ePHI. Your job is to make sure the organization can react consistently under pressure. A good program prevents “panic-driven” decisions, reduces time lost to ambiguity (who decides, who gets called, what to preserve), and creates an evidentiary trail that stands up in audits and internal investigations.

A fast way to sanity-check your procedures: if your on-call engineer or IT manager gets an alert at night about suspicious access to an EHR account, can they follow your documented steps without calling three people to figure out what “counts” as an incident?

Who it applies to

Entity types: Covered Entities and Business Associates. (45 CFR Parts 160, 162, 164)

Operational contexts where auditors expect maturity:

• Any environment that stores or transmits ePHI (EHRs, imaging systems, patient portals, billing platforms, document management)
• Distributed workforces (remote access, BYOD where permitted, shared workstations, clinical settings)
• Cloud and managed services (IaaS/PaaS/SaaS)
• Third-party relationships touching ePHI (clearinghouses, claims processors, call centers, transcription, MSPs, hosting, analytics) (45 CFR Parts 160, 162, 164)

What you actually need to do (step-by-step)

1) Define “security incident” for your environment

Write a definition your teams can apply consistently. Include examples tied to your systems and workflows, such as:

• Lost or stolen device with access to ePHI
• Suspicious authentication activity on an EHR/IdP account
• Malware on a workstation used for clinical documentation
• Misrouted data exports or exposed cloud storage
• Third-party notification of compromise involving your ePHI (45 CFR Parts 160, 162, 164)

Deliverable: Incident classification guide (1–2 pages) that maps common events to severity levels and required actions.

2) Establish roles, authority, and escalation paths

Your procedure must answer “who is in charge” at each stage:

• Reporter: any workforce member, service desk, monitoring tool, or third party
• Triage lead: security operations/IT, with defined backup
• Incident commander: named role with authority to direct containment actions
• Decision makers: Privacy, Compliance, Legal, IT, Security, affected business owner
• Executives: who gets notified based on severity
• External interfaces: third parties, cyber insurer (if applicable), forensic support (if applicable)

Write decision authority explicitly (for example: who can disable accounts, isolate systems, block IPs, suspend integrations). Ambiguity here causes delay and inconsistent containment. (45 CFR Parts 160, 162, 164)

Deliverables: RACI matrix; on-call/escalation roster; contact lists with alternates.

3) Create a single intake channel and minimum intake requirements

Pick a consistent method for incident intake (ticketing queue, hotline, email alias tied to case management). Define minimum fields:

• Reporter identity and contact
• Time detected and time occurred (if known)
• Systems, users, and locations involved
• What data might be affected (ePHI elements, patient count if known, but don’t guess)
• Screenshots/log references where available

Avoid requiring perfect information. Intake should be lightweight; triage is where you refine facts. (45 CFR Parts 160, 162, 164)

Deliverables: Intake form/template; ticket categories; triage checklist.

4) Run triage and declare incidents with documented criteria

Your procedure should separate:

• Event: something observed (alert, complaint, anomaly)
• Incident: confirmed or reasonably suspected compromise affecting ePHI or systems supporting ePHI

Define criteria for escalation to “incident” status (for example: credible indication of unauthorized access, malware on an ePHI system, confirmed misconfiguration exposing ePHI). Require documentation of who declared it, when, and why.

Deliverables: Triage SOP; incident declaration criteria; severity rubric.

5) Contain, eradicate, recover (with evidence preservation baked in)

Document standard response actions and prerequisites:

• Containment: disable accounts, isolate endpoints, block traffic, suspend integrations, revoke tokens
• Preservation: capture volatile data where feasible, preserve logs, snapshot affected systems, maintain chain-of-custody notes
• Eradication: remove malware, patch, rotate credentials, remediate misconfigurations
• Recovery: restore services, validate integrity, monitor for recurrence

A common operational gap is “fixing fast” while destroying evidence. Your procedure must tell responders what to preserve before major changes. (45 CFR Parts 160, 162, 164)

Deliverables: Evidence handling steps; log preservation requirements; containment playbooks for common scenarios (account compromise, endpoint malware, cloud exposure).

6) Coordinate communications, including third parties

Write rules for:

• Internal notifications (IT, Security, Privacy, Compliance, Legal, leadership)
• Workforce communications (what to say, who approves messages)
• Third-party coordination (how you request logs, timelines, and root cause; how you handle their containment actions)
• Patient/customer communications where applicable, routed through appropriate governance

Even though this requirement does not itself spell out breach notifications, auditors expect your procedures to route incidents to the right decision makers for downstream obligations. Keep this tight: “security incident procedure triggers privacy review” is better than leaving teams to improvise. (45 CFR Parts 160, 162, 164)

Deliverables: Notification matrix; third-party incident intake and evidence request template; communication approval workflow.

7) Document every incident and close with lessons learned

For each incident, require:

• Timeline of key events and decisions
• Scope assessment (systems, accounts, ePHI involved as known)
• Actions taken, by whom, when
• Root cause and contributing factors (as determined)
• Corrective actions and owners
• Post-incident review outcomes (control improvements, training, monitoring changes)

Then feed results into your risk management and security management processes so repeat issues produce measurable control changes. (45 CFR Parts 160, 162, 164)

Deliverables: Incident report template; post-incident review notes; corrective action tracker.

8) Operationalize through testing and training

Procedures that aren’t exercised degrade quickly. Build:

• Workforce reporting guidance (how to spot and report suspected incidents)
• Tabletop exercises for the incident team
• Targeted drills for high-risk systems (EHR access anomalies, ransomware-like conditions, third-party compromise notifications)

Practical tool: Daydream can serve as the system of record for incident procedures, evidence checklists, and corrective actions, so tickets, decisions, and artifacts stay linked for audits without chasing emails and chat logs.

Required evidence and artifacts to retain

Keep evidence that shows both design (the written procedure) and operating effectiveness (proof you followed it).

Design artifacts

• Security Incident Procedures document approved by appropriate governance (45 CFR Parts 160, 162, 164)
• Definitions and severity rubric
• RACI, escalation paths, and contact lists
• Incident intake template and triage checklist
• Evidence preservation/handling steps
• Third-party incident coordination procedure

Operating artifacts

• Incident tickets/cases with timestamps, ownership, and status changes
• Investigation notes, log references, screenshots, and forensic outputs where applicable
• Communications records (internal notices, third-party correspondence, approvals)
• Incident report and post-incident review
• Corrective action tracking to closure (with evidence of changes)

Common exam/audit questions and hangups

Auditors and assessors tend to probe:

• “Show me your incident procedures. Who approved them and when were they last updated?” (45 CFR Parts 160, 162, 164)
• “Provide evidence of recent incidents and walk through how you followed your procedure.”
• “How do workforce members report suspected incidents? How do you train them?”
• “How do you ensure third-party incidents involving your ePHI are captured, triaged, and documented?”
• “How do you preserve logs and evidence before systems are rebuilt or accounts are reset?”

Hangups that create findings:

• No consistent incident case management, so timelines are reconstructed later from chat messages
• Incidents handled as IT outages, with no ePHI scoping or privacy/compliance involvement
• Third-party incidents treated as “their problem,” with no internal documentation (45 CFR Parts 160, 162, 164)

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Writing a policy, not a procedure.
   Fix: Add actionable steps, roles, thresholds, and templates. A responder should be able to follow it under time pressure.

2. Mistake: No definition of “incident” tied to ePHI.
   Fix: Publish concrete examples and a severity rubric aligned to your systems. (45 CFR Parts 160, 162, 164)

3. Mistake: Evidence preservation is an afterthought.
   Fix: Put “preserve logs / snapshot / chain-of-custody notes” early in playbooks, before remediation steps.

4. Mistake: Third-party incidents aren’t integrated.
   Fix: Require third-party notification intake, evidence requests, and internal case creation even if the third party leads remediation.

5. Mistake: Closure without corrective action.
   Fix: Make post-incident review mandatory, track corrective actions, and require leadership visibility for overdue items.

Execution plan (practical 30/60/90-day)

Because you asked for speed, use phases. Tailor sequencing to your capacity and current maturity.

First 30 days (stand up a workable baseline)

• Draft and approve Security Incident Procedures aligned to 45 CFR § 164.308(a)(6)(i). (45 CFR Parts 160, 162, 164)
• Publish incident definition, severity rubric, and escalation paths.
• Stand up a single intake channel and case workflow.
• Create templates: triage checklist, incident report, evidence request to third parties.
• Run one tabletop exercise using a realistic ePHI scenario and capture action items.

Days 31–60 (make it operational across the business)

• Train service desk, IT, security, and key operations teams on intake, triage, and preservation steps.
• Integrate third parties: update onboarding/offboarding checklists so incident notification paths are current.
• Validate logging and access data sources needed for investigations (identity, EHR audit logs, endpoint telemetry, cloud logs).
• Start a corrective action tracker tied to incident outcomes.

Days 61–90 (tighten controls and prove repeatability)

• Run a second exercise focused on a third-party incident involving ePHI.
• Review a sample of incident cases for documentation quality and timing of escalations.
• Update procedures based on lessons learned; re-approve if changes are material.
• Build an audit-ready “incident binder” view in Daydream (or your GRC tool): procedures, training records, sample cases, corrective actions.

Frequently Asked Questions

Do we need separate procedures for privacy breaches and security incidents?

Keep security incident procedures focused on detection, containment, mitigation, and documentation, then add a clear handoff to privacy/compliance for any downstream determinations. The key is a documented escalation path so security events that may involve ePHI do not stall. (45 CFR Parts 160, 162, 164)

We’re a Business Associate. Can we rely on the Covered Entity’s incident response process?

No. You still need your own policies and procedures to address security incidents in your environment, including incidents involving the Covered Entity’s ePHI. Coordinate with the Covered Entity, but document your internal handling and evidence. (45 CFR Parts 160, 162, 164)

What evidence do auditors usually want first?

They typically start with your written procedures and then ask for incident records that prove you followed them: intake, triage notes, containment actions, and post-incident corrective actions. A clean timeline and decision log prevents rework during the audit.

How do we handle incidents at a third party that won’t share detailed forensics?

Create an internal incident case anyway, document what the third party provided, and record your follow-up questions and risk decisions. Your procedure should require evidence requests and escalation if the third party cannot support your ePHI impact assessment.

Does every malware alert become a “security incident”?

Not automatically. Your triage criteria should distinguish between routine security events and incidents that credibly affect systems supporting ePHI or suggest unauthorized access to ePHI. Document the triage decision either way. (45 CFR Parts 160, 162, 164)

How often should we test incident procedures?

Test often enough that responders remember the workflow and contact paths stay current, and re-test after major system or organizational changes. Document exercises, outcomes, and procedure updates as audit evidence.