#1Why most telehealth platforms fail their first audit
When a regulator opens a telehealth audit they rarely start with the application. They start with the data map: every place patient data is created, stored, transmitted, or processed. Most teams cannot produce that map confidently because their platform grew incrementally and PHI now leaks into logs, analytics, error trackers, and third-party SDKs that were added long after the threat model was last reviewed.
- Recording flags toggled on by support without a re-evaluation of storage encryption.
- Crash reporting SDKs ingesting screen captures that include patient identifiers.
- Push notification payloads quoting appointment subjects in plain text.
- Customer-success tooling syncing chat transcripts to a vendor without a Business Associate Agreement.
#2Mapping the PHI data flow before you write code
Every telehealth project we ship starts with a single artefact: a labelled data flow diagram. It traces PHI from the patient device, through the signaling layer, into the media plane, the persistence layer, and out to any downstream integration (EHR, billing, analytics, support). For each hop we document the carrier, the encryption posture, the retention policy, and the BAA status of the counterparty.
- Identify every system that touches PHI — including SDKs that exfiltrate logs.
- Classify each hop as either an essential clinical path or an optional convenience.
- Eliminate every optional convenience that cannot present a signed BAA.
- For essential paths, encrypt in transit (TLS 1.2+) and at rest (AES-256 GCM) with keys held in a customer-controlled KMS.
#3Encryption defaults that satisfy HIPAA and GDPR simultaneously
HIPAA's Security Rule and GDPR Article 32 both demand 'appropriate' encryption without prescribing algorithms — that ambiguity is where teams take shortcuts. Our default is to assume the strictest jurisdiction we serve and codify it into infrastructure modules that no environment can opt out of.
- TLS 1.3 with a constrained cipher suite enforced at the load balancer and re-asserted at every internal hop.
- Envelope encryption with per-tenant data keys rotated automatically every 90 days.
- Field-level encryption for the highest-sensitivity columns (diagnosis, medication, identifiers) so that even a database dump cannot expose them.
- Hardware-backed key custody (HSM or KMS) with strict separation of duties between the key administrator and the data owner.
#4Device, browser, and edge considerations
Telehealth lives or dies at the device. WebRTC is the standard for real-time audio and video, but its defaults are too permissive for healthcare. We harden it with strict SDP filters, force E2E DTLS-SRTP, and refuse downgrade to non-encrypted media even when the network is flaky. On native clients we pin certificates and ship updates through a signed channel so we can rotate trust without breaking established sessions.
Edge caching is the other quiet risk. A misconfigured CDN happily caches an authenticated avatar URL or a prescription PDF the moment the cache key fails to include the auth scope. We treat any PHI-bearing URL as `Cache-Control: no-store, private` and prefer signed, short-TTL URLs for media that genuinely needs CDN acceleration.
#5Operational practices that make audits routine
The engineering work above is necessary but not sufficient. The teams who pass audits without breaking sweat treat compliance as an operational discipline: continuous evidence collection, quarterly access reviews, immutable audit logs, and tabletop incident drills that include the privacy officer.
- Immutable, append-only audit logs streamed to a write-once store with a documented retention window.
- Quarterly access reviews driven by SCIM provisioning so nobody keeps PHI access after they change roles.
- Annual penetration tests against the telehealth surface, with remediation deadlines baked into engineering OKRs.
- Documented incident response runbooks covering breach notification timelines for every jurisdiction in scope.

