Breach Notification Procedures

Breach notification procedures require you to run a repeatable, documented workflow that determines whether an incident is a reportable breach, then issues required notifications to affected individuals, HHS, and (for large events) the media, while also meeting applicable state breach laws. You operationalize this by defining roles, decision criteria, timelines, templates, and evidence retention. ¹

Key takeaways:

• Build one end-to-end playbook that covers HIPAA Breach Notification Rule obligations plus state breach-law add-ons. ¹
• Make breach determination a controlled decision with documented inputs, approvals, and counsel involvement where appropriate. ¹
• Pre-stage templates, contact data, and third-party coordination steps so notifications do not stall during an incident. ¹

“Breach notification procedures” is not a policy you file away. For HIPAA-regulated environments and health IT ecosystems, it is an operational capability: detect an incident, preserve facts, decide if it meets the definition of a reportable breach, and notify the right parties through the right channels. HICP Practice 8.4 explicitly calls for breach notification procedures that comply with HIPAA breach notification requirements and state data breach laws. ¹

CCOs and GRC leads get pressure from two directions during a cyber event. Leadership wants speed and certainty. Regulators and plaintiffs’ counsel expect discipline: documented decisioning, consistent communications, and proof you followed your own procedures. The fastest way to fail is to improvise “who calls whom” while forensics are still developing, or to treat state law notifications as an afterthought.

This page translates the requirement into a deployable process: scope and applicability, step-by-step actions, concrete artifacts to retain, audit questions you will get, and the common implementation traps. It is written for operators who need a workable breach notification workflow that survives real incidents. ¹

Regulatory text

Requirement (HICP Practice 8.4): “Establish breach notification procedures compliant with HIPAA breach notification requirements and state data breach laws.” ¹

Operator interpretation: You need a documented, exercised procedure that:

• Determines whether a security incident rises to a reportable breach under HIPAA breach notification requirements. ¹
• Executes required notifications: affected individuals, HHS, and media notification for breaches affecting large populations. ¹
• Accounts for state breach notification laws that may add notice recipients, content requirements, or shorter timelines than your HIPAA workflow. ¹

HICP’s practical emphasis is clear: this is part of incident response. Treat it as an operational runbook, not a standalone “policy statement.” ¹

Plain-English requirement: what this means day to day

You must be able to answer, quickly and consistently:

1. Did the incident involve protected or regulated data?
2. Does it meet the definition of a reportable breach under HIPAA breach notification requirements?
3. Which states’ breach laws apply based on the affected individuals’ residency?
4. Who must be notified, by when, and with what content?
5. How will you prove you followed the process?

Your procedure must also cover incidents involving third parties (for example, a cloud EHR provider, billing clearinghouse, MSP, or collections agency). The operational point: a third party can create your notification obligation, and your contracts and playbooks must support fast fact gathering and coordinated communications. ¹

Who this applies to (entity and operational context)

HICP identifies applicability to:

• Healthcare organizations (providers, payers, and other covered environments managing health data). ¹
• Health IT vendors that create, receive, maintain, or transmit sensitive healthcare data in their services and operations. ¹

Operational contexts where this becomes urgent:

• Ransomware events affecting systems with ePHI.
• Misconfigured storage or databases with patient data.
• Lost or stolen devices containing patient information.
• Email compromise exposing patient records.
• Third-party incidents where your data was involved or your operations were impacted. ¹

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

The goal is a single “breach notification procedure” with clear decision gates and handoffs.

1) Define roles, authority, and a decision forum

Create a named breach decision group and document:

• Incident commander (often Security/IT).
• Privacy officer and/or HIPAA compliance lead.
• Legal (in-house or outside counsel route).
• Communications/PR.
• Customer/patient relations (call center support).
• Third-party management/procurement for rapid vendor coordination. ¹

Operational rule: one person owns the clock and the checklist; the group owns the breach determination.

2) Build a “breach determination” checklist that can be evidenced

Write a short, structured worksheet that captures:

• Incident summary and timeline of key facts.
• Systems impacted and data types possibly involved.
• Population estimation method and confidence level.
• Containment actions taken.
• Whether a third party was involved and what they confirmed in writing.
• Decision outcome: reportable vs not reportable, and rationale. ¹

Avoid free-form narrative as your only record. Auditors look for consistent decision artifacts.

3) Map notification obligations: HIPAA + state law overlay

Create and maintain a matrix that answers:

• Who gets notified (individuals, regulators, consumer reporting agencies if applicable, attorneys general, HHS, media for large events). ¹
• Allowed notification methods (mail, email, substitute notice, website posting, press release) per your legal interpretation.
• Content elements you will include by default, plus optional elements your counsel may add.
• State-by-state deltas and triggers tied to residency. ¹

This matrix becomes your “routing table” during an incident. Keep it version-controlled and owned by Compliance with Legal review.

4) Pre-stage notification templates and a contact data pack

Prepare:

• Individual notice templates (patient/member/consumer).
• HHS notice inputs checklist.
• Media statement template for large events. ¹
• FAQs for call center and frontline teams.
• Regulator contact list and submission methods.
• Affected individual address quality process (how you validate, dedupe, and handle returns).

During a breach, writing from scratch causes delays and inconsistent language.

5) Integrate third-party coordination steps

Your procedure should require, when a third party is involved:

• Immediate written incident summary from the third party.
• Agreed timeline for forensics updates.
• Who drafts notices and who approves them.
• Whether notices are sent by you, the third party, or jointly.
• Evidence you received the third party’s confirmation about data elements and impacted population methodology. ¹

Contractually, you want breach cooperation clauses, prompt incident reporting, and access to relevant evidence. Operationally, you want a named escalation path and pre-established communications channel.

6) Run tabletop exercises focused on notifications, not just containment

A notification tabletop should test:

• Data residency and state-law routing.
• Population counts changing over time.
• Internal approvals (Legal/Privacy/Exec) and documented sign-off.
• Press handling and patient/member support scripts. ¹

Exercise outputs should produce action items, updated templates, and updated decision worksheets.

Required evidence and artifacts to retain

Keep these in a controlled repository with access logging:

• Breach notification procedure (version-controlled) and related incident response references. ¹
• Breach determination worksheet for each qualifying incident (even if you decide “not reportable”).
• Incident timeline and investigation notes (sanitized as needed for privilege strategy).
• Notification matrix (HIPAA + state law mapping) and revision history. ¹
• Final notification copies, distribution lists, and proof of sending.
• Regulator submissions and confirmations/receipts.
• Media statement and publication evidence when applicable. ¹
• Third-party communications: incident reports, attestations, contractual notices, and coordination records.
• Training records for the team roles and tabletop after-action reports.

Common exam/audit questions and hangups

Expect auditors to ask:

• “Show me your breach notification procedure and the last time it was updated.” ¹
• “Walk through a recent incident. How did you determine whether it was a reportable breach?”
• “How do you ensure state breach laws are met for affected individuals in different states?” ¹
• “Who can approve a notification? What happens if Legal is unavailable?”
• “How do you handle third-party incidents? Show the evidence you received from the third party.” ¹
• “Where are your templates and contact lists stored, and how do you ensure they are current?”

Hangups that trigger follow-ups:

• No documented rationale for “not a breach.”
• Inconsistent numbers across HHS submission, individual letters, and internal incident ticket.
• No clear owner for state law tracking. ¹

Frequent implementation mistakes (and how to avoid them)

1. Procedure exists, but it’s not executable. Fix: add roles, decision gates, templates, and an evidence checklist tied to your ticketing system. ¹

2. State law treated as a postscript. Fix: maintain a state-law overlay matrix and make it a required step in breach determination. ¹

3. Third-party incidents stall your process. Fix: bake cooperation requirements into third-party contracts and set a standard “third-party incident intake” form. ¹

4. No evidence trail. Fix: require a breach determination worksheet and store drafts/finals of notices with proof of distribution.

5. Comms and compliance are misaligned. Fix: pre-approve language blocks and require Privacy/Legal sign-off before external publication.

Enforcement context and risk implications

HICP frames breach notification as an incident response discipline tied to HIPAA breach notification requirements and state breach laws. The operational risk is twofold:

• Regulatory risk: inability to demonstrate timely, compliant notification decisions and execution. ¹
• Litigation and reputational risk: inconsistent statements, inaccurate population counts, or delayed outreach can escalate downstream scrutiny.

Even when facts are incomplete early, regulators expect a controlled process that updates as evidence evolves. Your safest position is disciplined documentation and consistent internal governance.

Practical execution plan (30/60/90)

First 30 days (Immediate foundation)

• Assign the breach decision group, define decision authority, and publish an on-call roster.
• Draft the breach determination worksheet and evidence checklist.
• Inventory third parties that touch sensitive data; confirm breach cooperation clauses exist or open remediation items. ¹

By 60 days (Make it executable)

• Build the HIPAA + state-law notification matrix and set an update owner.
• Create notification templates, call scripts, regulator contact pack, and an internal comms plan. ¹
• Integrate the workflow into your incident ticketing system (required fields, approvals, and attachment requirements).

By 90 days (Prove it works)

• Run a tabletop focused on breach determination and multi-state notification routing. ¹
• Close gaps from the tabletop: template edits, missing contacts, unclear approvals, third-party escalation failures.
• Establish ongoing governance: periodic review of templates, contact lists, and the state-law matrix.

Where Daydream fits: Daydream can centralize third-party incident intake, track breach cooperation obligations, and keep notification artifacts (templates, approvals, evidence) attached to the underlying incident record for audit-ready retrieval.

Frequently Asked Questions

Do we need a separate procedure for HIPAA vs state breach laws?

You need one operational procedure with a state-law overlay. HICP Practice 8.4 expects compliance with HIPAA breach notification requirements and state breach laws in one workable workflow. ¹

Who should “own” breach notification procedures?

Compliance/Privacy typically owns the procedure content, while Security/IT owns incident technical response. The breach decision should be a defined forum with documented authority and a single owner for execution tracking. ¹

How do we handle a breach caused by a third party?

Your procedure should require immediate written facts from the third party and define who drafts and sends notices. Contract terms should support cooperation, fast reporting, and evidence sharing so you can meet HIPAA and state-law obligations. ¹

What evidence do auditors expect if we decide an incident is not a reportable breach?

Keep a completed breach determination worksheet with the inputs you reviewed, the rationale, and the approvers. Auditors commonly focus on consistency and documentation for “no notification” decisions. ¹

Where should templates and regulator contact lists live?

Store them in a controlled, versioned repository with restricted editing and clear ownership. Your incident process should point responders to the current versions to avoid outdated language during an event. ¹

How often should we test breach notification procedures?

Test often enough that new leaders, comms staff, and Security responders know the workflow and can execute it under pressure. Use an incident-response tabletop format focused on notification decisioning, state-law routing, and evidence capture. ¹

Footnotes

1. HICP 2023 - 405(d) Health Industry Cybersecurity Practices