Skip to content
CogniYukti

Governance

You hold the most data on the people you did not hire.

Most of a recruitment database is people who never became employees, never became customers, and have no ongoing relationship with you at all.

Under DPDP that is the hardest part of the estate, and it is the part most applicant trackers answer with a policy document.

Why erasure is harder here than anywhere else

A recruitment business keeps frozen copies of people on purpose.

When you submit somebody to a client, what the client sees is frozen at that moment — so editing the profile next month cannot quietly rewrite what they reviewed. That is the right design and it is also the reason a naive erasure fails: it blanks the person and leaves their name sitting in everything you already sent.

So the sweep goes after those copies too, and it is explicit about what it keeps.

One erasure · what it reaches4 cleared · 2 kept
  • Their candidate recordcleared
    name, email, phone
  • What you sent each clientcleared
    the frozen copy on every submission
  • The placement and its invoice linecleared
    the fee stays; the person does not
  • Contacts, leads, mail and recordingscleared
    swept on the platform side too
  • The record that consent existedkept
    kept — it is how you prove what was agreed
  • The shape of the historykept
    kept — a purged person still resolves across roles
And the two times it does not run
  • Never while they have a live application anywhere — a stale policy should not destroy an active pipeline.
  • Never under a legal hold. The request is refused with the reason, to their face.
Illustrative

Retention, when you work for several clients

The strictest client wins.

An agency does not have a retention policy. It has one per client, set in whichever contract was signed hardest. Somebody submitted to two clients therefore has two deadlines, and the earlier one is the one that counts.

That is computed rather than remembered, and the nightly sweep acts on it.

  • Never while a pipeline is live

    Somebody with an open application anywhere is not purged, even if one client's window has passed. A stale policy should not destroy work in progress.

  • Legal hold stops everything

    Including a candidate's own erasure request, which is refused with the reason rather than queued and quietly ignored.

  • Anonymised, not vaporised

    The person goes; the shape of the history stays, so a purged candidate still resolves across the roles they were considered for and your analytics do not develop holes.

  • Consent survives erasure

    The record that consent existed is deliberately kept. It is how you answer a regulator about somebody who is no longer in your database.

The rest of the estate

Consent captured at the source, and the registers underneath.

Consent is recorded as part of the application — when, under which regulation, the exact wording shown, and the circumstances. Where a partner firm submitted somebody, their attestation is on the record too, because in a vendor chain the question is always who obtained this consent.

Underneath sit the things an auditor asks for: standard reports, an evidence bundle you can produce in one action, a sub-processor register, and fairness reporting with small-cell suppression so an aggregate cannot be read back to a person.

  • Recordings have their own clock

    Consent and a retention date live on the interview recording. Ask us specifically how uploaded recordings are handled — the answer is not identical to the bot's, and you should hear that from us.

  • The candidate can act for themselves

    Access and erasure requests run from their own portal and report back immediately, including the refusal.

What your DPO will ask

Answers, including the limits of what a product can do.

Does this make us DPDP compliant?

No product does. Compliance is a programme, not a purchase. What this gives you is the operable part — retention that computes, erasure that reaches the copies, holds that stop it, and evidence you can produce. The policy decisions stay yours.

What happens to somebody a client's retention window catches?

They are anonymised — unless they have a live application anywhere, or a legal hold, in which case nothing happens and the reason is recorded.

Can a candidate erase themselves?

Yes, from their portal, and it runs immediately and reports what it cleared. Under a legal hold it is refused with the reason stated to them.

If we erase someone, do our historical numbers change?

No. The person is anonymised rather than deleted, so a hire that happened still happened. You lose the individual, not the history.

Where is the data held?

Region options belong to the platform's tenancy layer. Ask on the call and we will be specific rather than reassuring.

Does GDPR work too?

The same machinery serves EU applicants where you have them. The per-client retention model is the part that does the heavy lifting in both.

Book a demo

Bring your DPO.

This is the section that decides enterprise deals, and the second item is the one most products fail.

  • Run an erasure and watch it reach what you already sent a client
  • Place a legal hold, then try to erase the same person
  • Set two clients' retention windows and see which one applies
  • Try to purge somebody with a live application
  • Produce the evidence bundle in one action