Data Security | Investatech

Encryption at rest

Two layers protect your data when it sits in storage:

Infrastructure-level (AES-256). Our database (Supabase Postgres) and our object storage encrypt every byte at rest at the disk-volume layer. This is automatic for every Supabase project and protects against someone walking out of a data center with a hard drive.
Application-level envelope encryption (Service Agreements). On top of that, sensitive Service Agreement fields (client name, email, phone, address, the full draft document, every signing party's identity, signed PDFs, AI-uploaded source documents) are encrypted with AES-256-GCM under a per-tenant data key (DEK). Each DEK is wrapped under a master key (KEK) that lives in our application platform's environment, NOT in the database. Decrypting any client name requires both database access AND access to that master key — separate credentials, separate access trails.

What this means in practice

If a SaaS administrator (us) were to browse the database directly, they would see ciphertext for the encrypted columns — strings like "hX9n..." rather than "Jane Doe". A database export, a backup tape, or a compromised database connection alone is not enough to read tenant client data. The master key is held outside the database and rotating it is a single operator-level action.

Encryption in transit

Every connection between your browser, our application, our database, payment processor (Stripe), email provider (Siteground SMTP), calendar provider (Google), and AI providers (Google Gemini and Anthropic Claude) is encrypted with TLS 1.2 or higher. We do not accept plain-HTTP traffic on any production endpoint.

Access controls

Tenant isolation. Every database query in our application is scoped by company_id and verified against the requesting user's membership before returning rows. Cross-tenant requests return 404 (we don't even confirm whether a target row exists).
Role-based access. Within a tenant, the Owner controls billing, team management, and per-member module access. Other members hold one of two seat types: Assistant or RCIC. Default access varies by seat type. For example, Assistants can prepare Service Agreements but cannot sign them; only verified RCICs (eligibility granted by the Owner, licence self-attested by the member) can be named on agreements and sign them. The Owner can override any module's default access on any member's row. Sensitive operations like account deletion, signed-PDF download, and multi-party finalize remain Owner-gated.
Login security. Every login on a new device requires a one-time email code (OTP). Trusted devices are remembered for 30 days. Authentication is rate-limited per IP and per email.
Append-only audit ledger. Service Agreement signature events (who signed, when, from what IP, and the typed name) are written to a database table that is technically protected against UPDATE — even our own service-role client can't modify a row once it's written. This protects the audit trail from tampering.

Transfer Room (file sharing module)

The Transfer Room module lets you and your client exchange files for a single matter through a private portal instead of email attachments. The same envelope-encryption posture as Service Agreements applies, plus a few specifics:

Per-file AES-256-GCM. Every file you or your client upload is encrypted under your per-tenant data key (DEK) before it lands in object storage. The same DEK that protects your Service Agreements protects your Transfer Room files — one tenant cannot decrypt another tenant's files even with full database access.
Portal access by one-time code. Clients authenticate by entering the agreement reference and their email, then a 6-digit code we email them. Sessions are HMAC-signed cookies with a 30-minute idle timeout. Failed code attempts are rate-limited (5 attempts per code, 60-second resend cooldown, 10 codes per day per email).
File retention is short by design. Transfers expire after 14 days by default (tenant-configurable 1–30 days). Once a file is downloaded, its bytes are purged 72 hours later. Once a file is copied to your Google Drive, its bytes are purged 24 hours later. The Transfer Room is intentionally not long-term storage — the durable copy lives in your matter file (or your Drive, when you copy it over).
Append-only audit log. Every event — room activation, transfer sent, viewed, downloaded, revoked, deleted — is written to a database table protected against UPDATE the same way the Service Agreement signature ledger is. You can replay exactly who did what when, with redacted IP addresses, from the Audit log tab.
Stage B plaintext window. Our upload flow is three stages: (A) we hand the browser a short-lived signed URL, (B) the browser uploads the file bytes directly to object storage, (C) our server downloads those bytes, encrypts them under your DEK, and overwrites the original. For a few seconds between Stage B and Stage C, the file bytes sit unencrypted in our private storage bucket. The bucket is not publicly readable and no API route serves those bytes; the only way to read them in that window would be direct administrative access to the storage layer. Closing this gap (client-side pre-encryption) is on our roadmap and will be invisible to you when it ships.

Data retention

Active tenants: data retained for the life of the account.
Deleted accounts: soft-deleted immediately, then permanently purged 90 days later by an automated cron job. Storage objects (signed PDFs, uploaded source documents) are removed alongside.
Signed Service Agreements: retained for the duration of your account so you can download them as legal records. CICC professional retention obligations are your responsibility as the licensee — we surface this reminder when you initiate account deletion.
Email logs: SMTP delivery records (success / failure timestamps, recipient address) retained 90 days. Email body content is not stored on our servers after delivery.

Where we draw the line

We're transparent about what our V1 encryption posture does NOT yet protect against:

End-to-end encryption. Our application server holds the master encryption key in memory while serving requests. A determined and authorized administrator with both database access and our application's environment access can decrypt your data — they would just leave a clear access trail. Customer-managed keys (BYOK) for tenants who want stronger guarantees are on the roadmap.
Other modules (Bookings, Written Consultations, Events, Invoicing). Application-level encryption currently covers the Service Agreements module. Expanding the same envelope-encryption scheme to client names + addresses on the other modules is the next phase of this work.
AI content review. When you subscribe to Premium, your documents and prompts pass through Google Gemini or Anthropic Claude (depending on the feature) under our zero-data-retention contracts (neither provider stores or trains on your content), but they do leave our infrastructure for the duration of the request. Use the AI features on documents you are comfortable sharing with those contracts.
Client-side device security. If your device, browser, or password is compromised, an attacker can sign in as you. Use a password manager, enable OTP for every login, and treat your device-trust cookies the way you treat your house keys.

Reporting a security issue

Found a vulnerability or have a security question? Email us directly at info@investatech.com with "Security Report" in the subject line. We treat security reports as priority and aim to acknowledge within one business day. Please do not test against another tenant's data.