Phishing Incident Response Checklist for Virtual Reality Therapy Vendors

How should staff report and contain a suspected phishing incident?

Treat a suspicious message, unexpected login prompt, or unusual VR platform alert as a potential security incident—even if no one is sure whether a link was opened or credentials were entered. Staff should report it immediately through the vendor’s designated security channel and contact the incident lead or on-call security contact. Do not reply to the message, click additional links, enter more information, or delete the original message.

• Record who received the message, when it arrived, and whether anyone clicked, downloaded a file, scanned a QR code, or entered credentials.
• Preserve the message and its headers, along with screenshots, suspicious URLs, and any relevant alerts. Use an approved method to share them with responders rather than forwarding suspicious attachments broadly.
• If credentials may have been exposed, use a trusted device and known-good route to contact IT. Responders can disable or secure the account, revoke active sessions and tokens, and require a password reset and appropriate multifactor authentication.
• If a device may have run malware, disconnect it from networks when safe to do so, but do not wipe or factory-reset it before responders consider evidence preservation and clinical impact.

HIPAA’s Security Rule requires covered entities and business associates to identify and respond to suspected or known security incidents, mitigate harmful effects where practicable, and document incidents and outcomes. The applicable duties depend on the vendor’s role: a VR therapy vendor is not automatically a covered entity or business associate simply because it serves healthcare clients. See the HHS summary of the HIPAA Security Rule and its guidance on reporting security incidents.

Which accounts, devices, systems, and data may be affected?

Start with the account or device mentioned in the report, then trace its access and connections. A single compromised mailbox or identity account may provide access to shared files, password resets, cloud consoles, support tools, or clinical systems.

• Accounts: email, identity provider and single sign-on, administrator and support accounts, clinician and patient accounts, cloud hosting, billing, and vendor portals.
• Devices: staff computers and phones, VR headsets, paired controllers, management tablets, and any endpoint used to administer or support the therapy environment.
• Systems and services: VR applications and backends, headset-management tools, telehealth platforms, electronic health record integrations, file storage, backup services, and email or messaging systems.
• Data: authentication records, session and treatment records, patient identifiers, clinical notes, support tickets, uploaded files, and any PHI accessible through affected accounts or devices.

Map what each affected identity could access and whether it had administrative privileges. Determine whether data was merely reachable or whether the evidence shows it was viewed, downloaded, changed, or transmitted. For VR systems, check both locally stored data and information held in connected cloud services. Do not assume that motion, voice, or session telemetry is PHI in every case; assess whether it identifies or can reasonably be linked to a patient and is maintained or handled in a regulated context.

An accurate inventory of devices, software, and ePHI flows can help responders determine the scope of exposure. HHS discusses these resources in its cybersecurity guidance on asset inventories and data-flow diagrams.

How should vendors preserve evidence and establish an incident timeline?

Preserve evidence before routine log rotation, device cleanup, or account changes erase useful records. Containment should still happen promptly; coordinate actions so responders capture relevant information without allowing an attacker to remain active.

• Retain the original phishing message, full email headers, URLs, attachments, screenshots, and user reports.
• Export relevant email, identity-provider, authentication, endpoint, firewall, cloud, VR-platform, headset-management, and clinical-system logs.
• Record account changes, password resets, session revocations, device isolation, support-provider actions, and any service interruption.
• For each evidence item, note what it is, where and when it was collected, who collected it, and how it was stored. Preserve the original export and restrict access to authorized investigators.

Build an incident timeline using a consistent time zone and note the source and confidence for each entry. Include the message’s arrival, any link or attachment activity, suspicious sign-ins, changes to accounts or permissions, potential access to data, detection, containment, and recovery. Mark unknown times as estimates rather than presenting them as confirmed facts.

CISA’s incident response playbook recommends collecting and preserving incident data and recording how, when, and by whom evidence was acquired. Adapt that approach to your organization’s systems and applicable obligations.

How should VR therapy vendors coordinate with service providers?

Identify which outside providers operate or support affected parts of the environment. This may include the email host, identity provider, cloud or data-storage provider, VR platform, headset-management service, telehealth or EHR vendor, managed security provider, and digital forensics team.

• Contact each provider through a verified support or security channel. Share a concise incident summary, relevant time window, affected accounts or devices, and specific requests for containment and log preservation.
• Ask providers to preserve relevant logs and confirm the time zone, retention period, and systems covered by their records.
• Coordinate session revocation, account restrictions, suspicious access review, and restoration so actions do not conflict or destroy evidence.
• Review contracts, security incident procedures, and business associate agreements (BAAs) for required contacts, reporting details, and timelines.

If the vendor is a business associate handling PHI for a covered entity, the BAA and HIPAA rules shape its reporting responsibilities. HHS explains that business associate contracts must address security incident reporting, and that the parties may set more specific or faster reporting terms in the contract. See HHS business associate contract guidance and its FAQ on cloud service provider incident reporting.

Notify affected healthcare customers promptly under the applicable agreement and keep them updated as the facts change. The covered entity or other responsible party should assess required regulatory and patient notifications; the vendor should not make unsupported assurances or issue notices on a customer’s behalf unless that role has been agreed and authorized. Consider involving legal counsel, the cyber insurer if the policy requires it, and law enforcement or relevant authorities when appropriate.

How can vendors assess patient information exposure and maintain care continuity?

Work with the healthcare customer’s privacy and security contacts to determine whether protected health information exposure is possible. Identify the data involved, the patients or sessions that may be affected, the people or systems that could have accessed it, and whether logs show that it was actually viewed, acquired, or disclosed.

For a HIPAA breach assessment, an impermissible use or disclosure of PHI is generally presumed to be a breach unless an exception applies or the responsible regulated entity demonstrates a low probability that the PHI was compromised through a risk assessment. HHS identifies factors including the nature and extent of the PHI, who received or used it, whether it was actually acquired or viewed, and how the risk was mitigated. See the HHS Breach Notification Rule guidance. A suspected phishing event alone does not establish that patient information was exposed.

Plan care continuity with clinical leaders rather than treating it as a purely technical decision. If a VR service, account, or headset is not trustworthy or available, follow the healthcare organization’s downtime procedures and use an approved alternative, such as a non-VR session or rescheduling when clinically appropriate. Keep clinicians informed through a verified communication channel, protect any temporary records, and do not return affected devices or systems to clinical use until the responsible technical and clinical leads approve them.

Under HIPAA, covered entities generally must provide required individual breach notices without unreasonable delay and no later than 60 days after discovery of a breach of unsecured PHI; a business associate must notify the covered entity under the applicable rule and contract. Contractual reporting deadlines may be shorter. The covered entity and its advisers should determine whether notices to individuals, HHS, or others are required. See HHS breach notification requirements.

What steps secure systems and monitor for further activity?

After preserving critical evidence and coordinating with providers, remove the attacker’s access and address the cause of the compromise. CISA recommends re-provisioning suspected or confirmed compromised accounts, auditing account access, and isolating affected workstations after phishing activity. See CISA’s phishing guidance.

• Reset affected credentials, revoke active sessions and tokens, remove unauthorized forwarding rules or app grants, and review changes to roles and recovery methods.
• Patch or reconfigure affected systems and remove malicious files or persistence mechanisms with qualified support. Rebuild a device when the investigation indicates that cleaning it is not sufficient.
• Restore from known-good backups only after checking their integrity and securing the accounts used to manage them.
• Increase post-incident monitoring for unusual sign-ins, repeated password-reset attempts, new administrator accounts, unexpected downloads, suspicious VR platform activity, and renewed messages using the same lure.
• Confirm that clinical workflows, integrations, access controls, and backups work as intended before returning affected systems to normal use.

Set monitoring duration and escalation criteria based on the investigation’s findings, system risk, and contractual or organizational requirements. Track suspicious activity across the vendor and relevant providers so a recurring attempt or a second compromised account is not treated as an unrelated event.

How should vendors document the incident and improve response procedures?

Maintain one controlled incident record that captures the initial report, investigation scope, incident timeline, affected systems and data, evidence collected, provider communications, containment and recovery actions, decisions, and unresolved questions. Separate confirmed facts from working hypotheses, and record who made key decisions and when.

For regulated entities, HIPAA requires documentation of security incidents and their outcomes. If a breach determination is made, preserve the supporting assessment and records of required notifications; if notification is not required, document the basis for that decision. HHS describes these documentation expectations in its Breach Notification Rule guidance.

After services are stable, review what enabled the phishing attempt and whether staff could report it quickly. Update the response checklist, provider contact list, evidence-retention steps, account-recovery process, and clinical downtime plan. Test the revised procedures with a scenario that includes a compromised identity account, a VR system or integration, and a possible PHI exposure. A clear incident timeline, coordinated third-party service provider response, and documented lessons learned help make the next response faster and more reliable.

FAQs

Who should a VR therapy vendor notify after a suspected phishing incident?

Notify the vendor’s security or incident-response contact and relevant leadership promptly. If a healthcare customer’s systems or data may be involved, contact that customer’s designated security and privacy contacts under the applicable agreement or BAA. Engage affected service providers through verified channels. The covered entity or other responsible party should evaluate any required patient, HHS, or other notifications; a vendor’s reporting duties depend on its role and contract.

How should compromised accounts or devices be contained?

Have responders disable or secure suspected accounts, revoke active sessions and tokens, reset credentials through a trusted route, and review account activity and permissions. Isolate a potentially infected device from networks when safe, but avoid wiping or factory-resetting it until evidence has been considered. Coordinate containment with clinical and technical leads to reduce unnecessary disruption to patient care.

What evidence should be preserved during a phishing investigation?

Preserve the original message and headers, suspicious URLs and attachments, user reports, relevant identity and email logs, endpoint and network records, VR platform and headset-management logs, and records of response actions. Document when and how each item was collected, who handled it, and where it is stored. Include timestamps and time zones so investigators can build a reliable incident timeline.

How can vendors maintain patient care if clinical systems are disrupted?

Follow the healthcare customer’s downtime procedures and coordinate alternatives with clinical leaders. Depending on the situation and clinical judgment, care may continue through an approved non-VR workflow or be rescheduled. Keep affected clinicians informed through a verified channel, protect temporary records, and do not return a questionable system or device to clinical use until it has been assessed and cleared by the responsible leads.