Is Your Remote Desktop HIPAA / SOC 2 Compliant?

中文版本： 《你的远程桌面符合 HIPAA / SOC 2 合规吗？》

"We're HIPAA compliant" is something many remote desktop vendors say. Whether that's true depends entirely on how you configure and use the tool. Compliance is something you do, not something the vendor gives you.

This post covers what the major standards actually require for remote desktop access to regulated data — and how to evaluate vendor claims honestly.

HIPAA: What It Requires for Remote Access

HIPAA's Security Rule has three categories of safeguards. For remote desktop, the relevant ones are:

Safeguard	What it means for remote desktop
Access control	Unique user ID per person; no shared logins. Auto-logoff on idle.
Audit controls	Log every session, file transfer, and admin action. Logs must be tamper-evident.
Integrity	Detect unauthorized changes to PHI. Session recording is one way.
Authentication	Verify identity before access. Strong recommendation: MFA.
Transmission security	Encrypt PHI in transit. End-to-end is the safest read of the rule.

You also need a Business Associate Agreement (BAA) with your remote desktop vendor if they could see PHI (even theoretically, through their relay).

SOC 2: What Auditors Look At

SOC 2 isn't a checklist — it's a report on whether your stated controls match what you actually do. For remote desktop, auditors typically check:

CC6.1 (Logical access): Provisioning and deprovisioning of remote access accounts. Are former employees still listed?
CC6.6 (Boundary controls): How do you prevent unauthorized network access? "We use remote desktop with E2EE" is part of this.
CC7.2 (Anomaly detection): Do you monitor for unusual remote access patterns?
CC8.1 (Change management): Are remote desktop tool updates tested and approved?

You write the controls; SOC 2 audits whether you follow them. The remote desktop tool is one input.

GDPR: The Data Transfer Issue

If you're in or processing EU data, the big question is where your remote desktop traffic actually goes:

Signaling server location: even metadata is "personal data" under GDPR.
Relay/TURN server location: traffic passing through these is subject to the host country's laws.
Vendor headquarters: affects which government can compel access.

A P2P-first tool with self-hostable signaling solves most of this. A relay-first US-based vendor with no self-host option is hard to defend post-Schrems II.

How to Evaluate Vendor Claims

When a vendor says "compliant," ask:

What evidence? Type 2 SOC 2 report from a Big 4 / mid-tier auditor, not a self-assessment.
What's in scope? A vendor may be SOC 2 compliant for their corporate IT but not their remote desktop product.
Can I get a BAA? Required for HIPAA. Real vendors have a standard one ready.
Where does data flow? Specifically: signaling, relay, and metadata. Get answers in writing.
What can the vendor see? "End-to-end encrypted" should mean the vendor literally cannot read sessions.

A vendor that can't answer these in detail isn't compliance-grade for your use case, regardless of marketing.

Configuration Checklist

Past vendor selection, configure for compliance:

If half of these aren't checked, you're not compliant regardless of which tool you picked.

The "Compliance Theater" Trap

Many organizations have:

A vendor claim of compliance
No actual configuration that uses the compliance features
No audit logs that anyone reads
No incident response plan

That's not compliance — it's compliance theater. Real compliance is boring operational hygiene practiced continuously.