Built carefully, on purpose.
Kova is built with careful boundaries, scoped workspaces, and readiness-focused guidance. This page explains what we currently do, what we do not claim, and what we are improving as the platform matures.
Careful claims, practical guidance, organization-scoped work.
Kova is designed for small business readiness, not enterprise compliance. Every feature is built so the score, the recommendations, and the report reflect what the team has actually documented. We use stronger validation language only when the underlying check exists, and we say so clearly when something is on the roadmap.
Supabase Auth, request-scoped sessions, route guarding.
Sign-in and sign-up are handled by Supabase Auth using email and password. Sessions are refreshed on every request to authenticated routes via a server middleware. Authenticated app routes are guarded so unauthenticated visitors are redirected to sign-in, with a clearly labeled demo workspace available without auth for prospect tours.
- Server-side session checks on every authenticated request.
- Three separate Supabase clients (browser, server, service) so privileges stay scoped.
- The service-role client is guarded by a server-only import; it is never reachable from the client bundle.
Workspaces are scoped to your organization.
Customer data is partitioned by organization. Every workspace record (checklist items, policies, evidence, training, insurance items, reports, activity) carries an organization id. Reads and writes are scoped to organizations the user belongs to. Demo workspace data is fictional and clearly labeled. Real evidence handling will continue to mature as the upload feature is built.
RLS on every table, membership-checked reads and writes.
Every Postgres table that holds customer data has Row Level Security enabled. The standard policy scopes a row to the organizations the signed-in user is a member of via the organization_members table. Server actions additionally run an explicit membership check and replace any caller-supplied organization id with the authenticated one, so a hostile client cannot pivot to another workspace.
- 15 tables, RLS enabled on each.
- Append-only change log scoped by membership (SELECT and INSERT only).
- Server actions require an authenticated user before any write.
A short, ordered list. Honest, not aspirational.
We track our hardening work in a single document and ship against it in order. The next items in the queue:
- Role-based access controls applied to every server action. The first action is gated today; the rest follow on a rolling basis.
- Granular change-log coverage across policy, evidence, checklist, and report mutations.
- Rate limiting on server actions per user.
- Safer evidence handling: file-type allowlist, retention policy, soft delete with undo window.
- More resilient sync: surfaced failures, retry on transient errors, idempotency keys.
- Transaction grouping for multi-step updates so partial writes do not leak.
Reading honestly is part of the product.
Kova does not claim any of the following until the underlying capability is built and clearly labeled:
- Formal certification of any kind (no SOC 2, ISO, or framework claim today).
- Insurance approval. Insurers make their own decisions.
- Tamper-evident or cryptographically signed evidence.
- Independent control verification by Kova.
- Breach prevention.
Where copy refers to evidence or readiness, the language reflects what the system can responsibly support. See our trust FAQ for the most common questions.
Built around common small-business security practices and reviewed through Kova’s security readiness methodology. Guidance is practical, careful, and grounded in what teams can actually maintain.