Security at TitusOS

TitusOS stores sensitive business data — client records, financials, patient health information, legal matters. Here is exactly how we protect it, in plain language.

1Strong authentication

Every account supports TOTP two-factor authentication (Google Authenticator, 1Password, Authy) and passkeys (WebAuthn — hardware keys, Face ID, Touch ID, Windows Hello). Workspace owners can require 2FA for their entire team with a 7-day grace period for enrollment, and can separately require passkeys for admins.

2Account lockout & anomaly detection

Five failed login attempts lock an account for 15 minutes, stopping credential-stuffing and password-spraying attacks. Every login is geolocated; impossible-travel events, new devices, and logins from new countries trigger email alerts. Rate limiting is enforced per endpoint via Redis.

3Session management

Users can see all active sessions at /settings/sessions, with device, IP, location, and last-active time. Each session can be revoked individually, or a user can sign out everywhere except this device with one click. Sessions expire after 30 days; tokens are hashed with SHA-256 in our database.

4Tamper-proof audit logs

Every meaningful action — create, update, delete, sign-in, permission change — is logged with:

• Who (user ID, role, IP, user agent)
• What (resource, action, JSON diff of changes)
• When (timestamp)
• A SHA-256 hash chain linking each log entry to the previous one, so tampering is detectable

Logs are searchable and exportable (CSV, PDF) by workspace admins.

5Granular role-based access control

Beyond owner/admin/member, TitusOS uses a resource + action + scope permission model. Example: a user can be allowed to view deals they own, edit deals in their team, but not see the tenant-wide deal list. Workspace owners can customize role-permission mappings to match their internal policies.

Owners receive an automated quarterly permission review email listing every team member's role, last login, and 2FA status — with a prompt to revoke access for anyone who no longer needs it. The same data is available on-demand at /settings/team/audit.

6Encryption in transit and at rest

• In transit: TLS 1.3 on all traffic, terminated at AWS Application Load Balancer. HTTP is redirected to HTTPS — no mixed-mode access.
• Database at rest: PostgreSQL (AWS RDS) with storage-level AES-256 encryption via AWS KMS. Automated daily backups and snapshots are encrypted with the same key.
• Field-level encryption: Sensitive fields (tax IDs, patient PHI, insurance IDs, clinical SOAP notes) are encrypted at the application layer with AES-256-GCM. Each workspace has its own Data Encryption Key (DEK), wrapped by a master Key Encryption Key (KEK) that lives in AWS Secrets Manager.
• Key rotation: DEKs are versioned and can be rotated without downtime.

7Backups, soft deletes, recovery

Deleted records use a deletedAt soft-delete pattern across 26 core models — a 30-day window during which records can be restored. RDS automated backups run daily with configurable retention; point-in-time recovery is available for the database.

8Full data export & GDPR compliance

Workspace admins can export all tenant data at any time — CSV or JSON — including clients, engagements, invoices, documents, and (optionally) the full audit log. Exports can be password-protected with AES-256-GCM; the password is derived using PBKDF2 with 200,000 iterations. TitusOS honors all six GDPR data subject rights: access, rectification, erasure, portability, restriction, and objection, with a 30-day SLA as required under GDPR, POPIA (South Africa), and NDPA (Nigeria).

9Multi-tenant isolation

Every database query is scoped by tenantId. The architecture enforces isolation at the service layer, not just the UI — it is impossible for one workspace's data to appear in another's query results. Role-based access control layers on top of this boundary.

Questions?

Email security@titus-os.com for any security questions, BAA requests, or to request a deeper technical review.