Security at Stasis

How is customer data isolated between tenants?

Stasis is multi-tenant, and isolation is enforced in the database itself, not only in application code:

• Every tenant-scoped table carries a tenant identifier, and Postgres row-level security (RLS) policies restrict every read and write to the caller's own workspace.
• RLS is set to FORCE on all tenant tables, so the policies bind even privileged database roles and table owners.
• Cross-table references use tenant-scoped composite foreign keys on sensitive paths, so a row in one workspace cannot be made to point at data in another.
• Background jobs that run with elevated database access re-assert tenant scope in code on every query, as a second layer on top of RLS.

How is access controlled inside a workspace?

Each user has a role (owner, manager, HR or member). Role checks are enforced in database policies and in server-side procedures that authorise the caller before writing, not only in the user interface. Two examples of least-privilege design in the product:

• Deadline visibility is role-gated. Only owners and managers see a job's committed client deadline. Members see only the planned start and finish of their own tasks, and that separation is applied at the data layer: members' schedule and task views never fetch the committed deadline.
• Cost and margin data is owner-only. Cost rates, margins and profitability are visible to the workspace owner alone; client-facing quote pricing is available to owners and managers.

Is data encrypted?

• In transit: all traffic between browsers, our API and the database is encrypted with TLS, and HSTS instructs browsers to refuse unencrypted connections.
• At rest: customer data lives in managed Postgres on Supabase, which encrypts storage at rest.
• Push notifications: payloads are encrypted end to end to the receiving device (see below).

How does authentication work?

Users sign in with email and password today; Google and Microsoft single sign-on is built and being rolled out. Sessions are managed by Supabase Auth using signed, expiring tokens. Passwords are stored only as salted hashes by the authentication provider and never touch our own servers. We intentionally do not offer our own multi-factor authentication: once single sign-on is enabled, users who sign in through Google or Microsoft inherit the MFA policies of their own identity provider.

Where is the service hosted?

The web application is served from Cloudflare Pages and the API runs on Cloudflare Workers, both on Cloudflare's global edge network. The database and authentication run on Supabase managed Postgres in Singapore (AWS ap-southeast-1). The full sub-processor list is below.

What browser-level protections are in place?

• A strict Content Security Policy (default-src 'self' with an explicit connect-src allowlist), which blocks injected scripts and unexpected outbound requests.
• HSTS and a restrictive Permissions-Policy.
• frame-ancestors 'none', so the app cannot be embedded in another site for clickjacking.
• User-supplied links are restricted to http and https, checked both at the database (a CHECK constraint on stored URLs) and again at render time.

How do push notifications work?

Web push is self-hosted: we sign and send pushes ourselves rather than routing content through a third-party relay. Each payload is encrypted end to end to the subscribing device using the Web Push encryption standard (RFC 8291), and our signing key is held as an isolated server secret. Notification content respects the same role gates as the app, so a push never reveals data the recipient could not see on screen.

Can we get our data out?

Yes, self-service and without a support ticket. A workspace owner can export the entire workspace at any time as a single JSON file plus per-table CSV files, covering the full structure of clients, jobs, templates, schedules, people and settings.

How is data deleted?

• Delete the workspace: the owner can permanently erase the whole workspace, guarded by a typed-name confirmation. This is a hard delete, including the associated user accounts.
• Remove a person: owners and HR can remove an individual; their future work is unassigned for reassignment and their past records are anonymised.
• Member requests: any member can file a data-deletion request from inside the app, which is routed to the workspace owners.

These flows support the erasure rights in Malaysia's PDPA and the deletion-on-termination commitments in our Data Processing Addendum.

Is there an audit trail?

Yes. Key delivery actions are recorded in a tenant-scoped audit log: job creation and changes, spreadsheet imports, task approvals and returns, and time-off decisions. The log is available to the workspace owner in the admin area.

What happens if there is a breach?

We maintain a written incident-response runbook with a 72-hour notification target, aligned with our obligations under the PDPA. If a breach affects your data, we notify you without undue delay with the facts known at the time, the likely impact, and the measures taken, and we assist you in meeting your own notification duties as controller.

Who are your sub-processors?

We use a small number of infrastructure providers, bound by contracts that require them to protect the data and act only on our instructions:

What certifications do you hold?

None yet. We do not hold SOC 2, ISO 27001 or similar attestations at this stage, and we will not claim them until an independent audit says so. We are happy to complete your security questionnaire or to walk your team through any of the measures on this page.

Security contact

Report a vulnerability or ask a security question at [email protected]. We acknowledge good-faith vulnerability reports and will not pursue researchers who test responsibly within their own workspace.