IDOS

Security, privacy, and data

IDOS protects firm data through application-level access controls, encrypted connections, and limited subprocessor relationships. This page describes the security measures currently in place and — just as importantly — the certifications, features, and contractual guarantees that are not yet available.

Access control and isolation

Firm-level isolation

Every database query is scoped to the authenticated firm’s firm.id. This is application-layer isolation: each request passes the firm identifier explicitly, and the application enforces the boundary in every read and write. There is no PostgreSQL row-level security (RLS) policy. The database schema does not rely on RLS to separate tenants.

Role-based access

Within a firm, team members are assigned one of three roles:

  • Owner— full access to all firm data, billing, and team management.
  • Admin— same data and configuration access except subscription and deletion actions.
  • Team / Viewer— access to assigned projects and read-only views; never gains money-writing or configuration privileges.

Authentication

Passwords are hashed with bcrypt. Password-reset tokens expire after a set period. API and page requests are throttled with HMAC-backed abuse limits that rate-limit tokens without exposing the underlying signing key. There is no built-in two-factor authentication.

Data in transit and at rest

All traffic between clients and IDOS is encrypted with TLS. Cloudflare terminates TLS at its edge and proxies requests to the application origin. The application and PostgreSQL database are hosted on Railway. For file storage, IDOS uses private, firm-prefixed object storage in Cloudflare R2. Each file access checks firm ownership and generates a 60-second signed URL; direct public access to the storage bucket is not possible.

Subprocessors

IDOS engages the following subprocessors to deliver the service:

  • Resend — transactional email delivery (notifications, invites, invoices).
  • Stripe — subscription billing and, when enabled, client invoice payments.
  • Cloudflare R2 — object storage for uploaded files.

Deletion and backups

Firm owners can request data deletion from the dashboard. The process removes firm records from the active database and object storage. Database backups are retained per Railway’s standard backup schedule; deleted data is removed from active backups on the next rotation cycle. Regular database backups are taken automatically.

See the data deletion page for the full process and timeline.

Token-link tradeoff

Client access uses signed tokens embedded in URLs rather than login/password accounts. This means clients never need to register or remember credentials — they open the link and see their project. The tradeoff is that anyone who possesses the link can access that surface. Tokens can be revoked from the dashboard, which invalidates all existing links for that surface and forces re-sending.

Last reviewed 2026-07-31.