Trust & Security
Turrilum is a multi-tenant applicant tracking system that processes sensitive HR and candidate data on behalf of its customers. This page documents the security controls, privacy rights mechanisms, and compliance posture that are actually implemented in the platform today — and where additional work is in progress.
Last updated: July 2025
Overview
Security at Turrilum is built into the application layer rather than bolted on afterward. The controls described below are implemented in the codebase and active in production. Where a control is in progress or planned, it is clearly labelled as such.
Encryption
TLS in transit. AES-256-GCM for stored secrets. Argon2 password hashing via Better Auth.
Access Controls
Role-gated API, per-company data isolation, scoped API keys with per-minute rate limiting.
Privacy Rights
DSAR export, right-to-erasure (with cascade), configurable data retention, EEO data firewall.
Encryption & Secrets
All data in transit between clients and Turrilum is protected by TLS 1.2+ enforced at the hosting layer (Vercel Edge Network). Data at rest in the Neon Postgres database is encrypted by the provider at the storage level.
Application-level secrets stored in the database receive an additional layer of encryption before write:
Webhook signing secrets
Stored AES-256-GCM encrypted (WEBHOOK_SECRET key). Outbound webhook payloads are signed with HMAC-SHA256 so receivers can verify authenticity.
SSO client secrets (OIDC)
OIDC provider client_secret values are stored AES-256-GCM encrypted (SSO_SECRET key) — never in plaintext.
E-sign provider tokens
OAuth access and refresh tokens for e-sign providers are stored encrypted in esign_connection.
SMS auth tokens
Twilio auth tokens are stored encrypted (authTokenEnc) in sms_connection.
Calendar / mail OAuth tokens
Google and Microsoft OAuth refresh and access tokens are stored encrypted in their respective connection tables.
Password hashing
User passwords are never stored in plaintext. Better Auth uses Argon2id via its built-in password hashing pipeline.
API key tokens
Raw API key tokens are shown once at creation. Only a SHA-256 hash prefix is stored. Verification re-hashes the incoming token.
SCIM bearer tokens
SCIM provisioning tokens follow the same hash-only storage pattern as API keys.
Access Controls & Multi-tenancy
Turrilum is a multi-tenant platform. Every database query that touches customer data is scoped to the authenticated company ID — there is no shared query layer that could leak cross-tenant data.
Role-based access control (RBAC)
Membership roles (owner, admin, elevated, limited, interviewer) gate every server action and API route. Role checks are enforced server-side.
Per-company data isolation
All queries include a companyId filter derived from the authenticated session. Cross-company reads are architecturally impossible at the query layer.
Scoped API keys
Partner API keys carry explicit scopes (read, write, candidates, jobs, offers). The API validates scope on every request before any data is returned.
API rate limiting
API key requests are rate-limited per minute (configurable; default enforced at the route layer). Excess requests receive HTTP 429 with a Retry-After header.
RFC 9457 error responses
The Partner API returns structured problem+json errors so clients can distinguish auth failures, validation errors, and rate-limit events without parsing message strings.
SAML / OIDC SSO with JIT provisioning
Enterprise customers can enforce identity-provider login via SAML 2.0 or OIDC. Just-in-time provisioning integrates with SCIM records to avoid duplicate users.
SCIM 2.0 automated provisioning
HR systems can push user lifecycle events (create, update, deactivate) via SCIM 2.0. Deactivated users lose access immediately.
Session management
Sessions are issued by Better Auth with configurable expiry. Session tokens are stored in HttpOnly cookies and validated server-side on every request.
Privacy & Data Subject Rights
Turrilum is designed to help customers meet obligations under GDPR, CCPA, and similar privacy regulations. The following rights mechanisms are implemented and available to customers.
DSAR data export
Customers can trigger a full data-subject access request export for any candidate. The export is generated as structured JSON covering all candidate records, activity, applications, and communications.
Right to erasure (cascade delete)
Candidate deletion cascades through all associated records: applications, activity, files, communications, assessments, and voluntary disclosures. A confirmation step is required.
Configurable data retention
Admins can configure a retention period (in days). The retention engine automatically flags and purges inactive candidate records after the configured window.
EEO / OFCCP data firewall
Voluntary equal-employment data (gender, race/ethnicity, veteran status, disability status) is stored in a separate table. It is inaccessible to recruiters and hiring managers — only aggregate reporting surfaces it, with no individual identifiers.
Texting consent tracking
Candidate SMS consent status (none / opted-in / opted-out) is recorded and checked before any outbound text message is dispatched.
Email suppression list
Bounced or unsubscribed addresses are recorded in an email_suppression table. The email sending pipeline checks this list before dispatching.
Consent-based retention (inactivityRetentionDate / consentRetentionDate)
Two independent retention clocks are tracked per candidate: one for inactivity and one for consent expiry. Whichever expires first triggers the retention workflow.
Integration Security
All outbound integrations follow the same security baseline: secrets are stored encrypted, tokens are refreshed server-side, and no credentials are exposed to the browser.
Outbound webhook HMAC signing
Every outbound webhook delivery includes an X-Turrilum-Signature-256 header containing an HMAC-SHA256 signature computed from the raw payload and the customer's encrypted signing secret.
E-sign (DocuSign / HelloSign / Dropbox Sign)
OAuth tokens are stored AES-256-GCM encrypted. Envelope creation and signing URL generation happen server-side. Signed PDF URLs are stored after completion.
Zoom meeting links
Zoom OAuth tokens (access + refresh) are stored encrypted. Meeting creation and join links are generated server-side and delivered via the calendar invite, not exposed to the browser.
Google Workspace (Calendar + Mail)
OAuth refresh tokens are stored encrypted. Scopes are limited to what the sync requires. Token refresh happens server-side on expiry.
Microsoft 365 (Calendar + Mail)
OAuth refresh tokens for Microsoft Graph are stored encrypted per-company. Mail and calendar sync are scoped to the connected organizer account only.
SMS / Twilio
Twilio auth tokens are stored encrypted. Outbound SMS is gated on candidate consent status. Inbound message routing uses per-company conversation tracking.
Sub-processor List
Turrilum uses the following sub-processors to deliver the service. Customer data may be transmitted to or processed by these parties in the course of normal platform operation. Turrilum will provide advance notice of material changes to this list.
| Sub-processor | Purpose | Data categories | Region |
|---|---|---|---|
| Vercel | Application hosting, edge network, serverless compute | All platform data (in transit); IP addresses, request logs | US / Global CDN |
| Neon (Neon Inc.) | Primary PostgreSQL database | All customer and candidate data at rest | US East (AWS us-east-1) |
| Resend / SendGrid | Transactional and notification email delivery | Recipient email addresses, subject lines, message bodies | US |
| Twilio | SMS messaging | Candidate phone numbers, message bodies, consent records | US |
| Zoom Video Communications | Video interview link generation (optional integration) | Meeting metadata, recruiter and candidate names | US |
| Google LLC | Google Workspace calendar and mail sync (optional integration) | Calendar event metadata, email headers, organizer identity | US |
| Microsoft Corporation | Microsoft 365 calendar and mail sync (optional integration) | Calendar event metadata, email headers, organizer identity | US |
| Dropbox Sign / HelloSign / DocuSign | Electronic signature for offer documents (optional integration) | Candidate and signer names, email addresses, signed document content | US |
| Indeed | Job board posting distribution (optional integration) | Job title, description, location, compensation, company name | US |
| Vercel Analytics | Aggregate page-view analytics (production only) | Anonymised page URLs, country-level geography, Web Vitals | US / Global |
Change notification:Turrilum will provide at least 14 days' advance notice of any addition to this list via the in-app notification system and by email to the account's billing contact. Customers who have executed a DPA may object to new sub-processors within the notice window.
Data Processing Agreement — Template
Template — not a signed or binding agreement
The text below is a template provided for customer review and negotiation. It has not been reviewed by legal counsel and does not constitute legal advice. Customers requiring a signed DPA should contact privacy@turrilum.com to initiate the process.
DATA PROCESSING AGREEMENT — TEMPLATE
Version 1.0 — July 2025 — Pending legal review
1. Roles
Controller:The customer entity that has entered into a Turrilum subscription agreement (the "Customer").
Processor: Turrilum Inc., the operator of the Turrilum applicant tracking platform.
Turrilum processes Personal Data solely on behalf of and under the instructions of the Customer, except where required to do otherwise by applicable law.
2. Processing Scope & Purpose
Turrilum processes Personal Data for the sole purpose of providing the hiring management services described in the Customer's subscription agreement. Processing activities include: storing and retrieving candidate profiles; routing applications through hiring pipelines; scheduling interviews; generating and delivering offer documents; sending transactional notifications; and providing analytics and reporting to authorised Customer personnel.
Categories of Data Subjects: job applicants, candidates, and Customer employees (recruiters, hiring managers, interviewers, administrators).
Categories of Personal Data: contact information (name, email, phone); professional history (resume, experience, education); application history; interview scheduling data; offer terms; voluntary equal-employment data (stored in a separate access-controlled table); device identifiers and session tokens for Customer personnel.
3. Sub-processors
The Customer authorises Turrilum to engage the sub-processors listed in the Sub-processor List section of this page. Turrilum will provide advance notice of any addition to the sub-processor list and Customer may object within 14 days. If Customer objects and the parties cannot resolve the objection, Customer may terminate the subscription.
4. Security Measures
Turrilum implements and maintains the technical and organisational security measures described in the Trust & Security page at turrilum.com/trust, including: encryption of data in transit (TLS); AES-256-GCM encryption of stored secrets; Argon2id password hashing; role-based access control; scoped API keys with rate limiting; HMAC webhook signing; SAML/OIDC SSO support; and SCIM 2.0 automated provisioning.
Turrilum will review and update these measures no less than annually and will notify Customer of material changes.
5. Data Subject Rights
Turrilum will, upon Customer's request, assist with responding to data subject requests including: access (DSAR export as structured JSON), rectification, erasure (cascade delete), restriction of processing, and data portability. Customer is responsible for receiving, triaging, and responding to data subject requests from candidates. Turrilum provides the technical mechanisms; Customer operates them.
6. Breach Notification
In the event of a personal data breach affecting Customer data, Turrilum will notify the Customer without undue delay and in any event within 72 hours of becoming aware of the breach, to the extent that notification is possible. The notification will include: nature of the breach; categories and approximate number of data subjects affected; likely consequences; and measures taken or proposed to address the breach.
7. Deletion & Return of Data
Upon termination or expiry of the Customer's subscription, Turrilum will, at Customer's election: (a) return all Personal Data in a machine-readable format, or (b) securely delete all Personal Data from its systems within 30 days, except where retention is required by applicable law. Turrilum will confirm deletion in writing upon request.
8. Audit Rights
Customer may, upon reasonable notice (not less than 30 days) and at its own expense, audit Turrilum's compliance with this agreement no more than once per calendar year. Turrilum may satisfy this obligation by providing an up-to-date SOC 2 Type II report from an independent auditor (once available) in lieu of a Customer-conducted audit.
SOC 2 Type II Readiness
Readiness — not attainment
Turrilum has NOT completed a SOC 2 Type II audit and does not hold a SOC 2 certification. The controls below are mapped to the AICPA Trust Services Criteria as part of our readiness programme. SOC 2 Type II requires an independent Certified Public Accountant firm to observe controls over a defined period (typically 6–12 months). That engagement is in progress.
The table below maps implemented platform controls to the five Trust Services Criteria. Status reflects the current state of the control in the codebase — not an auditor's opinion.
CC6 — Logical and Physical Access Controls
Role-based access control
Server-side role enforcement on all routes and actions.
Multi-tenant data isolation
All queries scoped to authenticated companyId.
Scoped API keys with rate limiting
Partner API keys carry explicit scopes; excess requests are rejected 429.
Enterprise SSO (SAML + OIDC)
IdP-enforced authentication for enterprise customers.
SCIM 2.0 lifecycle management
Automated provisioning and deprovisioning via HR systems.
Penetration test
Third-party penetration test by a qualified firm.
CC9 — Risk Mitigation
Encrypted secrets at rest
AES-256-GCM for webhook secrets, SSO secrets, OAuth tokens.
Outbound webhook HMAC signing
All webhook deliveries are signed; receivers can verify authenticity.
TLS in transit
Enforced at the Vercel edge layer for all connections.
Vendor risk assessments
Formal review of sub-processor security posture.
P1–P8 — Privacy (AICPA)
DSAR export & right to erasure
Structured JSON export and cascade delete for all candidate records.
Configurable data retention
Admins set retention period; engine purges expired records.
EEO data firewall
Voluntary equal-employment data segregated and access-gated.
Consent tracking (SMS, recording)
Candidate consent status stored and checked before outbound contact.
Privacy policy (external legal review)
Formal privacy policy drafted and reviewed by legal counsel.
A1 — Availability
Hosted on Vercel serverless infrastructure
Auto-scaling compute; no single server to fail.
Neon Postgres high availability
Neon provides continuous backup and point-in-time recovery.
Uptime monitoring
Automated external uptime monitoring with alerting.
Incident response runbook
Documented runbook for production incidents including breach scenarios.
PI1 — Processing Integrity
Idempotent schema self-heal
ensure-schema.ts runs on boot to guarantee full column coverage — no 42703 errors on cold starts.
RFC 9457 structured error responses
API errors are machine-readable problem+json; no information leakage in messages.
Automated testing coverage
Unit and integration test coverage for critical data paths.
SOC 2 Type II Roadmap
Security Contact
Security disclosures
To report a vulnerability, please email security@turrilum.com. We aim to acknowledge reports within 2 business days and will coordinate disclosure responsibly.
Privacy & DPA requests
For privacy questions, DPA execution, or data subject rights assistance, contact privacy@turrilum.com.