Virtual Reality Therapy Vendor Security Risk Assessment: A Practical Guide

What data does a VR therapy system collect and how sensitive is it

Start by listing every data type the system collects, creates, receives, or transmits. Depending on the product, this may include patient identifiers, diagnoses, treatment plans, session notes, progress scores, headset and controller movements, gaze or eye-tracking data, voice recordings, and device or usage logs. Confirm which data are collected by the headset, the vendor’s app, cloud services, and any connected clinical systems.

Some systems may perform biometric data processing or capture behavioral signals that could reveal sensitive information. Do not assume every movement or sensor reading is automatically protected health information (PHI): HIPAA PHI generally involves individually identifiable health information held or transmitted by a covered entity or its business associate. Assess identifiability, clinical context, and who handles the data. HHS’s explanation of protected health information describes the relevant definition.

Ask the vendor for a data inventory that identifies each field, its purpose, whether collection is optional, how long it is retained, and whether it is used for analytics, product improvement, or advertising. Verify that the organization can disable unnecessary collection and that the vendor does not treat therapy-related data as low risk merely because a field lacks a patient’s name.

How does the vendor process store retain and share patient data

Trace data from the headset through the app, network, vendor platform, backups, support tools, and any electronic health record integration. Identify where processing occurs, which subcontractors can access the information, and whether data are copied to diagnostic logs or support tickets. Confirm who can export, correct, or delete records and how deletion applies to backups and derived data.

Review data residency separately from security controls. HIPAA does not impose a general U.S.-only storage rule for ePHI, but HHS advises organizations to account for the risks and legal considerations of overseas processing in their risk analysis. Ask the vendor to identify storage and support locations, the entities that may access data, and any contractual or legal limits on that access. HHS guidance on overseas cloud storage explains this distinction.

Verify encryption at rest and in transit, how encryption keys are managed, and whether data remain encrypted on local devices and removable media. Ask for the retention schedule and deletion process in writing, including how the vendor handles returned or destroyed data when services end. HIPAA requires appropriate safeguards and procedures for electronic PHI disposal, but does not prescribe one specific disposal method. HHS disposal guidance provides further detail.

Which cybersecurity threats could disrupt therapy or put patients at risk

Consider threats to confidentiality, integrity, and availability. Examples include stolen staff credentials, excessive account privileges, exposed cloud storage, lost headsets, malicious software, unpatched devices, compromised vendor or subcontractor systems, and ransomware that blocks access to therapy records or sessions. A modified treatment plan, session configuration, or VR scene may also create an integrity risk even if no data are stolen.

Assess the operational path from a security incident to a clinical consequence. For example, a service outage could interrupt a scheduled session, while unauthorized changes to content or settings could make a session unsuitable for a patient. HHS says a HIPAA risk analysis should evaluate risks and vulnerabilities to ePHI confidentiality, integrity, and availability, including relevant systems and vendors. HHS risk analysis guidance offers a framework for that assessment.

Include physical and clinical hazards alongside cyber threats. FDA identifies potential AR/VR risks such as cybersickness, dizziness, fatigue, vision effects, head and neck strain, privacy risks, and collisions or falls. Consider whether a security incident could disable safeguards, interrupt clinician oversight, or expose patients to altered content. FDA’s overview of AR/VR medical-device benefits and risks describes these types of concerns.

What security controls should an organization verify

Verify that access is limited to people who need it for their work. Ask whether the platform supports unique user accounts, multifactor authentication, timely account removal, and role-based access control for clinicians, administrators, vendor support staff, and other users. Check whether the organization can review access and whether the system records administrative actions and access to patient data.

Review safeguards for devices, networks, and information. These may include encryption at rest and in transit, secure configuration, device locking, protection against unauthorized software, network segmentation, secure update procedures, and tested backups. Confirm that the vendor has a documented vulnerability management process covering discovery, prioritization, remediation, and customer notification for relevant security issues.

Ask how the vendor monitors security events, investigates incidents, restores services, and tests recovery plans. Match the evidence to your organization’s risk assessment rather than relying on a general claim that the product is “secure.” HHS identifies access control, audit controls, authentication, integrity, and transmission security among the HIPAA Security Rule’s technical safeguards. HHS’s HIPAA Security Rule summary explains the broader requirement to use reasonable and appropriate safeguards.

How should vendor contracts and compliance requirements be assessed

First determine the vendor’s role. If it creates, receives, maintains, or transmits PHI on behalf of a covered entity or another business associate, it may be a business associate; the relationship and services matter, not the vendor’s marketing language. When a business associate relationship applies, review whether a business associate agreement (BAA) covers permitted uses and disclosures, safeguards, subcontractors, incident reporting, and return or destruction of PHI when the agreement ends. HHS’s sample BAA provisions identify topics a written agreement must address.

Review breach notification obligations carefully. Under HIPAA, a business associate must notify the covered entity of a breach of unsecured PHI without unreasonable delay and no later than 60 days after discovery. That is a maximum federal deadline, not necessarily an appropriate operational reporting window for your organization; negotiate a faster contractual notice period so you have time to investigate and meet your own duties. HHS’s breach notification guidance explains the rule and notification responsibilities.

Do not assume every VR therapy vendor is covered by HIPAA. If a product or service is outside HIPAA, other requirements may apply; for certain non-HIPAA health apps and related services, the FTC’s Health Breach Notification Rule may be relevant. Assess applicable federal and state law, contractual commitments, data location, retention requirements, and the organization’s own privacy policies. The FTC’s Health Breach Notification Rule overview explains its potential application to health technologies.

How do system failures affect clinical and physical safety

Map failures to the patient’s care pathway. A headset, network, cloud platform, or integration outage may cancel or interrupt treatment, delay access to session history, or prevent a clinician from reviewing progress. A corrupted record or incorrect configuration could lead staff to rely on inaccurate information. Define a fallback process, such as pausing the session, switching to an approved alternative, and recording the interruption in the clinical workflow.

Consider what happens if VR content is altered, displayed incorrectly, or delivered to the wrong patient. Depending on the therapy and setting, changes could cause distress, confusion, dizziness, or unsafe movement. Patients using immersive equipment may have limited awareness of nearby objects and people, so a session could also increase collision or fall risk. FDA identifies collisions, falls, cybersickness, and display-related concerns among potential AR/VR risks. FDA’s AR/VR risk overview provides examples.

Ask the vendor how it validates content and updates, communicates known issues, supports clinician control, and enables a rapid pause or stop. Include patient supervision, room setup, device cleaning, and a procedure for reporting adverse events in your local safety review. Treat security and clinical safety as connected: availability, correct content, and reliable clinician access can all matter to safe therapy delivery.

What evidence should a VR therapy vendor provide during assessment

Request evidence that directly addresses the system and data flows in your deployment. Useful materials include a current architecture and data-flow diagram; data inventory and retention schedule; subprocessor list; access-control and encryption descriptions; incident response and recovery procedures; and documentation of how security updates and vulnerabilities are managed.

Where available and appropriate, request independent assessment summaries, penetration-test scope and remediation status, and evidence that corrective actions were completed. Ask what systems and dates an assessment covers, whether the VR headset and associated applications are included, and what exclusions or unresolved findings remain. An audit report or security certificate can inform your review, but does not by itself establish that the product is safe for your specific use or that your organization meets its legal obligations.

HHS notes that HIPAA does not expressly require a cloud service provider that is a business associate to provide its customers with security documentation or permit customer audits. Organizations may nevertheless seek additional assurances through a BAA, service-level agreement, or other contract based on their own risk analysis. HHS guidance on cloud-provider documentation and audits clarifies this point.

In summary: assess the full data lifecycle, verify safeguards and contractual duties, and evaluate cyber incidents for their possible effects on treatment and physical safety. Base approval on evidence that fits your deployment, and document any remaining risks and the controls your organization will use to manage them.

FAQs

What types of patient data can VR therapy systems collect?

Depending on the product, a system may collect identifiers, clinical details, treatment plans, session notes, progress measures, movement and gaze signals, voice recordings, and device or usage logs. Ask the vendor for a complete data inventory, including data collected by the headset, app, cloud services, and connected clinical systems.

How can a vendor limit access to VR therapy data?

A vendor can use unique accounts, role-based access control, multifactor authentication, least-privilege permissions, timely account removal, and audit logs. Your assessment should verify how these controls apply to vendor support staff and subcontractors, not just clinical users.

What security evidence should a VR therapy vendor provide?

Request a data-flow diagram, data inventory, subprocessor list, retention and deletion details, security-control documentation, incident and recovery procedures, vulnerability-management information, and relevant independent assessment summaries. Confirm the scope and date of each document and ask how open findings were addressed.

How can altered VR content create clinical or physical safety risks?

Altered or incorrectly displayed content may be unsuitable for a patient or treatment, cause distress or disorientation, or affect how a patient moves while unable to see the surrounding room. Ask how content is validated and updated, how clinicians can pause a session, and what fallback and incident-reporting procedures are available.