Security & Trust

Last updated: 27 June 2026

Synnea holds engineering register data for marine and offshore installations, so security is foundational to how we build. This page explains, in plain terms, how the product is architected to keep each customer’s data isolated and protected, where it lives, and how to report a suspected vulnerability. It is a description of our practices, not a contract; where it touches on data processing, the Data Processing Agreement and Privacy Policy govern.

1. Overview

Synnea is a Next.js application hosted on Vercel, with data, authentication and file storage on Supabase (managed PostgreSQL) in the EU region (eu-north-1). Security is built into the architecture rather than bolted on: tenant data is isolated at the database level, all traffic is encrypted in transit, and privileged operations run through audited database functions.

The sections below describe how access is controlled, where data resides, the third parties that help us run the service, and how you can reach us about anything security-related.

2. Tenant isolation & access control

Synnea is multi-tenant from the first table. PostgreSQL Row-Level Security (RLS) is the authorization boundary: every row is scoped to an organisation and installation, and that scoping is enforced by the database itself, not only by the application. This means an application-layer bug cannot, by design, expose one tenant’s data to another — the database refuses to return rows that the current session is not entitled to see.

Operations that need elevated privileges (for example, certain administrative or cross-organisation actions) do not bypass these controls in application code. Instead they run through audited SECURITY DEFINER database functions, so privileged behaviour is centralised, reviewable and constrained.

Access within and across organisations is explicit. Cross-organisation sharing is scoped: an owner can share a whole installation, or only specific systems, with another organisation, and counterpart data stays redacted unless it has been deliberately shared. Roles govern what each user can do — organisation roles (owner, admin, member) and per-installation roles (viewer, editor, admin).

3. Authentication

Sign-in is handled by Supabase Auth, supporting email and password as well as Google sign-in. Passwords are handled and hashed by the authentication provider; Synnea never stores plaintext passwords. Sessions use secure, http-only cookies.

What an authenticated user can see and do is determined by their organisation role (owner, admin, member) and their per-installation role (viewer, editor, admin), enforced together with the database-level isolation described above.

4. Encryption

All traffic between your browser and Synnea is encrypted in transit using TLS/HTTPS. Data is encrypted at rest by our infrastructure providers.

5. Data residency & hosting

The primary database is hosted in the EU (eu-north-1). Application hosting and content delivery run on Vercel, and error monitoring is EU-hosted. Backups are performed by our database provider.

The third parties that process data on our behalf are listed in the next section and in the Data Processing Agreement.

6. Sub-processors

We rely on a small set of infrastructure providers to operate Synnea. Each acts as a sub-processor under our Data Processing Agreement, and the table below summarises their role and location. The Data Processing Agreement and Privacy Policy describe how customer and personal data are processed in more detail.

7. Monitoring & logging

We use Sentry (EU-hosted) for error monitoring. Session replay is masked and is recorded only when an error occurs; personally-identifying information is not sent by default (the sendDefaultPii setting is off).

Within the product, an activity log records relevant actions on a register so that organisations can see what changed and by whom.

8. API keys

Organisations can issue API keys for programmatic access. Keys are stored only as a salted hash, never in plaintext, so the raw key is shown to you once at creation and cannot be recovered from us afterwards. Keys can be revoked at any time, which immediately ends access for that key.

9. Data ownership, export & deletion

Customers own their data. You can export it (as CSV or Excel) at any time. On request, or on termination, your data is returned or deleted as set out in the Data Processing Agreement, which governs in case of any conflict with this page.

10. Analyses & engineering disclaimer

Synnea’s engineering analyses — including single-point-of-failure detection, worst-case-failure simulation and draft FMEA worksheets — are decision-support, not certified verdicts. Their scope and limits are described in the Engineering Disclaimer, which you should read alongside this page: see /legal/disclaimer.

11. Responsible disclosure

We welcome reports of suspected vulnerabilities. If you believe you have found a security issue in Synnea, please email hello@synnea.no with enough detail for us to reproduce it.

We ask that you act in good faith — avoid accessing or modifying data that is not yours, avoid degrading the service for others, and give us a reasonable time to investigate and remediate before any public disclosure. We will work with you in good faith in return.

12. Contact

Questions about security, or about anything on this page, can be sent to hello@synnea.no.