Trust Centre

1. Why this page exists

In short:We ask candidates to trust us with sensitive data, so we should be able to show our own work.

A background verification platform holds some of the most sensitive personal data a person has: identity numbers, addresses, employment history, court-record searches. Asking an organisation to route that through us is asking for a great deal of trust.

This page states what we do about it, in terms specific enough to be checked. Where we hold a certification, the certificate number is above — a badge without a number is a graphic, not evidence, so we do not display one.

2. Data protection

In short:Encrypted, minimised, access-controlled, and deleted under our retention policy.

Personal data is stored and processed primarily on infrastructure located in India, with encryption applied in transit and at rest.

We collect only what the selected check package requires, mask identity numbers at rest once the verification result exists, and store verification findings separately from the evidence behind them so each can expire on its own schedule.

Deletion is automated rather than manual. Full detail is in our Privacy Policy and DPDP Compliance pages.

3. Access control and monitoring

In short:Least privilege, and every look at a case file is logged.

Access to production data is role-based, granted on the principle of least privilege, monitored, and reviewed periodically.

Administrative access requires individual accounts — there are no shared logins — and the admin panel records an audit entry for every change to content, configuration or team membership.

4. How we treat verification sources

In short:We report what a source said, including when it said nothing.

Every finding carries the source that produced it, the method used, and the time it was captured. A search that returns nothing is reported as nothing found in the jurisdictions searched — not as an assurance that nothing exists.

A check that cannot be completed is reported as an insufficiency with the reason, never as a clear. This is a deliberate design choice: a false clear is the most damaging output a verification platform can produce.

5. Sub-processors

In short:A short list, each under a written agreement.

We use a limited set of infrastructure and service providers. Each operates under a written processing agreement restricting them to our documented instructions.

A current list of our sub-processors, and the infrastructure they run on, is available to customers on request.

6. Reporting a security issue

In short:Tell us, and we will not come after you for it.

If you believe you have found a vulnerability, our Responsible Disclosure Policy explains how to report it, what is in scope, and the safe-harbour undertaking that applies to good-faith research.

7. Questions

In short:Security reviews and questionnaires are welcome.

For security questionnaires, processing terms, sub-processor lists or certification evidence, contact [email protected]. We would rather answer a hard question than have it assumed.