Security

Security for witness evidence, legal workflows, and firm data.

Casey is designed for UK legal practices that handle sensitive witness statements and case material. This page explains the security posture, current platform controls, and shared responsibilities that support safer adoption.

Discuss security on a demo Privacy policy

Designed for sensitive legal work

Case files, witness accounts, draft statements, and exhibits can contain highly sensitive personal data. Casey is built around controlled access, clear accountability, and cautious defaults.

Firm-scoped at the database layer

Casey uses Supabase row-level security policies so firm boundaries and role checks are enforced in the database, not only in the user interface.

Auditable workflows

Important activity across statement preparation, follow-up, final review, and administrative actions is designed to leave an operational trail.

Controls

How Casey protects access and activity

Security is applied across the user, firm, matter, statement, and witness-link layers. The controls below are a high-level summary, not a substitute for a firm's own information security review.

Role-based write controls

Firm users are assigned roles such as firm admin, solicitor, or paralegal. Sensitive case, statement, magic-link, and storage writes are restricted by database policies to appropriate roles.

Time-bound witness links

Witness intake is accessed through tokenised links tied to a specific statement, with expiry and state checks before sensitive actions proceed.

Server-side enforcement

Public witness operations go through server-side routes that validate token scope, statement state, expected document paths, upload limits, and rate limits before privileged storage actions run.

Scoped data access

Application queries, RLS policies, and storage policies are designed to limit access to the correct firm, matter, statement, and document context.

Operational monitoring

Request logging is sanitized to avoid bearer-token leakage, and audit-style event records help identify unexpected access patterns and reconstruct important workflow activity.

Document safeguards

Template and DOCX review tooling helps reduce errors in generated legal documents before they are published or used in live work.

Implementation

What is enforced today

The controls below describe the current implementation rather than a future target state. They are intentionally specific so firms can evaluate whether the model fits their risk profile.

Firm isolation is enforced with Supabase RLS policies for application tables and storage policies for organisation buckets.

Paralegal, solicitor, firm-admin, and app-admin roles are not treated as interchangeable for write access.

Witness links are bearer-style access tokens, so logs redact token-like path segments and public routes re-check token validity before each sensitive action.

Uploaded evidence is stored only through server routes for public intake, with server-derived metadata and expected path prefixes.

Data is not currently application-level encrypted before it is written to Supabase. Transport encryption, Supabase platform controls, RLS, and access controls are therefore important parts of the current model.

Firms with a requirement for customer-managed keys or field-level encryption should raise that during security review before using the platform for highly sensitive matters.

Witness-link security model

Witnesses do not need access to an internal legal dashboard. Instead, Casey uses scoped intake links for the task they have been invited to complete.

This separation helps firms collect witness information while reducing exposure of unrelated cases, team dashboards, template settings, or administrative tools.

Witness intake safeguards

Privacy notice acknowledgement before the witness intake flow continues

Token checks before interview, follow-up, evidence, and final-review actions

Direct anonymous storage access removed from public witness flows

Statement-specific storage path validation for evidence and signed documents

Upload count, size, file-type, and persistent rate-limit controls for public evidence endpoints

Statement-state validation to reduce accidental post-submission changes

Final-review and follow-up routes separated from internal firm dashboards

Shared responsibility with the legal practice

Casey provides platform controls, but each firm remains responsible for how it configures access, instructs users, and applies its own professional, regulatory, and data-protection obligations.

Choose appropriate user roles and remove access when team members change matters or leave the firm

Confirm the legal basis, privacy notices, retention rules, and client-care wording used for live matters

Use strong identity practices for firm email accounts and devices used to access the platform

Avoid sharing witness links outside the intended recipient and matter context

Review exported documents before filing, serving, or relying on them

Maintain internal policies for incident response, retention, supervision, and staff training

Incident and vulnerability reporting

If you believe you have found a security issue, please report it promptly and avoid accessing, modifying, or sharing any data that is not yours.

Email security contact

Security review notes

This page describes the product's high-level security design. It does not guarantee that every possible risk has been removed, and it should be read alongside the firm's own policies, supplier due diligence, client obligations, and professional duties.

Legal practices should confirm their own retention schedules, data-processing terms, privacy notices, and acceptable-use requirements before using the service for live matters.