SiteSphere

SiteSphere — Legal

Security

Effective date: 2026-04-29

Security at SiteSphere is built around three principles: encrypt everything, isolate every tenant at the database, and minimise the data we hold.

Infrastructure

  • Database & storage: Supabase (managed PostgreSQL + object storage), hosted in the Sydney AU region. Backups are managed by Supabase with point-in-time recovery on all production databases.
  • Application hosting: Railway for the API and web app; Vercel for the marketing site. Both providers operate SOC 2 Type II certified infrastructure.
  • Email & SMS: Resend (transactional email) and ClickSend / Sinch (SMS). Both are bound by data processing arrangements limiting use to message delivery.

Encryption

  • In transit: TLS 1.2 or above is required for all connections to SiteSphere. HTTP requests are redirected to HTTPS.
  • At rest: AES-256 encryption is applied to all data stored in our Supabase databases and object stores.
  • OAuth tokens: Xero refresh tokens are encrypted with AES-256-GCM using a key held outside the database before being stored.
  • Authentication: Passwords are stored as bcrypt hashes (handled by Supabase Auth). Session JWTs are signed with HS256 using a key held only in the application environment.

Multi-tenant isolation

Multi-tenancy is enforced at the database via Postgres row-level security (RLS). Every table that contains tenant data has an RLS policy that filters reads and writes by the requesting user's business or client membership. The application layer does not perform this check — it's enforced one layer below the application boundary, which means a bug in a route handler cannot leak data across tenants.

Service-role access (used for system operations like push notification fan-out) is restricted to a small set of clearly marked code paths and never reaches the user-facing surface.

Access controls

  • Role-based access enforced at both the API (request middleware) and the UI (route guards).
  • Field roles (workers, leading hands, supervisors) and desk roles (business admins, payroll managers, client admins) live on different surfaces (mobile vs web). The split is enforced symmetrically in middleware on both surfaces.
  • Supervisors are client-side: they see crew sheets for their client's projects only, with row-level enforcement at every read.
  • Magic-link tokens for unauthenticated supervisor and client approvals are single-use and short-lived; the underlying scoped JWT does not grant general account access.

Audit and observability

  • API request logs retained for 30 days for troubleshooting.
  • Calculation trail: every payroll line written to the database carries a per-clause trail describing exactly which rule produced the value. This is visible to business admins for dispute resolution.
  • Xero webhook activity is logged and reconciled against expected state.

Vulnerability management

  • Dependencies are tracked via automated tooling. Critical and high-severity advisories are patched within 7 days of upstream release.
  • Static analysis runs on every pull request. Strict TypeScript + ESLint configurations are enforced as merge gates.
  • Production database migrations are applied through a CI/CD pipeline; manual SQL access to production is restricted and logged.

Incident response

We follow the Notifiable Data Breaches scheme under the Privacy Act 1988. Where a security incident meets the notification threshold, we will notify affected individuals and the Office of the Australian Information Commissioner (OAIC) as soon as practicable.

Customers can subscribe to status updates and incident notices by contacting security@sitesphere.com.au.

Reporting a vulnerability

If you believe you have found a security issue in SiteSphere, email security@sitesphere.com.au with the details. We will acknowledge receipt within one business day and keep you informed as we investigate.

Please do not perform load or vulnerability testing against production without prior written consent.