Draft template. This document describes how the product works today but has not yet been reviewed by legal counsel. It is not a binding agreement until finalised and, where relevant, signed.

Security

Last updated 28 September 2026

An honest description of how GrowthPPL is secured today — and what we have not done yet. We would rather under-claim than over-claim.

What's in place

Tenant isolation: every query is scoped to the caller's tenant in application code — the mechanism that's actually enforced today.

Authentication: passwords of at least 10 characters, hashed with bcrypt; optional two-factor sign-in with an authenticator app, which a workspace owner can require by role; Google and Microsoft sign-in where enabled, matched to an existing login by verified address; sessions are JWT-based and expire; invite and password-reset links are single-use and stored as hashes.

Transport & data: served over TLS; user data uses soft-delete so accidental deletes are recoverable before purge.

Operations: structured logging with request/error context; parameterised queries throughout; server secrets are never exposed to the browser.

What we have NOT done yet

We are not SOC 2 / ISO 27001 certified. We do not yet offer SAML single sign-on, a published penetration-test report, or a contractual uptime SLA. We will say so plainly until each is real — we will not display a compliance badge we have not earned.

Every tenant table defines a Postgres row-level security policy, but the application's own database role currently has elevated privileges that bypass them — RLS is defined, not yet an independently enforced second layer on top of the application-code scoping above. Moving to a restricted database role is on our roadmap.

Reporting an issue

Found a vulnerability? Email security@growthppl.com. We will acknowledge and work with you in good faith.