Trust centre

• Every customer’s data is isolated in the database

  Row-level security is enforced on every table that holds customer data, including for the application’s own database role, and an automated check fails if any table is missing its policy.

  In place

• Permission checks look at the record, not just the role

  Access is decided against the specific person, team or record requested, and an automated test blocks checks that only ask whether someone holds a permission at all.

  In place

• Default roles start narrow

  Employees see their own records and managers their direct reports by default; granting a self-service role company-wide is refused.

  In place

• Sensitive identifiers are encrypted field by field

  PAN, Aadhaar, passport, bank account, UAN, ESI number and date of birth are encrypted with AES-256-GCM under a key per customer. They are masked by default; revealing one needs a permission and a fresh sign-in, and is recorded in the audit log.

  In place

• Encryption in transit (TLS 1.2 or later, with HSTS)

  Configured and reviewed. It becomes true when the service launches and certificates are issued.

  In progress

• Encryption master key in a key-management service, with rotation

  The key that protects every company’s data keys can be held in AWS KMS instead of a server setting, and can be rotated without downtime using a tested re-wrap command. The KMS path has not yet been run against a real KMS account.

  In progress

• Disk and storage encryption at rest

  A property of the production hosting, which is not live yet.

  In progress

• Continuous backups with tested restores

  Continuous archiving, nightly backups and a restore drill are built, but no restore drill has completed yet (the first scheduled run failed before restoring anything). Recovery targets of 5 minutes of data and 2 hours to restore are design goals, not measured figures.

  In progress

• Passwords are checked against known breaches

  Passwords must be at least 12 characters and are checked against the Have I Been Pwned breach corpus without the password itself leaving our service.

  In place

• Two-factor authentication

  Authenticator-app codes with single-use recovery codes, and an audited, permission-gated reset for administrators.

  In place

• Fresh sign-in for sensitive actions

  Changing roles, revealing personal identifiers, downloading bank files, bulk exports, creating API keys, changing SSO, finalising payroll and similar actions need a sign-in from the last five minutes. Every sensitive action in our catalogue now has the check.

  In place

• Role-based access with data scopes

  Access can be limited to self, direct reports, a unit, a location, a legal entity or the whole company, with custom roles, time-limited delegation and a read-only auditor role.

  In place

• Session limits and revocation

  Sessions end after 12 hours idle and 30 days at most; sign-ins from a new device are notified, people can see and sign out their own devices, and administrators can revoke any session.

  In place

• Support staff enter your workspace only with your permission

  Entering a workspace needs your consent grant. Urgent “break-glass” entry needs a ticket reference and is allowed only while your own switch is on (it is on by default); every entry is recorded. Sign-in for our own support staff does not exist yet.

  In place

• Two-factor required for admin, payroll and finance roles

  Admin, payroll and finance roles must enrol a second factor before reaching any page, action or administrative download. Not yet every endpoint: the AI assistant’s request endpoint is outside the rule.

  In progress

• Single sign-on (SAML and OIDC)

  Configured per company, with an option to require it for everyone except the account owner. Tested with generated test assertions; not yet tried against a live identity provider such as Okta, Entra ID or Google.

  In progress

• Automated user provisioning (SCIM 2.0)

  Users and groups, authenticated per company, rate limited and logged; removing a person ends their sessions. Not yet connected to a real identity provider.

  In progress

• IP allowlists

  Limit administrative access and API keys to your own network ranges; outside them, a listed role’s whole signed-in session is refused. One endpoint — the AI assistant’s request endpoint — is not yet covered.

  In progress

• Strict browser security headers

  A per-request Content Security Policy with no inline-script exceptions, plus HSTS, framing, content-type, referrer and permissions policies on every response.

  In place

• Cross-site request forgery protection

  Form submissions are checked against the origin of the page that sent them.

  In place

• Input validated at the API boundary

  Every write to the public API is checked against a declared schema before it runs.

  In place

• No hand-built SQL

  All database access goes through parameterised queries.

  In place

• Uploaded files are scanned

  Every upload is size-checked, type-checked from its content rather than its name, and virus-scanned.

  In place

• Tamper-evident audit log

  An append-only, hash-chained record of sensitive reads and writes that can be independently verified.

  In place

• Dependency and secret scanning

  Vulnerability, licence and secret scanning run in our build pipeline and last passed on 26 September 2026; work since then has not yet been through the pipeline.

  In place

• Webhooks cannot be pointed at internal addresses

  Webhook and audit-stream addresses that point at private, internal or cloud-metadata ranges are refused when saved and again when delivering, including after a DNS change; redirects are never followed.

  In place

• Rate limiting

  Applied to sign-in, the API, provisioning, public forms, emailed links and the AI assistant. Edge-level limits at the network perimeter are still to come.

  In progress

• Logs with personal data redacted

  Structured logs strip identifiers, credentials and cookies. Central log storage arrives with the production launch.

  In progress

• Signed daily audit checkpoints and audit streaming to your SIEM

  Every day each company’s audit trail is sealed into a signed checkpoint kept where the application cannot alter it, and the audit trail can be streamed to your own SIEM as signed batches. Tested with stand-ins only: not yet connected to a real SIEM, S3 bucket or public publication point.

  In progress

• AI never makes adverse decisions about people

  No AI tool exists that can reject a candidate, end employment, set a performance rating or change pay. Database rules also refuse those writes while an AI is acting, and a test fails if any tool with such a name or permission is added. Those decisions stay with people.

  In place

• AI acts with your permissions, under human approval

  An assistant can use only the tools the signed-in person could use. Anything above the autonomy level you choose waits for a named person to approve, and every run is budgeted, traced and can be switched off.

  In place

• Protection against instructions hidden in documents

  Résumés, candidate answers and other third-party text are marked as untrusted data before an AI model sees them.

  In place

• AI reporting sees only approved data

  The AI that answers reporting questions uses its own database role, limited to an explicit list of reporting views.

  In place

• Small groups are never singled out

  Summaries the AI can see hide any group smaller than five people — in a way that cannot be undone by subtraction — and never include identities.

  In place

• AI provider terms: no training on your data

  AI features use Anthropic’s Claude models, with Google’s Gemini as an optional backup. Both vendors’ published terms say API data is not used for training; we cannot verify that ourselves, so it is not counted as in place.

  In progress

• Your say over which AI provider processes your data

  You see which AI provider processes your requests, where and with what retention, and your choice is recorded; a request is held rather than sent to a provider you have not allowed. A backup provider is allowed by default, and neither provider is in India.

  In progress

• AI conversation traces are scrubbed on a schedule

  Content of AI runs is scrubbed after a period you set (180 days by default), keeping only cost and status, and one person’s traces can be erased. It is not yet part of the data-request flow.

  In progress

• Personal data stripped before every AI call

  ID numbers, bank details, phone numbers, emails and labelled dates of birth are replaced before every AI request. Names and addresses written in free text, and records the assistant looks up, are not yet filtered.

  In progress

• Zero data retention at the AI provider

  The provider currently keeps data for up to 30 days; a zero-retention agreement is not yet in place.

  In progress

• AI safeguards evaluated against the live model

  Our AI safeguards are tested with recorded scenarios. Testing against the live model — including a 40-pair bias test on identical résumés — is still to come, so there are no results to publish.

  In progress

• Clear roles under the DPDP Act

  You are the Data Fiduciary; we act as your Data Processor under a data processing agreement.

  In place

• Candidate consent, recorded and withdrawable

  Applicants give versioned, purpose-specific consent that is recorded with their application and can be withdrawn.

  In place

• A published sub-processor list

  Maintained against the code that actually calls each vendor, with its purpose and location.

  In place

• Automatic deletion on a retention schedule

  The schedule, the deletion job and default policies for new workspaces exist; automatic deletion now covers nine of ten data categories (audit is never purged). Not yet run against a live company, and the retention periods await legal sign-off.

  In progress

• Legal holds

  A hold correctly blocks deletion; placing one from the product is still to come.

  In progress

• Data-access requests

  The export is built and tested, and an HR or privacy person can now log, verify, fulfil and download a request from a screen. There is no form for employees or candidates to make a request themselves yet.

  In progress

• Data-erasure requests

  Erasure works for profiles and records what the law requires us to keep; several data categories still need a decided policy. Requests are handled from the same HR and privacy screen.

  In progress

• Workspace deletion with a signed certificate

  At contract end we build a full export for you, then destroy the workspace’s keys, data and files and issue a signed certificate that also states what remains (backups, up to a year). Proven on a real database, not yet on real file storage, and operator-run: there is no customer-side button yet.

  In progress

• Privacy notice for employees at onboarding

  An employee can already record or withdraw their WhatsApp consent from their own privacy page. What the product does not do yet is show every new employee a privacy notice at onboarding and record that they have read it, so nothing is recorded today.

  In progress

• Automatic 30-day notice of sub-processor changes

  The sub-processor list and its change history are published on this site. What the product does not do yet is notify each customer automatically 30 days before a vendor is added or changed, so there is nothing to subscribe to; check the list.

  In progress

Where your data is held

• Primary application data: planned for an Indian data-centre region. Production is not live yet.
• Documents, résumés and exports: Cloudflare R2 object storage, which gives no India jurisdiction guarantee.
• AI features: processed by Anthropic, PBC — United States.
• Other vendors: 10 are always in use and 15 apply only if you, or the person concerned, turn them on.
• Vendors with a disclosed residency caveat: Cloudflare, Inc., Anthropic, PBC, Google LLC (Gemini API), Resend (Resend, Inc.), Brevo (Sendinblue SAS), Sentry (Functional Software, Inc.) — or self-hosted GlitchTip, Face++ (Megvii Technology Limited), Speech-to-text provider — selection pending (no provider engaged yet), Cloud hosting provider — Amazon Web Services, Inc. or Oracle Corporation (Oracle Cloud Infrastructure), per deployment, Zoho Corporation Pvt. Ltd. (Zoho Books), Leegality (Grey Swift Pvt. Ltd.), SpringVerify (legal entity to be confirmed from the customer's contract), AuthBridge Research Services Pvt. Ltd., OnGrid (legal entity to be confirmed from the customer's contract). Each caveat is spelled out on the sub-processor list.

Agreements

• Data processing agreement — its structure and generated annexes. A signable copy awaits our registered legal details.
• Sub-processors — every outside company that processes personal data for us, what for, and where.