DPDP-ready verification workflows

Most DPDP readiness work produces a document. A policy is written, a clause is added to the offer letter, a training deck circulates, and the workflow that actually processes candidate data continues exactly as before.

That gap is the risk. The Act's obligations are almost entirely about what a system does — what it collects, when it stops, what it deletes — and a policy that the system does not implement is an unkept promise with your signature on it.

Here is what has to change in the workflow itself.

Consent has to be an object, not a checkbox

Under the Act, consent is free, specific and informed. "Specific" is the one with system consequences: consent attaches to a purpose. One box covering "background verification" is not specific, because background verification is not a purpose — it is a category containing several.

In workflow terms, consent stops being a boolean on the candidate record and becomes a set of rows: which purpose, granted when, by which candidate, against which notice version, and whether it has since been withdrawn.

That last field is what makes the rest enforceable. If consent is a boolean, withdrawal has nowhere to go.

Every check dispatch has to be gated on its own consent

Once consent is per purpose, the dispatch path has to read it. A check should be impossible to start without a live consent row for its purpose — not "should not be started", but cannot be, enforced in the code that dispatches rather than in a reviewer's judgement.

This sounds heavy and is not. It is one lookup at the point of dispatch. What it buys is that the answer to "were we authorised to run this?" is a query rather than an investigation.

Withdrawal has to reach in-flight work

A withdrawal that only stops future checks is half a control. The candidate withdrew now; there are three checks in flight now.

The workflow needs a real cancel path: mark the consent withdrawn, halt anything dispatched under it, stop chasing the candidate for its inputs, and record the check's outcome as withdrawn rather than as an insufficiency or a failure. Those are different states and a report that conflates them misrepresents the candidate.

What withdrawal does not do is unmake a completed verification, or override an independent retention obligation. Say so in the notice rather than promising something the law does not require and the system cannot deliver.

Separate the verdict from the evidence

This is the single highest-value structural change, and it serves two obligations at once.

A verification produces two things: a finding ("degree confirmed with the issuing university, 14 August 2026") and the evidence that produced it (the certificate scan, the registrar's reply, the Aadhaar XML). They have entirely different retention profiles. The finding may reasonably be kept for the life of the employment relationship. The scanned identity document usually has no purpose the moment the finding exists.

Store them separately, with separate retention clocks. A system that keeps them in one blob has to choose a single retention period for both, and it will choose the longer one — which is how programmes end up holding candidate identity documents for years with no purpose to point at.

Retention has to expire on its own

A retention policy enforced by someone remembering to run a deletion is not enforced. The workflow needs a retention period attached to each data class at the point of collection, and a scheduled job that deletes on expiry without being asked.

Two details make this survivable in practice. Deletion should be recorded — what class, how many records, when — so you can show it happened without keeping the data to prove it. And a legal hold has to be able to suspend expiry for a specific case, because a live dispute is exactly when automatic deletion is most damaging.

Hold the discrepancy, not just the answer

The Act gives candidates a right to correction, and in verification that right collides with something specific: a discrepancy is not an error. A candidate whose declared dates do not match the provident fund record may ask you to correct the record to match their claim.

They are entitled to correction of inaccurate personal data. They are not entitled to have a verified finding replaced by an unverified assertion. The only structure that survives this holds three things separately: what was declared, what was verified, and the difference between them. A system storing one final verdict has nowhere to put a contested correction and will end up either ignoring the right or destroying the finding.

The audit trail is the deliverable

Every control above produces a record: consent granted, dispatch authorised, withdrawal honoured, evidence deleted on schedule, discrepancy raised and resolved. Together they are the thing you can actually show a regulator, a customer's security review, or your own board.

A compliance posture you cannot demonstrate from your own logs is a claim, not a control. Build the logging in from the start — retrofitting it means reconstructing history you did not keep.

• DPDP
• compliance
• workflow
• retention