GDPR Requirements Your VR Software Vendor Must Meet

Why this article, in one word

GDPR is not a formality. It is a framework that defines what you can and cannot do with your patients' data. When you bring VR software into your practice, you are introducing the processing of special-category data (health) carried out by a third party (the software vendor). That makes you, the psychologist or clinic, the data controller, and the vendor the data processor.

This asymmetry matters: in an inspection by Spain's data protection authority (AEPD) or a complaint from a patient, the primary responsibility falls on you. That's why it pays to know what to demand from a vendor before signing, not after. home home

Mandatory notice: this article is informational. It does not replace individualized legal advice. If you have specific questions about your situation, consult your Data Protection Officer or an attorney specialized in healthcare data protection.

What data a clinical VR software product generates

Before discussing compliance, it helps to know what data is actually at stake. VR software used in a psychology practice generates, depending on the product, up to six categories of data.

Professional identification data: name, email, license number, clinical practice. General category, not special.

Patient identification or pseudonymized data: in many products, including VRET, the patient's real identity is never requested — instead, a pseudonym or clinical reference chosen by the psychologist is used ("Patient A", "P-2026-014"). If the pseudonym allows re-identification by cross-referencing your internal clinical records, it remains personal data attributable to the controller.

Clinical session data: scenarios used, duration, date and time, controls adjusted during the session, clinician notes. These are health data (Art. 9 GDPR).

Patient biometric data (if the product collects it): heart rate, eye movements, respiratory rate, body posture, skin conductance. Some eye-tracking systems collect data that can be categorized as biometric under GDPR.

The patient's voice, if a microphone is active during the session: many products do not record it; others do. It is important to know which applies.

Audiovisual recordings of the session: some products allow external-view video recording or headset screen capture. If generated, these are health data and possibly biometric data.

The first step, before signing anything, is to know which of these your candidate product actually generates.

The applicable legal framework, in brief

Regulation (EU) 2016/679, the General Data Protection Regulation (GDPR): the European framework, directly applicable.

Spanish Organic Law 3/2018 on Personal Data Protection and Digital Rights Assurance (LOPDGDD): Spain's national implementation of GDPR, with relevant articles on health data.

Royal Decree 1720/2007 (to the extent still in force after LOPDGDD): a legacy regulation that retains applicable provisions on security measures.

The Spanish Psychologists' Code of Ethics (COP, Madrid, updated 2010): deontological confidentiality obligations that apply on top of the legal ones.

For health data, Art. 9.1 GDPR prohibits processing except under the exceptions in Art. 9.2. The most relevant one for your practice is letter h): processing necessary for the purposes of preventive medicine, medical diagnosis, and the provision of health or social care, on the basis of EU or national law or under contract with a health professional bound by a duty of secrecy.

The patient, therefore, does not need to explicitly consent to the processing of their health data for you to provide psychological treatment (the legal basis lies in Art. 9.2.h and the care relationship itself). But they do need to be adequately informed, in accordance with Art. 13 GDPR.

Requirement 1: a data processing agreement (Art. 28 GDPR)

Any vendor that processes personal data on your behalf is, legally, a data processor. Art. 28 GDPR requires that the relationship between controller and processor be documented in a contract.

That contract must include, at minimum: the subject matter and duration of processing, its nature and purpose, the type of personal data and categories of data subjects, the controller's obligations and rights, documented instructions from the controller, a confidentiality duty, technical and organizational security measures, conditions for sub-processing, assistance to the controller, return or deletion of data at the end of the relationship, and audit rights.

If a vendor does not offer you a signed data processing agreement before you start using the software, that is a red flag. It is not an administrative detail — it is the document that defines shared legal liability.

Requirement 2: an operational Data Processing Addendum (DPA)

The DPA is the operational documentation detailing how what's agreed in the processing contract is actually carried out. It typically includes: a list of sub-processors with the controller's right to object, the geographic location of servers, international transfer mechanisms where applicable (standard contractual clauses, adequacy decisions, certifications), concrete technical measures (encryption, access control, audit logging, backups), and incident notification procedures and timelines.

A well-drafted DPA can be reviewed page by page. If the vendor hands you a generic three-page document with no operational detail, it is unlikely to cover what GDPR requires.

Requirement 3: encryption in transit and at rest

Encryption in transit: data traveling between the VR headset, your computer, the vendor's web dashboard, and the vendor's servers must be encrypted. The de facto standard is TLS 1.2 or higher with modern cipher suites. Ask the vendor explicitly which protocols they use.

Encryption at rest: data stored on servers must be encrypted with standard algorithms (AES-256 is the usual choice). This protects against physical theft of disks or unauthorized access to the infrastructure.

Encryption specifically for sensitive clinical data: session notes, identifiable biometric data, audio or video if collected. Some vendors apply column-level encryption in the database for these specific fields, with keys managed separately. This is good practice.

Requirement 4: server location

For your peace of mind and your patients', the cleanest option is: servers located in the European Union, operated by cloud infrastructure providers established in the EU.

If the software vendor uses AWS, Google Cloud, or Microsoft Azure (US providers with a European presence), that is not automatically a problem, but it introduces additional legal complexity due to international data transfer rules. Following the Schrems II ruling and the current EU-US framework (Data Privacy Framework, 2023), compliance is achievable but requires documentation.

If the vendor has servers in jurisdictions without an adequacy decision (the UK has adequacy status post-Brexit; other countries do not), require additional safeguards (European Commission standard contractual clauses, a transfer impact assessment).

Ask the vendor directly: in which country are the servers where my patients' clinical data is stored physically located? A concrete answer is a sign of seriousness. An evasive answer is the opposite.

Requirement 5: retention policy

How long does the vendor keep your data? What happens when you stop being a customer? What happens when a patient requests erasure of their data?

The vendor must have a written retention policy, tailored to the purpose of processing and applicable legal obligations. Spanish health regulations require clinical records to be kept for a minimum of five years from the last visit (Law 41/2002 on Patient Autonomy), with some regional variation.

When the contractual relationship with the vendor ends, they should offer you two options: return of the data to you (the controller) in an exportable format followed by deletion, or direct deletion with a certificate of erasure. The reasonable approach is for the vendor to offer both and let you choose.

Requirement 6: 72-hour breach notification

Art. 33 GDPR requires the controller to notify the AEPD of security breaches within no more than 72 hours of becoming aware of them. To meet that deadline, you need your vendor to alert you quickly when something happens.

Ask the vendor: what is your contractual deadline for notifying the client of incidents? A reasonable answer is 24-48 hours from detection.

Also ask: how would you notify me? By email? With what minimum information? Who is the technical contact I can escalate to?

Breaches happen. What matters is not promising they won't, but having a serious procedure for when they do.

Requirement 7: a data protection impact assessment (DPIA) when applicable

Art. 35 GDPR requires a data protection impact assessment (DPIA) when processing is likely to result in a high risk to the rights and freedoms of data subjects. Processing special-category (health) data at scale, or using new technologies, are criteria that point toward a DPIA obligation.

In practice, the AEPD has published guidance lists: a psychology practice using VR to treat a significant volume of patients, with biometric data and session records, will likely meet the DPIA threshold.

A good vendor will help you carry out your DPIA: documentation of data flows, a description of technical measures, identified risks, and mitigations. The DPIA is your responsibility, but the vendor is required to cooperate (Art. 28.3.f GDPR).

How to interview a vendor in fifteen minutes

If you're evaluating a clinical VR software product and have a first call with the vendor, these are the questions that give you the most signal in the least time.

Can you send me the data processing agreement and the DPA before I sign the commercial contract?

In which country are the servers physically located, and who is the underlying cloud provider?

Which sub-processors are involved in processing my data, and can I object to any of them?

How do you encrypt data in transit and at rest, and which specific clinical data fields are encrypted with a separate key?

What is your deadline for notifying clients of breaches?

What happens to my data when I stop being a customer? Return, format, deletion timeline?

Do you have a DPO and, if applicable, ISO 27001 certification or equivalent?

A professional vendor will answer all seven concretely. One that improvises here will be improvising on more serious matters when it counts.

What VRET does in this area

We publicly document our data processing regime at /privacidad and /legal/dpa. We operate under a standard data processing agreement compliant with Art. 28 GDPR, with servers located in the EU, TLS 1.2+ encryption in transit and AES-256 at rest with specific encryption for sensitive clinical fields (notes and patient reference), a retention policy aligned with Law 41/2002, contractual incident notification within 24 hours, and documented cooperation for the controller's DPIA.

We mention this for completeness, not as self-promotion: the goal of this article is to give you criteria to evaluate any vendor, not to sell you ours.

VRET is a support tool for psychological intervention, not a CE-marked medical device.

This article is for informational purposes for psychology professionals. It is not clinical advice for any individual case and does not replace the judgment of the licensed psychologist in charge. VRET is professional clinical-support software, not a CE-marked medical device.