← Legal center

DocVex — Legal

Security Policy

Confidentiality is foundational for legal work. This page describes the layered safeguards DocVex applies — starting with the strongest one: your documents never leave your device by default.

Last updated: 18 July 2026

1. Our approach

Reduce what exists to protect.

Most security programs protect data after it has been centralised. DocVex starts one step earlier: the most sensitive data — your documents — is never centralised at all. What remains on our infrastructure (accounts, project metadata, chat) is protected with defence in depth: encryption, database-enforced access control, and minimal operational access.

2. Local-first architecture

The strongest control is absence.

  • Project files live in a folder on your device that you choose. There is no DocVex cloud file store — nothing to breach server-side.
  • File-organization metadata (a sidecar file with filenames and content hashes) stays inside that folder, on your device.
  • Content reaches an external processor only when you explicitly invoke a feature on it (for example an AI summary), and only the content needed for that request is transmitted.
  • Deleted files move to a local recycle folder on your device, not to a server.

3. Encryption

In transit and at rest.

  • In transit — all traffic between the applications and our backend uses TLS (HTTPS/WSS).
  • At rest — data stored on our backend (hosted in the EU on Supabase/AWS) is encrypted at rest by the platform.
  • Application-layer encryption — OAuth tokens for connected Gmail/Outlook mailboxes are additionally encrypted with AES-256-GCM before storage, with the key held only in the serverless environment, never in the database or client.
  • Passwords — never stored in plaintext; handled as salted hashes by our authentication provider.

4. Access control

Enforced at the database, not just the interface.

  • Row-level security (RLS) — every query runs under policies enforced by the database itself; a member can only read or write rows for projects they belong to. This holds even if a client is buggy or hostile.
  • Roles & capabilities — owner/admin/member/viewer tiers, plus custom roles with fine-grained capability overrides (inviting members, deleting files, changing roles), evaluated server-side.
  • Personal data isolation — notifications, preferences, and mailbox connections are scoped to the individual user by the same database policies.
  • Administrative functions — privileged operations are gated to an explicit allowlist, checked server-side.

5. Authentication

Modern flows, revocable everywhere.

  • Email/password and Google sign-in, using the PKCE OAuth flow — the standard that protects authorization codes on native apps.
  • Sessions use short-lived access tokens with rotating refresh tokens.
  • Erase data in account settings revokes refresh tokens globally — signing you out on every device, not just the current one.
  • Desktop deep-link callbacks are restricted to the app's registered protocol; external links opened by the app are restricted to http(s).

6. Release & update integrity

The app you run is the app we shipped.

  • Installers and updates are served exclusively from our official GitHub Releases and the Electron update service — no third-party download portals.
  • Windows updates install through the platform updater with verification against the official feed; macOS builds are signature-verified during packaging.
  • The renderer runs with Electron's context isolation: pages have no direct access to the system; every native capability crosses a narrow, explicitly defined bridge.

7. Operational security

How we run the backend.

  • Backend secrets (AI provider keys, email keys, token-encryption keys) live in the managed secrets store of our serverless platform — never in source code or clients.
  • Production access is limited to the small DocVex team on a need-to-use basis.
  • Third-party providers are limited to those listed in the sub-processor list, each bound by data-processing terms.
  • AI providers are used via their business APIs, which do not train on submitted content.

8. Reporting a vulnerability

Responsible disclosure.

If you believe you have found a security vulnerability in DocVex, please email docvexteam@docvex.ro with "Security" in the subject. Include steps to reproduce and, if possible, an assessment of impact.

  • We will acknowledge your report within 72 hours and keep you informed as we investigate.
  • Please give us a reasonable opportunity to remediate before public disclosure.
  • Good-faith research that respects user data and service availability will never result in legal action from us. Do not access data that isn't yours, and do not run denial-of-service tests.

9. Incident response

If something goes wrong.

Security incidents are triaged immediately: contain, assess scope and affected data, remediate, and notify. Where personal data is involved, we follow the GDPR breach-notification timelines described in GDPR Compliance — supervisory authority within 72 hours where required, affected users and controller customers without undue delay. Every incident ends with a written post-mortem and preventive follow-up.

10. Your responsibilities

Security is shared.

  • Use a strong, unique password, and protect the devices where your project folders live — local-first means device security is data security.
  • Keep the app updated; updates carry security fixes.
  • Manage project membership deliberately: remove people who leave, and use roles/capabilities to limit what each member can do.
  • Back up your local project folders — DocVex holds no server copy to restore from.

This page describes controls current as of the date above; as an early-stage product, formal certifications (e.g. ISO 27001, SOC 2) have not yet been pursued. This document has not been reviewed by counsel and does not constitute legal advice.