> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mavioapp.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Data Protection
> How Mavio protects your meeting data with encryption, access controls, and security best practices.
Mavio is built with security at every layer. Your meeting recordings, transcripts, and summaries are protected by enterprise-grade encryption, strict access controls, and a security-first architecture.
## Encryption
### In transit
All data transmitted between your devices and Mavio's servers is encrypted using TLS 1.3. This includes:
* Audio streams during recording
* API requests and responses
* File uploads and downloads
* WebSocket connections for real-time features
### At rest
All stored data is encrypted at rest using AES-256 encryption:
| Data type | Encryption | Storage |
| -------------------------- | ------------- | -------------------- |
| Audio recordings | AES-256 | Cloud object storage |
| Transcripts | AES-256 | Encrypted database |
| Summaries and action items | AES-256 | Encrypted database |
| User credentials | Bcrypt + salt | Encrypted database |
| API keys | SHA-256 hash | Encrypted database |
| Voice profiles | AES-256 | Isolated storage |
For maximum security, enable [privacy mode](/documentation/security/on-device-processing) to process audio entirely on your device. No audio data reaches Mavio's servers.
## Access controls
### Authentication
* **Email + password** with configurable password requirements
* **Two-factor authentication (2FA)** via authenticator apps (TOTP) or SMS
* **Single Sign-On (SSO)** via SAML 2.0 (Enterprise plan)
* **SCIM provisioning** for automated user lifecycle management (Enterprise plan)
* **OAuth 2.0** for Google and Microsoft sign-in
### Authorization
Mavio uses role-based access control (RBAC) at the team level:
* **Owner** — full administrative access
* **Admin** — manage members and settings
* **Member** — create and view shared recordings
* **Viewer** — read-only access to shared content
Each recording has its own sharing permissions. Users can only access recordings that are explicitly shared with them or shared with their team (depending on team settings).
## Infrastructure security
| Layer | Protection |
| ------------------ | ------------------------------------------------------------ |
| **Network** | VPC isolation, WAF, DDoS protection |
| **Compute** | Hardened containers, no persistent state |
| **Database** | Encrypted volumes, automated backups, point-in-time recovery |
| **Object storage** | Server-side encryption, versioning, access logging |
| **Secrets** | Hardware security modules (HSM) for key management |
## Application security
* **Input validation** on all API endpoints using strict schemas
* **SQL injection protection** via parameterized queries
* **XSS protection** with content security policies and output encoding
* **CSRF protection** with token-based validation
* **Rate limiting** on all API endpoints to prevent abuse
* **Dependency scanning** — automated vulnerability scanning on all third-party packages
## Security practices
### Development
* Security code reviews on all changes
* Static analysis (SAST) in the CI pipeline
* Dynamic application security testing (DAST) on staging environments
* Dependency vulnerability scanning with automated alerts
* Secret scanning to prevent credential leaks
### Operations
* 24/7 monitoring and alerting
* Incident response plan with defined SLAs
* Regular penetration testing by independent firms
* Bug bounty program for responsible disclosure
### Personnel
* Background checks on all employees
* Security awareness training
* Least-privilege access to production systems
* Access auditing and review
## Data isolation
Each Mavio workspace operates in a logically isolated environment:
* **Database isolation** — workspace data is segmented and access-controlled at the query level
* **Storage isolation** — audio files and documents are stored in workspace-specific paths
* **Processing isolation** — transcription and AI processing jobs are scoped to the workspace
Enterprise customers can request dedicated infrastructure for full physical isolation. Contact [sales@mavioapp.com](mailto:sales@mavioapp.com) for details.
## Vulnerability reporting
If you discover a security vulnerability, please report it responsibly:
* **Email:** [security@mavioapp.com](mailto:security@mavioapp.com)
* **PGP key:** Available at [mavioapp.com/.well-known/security.txt](https://mavioapp.com/.well-known/security.txt)
* **Bug bounty:** We offer rewards for qualifying vulnerabilities. See our responsible disclosure policy.
We acknowledge reports within 24 hours and provide updates every 72 hours until resolution.
## Security details
All data protection uses industry-standard encryption:
**In transit (TLS 1.3):**
* All connections between your devices and the server use TLS 1.3, the latest version of the Transport Layer Security protocol.
* Older TLS versions (1.0, 1.1) are not supported. TLS 1.2 is accepted as a fallback for legacy clients.
* Certificate pinning is enforced on mobile and desktop apps to prevent man-in-the-middle attacks.
* WebSocket connections for real-time transcription use the same TLS encryption.
**At rest (AES-256):**
* Audio files, transcripts, summaries, and all user data are encrypted using AES-256, which is the encryption standard used by governments and financial institutions worldwide.
* Encryption is applied at the storage layer — data is encrypted before being written to disk and decrypted only when accessed by authorized services.
* Database fields containing sensitive information use additional column-level encryption beyond the volume-level encryption.
Encryption keys are managed using a layered approach:
* **Master keys** are stored in Hardware Security Modules (HSMs) that are FIPS 140-2 Level 3 certified. Master keys never leave the HSM in plaintext.
* **Data encryption keys (DEKs)** are generated per-workspace and used to encrypt actual data. DEKs are themselves encrypted by the master key (envelope encryption).
* **Key rotation** — data encryption keys are rotated automatically every 90 days. Master keys are rotated annually. Key rotation is seamless and does not require downtime or re-encryption of existing data.
* **Key access** — only authorized backend services can request key decryption from the HSM. All key access is logged and auditable.
Enterprise customers can bring their own encryption keys (BYOK) for additional control. Contact sales for details.
Infrastructure is hosted in SOC 2-certified data centers:
* **Default region:** US-East (Virginia) and US-West (Oregon) with automatic failover.
* **EU region:** Frankfurt, Germany — available for Enterprise customers who require EU data residency.
* **Asia-Pacific region:** Singapore and Sydney — available for Enterprise customers.
All data centers provide:
* Redundant power with UPS and generator backup
* Multi-zone availability for high availability
* Physical security with biometric access, 24/7 surveillance, and visitor logging
* Network redundancy with multiple ISP connections
Data residency is configurable at the workspace level. Once set, audio, transcripts, and metadata are stored and processed exclusively in the selected region.
All access to user data is logged for security and compliance:
* **API access logs** — every API request is logged with the user identity, IP address, timestamp, endpoint, and response status.
* **Data access logs** — when recordings, transcripts, or summaries are accessed (viewed, downloaded, or shared), the action is logged with the accessor's identity.
* **Admin action logs** — team admin actions (adding/removing members, changing settings, managing integrations) are logged separately.
* **Infrastructure access** — all employee access to production systems is logged and requires multi-factor authentication plus manager approval.
Enterprise customers can export access logs via the API or receive them as a scheduled report. Logs are retained for 12 months by default, or longer on Enterprise plans.
The security team follows a structured incident response process:
**Severity levels:**
| Level | Definition | Response time | Update frequency |
| ----------------- | ---------------------------------------------- | ------------- | ---------------- |
| **P0 — Critical** | Active data breach or service compromise | 15 minutes | Every 1 hour |
| **P1 — High** | Vulnerability with potential for data exposure | 1 hour | Every 4 hours |
| **P2 — Medium** | Security issue with limited impact | 4 hours | Every 24 hours |
| **P3 — Low** | Minor issue, no data at risk | 24 hours | Every 72 hours |
**Process:**
1. **Detection** — automated monitoring, vulnerability scanning, or external report identifies an issue.
2. **Triage** — the on-call security engineer assesses severity and impact within the response time SLA.
3. **Containment** — immediate steps to limit the scope of the incident (e.g., revoking compromised credentials, isolating affected systems).
4. **Resolution** — root cause is identified and a fix is deployed.
5. **Notification** — affected users are notified per regulatory requirements and internal policy. For GDPR-covered data, notification occurs within 72 hours.
6. **Post-mortem** — a detailed review is conducted and published internally. Systemic improvements are tracked to completion.