Search our controls, current gaps, data-handling practices and assurance documents. Every status is intentionally plain: implemented, in progress or planned.
Flarea is not SOC 2 certified and no SOC 2 audit is currently underway.
TRUST EXPLORER
37 searchable results · 18 controls shown below
CONTROL REGISTER
Application traffic uses TLS; live audio and video use WebRTC DTLS-SRTP.
HSTS is applied at the application edge. Media encryption is provided by the WebRTC transport between participants and the managed media infrastructure.
Customer tables use Postgres Row-Level Security and privileged server routes perform explicit authorization checks.
Event, attendee and reporting data is owner-scoped. Some server workloads require a service credential and therefore enforce ownership at the route boundary rather than relying on RLS alone.
Recording objects are private, browser reads use short-lived links, and anonymous arbitrary-path uploads are blocked.
Anonymous guest backup uploads use a room-token-verified, single-object capability. Direct browser INSERT access is restricted to authenticated owners, admins, producers and hosts.
Authentication is provided by a managed auth service, with password and Google sign-in paths subject to the same host-account gate.
Uninvited identities do not receive a host profile. Flarea does not receive or store a user’s plaintext password.
System-administration requests produce a minimal, access-restricted authorization record with a 400-day retention rule.
The trail records actor identifier, method/path, outcome and request ID. It deliberately excludes bearer tokens, request bodies, email addresses and IP addresses.
Platform API keys are high-entropy, scoped, expiring and stored only as cryptographic hashes after one-time display.
Keys can be revoked immediately. Authentication and rate-limit identity use the hash rather than retaining recoverable bearer material.
Stripe hosts checkout and billing-management surfaces; Flarea does not store card numbers.
The application retains billing references, subscription state and usage records needed to operate paid plans. Payment credentials remain with Stripe.
Platform email includes sender context, RFC 8058 one-click opt-out and signed visible unsubscribe paths backed by suppression.
Host workflows cannot bypass global suppression. Onboarding has a scoped opt-out, physical sender identification ships in both footer formats, and mailbox-provider POST requests use the same signed capability.
A deep health endpoint, external watchdog and grouped operational-event alerts monitor the application plane.
The watchdog runs outside the Vercel application plane and records failures and recoveries. Central long-term log retention remains a separate in-progress control.
Production dependencies are kept on reviewed lockfiles; continuous multi-scanner enforcement is being completed.
Known production advisories are reviewed and remediated through point-in-time scans. Secret and source scanning are not represented here as standing controls until the private-repository workflows are checked in and verified.
Automated tests and production builds are used before release; enforced branch protection and separation of duties remain open.
The repository has broad automated coverage, but the current repository plan does not enforce all desired approval and required-check gates on the main branch.
System-administration routes and database policies require an AAL2 session; password-only admin access is denied.
Administrative identities enroll and challenge a TOTP factor before entering the system-administration plane. Authorization is based on the canonical admin role plus AAL2, with no email fallback.
A named incident owner, severity model, response targets, escalation path and breach-handling procedure are documented.
The program covers evidence preservation, narrow containment, tested release recovery, customer/regulatory notification ownership, post-incident review and scheduled exercises.
Recording capture has redundant application paths; documented database restore testing remains incomplete.
Live recording uses managed egress plus in-browser backup and recovery logic. A formal restore drill, recovery-time objective and recovery-point objective are not yet published controls.
On-stage publishers must affirm the recording notice before receiving a token, and Flarea stores pseudonymous timestamped evidence.
The token boundary records event, participant role, notice version, lawful basis, first and latest confirmation timestamps and a confirmation count without storing the bearer token, email or IP.
Optional analytics is default-off and creates no visitor identifier until the visitor explicitly allows it.
Do Not Track remains authoritative. Pre-consent events and identify data stay memory-only; every generated embed requires the host consent callback before transmission.
Hosts can delete recordings and attendees can self-serve profile export/erasure; automatic retention enforcement is not active.
The retention engine remains dry-run pending a cold-archive safety net. The public privacy policy states the current behavior instead of advertising automatic deletion that is not enabled.
A canonical public subprocessor register is maintained; formal review records and DPA coverage are still being completed.
The register identifies purpose, data categories and processing region. It does not imply that every vendor review or contract artifact is complete.
ASSURANCE LIBRARY
Unavailable documents are labeled explicitly so procurement teams do not mistake a request button for an existing report.
Data categories, purposes, legal bases, retention posture and individual rights.
Open document ↗Vendors, processing purpose, data categories and processing regions.
Open document ↗Commercial and service terms for the Flarea platform.
Open document ↗Security contact, preferred language, canonical location and reporting guidance.
Open document ↗No executable customer DPA is currently published. Contact us to discuss your Art. 28 and transfer-mechanism requirements.
Submit your questionnaire or control questions and we will provide evidence-backed answers.
Not available. Flarea is not SOC 2 certified and no audit is currently underway.
No artifact to requestNo independent report is currently available for distribution.
No artifact to requestDATA MAP
Canonical register last updated 21 August 2026. Search applies to vendor, purpose, data and region.
| Subprocessor | Purpose | Data | Region |
|---|---|---|---|
| Application hosting & content delivery | All request traffic (in transit); no data at rest beyond logs | All request traffic (in transit); no data at rest beyond logs | United States |
| Database, authentication & file storage | Account, event, registration, survey & recording data | Account, event, registration, survey & recording data | United States |
| Real-time audio/video transport & recording | Live stream media during a show; recordings in transit | Live stream media during a show; recordings in transit | United States / global edge |
| Media object storage | Show recordings and generated media files | Show recordings and generated media files | United States / global |
| AI processing | Show transcripts, prompts & uploaded content sent for processing | Show transcripts, prompts & uploaded content sent for processing | United States · China / global |
| Background media compute | Show recordings downloaded temporarily for rendering; scoped database service credentials | Show recordings downloaded temporarily for rendering; scoped database service credentials | United States / EU (deployment region) |
| Transactional email delivery | Recipient name & email address, message content | Recipient name & email address, message content | United States |
| Federated sign-in | Your Google account email, name & profile photo. Only if you choose Google sign-in | Your Google account email, name & profile photo. Only if you choose Google sign-in | United States / global |
| Payment processing | Billing contact (name, email), plan & usage records, payment method held by Stripe. Card data never reaches our servers | Billing contact (name, email), plan & usage records, payment method held by Stripe. Card data never reaches our servers | United States / global |
| AI voice synthesis | The text sent for synthesis, which may include a participant or prospect name | The text sent for synthesis, which may include a participant or prospect name | United States |
| CRM synchronization (when a customer connects it) | Registration & attendance records the host chooses to sync into their own CRM | Registration & attendance records the host chooses to sync into their own CRM | United States / EU (per the host’s own HubSpot region) |
PROCUREMENT FAQ
No. Flarea is not SOC 2 certified and no SOC 2 audit is currently underway. The control register distinguishes operating controls from in-progress and planned work.
Core hosting, database, authentication, storage, live media and email delivery use the subprocessors listed in the public register. Current primary regions are disclosed there; customer-selectable data residency is not available today.
Flarea does not operate a model-training pipeline using private show content. When an AI feature is invoked, required content may be sent to listed AI subprocessors under their applicable service terms. Contact us for feature-specific data-flow and retention details.
Yes. Use the inquiry form and select DPA / legal or Security questionnaire. Available artifacts and evidence-backed answers are provided by a human.
Use the responsible-disclosure contact in /.well-known/security.txt. Avoid placing exploit details, credentials or sensitive customer data in the general inquiry form.
Google sign-in is available and Flarea system-administration access requires an AAL2 TOTP session. Enterprise SAML and SCIM are not currently available.
HUMAN REVIEW
Send a questionnaire, DPA request or architecture question. We answer from current evidence, not a generic sales script.
Vulnerability report? Use responsible disclosure so sensitive details go to the right channel.