Security
Candidate data deserves serious protection
Resumes, interview feedback and hiring decisions are some of the most sensitive data a company holds. Here’s how we protect them. We’ve kept it plain and specific, and we say what isn’t done yet.
Every company walled off, in the database itself
Each company’s data is separated by row-level security in PostgreSQL, not just by application code. Our services connect with database roles that can’t bypass it. If a request has no company set, it sees nothing. Automated tests try to read across companies on every change.
Encrypted in transit and at rest
All traffic uses TLS, and the database accepts encrypted connections only. Our database and file storage providers encrypt data at rest. To be precise about what protects it: the database endpoint is reached over the internet rather than a private network, so TLS and per-service credentials do that work — which is part of why the row-level security above, and the roles below, carry the weight they do.
Least privilege, everywhere
Each service connects as its own database role, created with no superuser rights and no ability to bypass row-level security — our setup script refuses to finish if any role has either. Database schema changes run as a separate migrator role the running services never hold. Secrets live in Fly’s encrypted secret store, never in code.
An audit trail you can trust
Every hiring decision records who made it and what AI information they could see. Audit and decision logs are append-only: the application can’t edit or delete them.
Careful with files and logs
Uploaded resumes are checked by their contents, not their names, and are only ever downloaded, never opened in the browser. Names, emails and phone numbers are masked in our logs, and resume text and AI prompts are never logged.
Access on a need-to-know basis
Roles control what each person sees. Interviewers only see the candidates they’re interviewing. Anyone who can’t see a job or candidate gets “not found”, so IDs can’t be probed.
Backups and recovery
The database is backed up automatically, with point-in-time recovery. Deploys run database changes first, and new versions only take traffic once their health checks pass.
Where we are
We’re a new company. We won’t show certification badges we haven’t earned. What’s in place today:
- In place Tenant isolation, encryption, least-privilege access, audit logs, backups, a DPA and a subprocessor list
Report a vulnerability
If you find a security issue, email security@talunly.com with the details. We’ll acknowledge it within 2 working days and keep you updated. Please give us reasonable time to fix it before sharing it publicly, and don’t access or change other people’s data while testing. We won’t take legal action against good-faith research that follows these rules.
Security questionnaires and DPA requests: security@talunly.com