Back to Overview
Infrastructure Security

Security & Trust

Last Updated: May 29, 2026 • Security Architecture Profile

Pilot deployment: Security practices below describe the intended architecture for this pilot. Formal compliance attestations are not published on this site.

1. Encryption Standards

We implement comprehensive encryption strategies to protect data regardless of whether it is actively traveling over the internet or residing in database storage.

In-Transit Protection

All platform requests and data feeds are encrypted using Transport Layer Security (TLS 1.3). This prevents unauthorized eavesdropping or tampering of clinical interactions.

At-Rest Protection

Database storage volumes, tables, and backups are encrypted using Advanced Encryption Standard with a 256-bit key length (AES-256) managed under secure cryptographic key architectures.

2. Identity & Authentication

Verifying who is accessing the dashboard is a key component of patient data protection. We utilize industry-recognized authentication providers to handle clinical identity:

Multi-Factor Authentication (MFA): Support for multi-factor authentication, including email codes and authenticator apps, ensuring that accounts cannot be breached with a simple password leak.
Secure Session Tokens: Cryptographically signed session tokens that expire automatically, preventing unauthorized session hijacking.

3. Operational Safeguards

Our engineering team adheres to administrative security controls to limit internal risks:

  • Least Privilege Access: Only a restricted number of core operations staff can access cloud server configurations, strictly for deployment and maintenance.
  • Vulnerability Management: Dependencies and packages are audited during our build process to identify code issues.
  • Audit Trails: Staff administrative actions are tracked to maintain auditability.

4. Backup & Recovery Philosophy

Data reliability is essential for clinic operations. We implement a structured replication and backup framework:

Daily BackupsAutomated snapshot cycles capture full database states daily, stored securely in geographically separated backup facilities.
Point-in-Time RecoveryDatabase transactions are written to transaction logs, allowing us to roll back or restore states to a specific minute in the event of failure.
Geographic RedundancyCloud systems are replicated across separate geographic availability zones to remain online during local datacenter outages.

5. Data Handling & Tenant Isolation

To guarantee that client data is never mixed or leaked, Audaya employs tenant isolation mechanisms:

  • Row-Level Security (RLS): Our database utilizes Row-Level Security policies. This means that a clinic user can only query rows associated with their specific clinic organization ID. Queries attempting to access data outside the tenant boundary are rejected at the database engine level.
  • Ephemeral Transcription Processing: Audio recordings processed for ambient dictation and transcriptions are processed securely. They are stored temporarily only for clinical verification and notes generation, and are subject to immediate deletion rules after user-confirmed session completion.