Waysa
  • Home
  • Platform
  • Pricing
  • About
  • Contact
Sign inRequest a demo
HomePlatformPricingAboutContact
Sign inRequest a demo

Trust

Security at Waysa

Last updated: 6 June 2026

Waysa Systems is built for professional-services firms handling sensitive information — claim files, case files, medical records, legal correspondence. Security and data protection are central to how we design, build and operate the Service. This page summarises the technical and organisational measures we have in place today.

For how we handle personal data, see our Privacy Policy. For how we use AI, see our AI Usage Policy.

1. Infrastructure and hosting

  • EU-region hosting. Customer data is stored and processed on infrastructure located in the European Union. Our database, authentication system and file storage are hosted on Supabase in an EU region; our web application is hosted on Vercel in an EU region.
  • Managed providers. Both providers are subject to independent security audits and maintain published trust reports.
  • No on-premise access. Customer data is not stored on staff devices.

2. Encryption

  • In transit: all traffic to and from the Service is encrypted with TLS 1.2 or higher. HTTPS is enforced; HTTP requests are redirected.
  • At rest: the underlying Supabase database and file storage are encrypted at rest using AES-256.
  • Secrets: API keys, service-role tokens and other secrets are stored in encrypted environment variables, not in source code.

3. Access controls

  • Row-Level Security (RLS). Every database table enforces row-level security policies that scope reads and writes to the user’s own company. Cross-tenant access is not possible via the application layer.
  • Role-based access. Within a workspace, users have one of three roles — admin, manager or case handler — with permissions enforced both at the database and the application layer.
  • Invitation-only onboarding. Self-serve sign-up is disabled. New users join an existing workspace only when an admin sends them an emailed invitation.
  • Service-role isolation. The privileged service-role key that bypasses RLS is held server-side only. It is never exposed to the browser or to client-side code.
  • Least privilege internally. Production access is limited to the smallest practicable set of operators; access is reviewed periodically.

4. Authentication

  • Authentication is handled by Supabase Auth. Passwords are hashed using industry-standard algorithms; we never see or store plain-text passwords.
  • Password recovery and team invitations use single-use, time-limited tokens delivered by email.
  • Sessions are bound to short-lived JWTs with rolling refresh tokens; revoked sessions stop working immediately.

5. Audit logging

Waysa maintains an immutable audit trail of significant actions across the platform — including authentication events, file uploads and downloads, AI processing runs, report generation, role changes and administrative actions. Audit entries are queryable by workspace admins and retained for at least 12 months to support security investigations and regulatory queries.

6. AI processing

  • AI features are powered by OpenAI’s API. We do not allow customer content to be used to train any model — ours or our subprocessors’ — and OpenAI does not train on API content by default.
  • Only the document text necessary for the requested operation (summarisation, key-fact extraction, report drafting) is sent to the AI provider. Full files are not sent unless needed for that operation.
  • AI processing is initiated by an authenticated user request and is recorded in the audit log with the user, the file, the model used and the response identifier.

For full details, see our AI Usage Policy.

7. Application security

  • The Service is built on Next.js with server-side rendering and a Python FastAPI service for AI orchestration. Both run within managed, isolated environments.
  • Inputs are validated and outputs encoded to mitigate common OWASP-listed vulnerabilities (injection, XSS, CSRF).
  • File uploads are restricted by MIME type and size; storage is partitioned by company and role-gated by RLS.
  • Dependencies are kept up to date and reviewed for known vulnerabilities.

8. Operational practices

  • Backups. The Supabase managed database is backed up automatically by our hosting provider, with point-in-time recovery available within the retention window of the active plan.
  • Change management. Code changes are reviewed before merge. Production deployments are automated and version-pinned for traceability.
  • Monitoring. The platform is monitored for availability and errors; on-call procedures govern incident response.

9. Subprocessors

We use a small number of carefully chosen subprocessors. Each is bound by data-protection terms equivalent to our own:

  • Supabase — database, authentication, file storage (EU region)
  • Vercel — web application hosting (EU region)
  • OpenAI — large-language-model API (US, with the appropriate transfer safeguards)

10. Responsible disclosure

If you believe you have found a security vulnerability in the Waysa platform, please report it privately to waysasystems@gmail.com with the details and steps to reproduce. We will acknowledge receipt promptly and work with you to remediate the issue. Please do not disclose the issue publicly until we have had a reasonable opportunity to address it.

11. Roadmap

Security is a continuing investment. Items on our near-term roadmap include independent third-party penetration testing, formal SOC 2 readiness, customer-managed keys, optional SSO/SAML, and a public sub-processor change-notification feed. We will update this page as those items ship.

12. Contact

Security questions and procurement enquiries can be sent to waysasystems@gmail.com.

© 2026 Waysa Systems
PrivacyTermsCookiesSecurityAI usageContact