Skip to content

← Back to OmniLink

OmniLink Security

Last updated: September 30, 2026
Status: Qualified by legal counsel.
Audience: Customer security and compliance reviewers. For privacy-specific terms see the Privacy Policy; for the third parties that process customer data see Subprocessors.

Interface OmniLink IP, LLC (“OmniLink,” “we”) delivers AI-assisted, real-time language interpretation. Customer sessions contain sensitive spoken communication — clinical, legal, financial, and workplace. This page documents the controls we operate today and the posture we offer to compliance reviewers as part of due diligence.

1. Data residency

OmniLink runs entirely in the United States.

  • The primary data store (Supabase, hosted on AWS) runs in AWS us-west-2.
  • Every AI, telephony, and storage subprocessor is engaged on US processing terms.
  • We do not transfer customer data outside the United States.

See the Subprocessors page for the full list of vendors and processing locations.

2. Encryption

  • In transit: all customer-facing endpoints require TLS 1.2 or higher. Browser and edge function traffic uses HTTPS with HSTS.
  • At rest: all databases, object storage, and file storage are encrypted with AES-256 at the storage layer.
  • Application-layer encryption for credentials: integration credentials (e.g., OAuth refresh tokens for connected EHR, CRM, or telephony platforms) are encrypted at the application layer with a server-side key before being written to the database, on top of the storage-layer encryption. This means even a leaked database row does not expose usable credentials.

3. Access controls

  • Workspace isolation. Every customer tenant is created as a clean isolated environment. Row-Level Security policies in the database scope every read and write to the requesting user’s workspace; no cross-tenant data access is possible from the application layer.
  • Role-based permissions. Within a workspace, every action is gated by a typed permission (e.g., sessions.start_live, notes.approve, settings.manage). Workspace admins assign roles; the platform enforces the permission at every API surface.
  • Least privilege for OmniLink staff. Production access is restricted to authorized personnel. Privileged access requires multi-factor authentication and is logged.
  • Sign-out + termination. Customers can immediately terminate a user’s session and revoke their workspace access from the admin console; the change is atomic and audit-logged.

4. Audit logging

Every consent capture, sign-in, sign-out, failed login, role change, member invitation, member termination, integration grant, delivery destination change, retention configuration change, and data-subject request is written to an append-only audit log. The log records actor, target, action, timestamp, and outcome. Workspace admins can view their tenant’s log in the admin console; OmniLink staff retain access only for incident investigation and compliance review.

5. Retention and deletion

Retention is configurable per workspace and per content type:

  • Session audio. Default: discarded as soon as the approved transcript is delivered to the customer’s chosen destination (“deliver-then-purge”). Optional retention windows of 30, 60, or 90 days are available.
  • Session transcripts and AI notes. Default retention follows the customer’s compliance posture for their industry (often 7 years for healthcare, varies for legal and other verticals). A scheduled job enforces the configured retention.
  • Account, billing, and audit data. Retained for the duration of the customer relationship plus the period required by law.

Customers can issue Data Subject Requests (DSRs) — to access, export, or delete specific Participant data — through their admin console.

6. Vendor due diligence

We engage third-party subprocessors only after they meet the standards we’d expect for our own systems:

  • A signed Data Processing Agreement (DPA).
  • Where the subprocessor will process Protected Health Information for a healthcare workspace, a signed Business Associate Agreement (BAA) before that workspace is activated.
  • Public SOC 2 / ISO 27001 / HITRUST attestation, or an equivalent independent security review.
  • A contractual prohibition on training the vendor’s general models on customer data.

Payments are processed by Stripe (PCI DSS Level 1). Payment card details are collected and held by Stripe; OmniLink does not store full card numbers, and Stripe receives only the workspace’s commercial billing data — never session content.

The current subprocessor list is published on the Subprocessors page. Customers are notified before any new or replacement subprocessor begins processing customer data, with a reasonable opportunity to object.

7. HIPAA posture

Healthcare workspaces:

  • Launch only after a Business Associate Agreement is in place with OmniLink and with every subprocessor in the PHI path (Supabase, Anthropic, ElevenLabs, RingCentral, and any storage subprocessor).
  • Are configured to keep audio retention compatible with §164.530(j) and your internal documentation policy.
  • Receive the §1557 language-access materials documenting the role of machine vs. qualified human interpretation in your specific use case.

Vercel (frontend hosting) and Stripe (billing) are outside the PHI path: session content flows from the browser directly to Supabase, Anthropic, and ElevenLabs over TLS and never passes through them. See the Subprocessors page.

OmniLink’s underlying stack is HIPAA-eligible end-to-end. Posture documentation is available on request.

8. Incident response

We maintain a written incident response runbook that covers triage, containment, eradication, recovery, customer notification, and post-mortem. Material security incidents affecting customer data are communicated to the affected workspace’s primary admin contact within the timeframe required by applicable law and our customer agreements, and in any event without undue delay.

9. Business continuity and disaster recovery

OmniLink operates on managed cloud infrastructure (Supabase + AWS + Vercel) with vendor-provided redundancy, automated backups, and multi-AZ availability. We maintain a written BCP/DR plan that defines recovery objectives, dependencies, and tested restore procedures.

10. Secure software development

  • All code changes flow through pull requests with automated build + type-check gates before they can reach production.
  • Production deploys are gated by a Trusted Author check that rejects commits authored by emails not tied to an authorized GitHub identity.
  • Secrets are stored in encrypted vaults (never in source control), enumerated in an internal secrets inventory, and rotated when personnel changes occur.

11. Compliance frameworks

OmniLink’s posture is aligned to the following frameworks based on customer industry:

  • HIPAA Security Rule §164 for healthcare workspaces.
  • ACA §1557 language-access requirements for federally funded healthcare programs.
  • Title VI for education and federally funded service providers.
  • GLBA Safeguards Rule for financial services workspaces.
  • CCPA / CPRA for California-resident data subjects.
  • OSHA documentation expectations for industrial workspaces.

Posture documentation for HIPAA, FERPA, and GLBA is available on request to qualified compliance reviewers.

12. Reporting a vulnerability

If you believe you have found a security vulnerability in OmniLink:

  • Email support@interfaceomnilink.com with the subject line Security report — <short summary>.
  • Include enough detail to reproduce the issue, the URL or component affected, and any proof-of-concept material you can share safely.
  • We commit to acknowledging receipt within two business days, providing a triage assessment within five business days, and keeping you informed through resolution.

We do not currently operate a paid bug bounty program. We will publicly thank responsible reporters with permission.

13. Compliance documentation requests

Customer compliance teams can request:

  • Subprocessor list with safeguards (above + public list).
  • HIPAA posture summary + BAA template.
  • FERPA / GLBA posture summaries (industry-dependent).
  • Audit logging schema overview.
  • Retention configuration walkthrough.
  • Incident response runbook summary.

Reach support@interfaceomnilink.com with the subject line Compliance posture request and we’ll route you to the right documents within two business days.

This page describes the security posture OmniLink operates today. We will publish material changes here and notify affected customers per our customer agreements. For privacy-specific terms see the Privacy Policy; for governing terms see the Terms of Use.

Questions? Email support@interfaceomnilink.com.