Incident Communication Plan

To meet the HICP Practice 8.8 incident communication plan requirement, you need a written, role-based playbook that defines who communicates what, to whom, through which channels, and on what triggers for internal stakeholders, patients, regulators, media, and business partners during and after a cybersecurity incident. The plan must be executable under pressure, with pre-approved templates, contact lists, and decision rights. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

Key takeaways:

• Your plan must cover five audiences explicitly: internal stakeholders, patients, regulators, media, and business partners. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)
• “Communication plan” means operational details: triggers, approvals, timing logic, channels, and message templates, not a policy statement.
• Evidence matters: retain the plan, approvals, training/testing records, and incident communication logs that prove the plan works in practice.

An incident communication plan is one of the fastest ways to reduce confusion, contain reputational damage, and avoid missteps that create secondary compliance exposure after a security event. HICP Practice 8.8 is narrowly worded but operationally demanding: it expects you to establish a plan that covers communications to internal stakeholders, patients, regulators, media, and business partners. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

For a Compliance Officer, CCO, or GRC lead, the goal is not to write prose. The goal is to make incident communications repeatable: decisions are made by the right people, messages are consistent across audiences, and communications happen on the right triggers without improvisation. This page translates the requirement into an implementable playbook, with the minimum artifacts you need to show an auditor and the practical “hangups” that cause plans to fail in real incidents.

HICP is a healthcare-focused cybersecurity practices framework published by HHS under the 405(d) program. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices) Even when it is not contractually mandated, many healthcare organizations use it as a defensible “reasonable security” reference point. Treat Practice 8.8 as a requirement to operationalize communications as part of incident response, not as a PR exercise.

Regulatory text

Requirement (excerpt): “Establish an incident communication plan covering internal stakeholders, patients, regulators, media, and business partners.” (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

Operator interpretation: You must have a documented incident communication plan that (1) explicitly includes each of the five audiences listed, and (2) defines how and when communications occur during and after cybersecurity incidents. “Establish” implies the plan exists, is approved, and is ready to run; a draft that is not owned, not tested, or missing contact paths is not established in practice. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

Plain-English interpretation (what the requirement really expects)

You need a communications “runbook” that works during an incident bridge call. It should answer, without debate:

• Who is allowed to speak externally, and who is not.
• Who approves patient notifications, regulator notifications, and partner notifications.
• What triggers patient/regulator/partner communications (for example, “confirmed incident with potential patient impact”).
• How you coordinate facts across Security/IT, Privacy, Legal, Compliance, Operations, and Communications.
• What you say when you do not yet know root cause or full scope (and how you avoid speculation).

HICP Practice 8.8 is explicit about audiences. If your plan covers “external communications” generically but does not call out patients, regulators, media, and business partners, you are exposed on a plain reading of the requirement. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

Who it applies to

Entity types: Healthcare organizations and health IT vendors. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

Operational context where this becomes mandatory in practice:

• You handle patient data, clinical operations, or systems that affect patient care continuity.
• You rely on third parties for EHR/hosting, billing, managed security, call centers, transcription, labs, or other services that can be impacted by an incident.
• You have contractual duties to notify customers/business partners of incidents (common in BAAs and security addenda), even when the framework itself is not “law.”

Teams that must co-own execution:

• Incident Response lead (Security/IT)
• Privacy and Compliance (patient-facing impact analysis and notification governance)
• Legal (privilege, risk posture, contractual/regulatory interpretation)
• Communications/PR (media handling, holding statements)
• Customer Success / Partner Management (business partner communications)
• Clinical/Operations leadership (patient safety impacts and operational messaging)

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

Use this build sequence so you end with an executable plan, not a document.

1) Define scope and activation triggers

Write down:

• What counts as an “incident” for activating communications (tie it to your incident severity scheme).
• Who can declare activation (primary and backup).
• What “during and after” means in your environment: during active containment; after stabilization; post-incident reporting and partner follow-ups. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

Deliverable: “Activation criteria” section in the plan with a simple decision tree.

2) Assign decision rights and roles (RACI that can run on a bridge)

At minimum, define:

• Spokesperson authority: Who can speak to media; who can speak to regulators; who can speak to patients; who can speak to business partners.
• Approvals: Who approves outbound statements and notifications (and a backup approver).
• Single source of truth: Who maintains the incident fact pattern and timestamps (often the IR lead plus Legal/Compliance reviewer).

A practical pattern: Security owns technical facts; Compliance/Privacy owns patient-impact assessment; Legal owns risk and privilege strategy; Comms owns language and channel execution. Your plan should state this explicitly.

Deliverable: one-page “roles and approvals” table.

3) Build audience-specific communication tracks

Create a dedicated subsection for each required audience. Each subsection should include: purpose, trigger, channel(s), approver(s), and message templates.

A. Internal stakeholders

• Audience: executive leadership, board liaison, IT ops, clinical leadership, front desk/call center, HR, affected business owners.
• Goals: align operations, prevent rumors, control information sprawl.
• Include: internal talking points, “do not speculate” guidance, escalation path for patient safety concerns.

B. Patients

• Audience: impacted patients and patient representatives.
• Goals: provide accurate, actionable guidance; set expectations for updates.
• Include: patient-facing templates written for clarity, a call center/FAQ plan, and a mechanism to correct misinformation.

C. Regulators

• Audience: relevant oversight bodies based on incident type and data involved.
• Goals: timely, accurate notification; consistent statements across agencies; preservation of required records.
• Include: who owns regulator interface, what minimum facts must be validated before outreach, and how you document interactions.

D. Media

• Audience: press and public inquiries.
• Goals: prevent contradictory messaging; respond consistently; route inquiries quickly.
• Include: a holding statement template, inbound inquiry triage, and a strict “only these roles respond” rule.

E. Business partners (including third parties and customers)

• Audience: customers, downstream providers, payers, integrating partners, critical third parties.
• Goals: enable partner risk decisions (containment actions, credential resets, interface shutdowns), meet contractual duties, and reduce churn.
• Include: partner notification workflow, secure delivery method, and a “partner FAQ” template.

This five-track structure directly maps to the requirement language, which makes audits easier. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

4) Create and maintain a contact and channel inventory

Your plan fails if contact data is stale. Maintain:

• Named distribution lists for leadership, IR team, privacy/legal/comms.
• Regulator contact points (role-based inboxes where possible).
• Media intake mailbox and phone script.
• Partner escalation contacts (primary and backup) for critical partners.

Also define approved channels (secure email, portal message, phone bridge) and rules for sensitive content (what can be shared, what must be redacted).

Deliverable: controlled contact annex with an owner and refresh cadence.

5) Pre-approve templates and “minimum facts” checklists

Build templates that speed execution:

• Internal incident update (short, timestamped, action-oriented)
• Patient notice skeleton
• Regulator notice skeleton
• Media holding statement
• Partner notification and technical advisory (IOCs, required customer actions, containment steps)

Add a “minimum facts to confirm” checklist to reduce retractions:

• What happened (known facts only)
• Systems impacted
• Whether patient data may be involved (state uncertainty clearly)
• Actions taken so far
• What recipients should do now
• When you will update again

6) Integrate with incident response and third-party workflows

Connect the communication plan to:

• Your incident severity process (so comms activates automatically at defined thresholds)
• Your ticketing/IR tooling (so communications are logged and timestamped)
• Third-party incident intake (so partner-sourced incidents trigger your comms workflow)
• Legal hold and evidence preservation (so communications drafts and approvals are retained)

If you use a GRC workflow tool like Daydream, this is where it helps: map each audience track to a task checklist, require approvals before sending, and automatically collect artifacts (templates used, timestamps, approvers, distribution lists) into an audit-ready record set.

7) Test it and train the humans

A plan is “established” only if people can run it.

• Run tabletop exercises that force decisions: “media calls first,” “partner reports incident before you detect,” “patient safety disruption rumor on social media.”
• Train call center/frontline staff on routing and scripts.
• Capture lessons learned and update templates.

Required evidence and artifacts to retain

Auditors typically ask for proof that the plan exists, is approved, and is used. Maintain:

• Incident Communication Plan document (current version) with owner and approval history. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)
• Role/approval matrix (RACI) for all five audiences. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)
• Current contact lists and channel inventory, with change log.
• Message templates (internal, patient, regulator, media, partner) and “minimum facts” checklists.
• Training records (who was trained, what content, when).
• Exercise records (scenario, attendees, gaps found, remediation tasks).
• For real incidents: communications log (what was sent, to whom, when, by whom, approval evidence, and copies of messages).

Common exam/audit questions and hangups

Expect questions like:

• “Show me where patients are addressed in the plan.” (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)
• “Who is authorized to speak to the media, and how do you enforce that?”
• “How do you decide when to notify business partners?”
• “Where are your regulator contact procedures documented?”
• “Show evidence from your last incident or tabletop that the plan was followed.”

Hangups that slow audits:

• Templates exist but are not controlled (no versioning, no approvals).
• Contact lists are spread across personal inboxes and spreadsheets with no owner.
• “External communications” is centralized in PR, but Security/Privacy can bypass it during an emergency.

Frequent implementation mistakes (and how to avoid them)

1. A single generic “external comms” section. Fix: build five distinct audience tracks that mirror HICP’s wording. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)
2. No decision rights. Fix: write down approvers and backups; test in a tabletop where the primary approver is unavailable.
3. Overpromising in early statements. Fix: require the “minimum facts” checklist and prohibit speculation in templates.
4. Partner communications treated as procurement-only. Fix: include technical advisories and secure delivery methods; partner teams must coordinate with Security.
5. No proof of execution. Fix: log every incident communication like you log incident actions, and retain approvals.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Operationally, the risk is still real: inconsistent statements across patients, partners, and public channels create credibility gaps and can expand legal and contractual exposure. A strong communication plan reduces the chance that well-intentioned staff share unverified details or miss key audiences explicitly named by the framework. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

Practical execution plan (30/60/90-day)

First 30 days (Immediate build)

• Name an owner and backups (Security + Compliance/Privacy + Comms).
• Draft the plan structure with the five audience tracks. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)
• Create a roles/approvals table and a simple activation decision tree.
• Stand up controlled contact lists and define approved channels.
• Produce first-pass templates: internal update, media holding statement, partner notice, patient notice skeleton, regulator notice skeleton.

Day 31–60 (Operationalize)

• Run a tabletop focused on communications failure modes (media inquiry, partner escalation, patient confusion).
• Update templates and decision logic based on lessons learned.
• Train frontline intake teams (help desk, call center, partner support) on routing scripts.
• Integrate the comms checklist into your incident response workflow so it triggers automatically at defined severities.

Day 61–90 (Prove and harden)

• Conduct a second exercise with a different scenario (third-party incident, ransomware disruption, suspected data exposure).
• Audit your artifacts: plan versioning, approvals, contact list ownership, log retention.
• Create a standing “post-incident communications review” step in lessons learned.
• If you use Daydream or another GRC workflow tool, automate evidence capture so each incident produces an audit-ready communication record without manual chasing.

Frequently Asked Questions

Do we need separate plans for cybersecurity incidents versus other incidents (e.g., power outages)?

HICP Practice 8.8 is focused on incident response under cybersecurity practices. You can keep one enterprise plan if it clearly covers cybersecurity triggers and includes the required audiences. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

Who should own the incident communication plan: Security, Compliance, Legal, or PR?

Put a single accountable owner on the document, but split execution ownership by audience. Security should not own patient messaging alone, and PR should not approve technical statements without Security review.

What if we don’t know whether patients are affected yet?

Your templates should support “known facts only” messaging and set expectations for updates. The plan should require a minimum-facts check before external outreach and should prohibit guessing about scope.

How do we handle communications when a third party causes the incident?

Your plan should include partner notification workflows and a process to reconcile statements with the third party while still meeting your own obligations. Treat third-party incidents as a standard activation trigger in your internal process.

Can we point all media inquiries to Legal and refuse to comment?

You can route inquiries through Legal, but the plan should still define media intake, triage, and authorized spokespersons. “No comment” without a process often results in inconsistent off-script responses.

What evidence should we have if we haven’t had a real incident recently?

Keep tabletop and training records, approved templates, and controlled contact lists. Auditors typically accept exercises as proof the plan is established and executable.