Found something off? Report it here. This helps us fix issues faster during the Briedo pilot.
Trust & Security

Security

Last updated: March 2026

Briedo is built to handle sensitive business information, leads, briefs, and client data submitted on behalf of professional service teams. We take a security-first approach to infrastructure, access control, and data handling. This page describes the practical measures in place, honestly and without over-statement.

If you believe you have found a security vulnerability, please see the Responsible Disclosure section below.

1. Infrastructure

Briedo runs on Google Cloud / Firebase, a managed cloud platform operated by Google LLC. By using Google Cloud's managed services, Briedo inherits Google's physical and infrastructure-level security controls, including:

  • Data centre physical security managed by Google (access controls, surveillance, redundancy)
  • Encryption in transit, all communication between users and the platform is carried over HTTPS/TLS
  • Encryption at rest, Firebase and Google Cloud Storage apply server-managed encryption to stored data by default
  • Backend functions run in a managed serverless environment (Firebase Cloud Functions, europe-west1 region) with no persistent server that requires manual patching

Briedo does not operate its own physical servers, bare-metal infrastructure, or unmanaged VMs. The platform relies entirely on Google-managed services with documented security practices.

More on Google Cloud's security posture: cloud.google.com/security

2. Access Control

Access to platform data is controlled at multiple layers:

Authentication

All Briedo accounts are authenticated via Firebase Authentication, which supports email/password login and Google login. Passwords are never stored in plaintext, they are managed entirely by Firebase Auth's secure credential layer.

Email verification

New accounts must verify their email address before accessing the product. Unverified accounts are redirected to a verification gate and cannot access workspace data.

Workspace isolation

Data in Briedo is scoped to workspaces. Each workspace is accessible only to its members. Firestore security rules enforce that a user can only read and write data for workspaces they are explicitly a member of. Cross-workspace data access is not permitted.

Role-based access

Workspace features are gated by member roles. Administrative functions, such as billing, branding, team management, and account deletion, are accessible only to workspace owners or admins.

Route protection

All application routes that involve user or workspace data are behind authentication guards. Unauthenticated requests to protected routes are redirected to the sign-in page. Public routes do not expose any workspace or user data.

3. Data Protection

Transmission security

All data between user browsers and the Briedo platform is encrypted using HTTPS/TLS. Non-HTTPS access is not served.

Storage security

Briedo uses Firebase Firestore for structured data and Firebase Storage for file assets (such as workspace logos). Both services apply server-managed encryption to data at rest by default as part of the Google Cloud platform.

Public vs. private data

The platform enforces a strict separation between public and private routes. No workspace data, user profiles, or brief content is accessible from public-facing routes. Access to this data requires authentication and valid workspace membership.

Account and data deletion

Users can permanently delete their account and all associated data from within the platform. The deletion flow removes all workspace data, members, templates, briefs, and the user record, in a pre-defined, safe order, before deleting the Firebase Auth credential. Deletion from live systems is immediate; residual copies in infrastructure backups are purged within the backup retention window, and error-monitoring events expire under Sentry's retention period.

API credentials

Sensitive configuration values (API keys, Firebase project credentials) are stored as environment variables and are never embedded in client-side source code at build time in a way that exposes production credentials directly.

4. Privacy and Consent

Security and privacy are complementary. Briedo's approach to both is documented separately and connected:

  • Privacy Policy, explains what personal data is collected, how it is used, the legal bases, and your rights under GDPR.
  • Cookie Policy, explains which cookies and tracking technologies are used, by category, and how to manage them.
  • Consent management, Briedo implements Google Consent Mode v2. Non-essential cookies (analytics, functional, marketing) are denied by default and only activated after explicit user consent. Consent choices are stored locally and can be changed at any time.

5. Operational Care

Briedo is a product in active development. We operate with the following practical defaults:

  • Managed platform dependencies, By building on Firebase and Google Cloud, Briedo inherits infrastructure-level patching and security updates applied by Google without requiring manual intervention.
  • Fail-fast configuration validation, The application validates required configuration at startup and refuses to initialise if critical environment variables are missing, reducing the risk of running in a misconfigured state.
  • Strict Firestore security rules, All database read/write operations are governed by server-side Firestore security rules that enforce authentication, membership checks, and role conditions. No rule allows unrestricted data access.
  • Token-based authentication architecture, All authenticated requests to the database use short-lived Firebase ID tokens transmitted as bearer tokens in request headers, not as cookies. This means the browser does not automatically attach credentials to cross-origin requests, which eliminates the classical cookie-based CSRF attack path for all data operations.
  • Protection on public surfaces, Every public unauthenticated surface carries its own protection: the pilot application form (server-side reCAPTCHA v3, CORS origin allowlisting, payload validation), the lead intake conversation and embed runtime (rate limiting and a honeypot field), and the guest report portal (single-use, SHA-256-hashed, expiring access tokens).

We do not currently hold independent security certifications (SOC 2, ISO 27001) or formal penetration test reports. We are a focused, early-stage product and aim to represent our security posture honestly. Future investment in formal audits and certifications is planned as the platform scales.

7. Related Policies

Security contact — Briedo

contact@briedo.com