Security Overview

Authentication

Success.co uses federated authentication exclusively - we do not store passwords.

Users sign in via:

• Google OAuth (OpenID Connect)

• Microsoft OAuth (including GCC High for government environments)

• Custom OpenID Connect providers

This eliminates entire categories of risk including password reuse, weak passwords, and credential stuffing attacks.

Session Management

• Sessions are stored server-side with a 30-day maximum age

• Cookies are marked Secure (HTTPS-only) and SameSite

• Sessions are scoped to a single company context

API Authentication

For programmatic access, we support:

• OAuth 2.0 with PKCE: full Authorization Code flow with Proof Key for Code Exchange, preventing authorization code interception

• API Keys: prefixed, cached, and rate-limited (1,500 requests/hour)

• RS256 JWT tokens: signed with rotating RSA key pairs, verifiable via a public JWKS endpoint

Infrastructure

Hosting & Network

• Google Cloud Platform (GCP): all backend services run on GCP in the US

• Cloudflare: all traffic is routed through Cloudflare, providing DDoS protection, WAF, CDN, and TLS termination

• Cloudflare Pages: static frontend assets are served from Cloudflare's edge network

Encryption

In transit: All connections are encrypted via TLS. Cloudflare enforces HTTPS for all public endpoints, and internal service-to-service communication uses secure channels.

At rest: Data stored in GCP-managed database storage benefits from GCP's default encryption at rest using AES-256. File uploads are stored in Google Cloud Storage, which is encrypted at rest by default.

Multi-Tenancy & Data Isolation

Data isolation is enforced at the database level using Row-Level Security (RLS) - not at the application level. This means:

• Every data table includes a company_id column

• Every query is automatically filtered to the authenticated user's company

• Even if application code contained a bug, the database itself prevents cross-tenant data access

• RLS policies are defined for SELECT, INSERT, UPDATE, and DELETE operations independently

Session variables are set per-request before any query executes:

• User identity (userId, email)

• Company context (companyId)

• Permission level (permissionId)

This is defence-in-depth: the database is the final enforcer of tenant boundaries, not the application.

Permission Model

Success.co implements a six-tier role-based access control system:

• Owner: Full access, company-level administration

• Admin: Full access to all company data

• Implementer: Full access (for EOS implementers working with the company)

• Practice Manager: Full access (for practice managers overseeing multiple companies)

• Manager: Scoped to their assigned teams only

• Observer: Read-only access with limited scope

Team-level scoping is enforced at the database level via RLS policies - Managers and Observers can only see data belonging to teams they are members of.

Application Security

• No stored passwords: federated auth only

• Rate limiting: API key requests are rate-limited per IP

• Statement timeouts: all database queries are capped at 3 seconds, preventing denial-of-service via expensive queries

• Soft deletion: records are logically deleted (not immediately purged), with automatic cleanup after 30 days

• File upload limits: 30 MB maximum with file type validation

• Webhook signature verification: third-party webhooks (e.g. Stripe) are verified using cryptographic signatures

• CORS: configured to restrict cross-origin requests with credential support

Real-Time Sync Architecture

Success.co uses a local-first sync engine for real-time collaboration:

• Server-side: Database logical replication captures changes at the WAL (Write-Ahead Log) level and broadcasts them via WebSocket to authenticated, company-scoped rooms

• Client-side: Data is stored locally in IndexedDB for offline support and fast reads

• Isolation: WebSocket rooms are scoped per company - users only receive events for their own organisation

• Optimistic updates with automatic rollback on server rejection

Subprocessors

• Google Cloud Platform

  • Purpose: Infrastructure, compute, database, storage

  • Data Handled: All application data

• Google Cloud Storage

  • Purpose: File uploads

  • Data Handled: User-uploaded files and documents

• Cloudflare

  • Purpose: CDN, DDoS protection, DNS, static hosting

  • Data Handled: Request routing, cached assets

• Stripe

  • Purpose: Payment processing

  • Data Handled: Billing and payment information

• Postmark

  • Purpose: Transactional email

  • Data Handled: Email addresses, meeting summary and notification content

• PostHog

  • Purpose: Product analytics

  • Data Handled: Anonymised usage events

Optional Integrations (User-Enabled)

These services are only connected if the user explicitly enables them:

• Google Calendar / Tasks

• Microsoft Outlook Calendar / To Do

• Slack

• Monday.com, Asana, ClickUp, Teamwork

Data shared with optional integrations is limited to what the user chooses to sync (e.g. meeting events, tasks).

Data Retention & Deletion

• Active data is retained for the lifetime of the account

• Soft-deleted records are automatically purged after 30 days

• Users with appropriate permissions can delete their own data at any time

• Account and company deletion can be actioned by company owners

Incident Response

If you have a security concern or need to report a vulnerability, please contact us at security@success.co.

Questions

For security questionnaires, further documentation, or to discuss specific compliance requirements, please reach out to security@success.co and we'll work with your team directly.