Security

Last reviewed: May 11, 2026

Watari processes customer support data and source code on behalf of our customers. The following describes the technical and organisational measures we use to protect that data. For contractual security commitments, see Exhibit C of our Data Processing Agreement.

Encryption

  • In transit: TLS 1.3 minimum on every customer-facing endpoint. HSTS enabled with a 2-year max-age,includeSubDomains, preload-eligible. Inter-service calls between Watari and its subprocessors use HTTPS exclusively.
  • At rest: sensitive secrets (OAuth access tokens, refresh tokens, per-tenant webhook signing secrets, integration credentials) are encrypted with AES-256-GCM before being written to the database. The encryption key (INTEGRATION_SECRET_KEY) is held in a Vercel Sensitive Environment Variable and is rotated on a defined cadence.
  • Storage layer: all customer data is stored on Supabase managed Postgres, with disk-level AES-256 encryption provided by the underlying AWS infrastructure (United States, us-east-1).

Tenant isolation

Every customer-data table carries an organization_id column and a Postgres row-level security (RLS) policy that restricts SELECT, INSERT, UPDATE, and DELETE to rows owned by the authenticated organisation. Every new migration that introduces a customer-data table is required to ship with a paired RLS policy; we treat a missing policy as a release-blocking bug.

A service-role “admin” client that bypasses RLS is used for flows that intentionally cannot rely on the user-bound RLS client: OAuth callbacks that run before a session exists, background jobs (Inngest) operating on a pre-resolved organisation, and admin-gated server actions that have already validated the caller's organisation membership. Every admin-client call site is reviewable in the source repository.

Authentication

  • Customer authentication runs on Supabase Auth: email + password with strong password requirements, plus OAuth login with GitHub and Google.
  • Sessions are protected with HTTP-only, Secure, SameSite=Lax cookies.
  • Server-side code uses getUser() (not getSession()) to verify the session against the Supabase auth server on every request — defending against forged cookies.
  • Webhook endpoints verify HMAC signatures before any side effects. Zendesk uses a per-tenant signing secret auto-provisioned during the OAuth callback and stored encrypted in the integration row. Intercom uses the app-wide signing secret (Intercom does not provide per-install secrets). GitHub and Razorpay use app-wide secrets per their respective conventions.

Personnel access & audit

Watari personnel access to production systems is least- privilege and audit-logged. Administrative actions on the database are restricted to a small group of named engineers and require single sign-on. Customer-content access by Watari personnel is prohibited except as described in §6.2 below.

6. Operational controls

6.1 Monitoring & alerting

  • Application logging via structured pino logger.
  • Error monitoring via Sentry with PII scrubbing before transmission.
  • Uptime and synthetic monitoring via Better Stack, with on-call alerting.

6.2 Customer-content access

Watari personnel are prohibited from viewing Customer Content, except when (a) instructed by the Customer; (b) necessary to resolve a support issue the Customer has raised; (c) necessary for security, Service integrity, or legal purposes (incident response, abuse investigation, lawful process).

6.3 Backups

Automated daily backups with a rolling 30-day retention window. Backups are encrypted at rest and stored in the same region as the primary database (United States). Periodic restore drills validate recoverability.

6.4 Change management

Production deployments run through Vercel and require a passing CI pipeline (lint, type-check, unit and integration tests). Database migrations are reviewed and applied via the Supabase MCP migrate command; destructive migrations require explicit approval.

7. Incident response

We maintain a documented incident-response runbook covering detection, triage, containment, communication, eradication, and post-incident review. For confirmed personal data breaches affecting customer data, we notify the affected Customer (Controller) within 72 hours of becoming aware of the breach, with the information required by GDPR Article 33(3) where applicable. See DPA §8 for the full commitment.

8. Compliance posture

  • SOC 2 Type II:in progress — observation window engaged with a Vanta-supported audit programme; the certification target date will be published here once locked.
  • GDPR: in scope as Processor for EEA Customer Personal Data, with SCC Module 2/3 transfers and supplementary measures.
  • UK GDPR + DPA 2018: in scope; UK Addendum to SCCs incorporated by reference for UK transfers.
  • DPDP Act 2023 (India): in scope as Data Fiduciary for direct collection and Data Processor for Customer Content; Grievance Officer published at Privacy §9.
  • HIPAA: the Service is not configured for handling Protected Health Information and we do not sign Business Associate Agreements.

9. Responsible disclosure

We welcome reports of suspected security vulnerabilities. Please email security@watari.ai with steps to reproduce, the affected component, and your contact details. We will acknowledge within 3 business days and work toward remediation in good faith.

We commit to a safe-harbour for good-faith research that stays within the scope outlined in our security.txt and avoids: privacy violations of other users, destruction of data, degradation of the production Service, or social engineering of Watari personnel. See /.well-known/security.txt for machine-readable contact information.

10. Subprocessors & supply chain

The third parties Watari relies on to operate the Service are listed at watari.ai/legal/subprocessors. We provide 30 days' advance notice of new or replaced subprocessors via email subscription; see DPA §5.

11. Contact

For security questions, vulnerability reports, or audit requests, email security@watari.ai.