Security at InforceDesk

We build InforceDesk to handle the part of an insurance practice that doesn't tolerate downtime or data loss — pipelines, renewals, commission tracking, client records. This page is an honest account of what we do today to keep that data safe, and what we deliberately don't yet claim.

1. PHI and HIPAA

The product surfaces this notice on every document upload form and removes the "Medical Records" category from the document tagger. Carriers, policy details, premiums, beneficiaries, signed applications, and IDs are fine. Lab work and diagnoses aren't.

2. Infrastructure

InforceDesk runs as a single Node.js process backed by a managed PostgreSQL database. Production workloads run on Railway, behind their managed reverse proxy. All public traffic is served over TLS; HTTP requests are redirected to HTTPS at the edge. The application uses HTTP-Strict-Transport-Security and a Content Security Policy that locks down script + style sources to a tight allowlist.

3. Encryption

In transit

TLS 1.2 or higher on every public endpoint. Internal traffic between the application and the database stays inside Railway's private network and is also TLS-encrypted.

At rest — application layer

Sensitive credentials are encrypted at the application layer with AES-256-GCM before they hit the database. The packed format is nonce(12) || ciphertext || tag(16) with additional authenticated data (AAD) bound to the row's identity, so a hostile actor with database write access can't shuffle ciphertexts between rows. We encrypt:

• Per-workspace integration credentials (Resend API keys, Twilio auth tokens, Google service account keys).
• Per-user Google Calendar OAuth refresh tokens.
• Per-user two-factor authentication secrets.

At rest — host layer

Everything else — leads, clients, appointments, notes, documents, message bodies — relies on Railway's volume-level encryption for disk-at-rest protection. Database backups inherit the same encryption. Honest framing: this is meaningful protection against a database-only compromise; it isn't a substitute for end-to-end encryption, which we don't currently offer.

4. Authentication

• Passwords are hashed with scrypt (PHC format). We do not store plaintext passwords or recoverable encryptions of them.
• Two-factor authentication (TOTP) is available for every account. Owners and admins are strongly encouraged to enable it. Enabling generates ten single-use recovery codes shown once; we store only their SHA-256 hashes.
• Session timeout. Sessions expire after 7 days of inactivity, sliding window. Signing out invalidates the session immediately.
• Brute-force protection. The login form is rate-limited per IP and per account. Ten consecutive failed password attempts on the same account triggers a one-hour lockout.
• New-device alerts. Signing in from an IP and device combination we haven't seen for the account in 90 days triggers an email notification with a "this wasn't me" path.
• Email-change protection. Changing your account email triggers two emails — a confirm link to the new address and a "this wasn't me" link to the old. The dispute link cancels the change and locks the account for seven days so you can reset your password.
• CSRF. Every state-changing request inside the app carries a signed double-submit token bound to the session.

5. Access controls

Workspaces have three roles — owner, admin, member — with the higher roles inheriting everything the lower roles can do. Billing actions, ownership transfer, and workspace deletion are owner-only. Member management and integration credentials are owner-or-admin. API key issuance is owner-only. Members manage their own profile, two-factor settings, and the records their workspace gives them access to.

Internal InforceDesk operators have a separate developer-flag console for support and debugging. Access to that console is reviewed quarterly. We never log into a customer workspace as the customer.

6. Tenant isolation

Every customer-scoped table carries a workspace_id column with a foreign key cascade and a database-level NOT NULL constraint. Application code accesses these tables only through middleware that pins requests to the active workspace, and every list and detail query filters explicitly on workspace_id. We run a tenancy audit script over the routes and services on every meaningful change; the script greps for SQL touching workspace-scoped tables that don't visibly carry a workspace filter, and the build does not progress past a non-zero count.

A separate cross-workspace isolation test suite exercises every list, detail, and mutation route from one workspace's session against another workspace's data and confirms the second workspace is never visible or modifiable.

7. Audit logging

Every meaningful workspace event — member invitations and removals, role changes, integration credential changes, ownership transfers, soft-deletes and restores, billing transitions, two-factor enables and disables, lead and client assignments, audit log exports — is recorded in an append-only audit log. Owners and admins can view the log in workspace settings and export the filtered current view as CSV. The default retention is seven years.

Authentication events that fire before a session resolves a workspace — failed logins, MFA challenge failures, account locks, password resets — are recorded in a separate, platform-level log we use for forensics. Successful sign-in entries are kept for ninety days; everything else is kept for a year.

8. Backups

Database backups run continuously through Railway's managed Postgres. Backup retention follows the deployment plan; backups inherit the same volume-level encryption as the live database.

9. Incident response

We maintain an internal runbook with severity classes, response steps, and escalation contacts. For confirmed incidents that affect customer data, we will notify affected workspace owners within 72 hours of confirmation, including the scope of the issue, what we know and don't yet know, and the remediation underway. We follow up with a postmortem within 30 days.

10. Subprocessors

We rely on a small number of subprocessors to operate the platform. Each handles a specific slice of the data and nothing more.

A workspace owner can disable any optional integration at any time from the Integrations settings page; doing so revokes the credentials we hold and stops further outbound traffic to that subprocessor for that workspace.

11. Reporting a security issue

If you've found a vulnerability, configuration weakness, or behavior that looks like a bug with security implications, please email us. Include enough detail to reproduce. We don't yet have a formal bug bounty program, but we'll respond to good-faith reports promptly and credit researchers who'd like to be named.

For a full description of how we handle data and your rights, see the Privacy Policy.