OraTek DX SECURITY

Security overview

Last updated: May 14, 2026

This document summarizes how OraTek Diagnostics, Inc. ("OraTek") secures the OraTek CRM service. It's written for security teams reviewing OraTek as a vendor. For a formal questionnaire or a redacted pen-test report, contact security@oratekdx.com.

In transit
TLS 1.2+
All traffic, no plain HTTP accepted
At rest
AES-256
Managed Postgres + Valkey encrypted volumes
Tenant isolation
PostgreSQL RLS
Row-Level Security on every customer-data table
Sessions
httpOnly cookies
JWT + SameSite=Lax, 30-day default TTL
Passwords
bcrypt cost 12
Min 10 chars at signup
Audit log
Append-only
Auth, record changes, billing, deletions

Architecture

OraTek runs as a small, opinionated stack:

Data handling

Tenant isolation

Every customer-data table has an organization_id column and a PostgreSQL Row-Level Security policy that filters reads + writes to the caller's org. The current org id is set per-request via set_config('app.org_id', ...) after JWT validation, and the policy is USING (organization_id = current_org_id()). There is no application code path that can read across orgs.

Encryption

All traffic to and from OraTek terminates at TLS 1.2 or higher (HSTS-enforced on all production domains). Customer data at rest is encrypted by the underlying managed services (DigitalOcean Postgres + Valkey volume encryption, AES-256). Backups are encrypted at the same level.

Secrets

API keys, OAuth tokens, and LinkedIn session cookies are encrypted with AES-256-GCM (per-row IV, KMS-stored master key) before being written to the database. The application decrypts them in-memory only when needed for an outbound request.

Backups

Automated daily snapshots with 7-day retention (configurable to 30) plus continuous point-in-time recovery (PITR) covering the last 24 hours. Restore drills are run on a documented cadence; results are available under NDA.

Data residency

All customer data is stored in the United States (DigitalOcean NYC3 region). EU-specific residency is available on the Enterprise tier on request.

Identity & access

Authentication

Email + password (bcrypt cost 12) or Google OAuth. Email verification required on signup. Passwords minimum 10 characters; no maximum, no composition rules; rate-limited on login + reset endpoints.

Authorization

Role-based access control with five roles (rep / marketer / manager / director / admin) and an explicit team + division + manager hierarchy. visibleUserIds() in the auth middleware enforces "you can only read data attributed to users below you in the hierarchy" — managers see their team, directors their division, admins their org.

Internal access

Production database access is restricted to two engineers behind hardware-key SSH. There is no shared admin account. All production access is audit-logged at the OS layer.

Audit logging

The audit_log table records every authentication event, every change to a contact / deal / candidate / user / team, every billing event, and every deletion. Each entry captures user id, action namespace ("auth.login", "contact.update", "org.delete_requested"), target type + id, IP address, user agent, and an action-specific JSON payload. Admins can read their own org's log via GET /audit. We retain audit entries for the life of the org plus 30 days after deletion.

Vulnerability management

Incident response

Documented one-page playbook covering: detection (Sentry / monitoring alerts), triage owner, customer notification template, status-page incident format, and post-mortem. Notification commitment: affected customers contacted within 24 hours of incident confirmation, regardless of regulatory deadline.

Compliance posture

Customer responsibilities

Contact

Security disclosures: security@oratekdx.com
Privacy / DSAR requests: privacy@oratekdx.com
Postal: OraTek Diagnostics, Inc. — address available on request to verified parties.