NIS2: where RVer stands, and what stays with the institution

NIS2 is now one of the first items in any conversation with a healthcare IT department. Rightly so: the directive widened the set of entities in scope, raised the technical bar, and, the part that changes daily practice most, made entities accountable for the security of their supply chain.

Which means: the moment an RVer headset enters an in-scope institution, RVer's security posture stops being only our concern. It becomes an item in your file.

This article answers the question the way it is usually asked: where does RVer stand?

The position, in two sentences

The RVer platform meets the applicable technical requirements of the regime. Part of NIS2, however, is organisational rather than technical, and that part belongs to no supplier: it belongs to the institution. On those, what we do is recommend, document and support.

That distinction is the most useful thing we can bring to the meeting, and it is the rest of this article.

On our side: the technical measures

For obvious reasons we do not publish configurations, versions or implementation detail: describing the lock in public works against the point. In general terms, and this is what the documentation we hand over states:

• Data is encrypted, in transit and at rest. Backups are encrypted too, and the recovery key does not live in the same infrastructure it protects.
• Strong authentication is mandatory on all administrative access, with a second factor. No convenience exceptions.
• Least privilege by role: each user sees and does only what their function requires.
• Audit logging of access, changes and sensitive operations: who, when and what.
• Protection against abusive access attempts, with automatic lockout.
• Infrastructure and data in EU jurisdiction, backups included.
• Updates and security fixes applied under a controlled procedure, with a rollback path.

None of this is sold as a badge. It is the baseline we consider the minimum for putting equipment inside a healthcare institution.

Patient usage data does not leave the headset

In practice, this is the answer that settles half of every security meeting.

No patient usage data leaves the headset. The session record, the activity statistics, the readings attached to a person: all of it stays on the headset and inside the institution's perimeter. It is not sent to RVer, it feeds no dashboard of ours, and it does not exist on our side.

What does travel is two things, and only two:

1. Technical information for updates and remote support of the equipment: device status, versions, fault diagnosis. This is what keeps a fleet current without sending someone to every room.
2. Aggregated data about how the product behaves, which we use to improve it: what is slow, what fails, where.

Neither category includes the clinical content of a session or readings attached to an identified patient.

The practical effect for your data protection officer is simple: the institution is the controller of that data, and RVer holds no copy of it. The risk surface that would otherwise have to be assessed, negotiated and monitored... never comes into existence.

On your side: what NIS2 does not let you delegate

This is the part that sometimes catches institutions off guard. A substantial share of NIS2 is not about technology, it is about governance. And no supplier on the market can discharge it for you:

• Management body accountability: the board answers for the measures, and has to know them.
• Risk analysis and the organisation's own security policy.
• Access management and account lifecycle: who joins, who leaves, who no longer needs it. We provide the tools; the policy is yours.
• Incident response plan and notification duties, with tight deadlines and a defined recipient.
• Business continuity and recovery, including the tests that prove the plan works.
• Training and awareness for the people who use the systems.
• Supply chain risk management: in which we are one of the items to assess.

On these points, what RVer does is suggest and support: we provide the recommendations that apply to our equipment, we document our own measures for your supplier assessment process, and we maintain a defined channel for reporting incidents involving our product.

What we hand over for your file

When an institution asks us for security documentation, what follows is:

• a description of the technical measures applied to the product and the platform;
• the location and jurisdiction of the data, backups included;
• which categories of data leave the headset, and, above all, which do not;
• the retention and deletion policy;
• the channel and deadlines for reporting security incidents;
• configuration recommendations for the institution's side (network, accounts, device management).

It is material written to be attached to your process, not read as marketing.

Why this matters to whoever signs

Equipment that forces a security exception costs far more than its list price. It costs meetings, it costs an opinion, and it costs risk carried by someone who signs their name to it.

RVer's position was built for the opposite case: patient data that does not leave, encryption by default, mandatory strong authentication, EU jurisdiction, and an audit log that answers "who did what". What remains sits on the right side, the institution's own governance, and we say so up front, rather than letting it surface in an audit.

The RVer platform's base product is a Class I Medical Device registered in EUDAMED and with INFARMED (Portugal), with session records handled in line with the GDPR.

In a shorter, more practical form for a meeting: the eight questions hospital IT asks.