How we protect your client data
The technical details behind how DocketBuddy secures your data: what we actually do, how it works, and what it relies on. No marketing language.
What this means in plain English
Encrypted in transit and at rest
Your data is protected moving and stored. TLS on every connection; AES-256 at the database layer.
Firm data isolated
Your clients are yours. No attorney can access another firm's records — enforced at the application and database layer.
Never sold or licensed
Your data is not sold, licensed, or provided to third parties for advertising, AI training, or unrelated use. Subprocessors operate only to deliver the product.
AI outputs require attorney review
Nothing DocketBuddy generates is filed or sent automatically. Every AI output is reviewed and approved by you before it leaves your firm.
Not used to train AI
Client intake answers and case data sent to the Claude API are not used to train Anthropic's models. This is the default for all API customers.
Technical details
Encrypted in transit
All connections between your browser, our servers, and the database are encrypted with TLS.
Encrypted at rest
Client data in the database is encrypted at the storage layer. Sensitive credentials stored in the database get an additional application-level encryption pass.
SMTP_ENCRYPTION_KEY) that is not stored in the database. The ciphertext is iv:ciphertext in hex. Raw SMTP passwords are never stored.Never used to train any AI model
Client intake data and case information sent to Claude is not used to train Anthropic's models. This is the default for API customers, not an opt-in.
voyage-law-2 to generate embeddings for similarity search — structured client data is never included. DocketBuddy has opted out of Voyage AI model training; per Voyage's privacy policy, opted-out customer content is deleted immediately after processing and not retained beyond generating embeddings. (Source: voyageai.com/privacy)Client data never sold, licensed, or used outside providing DocketBuddy
Each attorney's clients are isolated. Your data is never sold, licensed, or provided to third parties for advertising, AI training, or unrelated use. Vetted subprocessors operate only within the scope of delivering the product.
clientSbGet, clientSbPatch, clientSbDelete — that inject attorney_id = [your ID] into every client-data query and throw at call time if the attorney ID is absent. A pre-commit guard blocks any raw client-data query from shipping without the wrapper or an explicit system-context annotation. A cross-tenant regression suite verifies the boundary: Attorney A's JWT cannot read, write, or mutate Attorney B's clients, invoices, documents, notes, or messages.attorney_id = auth.uid(). The backend uses a service-role credential, which bypasses RLS — so RLS does not act as a filter on the application's own queries. The application-layer predicate above is the primary isolation control. RLS does protect against direct database access: any connection using a standard user JWT — from the Supabase console, a database client, or any direct query tool — is restricted to that user's own rows regardless of what query is issued.The following third parties process data on DocketBuddy's behalf as vetted subprocessors. Client data is never sold, licensed, or used for advertising or unrelated purposes. All subprocessors have contractual data processing terms and operate only within the scope of delivering the product.
| Processor | Purpose | Data received |
|---|---|---|
| Supabase | Database, auth, and file storage | All client and attorney data; documents stored in private buckets |
| Railway | Backend application hosting | All data in transit — processes every API request passing through the backend |
| Anthropic | AI inference (Claude API) | Client intake answers and case data sent as prompts; document text for extraction and analysis |
| Voyage AI | Vector embeddings for knowledge base search | Text from attorney-uploaded firm documents and attorney query strings — not client data |
| Resend | Transactional and marketing email delivery | Recipient email addresses, attorney and client names, email body content |
| Stripe | Attorney billing and subscription management | Attorney payment method and billing details — no client financial data |
| Sentry | Error monitoring and diagnostics | Error stack traces and request context; may incidentally include data present in failed requests |
| Twilio | SMS notifications | Attorney and client phone numbers; SMS message content (case reminders, alerts) |
| DocuSign | Electronic signatures on client documents | Document content sent for signing; signer name and email address |
Responsible Disclosure
If you discover a security vulnerability, please report it privately before public disclosure. We will acknowledge receipt within one business day and work to resolve confirmed issues promptly.
Email: security@docketbuddy.org
A machine-readable security.txt is available per RFC 9116.
SOC 2 note: DocketBuddy is not SOC 2 certified today. The infrastructure providers used — Supabase (AWS-backed) and Railway — have their own established security programs, and Anthropic operates at enterprise scale with published security practices. We describe our infrastructure as "security-reviewed" rather than certified. If SOC 2 or equivalent certification is a requirement for your firm, please contact us to discuss.
Questions about security practices or data handling? security@docketbuddy.org
Last reviewed June 2026. This page describes the technical architecture at time of review.