Your meetings are yours.

When you record or upload a meeting, the audio flows through these systems and nowhere else:

1. Your browser or desktop app → Briva over TLS. The desktop app uses the same HTTPS endpoints — there's no separate channel.
2. Briva → Deepgram for transcription. Audio is sent over TLS; Deepgram returns text. Deepgram is a US-based, SOC 2 Type II certified provider and does not train models on customer audio.
3. Briva → Anthropic for AI summary and chat. Transcript text is sent over TLS; Claude returns the summary. Anthropic does not train models on data submitted through the API by default.
4. Briva → Voyage AI for cross-meeting search embeddings. Short chunks of transcript text are converted to vectors stored in our database. Voyage does not retain or train on submitted content.
5. Storage in Supabase (Singapore region) — audio, transcripts, summaries, embeddings. Supabase uses AWS infrastructure with SOC 2 Type II certification and AES-256 encryption at rest.

We do not sell data. We do not share data with third parties for advertising or analytics purposes. Vendor list above is the complete pipeline.

• In transit: TLS 1.2+ on every request — including the desktop app, the web app, and all vendor calls.
• At rest: AES-256 (database + object storage) via Supabase / AWS.
• Secrets: all third-party API keys (Deepgram, Anthropic, Voyage, Resend, Stripe) are server-side only — they never reach the browser. Live transcription uses short-lived scoped tokens issued by our server.
• Backups: Supabase performs daily encrypted backups with point-in-time recovery for our database tier.

You choose how long Briva keeps your raw audio:

• Keep forever (default) — audio stays available for re-summarisation.
• Delete after processing — audio is deleted as soon as transcription + summary complete. Transcript and summary are retained.
• Delete after 7 / 30 days — a scheduled job removes the audio file on that timeline. Transcript and summary are retained.

Workspace owners configure this in Settings → Team → Audio retention. Individual meetings can also be deleted on demand — audio, transcript, summary, embeddings, comments, and tasks are removed permanently within minutes.

Account deletion is honoured within 30 days; all personal data is purged from primary storage. Anonymised billing records are retained where required by HK / EU tax law.

Every meeting belongs to exactly one workspace. Access is enforced at the database layer using PostgreSQL row-level security (RLS) — there is no application-layer-only check.

• Members: only users in a workspace's member list can read its meetings.
• Removed members: losing membership instantly revokes access — their session can still issue requests, but RLS denies them.
• Roles: owner / admin / member with explicit write permissions per role.
• Share links: non-guessable IDs (random tokens, never sequential), optional password protection, revocable from the share dialog.

Recording laws vary by jurisdiction — Hong Kong and most APAC markets allow one-party consent; California and the EU require all-party consent in many contexts. Briva surfaces a reminder before any live recording starts so the person recording is responsible for verifying consent with the other participants.

Our commitment: we do not auto-join meetings on a user's behalf without their explicit action. Every recording is initiated by a Briva user who is present in the meeting or has explicit recording authority.

We're a young company and we're upfront about what we have versus what we're working on:

• Today: All vendors above are SOC 2 Type II or equivalent. Our own application enforces RLS, TLS, AES-256, and least-privilege secrets.
• Q3 2026: Third-party penetration test against the production stack. Findings published as a redacted summary on request.
• Q4 2026: Data Processing Addendum (DPA) template for enterprise customers; GDPR alignment for EU prospects.
• 2027: SOC 2 Type II audit. Existing controls are designed to map cleanly; the audit formalises them.
• Later: ISO 27001. We'll prioritise it once paying enterprise customers ask.

If you believe you've found a vulnerability, please email sattarikram81@gmail.com with a description and reproduction steps. We'll acknowledge within one business day and follow up with a triage timeline.

We do not currently operate a paid bug bounty programme, but we're happy to publicly credit responsible disclosures.