Security at Talent Intelligence Lab ATS.

What this page covers

This page describes how Talent Intelligence Lab protects data in the Talent Intelligence Lab applicant tracking system (the "Service") and on this website. Every control below is in place today. Where a control does not exist yet, this page says so rather than leaving you to assume it.

We do not hold SOC 2, ISO/IEC 27001, or any other independent security certification, and no third party has audited or penetration-tested our application. Some underlying service providers maintain independent certifications for controls within their own platforms; those do not certify the Service or our application controls. Section 14 sets out that distinction in full.

This page is about security controls. What personal data we collect, why, and what rights you have over it are covered in our Privacy Policy. Where this page and a signed agreement disagree, the agreement governs.

Where your data lives

• The Service uses managed application hosting with its compute configured for Singapore.
• Its managed identity, relational database, and private file-storage services are configured for Singapore.
• Primary account, workspace, candidate, and uploaded-file data are held at rest in Singapore.
• This marketing website is a separate deployment without a pinned processing region. It does not hold workspace or candidate data; contact enquiries are handled separately.

What may be processed outside Singapore

• The AI features described in Section 08: the optional recruiting and analytics features, and the in-product help assistant included on every plan. Requests are scoped to the task and do not give an external processor a bulk copy of your workspace.
• Transactional email delivery and website-enquiry notifications.
• Connected email and calendar services. Where a workspace uses its own connected account, email and calendar activity runs through that account. Otherwise we create the meeting link through a platform scheduling account — either because the workspace is in platform scheduling mode or because no calendar is connected for a video round. The calendar event contains the interview time, the candidate's name, and the job title, and is stored by the calendar service.
• Any other tool a customer connects to its own workspace, at that customer's direction.

The international-transfers section of our Privacy Policy covers the same ground in data-protection terms.

The region is fixed for all customers in the current release; we do not yet offer per-customer region selection. If a particular jurisdiction is a hard requirement for you, raise it before onboarding and we will tell you plainly whether we can meet it.

Tenant isolation

Every customer gets its own workspace, and every tenant record carries the workspace it belongs to. User-scoped application access is protected by database row policies and same-tenant integrity checks rather than by interface filtering alone.

• Row-level security is enabled across the tenant application schema and evaluates access against the signed-in user's active workspace and role.
• Policies resolve through a small set of security-definer predicates that check active, entitled workspace membership and the caller's role, rather than being restated by hand on each table.
• Ordinary browser and server data access uses request-scoped credentials that remain subject to those row policies.
• A user's active workspace is resolved on the server from their proven memberships. A value supplied by the browser cannot select a workspace the user does not belong to.
• Isolation is tested in CI: the database is rebuilt from its migrations and cross-tenant, role-matrix, privilege, and integrity suites run against it. Blocking failures prevent a normal release.

Where privileged service access is used

A limited set of public-ingestion, queue, platform, and maintenance workflows uses privileged service access that is not protected by row-level security. Before those paths reach tenant data, application code must establish the actor or public capability, workspace, role, resource ownership, and exact operation.

The isolation boundary therefore has two parts: database enforcement for user-scoped access and explicit application checks for privileged workflows. Service credentials are server-only and barred from client bundles. We test both layers, but we do not describe privileged paths as though the database is independently refusing every request.

Access and authentication

• Accounts are created through verified work-email signup or an administrator invitation. Email ownership is proven before a self-serve user and workspace are provisioned. Sign-in supports email and password or a supported social-login option; passwords are never stored by us in recoverable form.
• Invitations remain the way existing workspaces add people. Each setup code is stored only as a SHA-256 hash, expires 24 hours after issue, is consumed once by the database, and is protected by rate limits.
• Four roles — administrator, recruiter, hiring manager, and member — resolve to different permissions, and read scope is granted separately from write scope. Recruiter pipeline visibility is scoped to assigned requisitions rather than the whole workspace.
• Interface-level narrowing is convenience, not the boundary. Authorisation is checked on the server and, for user-scoped traffic, independently by database row policies. The privileged service paths in Section 03 rely on the explicit server-side checks described there.
• Idle sessions end automatically: after ten minutes without activity you get a sixty-second warning, then the session is signed out, active-workspace state and cached tenant/search data are cleared, and logout is propagated across open tabs with a bounded local fallback if global session cleanup cannot complete.

What we do not have

There is no multi-factor authentication, no SAML or OIDC single sign-on, no SCIM provisioning, and no customer-configurable session lifetime. Social login is not enterprise SSO, and we will not describe it as such. If your organisation mandates any of these, we are not the right fit today — better that you know now than after a migration.

Encryption

• In transit — all traffic is served over TLS. HTTP Strict Transport Security is set with a two-year max-age, subdomains included and preload requested, so a browser that has seen the site once refuses to fall back to plain HTTP.
• At rest — the managed database and file storage encrypt data at rest under our providers' platform controls. That is provider-level encryption, and we describe it as theirs rather than presenting it as an application control of ours.
• Integration secrets — credentials for connected email, calendar, and other workspace tools get a second layer: they are encrypted by the application with AES-256-GCM under a key held in our deployment environment, not in the database, before they are written. The format is versioned and authenticated, so tampered or truncated data fails rather than decrypting. Rotation procedures are documented, but a full rotation and recovery exercise remains outstanding.

Application and network hardening

• Cross-origin request forgery is blocked by a default-deny gate applied globally at the edge of the application rather than route by route, so a new endpoint is covered on the day it is written. Any cookie-authenticated state-changing API call is rejected unless it presents a trusted same-origin declaration; the Origin header is authoritative when present, a mismatch cannot be rescued by a Referer, and a request carrying neither fails closed.
• Responses carry a full browser security header set: an enforced Content Security Policy, frame-ancestors and X-Frame-Options set to deny so the app cannot be framed, cross-origin opener and resource policies, MIME-sniffing protection, a strict referrer policy, and a permissions policy switching off camera, microphone, geolocation, payment, USB, and the other device APIs the Service does not use.
• The policy's connection and image sources are pinned to our own backend host rather than left as a wildcard, so a stolen session cannot be relayed to an attacker-controlled backend and injected markup has no outbound channel. A production build fails outright if that host is not configured.
• Request payloads are validated against explicit schemas at the API boundary, and third-party AI endpoints are host-allowlisted so a tampered environment variable cannot reroute traffic.
• Abuse-prone public surfaces are rate-limited: job application intake, careers listings, the candidate portal and its magic links, sign-up, OAuth token exchange, and AI endpoints. Limits are counted in the database rather than in per-instance memory — so they survive a cold start — the identifier is hashed before it is stored, and if the counter cannot be reached the request is refused rather than allowed through.
• The application and this marketing site are separate deployments on separate origins. This website holds no customer data.

Two caveats

Our headers are public anyway, so there is no point being coy: the Content Security Policy now requires a fresh per-request nonce for inline scripts, but it still permits inline styles and admits scripts from a short allowlist of hosts rather than by nonce alone. It is enforced and it is a real defence, but we will not call it strict until that changes.

An automated anti-abuse challenge is implemented for sign-up, public job applications, and public CV parsing, including server-side verification before uploaded content is read. It is not enabled in production today, so those surfaces currently rely on the durable rate limits, origin checks, consent checks, honeypots, and request-size controls described above.

Candidate files

• CVs and other candidate attachments live in a private bucket whose storage policies mirror the row-level access rules on the record they belong to. User avatars are private and owner-scoped. There is no public URL for a candidate file.
• Files awaiting parsing sit in a separate private bucket, readable within the workspace that uploaded them until the parser promotes or discards them — a deliberately wider scope than the finished candidate record, because at that point there is no record yet to scope them to.
• Previews and downloads are streamed through an authenticated application route that resolves your active workspace, queries as you rather than as a privileged role, and checks the requested path is the canonical one for that record. Where a direct storage URL is genuinely needed, it is a signed link with a short expiry.
• Public and inline CV uploads are limited to 3 MiB; authorised queued imports support files up to 10 MB. Both paths restrict files to PDF and Word formats, cross-check metadata, content type, extension, and file signatures, and sanitise filenames. CV parsing runs on the server, never in the browser.
• A required-CV application is published only after the exact uploaded object has been proven and the candidate, application, and file metadata can be finalised together. Incomplete submissions are not accepted as completed applications, and abandoned upload paths remain queued for cleanup.
• Workspace logos and email-template images are deliberately public, because they are embedded in careers pages and outbound email. Nothing candidate-related is stored in those buckets.

We do not scan uploaded files for malware. Files are stored and handed back to your own team, never executed by us, but if scanning at the point of upload is a control you rely on, we do not provide it.

AI features and what leaves the platform

AI in the Service assists a recruiter; it does not decide. Nothing is advanced or rejected automatically, and a human reviewer remains accountable for every hiring outcome. One external AI processing service supports every feature below, apart from the Senior Help handoff described under the help assistant, and processes request data outside Singapore. Each request is scoped to its enabled task; the service never receives a bulk export of your workspace.

Recruiting assistance

Job-description drafting sends the role details and the outcomes and qualifications a recruiter has approved, plus any organisation context or compensation text they choose to include. Interview-question generation sends the job title and its published rubric criteria, or the job's stored requirements where no rubric is published. Drafting an assignment rubric with the assistant sends the job title and description, the assignment brief and settings, and the recruiter's setup conversation; calibrating that rubric sends the sample answers your team supplies, with the brief and rubric but not the expected scores. None of these requests reads a candidate record, although sample answers are sent exactly as your team enters them. The earlier resume-scoring feature has been retired, and candidate comparison now reads saved Candidate Fit reviews (below) without sending a new request to the AI service.

Two features do send candidate content, and we will not let that paragraph imply otherwise. The first is CV extraction. When our own parser cannot find a candidate's name and email in a CV — or reads it but produces only a sparse profile — the extracted text is sent to the same service to recover the work history, skills, and education the parser missed. Before it leaves, email addresses, links, phone numbers, address and personal-details lines, referee sections, and any name the parser did find are masked, and contact details are recovered locally rather than by the model. That masking is pattern-based, not field-level redaction: a name the parser could not find, or an identifier written into the prose, can still go with the text. The sparse-profile trigger also means a CV the parser handled adequately can still be sent. File bytes never are; only text.

The second, and the most significant for candidates, is automated case-study assessment, which sends the most candidate-authored content of anything we do. When a candidate submits a take-home assignment, the text extracted from their file goes to the same service along with the assignment brief and the rubric criteria set for AI assessment, so it can be scored against that rubric. It runs only against a rubric your team has calibrated and approved, and it fires on submission rather than when a recruiter asks. Whatever the candidate chose to put in that document goes with it, and the resulting score is internal to your team — the candidate is not shown it, and it does not advance or reject anyone by itself.

Candidate Fit

Candidate Fit uses versioned organisation context, immutable job criteria, and minimised candidate evidence to produce a cited recommendation for recruiter review. It replaces the retired resume score. It cannot change an application score, stage, or status; reject or shortlist a candidate; schedule an interview; send a message; or create an offer. The capability is released, but production candidate processing is not currently activated. Optional organisation research is separately disabled by default.

Analytics dashboard chat

Create with chat sends your instructions, bounded conversation history, and dashboard definition to the same AI processing service, outside Singapore. It does not send the underlying report dataset, computed results, resumes, or automatically loaded candidate records. User-entered text and filter labels are not automatically redacted. The service proposes a validated configuration, not executable SQL or calculated figures. Reports are calculated separately under the viewer's database access permissions. The feature is limited to eligible administrator and recruiter accounts and respects workspace AI controls, feature allowlisting, quotas, and rate limits.

Saved dashboards retain the latest 30 chat messages and 10 definition revisions until the dashboard is deleted. Workspace sharing includes this conversation and definition history for permitted readers, but does not broaden their access to underlying records. Unsaved recovery drafts are tab-local and scoped to the signed-in account, workspace, and dashboard.

In-product help assistant

The in-product help assistant is available on every plan, including Free; the other AI features in this section are not part of Free. The assistant receives your message, recent help-chat history, the screen path you are on, your workspace name, your plan and role, and aggregate count-only figures — how many jobs or candidates exist and how many sit at each pipeline stage. It receives no individual candidate, job, application, or other person's record. That is enforced by the shape of the data structure it is given, whose fields are numbers and your own workspace name, and by count-only database queries that transfer no rows at all.

If a signed-in user chooses Ask Senior Help, the help conversation and the screen path are passed to a separate assisted support workflow that we operate, which may use a different external AI service, outside Singapore, to prepare a reply. The handoff grants no additional record access and performs no hiring action, and no human response or response time is promised. Escalated conversations are scheduled for deletion after 90 days.

Across external AI processing

• Untrusted text is fenced and escaped before it reaches a model, with instructions inside it explicitly disregarded, and model output is schema-validated before the product acts on it.
• Provider endpoints are pinned to an allowlist of hosts over HTTPS, so a misconfigured or tampered environment variable cannot redirect prompts elsewhere.
• Apart from help-assistant replies, AI requests carry a one-way hash of the workspace identifier for provider-side isolation. This pseudonymous tag does not identify individual candidates.
• We do not use customer or candidate data to train our own models, and we do not license that data for model training.
• Outside the Free plan, AI features can be switched off for a workspace, per feature or entirely. Ask us — this is currently an operator setting on our side, not a self-service toggle in your settings. On the Free plan, the in-product help assistant is part of the plan and cannot be switched off separately; it processes only what a signed-in user types into it, and Free includes no other AI features.

The audit trail

• Key candidate, application, pipeline, membership, offer, integration, export, connector-session, and AI-review events are recorded with an actor or system source, the action, the affected record, and a timestamp. Where supported, material edits include before-and-after values.
• Reopening a closed application or changing its outcome is a separate, confirmed action limited to administrators and recruiters assigned to the job, and it records a reason. Each change writes one audit event with the actor, the previous and new status or stage, the reason, and where the change was made, including through the AI connector.
• Candidate lifecycle and AI-review records are append-only for browser-facing roles. Narrow privileged workflows can write the events they own, while database grants and triggers prevent ordinary user sessions from rewriting or deleting the trail.
• Relevant history is shown on the record or workflow it belongs to and is role-restricted. There is not yet a customer-wide audit-log interface, so we do not present the product as though every event can be reviewed from one place.
• Writes to connected-integration secrets, connector sessions, and sensitive exports are logged separately so those changes remain attributable.
• Infrastructure services retain their own request, error, and database-activity metadata under their platform retention windows. We do not deliberately log candidate file contents or credentials.

Retention and deletion

Candidate data belongs to the customer whose workspace holds it. Retention periods for each category of data are set out in our Privacy Policy.

• Deleting a candidate or an application removes the row. These are real deletes, not a hidden flag on a record that stays in the database, and they cascade to the applications and interviews attached. Jobs are closed, cancelled, or archived rather than deleted.
• File bytes are chased down rather than orphaned: deleting a candidate enqueues every one of their stored files in the same database transaction as the delete, and a background reaper erases the bytes and their metadata, retrying until it succeeds.
• Closing a workspace deletes the organisation and everything cascading from it, and purges its storage in a deliberate order so that file bytes are erased while they are still reachable — including the public logo and email-image buckets, which would otherwise stay world-readable after the tenant was gone.
• Workspace deletion is an operator action, requested from us and confirmed against the exact workspace name — not a self-service button in your settings. Individual user accounts can be removed by an administrator from workspace settings.

A deleted record can persist briefly in managed infrastructure backups before it ages out. Candidate-document deletion uses an exact-path queue with retries, but we do not promise instantaneous removal from every backup or operational copy.

External service categories and the responsibility boundary

We use a small set of external services to run the platform. Providers acting on our behalf are required by contract to protect personal data and use it only to deliver the relevant service. We describe them here by function so the processing boundary remains clear without publishing supplier names.

• Managed identity, relational database, and private file-storage services — authenticate users and hold account, workspace, candidate, and uploaded-file data in Singapore.
• Application hosting and compute services — run the Service with application compute configured for Singapore; the separate marketing website has no pinned processing region.
• An external AI processing service — supports the AI features in Section 08: the optional recruiting and analytics features, and the in-product help assistant included on every plan. Feature-specific request data is processed outside Singapore.
• An assisted support workflow — prepares replies to Senior Help requests and may use a separate external AI service, so an escalated help conversation may be processed outside Singapore.
• Transactional email services — deliver product messages and website-enquiry notifications and may process delivery metadata outside Singapore.
• Connected email, calendar, and scheduling services — process customer-directed activity. A calendar event created by us contains the interview time, the candidate's name, and the job title.

Current supplier identities and material changes are provided during onboarding, contracting, or a security review, and wherever a contract or applicable law requires review, notice, or authorisation.

What we are responsible for

Building and operating the Service securely: the isolation, access, encryption, and hardening described above; our choice of providers and the contracts with them; responding to vulnerabilities; and notifying customers of a breach affecting their data.

What the customer is responsible for

How the workspace is used: who is invited and at what role, removing people who leave, what is asked of candidates and on what lawful basis, what is uploaded, how long records are kept, and any tools connected to the workspace. We cannot enforce a customer's internal hiring policy on its behalf.

Availability, backups, and recovery

The Service uses managed database backup capabilities. The application exposes health and readiness endpoints — the readiness check covers required configuration, probes the database, and reports whether important optional controls are active without exposing their values. We check these around a release, and deployments can be rolled back to the previous known-good build.

We do not publish an availability SLA, a recovery time objective, or a recovery point objective, and we have not run a documented disaster-recovery exercise. We would rather say that than quote a number we cannot stand behind. Ask during onboarding and we will tell you exactly what our current backup cadence and restore path are.

Change and vulnerability management

• Changes reach production through version-controlled reviews. CI runs linting, type-checking, a production build, a production-dependency audit, static analysis, and transaction-wrapped database security suites. High-severity or unresolved static-analysis findings block the normal path unless each exception is explicitly justified.
• The enforcement point is the release, not the merge button. A guarded release binds the exact commit to its build and security evidence and rejects unexpected branches or unclean working trees. A documented exception path exists for hosted-CI outages, but it preserves local, review, staged, and runtime gates rather than treating missing hosted evidence as a pass.
• Dependencies are monitored weekly for known vulnerabilities and updated on a rolling basis.
• Schema changes are forward-only migrations, applied and reconciled against the live migration ledger rather than pushed blind.
• We run our own periodic security reviews and keep an internal risk register with explicit closure criteria for each open item. Recent hardening work tightened database privileges, document-preview sanitisation, mail-header handling, and preview-to-production data isolation. These are self-performed controls, not third-party attestation.

Reporting a security issue

If you believe you have found a vulnerability, email security@talentintelligences.com with enough detail to reproduce it — the same address published at our .well-known/security.txt. We will acknowledge your report and keep you posted while we work on it.

We do not run a paid bug-bounty programme, and we cannot offer legal safe harbour for unsolicited testing. Please do not access, modify, or retain data belonging to a workspace that is not yours, and do not run automated or load-generating tests against production. If you want to test properly, ask us first and we will arrange it.

Compliance posture and certifications

Talent Intelligence Lab does not hold SOC 2, ISO/IEC 27001, or any equivalent independent certification, and no third party has audited or penetration-tested our application. Any claim to the contrary — from us or from anyone else — is wrong, and we would like to hear about it.

Certifications held by underlying service providers apply only to the controls inside their platforms. They do not certify the Service, our application controls, the people we grant access to, or a customer's workspace configuration. Supporting information about that boundary can be provided during a security review without presenting upstream attestations as our own.

Health information is out of scope

The Service is not configured for protected health information. We do not offer a HIPAA Business Associate Agreement and have not enabled our providers' HIPAA options. Do not upload PHI or ePHI to a workspace.

Data protection law

We operate under Singapore's Personal Data Protection Act as our primary framework, and apply the GDPR and CCPA/CPRA where they reach you. Lawful bases, transfer safeguards, breach notification, and your rights are set out in the Privacy Policy.

We are glad to work through a security questionnaire or vendor review during onboarding, and to answer specific questions in writing.

Changes to this page

We update this page as the Service changes. A control appears here once it is live, and comes off if it is ever withdrawn. Material changes are dated, and we will tell customers about any change that reduces a protection they rely on.

This 2026-09-25 update reflects the move of every AI feature other than the Senior Help handoff to one external AI processing service, the disclosure of assignment-rubric drafting and calibration requests, the retirement of resume scoring, current CV-extraction masking and case-study scoring, the per-request script nonce in our Content Security Policy, and the audited reopen and change-outcome action. The 2026-09-09 update added conversational analytics data handling, access controls, and saved-history boundaries; the earlier 2026-09-03 update revalidated application-control descriptions and organised external services by function rather than supplier name.