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, in the database. Cost rates, salaries and overheads are readable by the workspace owner alone, and client-facing quote pricing is readable by owners and managers. That split is enforced by the database rather than by the interface: those fields are stripped from the record before it leaves Postgres, according to the role of whoever asked, and the underlying column is not readable by an ordinary session at all. A manager or a member cannot retrieve them by any route the application offers, including calling the API directly with their own credentials.

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 Content Security Policy with default-src 'self', object-src 'none' and an explicit connect-src allowlist, so scripts and outbound requests are confined to a published list of origins. Being exact about it: script-src still permits 'unsafe-inline' plus Google's sign-in and Cloudflare's analytics hosts, so this is not yet a nonce-based policy and it does not stop an injected inline script on its own. Moving to nonces is on the list. You can read the live header yourself with curl -I against any page here, and we would rather you did that than take our word for the word "strict".
• 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.

Do you set cookies or track users?

No. Stasis sets no cookies anywhere, and uses no advertising or cross-site tracking technology. What it does keep on the device is first-party browser storage: your sign-in session, a few display preferences, the tab-scoped flags behind the interactive demo, and a handful of short-lived entries that carry a step across a sign-in round trip. Clearing site data removes all of it. The Privacy Notice lists every entry and what each one is for.

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. Very large tables export up to 10,000 rows each, which the export panel tells you before you start. Within that, a workspace owner can export the whole 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 breach-response runbook aligned with the mandatory notification duty the PDPA has carried since its 2024 amendment. Where a breach causes or is likely to cause significant harm, or affects more than 1,000 people, we notify the Personal Data Protection Commissioner through the JPDP's notification channel as soon as practicable and within 72 hours. Individuals for whom we are the controller are notified within seven days of that, where significant harm is likely. If a breach affects your workspace's data, we notify you without undue delay with the facts known at the time, the likely impact and the measures taken, so that your own 72-hour clock as controller starts with what the filing needs. Every incident goes into a breach register we keep for at least two years.

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 privacy@clavis-data.com. We acknowledge good-faith vulnerability reports and will not pursue researchers who test responsibly within their own workspace.