Phishing Simulation and Training

The phishing simulation and training requirement in HICP Practice 1.4 means you must run recurring phishing simulations and deliver targeted remedial training to employees who fail (for example, click, open attachments, submit credentials, or report incorrectly). To operationalize it fast, define “regular,” build a repeatable campaign and remediation workflow, and retain evidence that proves simulations occurred and failed users received training. ¹

Key takeaways:

• Run recurring phishing simulations with documented scope, cadence, and scenarios, tied to your email threat model. ¹
• Provide targeted training to employees who fail simulations, and document completion and outcomes. ¹
• Keep audit-ready artifacts: campaign logs, failure definitions, training assignments, completion records, and exception handling. ¹

HICP Practice 1.4 is a requirement you can operationalize without rewriting your entire security program. The control is narrow: test user susceptibility through phishing simulations, then train the people who demonstrate risky behavior in those simulations. The value for a Compliance Officer or GRC lead is straightforward: this is measurable, repeatable, and easy to evidence if you set it up correctly.

The hard part is not sending fake phish emails. The hard part is defining what “regular” means for your organization, deciding what counts as a “fail,” ensuring training is targeted (not generic annual training), and proving that the workflow runs consistently across departments, locations, roles, and third parties with workforce access. You also need to handle edge cases: shared mailboxes, clinical shift workers with limited training time, and employees who repeatedly fail.

This page gives requirement-level implementation guidance you can use to stand up a defensible program quickly: scope, roles, step-by-step execution, evidence to retain, audit questions you should expect, and common mistakes that cause programs to fail in practice. All guidance is anchored to HICP Practice 1.4. ¹

Regulatory text

Requirement (HICP Practice 1.4): “Conduct regular phishing simulation exercises and provide targeted training to employees who fail simulations.” ¹

Operator interpretation (what you must do):

1. Run phishing simulations on a recurring basis. “Regular” is not defined in the excerpt, so you must define it in your standard (cadence + triggers) and follow it consistently. ¹
2. Identify simulation failures (your failure criteria must be documented and consistently applied). ¹
3. Deliver targeted training to failures. The training must be tied to the behavior observed and assigned to the specific employees who failed, with completion tracking. ¹

Plain-English requirement statement

You must repeatedly test your workforce with realistic phishing simulations, then retrain the people who fall for them, and keep proof that both activities happened. ¹

Who it applies to

Entity types: Healthcare organizations and health IT vendors. ¹

Operational scope (who should be in-scope in practice):

• All workforce members with email access, including clinical and non-clinical staff, executives, interns, volunteers, and temporary staff if they use corporate email.
• Privileged users and high-risk roles (finance, HR, revenue cycle, IT admins, contact center) should be included in the same program but may require role-specific scenarios and tighter remediation.
• Third parties with enterprise email accounts or equivalent access (contractors, managed services staff, outsourced billing) should be covered either through your program or via contractually required equivalent controls, with evidence.

Where teams trip up: limiting simulations to corporate staff while excluding clinics, acquired entities, or contractors with mailboxes. That becomes a “program integrity” issue during audit because the requirement is framed at the employee level, not the headquarters level. ¹

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

1) Define your standard: cadence, failure criteria, and remediation SLAs

Document a short internal standard that answers:

• Cadence definition: what “regular” means (for example, recurring campaigns plus off-cycle simulations after major incidents or onboarding waves). ¹
• Failure criteria: what counts as a “fail” (clicked link, entered credentials, enabled macros, replied with data, or did not report using the approved method). Keep it objective and tool-verifiable. ¹
• Targeted training rules: which training module maps to which failure type, who assigns it, and how completion is tracked. ¹
• Exceptions: how you handle shared inboxes, break-glass accounts, and staff on leave.

Keep this standard short enough that you can follow it. Auditors reward consistency.

2) Establish ownership and separation of duties

Set clear roles:

• Program owner: security awareness lead or GRC, accountable for cadence and reporting.
• HR/Learning admin: supports training assignment and completion tracking.
• IT/email admin: ensures simulation deliverability and safe-listing, without weakening real email security.
• Privacy/Compliance: reviews scenarios to avoid collecting sensitive information and to keep simulations appropriate for clinical settings.

3) Select or configure your simulation platform and training workflow

Minimum capabilities you need:

• Campaign scheduling and segmentation (by department, role, location).
• Multiple templates and landing pages.
• Event logging (delivered/opened/clicked/submitted/reported).
• Automated assignment of remedial training to failing users.
• Reporting exports for audit evidence.

If you manage this in Daydream, treat it like a control with two linked workflows: “Simulation Campaign” and “Remedial Training Assignment.” The operational win is consistent evidence capture: campaign metadata, failure events, assignment logs, and completion records stored in one place.

4) Build scenarios that reflect your email threat model

Create a small library of scenarios that match healthcare realities:

• Invoice/payment change requests (revenue cycle).
• Shared document links (clinical collaboration).
• Password reset/MFA prompts (IT helpdesk).
• Package delivery or scheduling notices (front desk).

Avoid scenarios that could be confused with real patient communications or that pressure clinical staff in ways that disrupt care operations. You want learning, not chaos.

5) Execute campaigns and track outcomes

Run campaigns per your cadence definition and record:

• Target population and exclusions (with reason).
• Templates used and why.
• Delivery constraints (e.g., acquired domain limitations).
• Results by group and by failure type. ¹

Operational note: trend reporting matters more than a single campaign result. Auditors often ask whether you adjust training based on observed failure modes.

6) Provide targeted training to employees who fail

This is the second half of the requirement and commonly under-implemented.

A defensible remediation workflow:

1. System flags failure event. ¹
2. User is assigned a short, targeted module tied to the failure (credential entry, link clicking, data sharing). ¹
3. Completion is tracked; non-completion triggers escalation to manager/HR per policy.
4. Repeat failures trigger enhanced coaching or additional controls (for example, higher-friction authentication prompts for that user group), aligned with your HR policies.

“Targeted” means the training content maps to the risky behavior demonstrated, not a generic annual CBT refresher. ¹

7) Close the loop: improve controls, not just users

Use simulation findings to drive operational improvements:

• Update email banners for external senders.
• Tune phishing reporting button workflows.
• Improve helpdesk scripts for “I clicked” events.
• Adjust new-hire onboarding content based on top failure modes.

This supports a credible story that the program reduces risk over time, even if user error never reaches zero.

Required evidence and artifacts to retain

Keep evidence that proves (a) simulations are regular and (b) targeted training occurs after failures. ¹

Minimum artifact list (audit-ready):

• Phishing simulation standard (cadence, failure definitions, remediation requirements). ¹
• Campaign calendar or schedule and campaign approvals (as applicable).
• Campaign configurations: target groups, templates, launch dates, exclusions with rationale.
• System-generated campaign results reports (events + summary).
• Failure event logs mapped to user IDs.
• Training assignment rules (mapping failure type → module).
• Training completion records, including timestamps and escalation records for non-completion.
• Evidence of program oversight: periodic metrics review notes, risk committee reporting, or management sign-off on changes.

Retention approach: align with your broader security training and audit log retention practices. The key is that you can reproduce what happened for a given campaign without relying on someone’s inbox memory.

Common exam/audit questions and hangups

Expect questions like:

• “Define ‘regular.’ Where is it documented?” Show your standard and campaign history. ¹
• “Who is included? Any exclusions?” Be ready to explain exclusions with compensating controls.
• “What counts as a fail?” Provide objective criteria and the system reports that measure it. ¹
• “Show me targeted training for failed users.” Auditors often sample named users and request assignment + completion proof. ¹
• “How do you handle repeat offenders?” Point to escalation paths and HR alignment.
• “How do you ensure simulations don’t weaken email security?” Explain safe-listing controls and change management.

Frequent implementation mistakes (and how to avoid them)

1. Running simulations but not enforcing remedial training. Fix: automate assignment and escalation, then test it with a sample failure. ¹
2. No written definition of “regular.” Fix: define cadence and triggers in a one-page standard; follow it. ¹
3. Overly punitive tone that drives under-reporting. Fix: separate “learning simulations” from disciplinary processes, except for repeated or egregious cases under HR policy.
4. One-size-fits-all scenarios. Fix: segment by role and use scenarios aligned to real workflows.
5. Poor evidence hygiene. Fix: centralize artifacts, export reports after each campaign, and keep a running control log.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so treat this as a framework-driven expectation rather than a specific cited enforcement pattern. ¹

Risk implications still matter operationally:

• Phishing remains a common initial access path for credential theft and email compromise in healthcare environments.
• If you cannot prove targeted remediation, an assessor can reasonably conclude the program is performative rather than risk-reducing.

Practical 30/60/90-day execution plan

First 30 days (stand up the control)

• Publish the phishing simulation and remedial training standard (cadence, failure criteria, training mapping). ¹
• Confirm in-scope populations, including third parties with enterprise accounts.
• Configure tooling and evidence capture (reports, exports, ownership).
• Run a pilot campaign with one or two departments; validate deliverability and logging.
• Test the remediation workflow end-to-end by intentionally failing a small set of test users and confirming training assignment and completion tracking. ¹

By 60 days (operationalize and prove repeatability)

• Expand to broader segments, including at least one high-risk function (finance or IT).
• Implement manager notification and HR escalation for non-completion.
• Establish monthly or quarterly reporting to a governance forum (security committee, risk committee, or equivalent).
• Document exception handling (leave, shared mailboxes, clinical shift constraints).

By 90 days (mature and optimize)

• Add scenario diversity and role-based content; retire templates that create confusion or false complaints.
• Implement repeat-failure handling (coaching, additional training, tightened technical controls as appropriate).
• Perform a mini-audit: sample users who failed and confirm you can produce simulation evidence and targeted training evidence quickly. ¹
• If you are managing the program in Daydream, standardize control evidence exports and map them to your audit request list so evidence collection is push-button instead of a scramble.

Frequently Asked Questions

What does “regular” phishing simulation mean under HICP Practice 1.4?

The excerpt does not define a specific cadence, so you must define “regular” in a written standard and then follow it consistently. Auditors will judge “regular” by whether your history matches your documented cadence. ¹

What counts as “fail” for the purpose of targeted training?

Define failure criteria that your platform can measure consistently, such as clicking a link, submitting credentials, replying with information, or failing to report via the approved method. Document the criteria and use the same definitions across campaigns. ¹

Do we have to train everyone or only employees who fail?

HICP Practice 1.4 specifically requires targeted training for employees who fail simulations. You can still run baseline training for everyone, but the control must include documented remedial training for failures. ¹

How should we handle executives and clinicians who resist simulations?

Include them in scope and adjust scenarios to fit their workflows and patient care realities. If you approve exclusions, document the rationale and apply compensating measures, then revisit periodically.

Can third parties be included in our simulations?

If third parties have your email accounts or equivalent access, treat them as in-scope for the control or require equivalent simulation and targeted training through contract terms. Keep evidence either way.

What evidence is most often requested in an audit?

Auditors typically ask for campaign schedules and results, plus a sample of users who failed and proof they were assigned and completed targeted training. Keep exports and completion logs ready to produce. ¹

Footnotes

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