Spear Phishing Incident Response Checklist for Surgical Scheduling Databases

A spear phishing incident can put surgical scheduling systems, patient information, and care coordination at risk. Use this checklist to coordinate security, privacy, IT, and clinical operations teams while investigating suspected exposure of electronic protected health information (ePHI).

How should teams triage a suspected spear phishing email?

Start the incident response process as soon as someone reports a suspicious message, clicks a link, opens an attachment, or enters credentials. Assign an incident lead and notify the appropriate security, privacy, IT, legal, and clinical operations contacts under your organization’s response plan. HIPAA requires regulated entities to identify and respond to suspected or known security incidents, mitigate harmful effects where practicable, and document the incident and its outcome, as described in the Security Rule at 45 CFR § 164.308.

• Establish what happened, when it happened, who received the message, and whether anyone clicked, opened, replied, or submitted information.
• Preserve the original email in its native format, including full headers, sender and recipient details, timestamps, links, and attachments. Record who collected it and when; avoid circulating the message by ordinary forwarding.
• Save relevant email security alerts, identity-provider records, endpoint detections, and other logs before routine retention limits remove them.
• Use approved security tools to inspect links and attachments. Do not open suspicious files or visit links from a workstation used for patient care.
• Search mailboxes for related messages, similar sender addresses, matching subject lines, and recipients who may have received the same campaign.

Ask the recipient what they did, but avoid blame: a timely report can help limit impact. CISA advises reporting suspicious messages through the organization’s established IT or security process; see its phishing guidance.

Which accounts and credentials should be contained first?

Prioritize accounts that may provide access to the scheduling database, email, identity and access management (IAM) systems, remote access, or administrative tools. Use a clean administrative workstation and verified contact channels when coordinating containment so the response does not rely on a potentially compromised account.

• Disable or temporarily restrict a confirmed compromised account, applying your organization’s emergency access and patient-care procedures.
• Reset the affected user’s password and revoke active sessions, including session and refresh token revocation where the identity platform supports it. Password changes alone may not end existing sessions.
• Review and secure privileged, service, and shared accounts that the affected user could access. Rotate exposed secrets or credentials according to your incident plan.
• Check multifactor authentication (MFA) methods, recent enrollment or recovery changes, unfamiliar devices, suspicious sign-ins, and unusual authentication challenges.
• Inspect the user’s mailbox for unauthorized delegates, inbox rules, external auto-forwarding, and changes to recovery or security settings. Remove unauthorized changes after preserving evidence.

Apply IAM controls proportionately: preserve necessary clinical access where safe, but prevent the suspected attacker from retaining access. Document each containment action, its time, the account or system affected, and any operational effect.

How can teams assess access to surgical scheduling records and ePHI?

Build a timeline that connects the email event to identity, email, endpoint, application, database, and network activity. Review available audit logs and access reports for the affected accounts and systems; the HIPAA Security Rule requires audit controls for systems containing or using ePHI and regular review of information-system activity. See 45 CFR § 164.312 and 45 CFR § 164.308.

• Determine whether the user accessed the scheduling database, patient lists, operating-room calendars, interfaces, exports, reports, or backups.
• Look for unusual sign-in locations or times, access outside the person’s normal role, repeated failed logins, bulk searches, downloads, exports, edits, and changes to appointments or patient details.
• Correlate application and database events with identity-provider sign-ins, MFA records, email access, endpoint alerts, VPN or remote-access sessions, and firewall or cloud-service logs.
• Investigate whether messages or data were forwarded, downloaded, printed, copied to removable media, or sent to external destinations.
• Record gaps in logging or retention. An absence of available evidence does not by itself establish that no access occurred.

Work with the privacy officer to assess whether the information involved is PHI and whether an impermissible access or disclosure may have occurred. For an impermissible use or disclosure of unsecured PHI, HIPAA generally presumes a breach unless the regulated entity demonstrates a low probability that the PHI was compromised through the required risk assessment. HHS identifies factors including the information’s nature and extent, the recipient, whether the information was actually acquired or viewed, and mitigation. See the HHS Breach Notification Rule guidance.

What endpoint and network containment steps help limit spread?

Coordinate containment with incident responders and clinical operations. If a device is suspected of compromise, isolate it from the network using approved tools when feasible, while considering patient-care effects. Preserve volatile evidence and relevant logs before actions that could erase or alter them; CISA’s incident response guidance discusses evidence preservation and containment.

• Quarantine affected endpoints through endpoint detection and response or network controls; do not wipe or reimage them before evidence collection unless an urgent safety need requires it.
• Block confirmed malicious sender domains, URLs, file hashes, and indicators of compromise at email, endpoint, DNS, and network controls, as appropriate.
• Remove the phishing message from other mailboxes after preserving the original and necessary investigation records.
• Check for suspicious software, browser extensions, scheduled tasks, remote-access tools, and unauthorized changes on affected devices.
• Review connected systems and third-party services for signs of lateral movement or compromised access. Coordinate with vendors that host or support affected systems.

Keep a record of containment decisions and the systems affected. Avoid shutting down or disconnecting equipment in ways that could disrupt care or destroy useful evidence without first considering the consequences with the response lead.

How can surgical scheduling continue safely during response?

Clinical and operational leaders should decide whether to activate clinical downtime procedures based on the availability and trustworthiness of scheduling systems, the scope of the incident, and the risk to patients. If an affected system cannot be trusted, use the approved downtime process rather than relying on unverified records or improvised workarounds.

• Use approved downtime forms, communication channels, and authorized access procedures to coordinate cases and communicate schedule changes.
• Confirm patient identity, procedure details, timing, and required resources through reliable sources and established verification steps.
• Limit access to paper or offline records to authorized personnel, and protect them from loss, unauthorized viewing, and disclosure.
• Maintain a clear record of changes, cancellations, rescheduling decisions, and communications so information can be reconciled when systems are restored.
• Set a defined process for reconciling downtime records with the validated system of record and checking for duplicate or conflicting entries.

HIPAA contingency planning includes procedures for emergency-mode operations that allow critical business processes to continue while protecting ePHI. CMS emergency-preparedness guidance also identifies communications interruptions, including cyberattacks, as hazards for providers. See the HIPAA Security Rule and CMS core emergency preparedness elements.

What recovery, reporting, and follow-up actions are required?

Restore affected systems only after responders have addressed the cause of compromise, verified the integrity of the systems and data, and obtained approval through the organization’s recovery process. Confirm that access controls, monitoring, backups, and vendor connections are functioning as expected before returning scheduling workflows to normal.

• Validate restored scheduling data against trusted records, investigate unexplained changes, and reconcile all downtime entries.
• Continue audit log review for suspicious access after restoration, and preserve incident records, evidence, decisions, and recovery steps.
• Notify affected business associates and vendors as required by contracts and applicable rules; coordinate with them on containment, evidence, and reporting.
• Have the privacy officer and counsel complete and document a breach notification assessment. Consider applicable federal, state, contractual, and other reporting obligations based on the facts.
• Document lessons learned, update response and downtime procedures, and address gaps in email security, IAM, logging, training, or access management.

Under HIPAA, covered entities must notify affected individuals after a breach of unsecured PHI without unreasonable delay and no later than 60 days after discovery. Breaches affecting 500 or more individuals must also be reported to HHS without unreasonable delay and within 60 days; breaches affecting fewer than 500 individuals are generally reported to HHS within 60 days after the end of the calendar year in which they were discovered. Additional media notice may apply when a breach affects more than 500 residents of a state or jurisdiction. Business associates must notify the covered entity under applicable requirements. Review the HHS Breach Notification Rule and HHS reporting instructions; involve privacy and legal professionals to determine which requirements apply.

In summary: Preserve evidence, contain compromised identities and devices, assess access to scheduling records and ePHI, protect continuity of surgical care, and document recovery and breach notification decisions.

FAQs

What evidence should be preserved from a spear phishing email?

Preserve the original message in its native format, including full headers, sender and recipient information, timestamps, links, and attachments. Also retain relevant mailbox, identity, endpoint, application, and network logs, along with a record of collection and handling. Coordinate evidence collection with your security or forensic team.

How can teams determine whether surgical scheduling records were accessed?

Correlate audit logs from the scheduling application and database with identity-provider, email, endpoint, VPN, and network records. Look for unusual logins, access outside the user’s role, searches or exports, downloads, edits, and external transfers. Document logging gaps and consider the evidence as part of the privacy officer’s breach notification assessment.

When should clinical downtime procedures be activated?

Activate them when clinical and operational leaders determine that scheduling systems are unavailable, potentially compromised, or cannot be trusted for safe use. Follow your organization’s established escalation and downtime procedures, use approved verification steps, and keep a record of changes for reconciliation after recovery.

What reporting obligations may apply after suspected ePHI exposure?

Reporting depends on whether the investigation establishes a breach of unsecured PHI and which rules apply to the organization and incident. HIPAA may require notice to affected individuals, HHS, and—in certain circumstances—the media; business associates may have notice duties to covered entities. State laws, contracts, and other requirements may also apply. Have the privacy officer and legal counsel assess the facts and deadlines; suspicion alone does not determine whether a reportable breach occurred.