DPDP & Data Protection

1. Who is responsible for what

In short:For verification the employer generally decides; we generally carry it out.

The Digital Personal Data Protection Act, 2023 distinguishes the Data Fiduciary, who determines the purpose and means of processing, from the Data Processor, who processes on the Fiduciary's behalf.

For candidate background verification performed for a customer, the customer generally determines the purpose and scope, and Papertrail generally acts as the Data Processor on their documented instructions. They decide that a candidate will be checked, which checks apply to the role, and what they do with the result.

Papertrail may act as a Data Fiduciary for processing it determines for its own purposes — operating and securing the platform, managing customer accounts and billing, preventing fraud, meeting legal obligations and handling grievances.

The role follows the processing activity rather than being fixed by declaration, which is the same position taken in our Privacy Policy.

This is not a way of shifting responsibility. A processor has direct obligations under the Act — security safeguards, breach notification, acting only on instructions — and we meet them. It does mean that a candidate exercising rights over verification data has an employer as their counterparty, and we will identify that employer.

2. Consent, captured properly

In short:One consent per purpose, with a notice that names the checks — not one blanket tick.

The Act requires consent to be free, specific, informed, unconditional and unambiguous, given by a clear affirmative action, and limited to the personal data necessary for the stated purpose.

We capture consent per purpose. A candidate consents to an employment verification, or to a criminal-record search, as separate acts — not to "background verification" as a single undifferentiated category. Each consent record stores which purpose, when, against which version of the notice, and whether it has since been withdrawn.

Where a check is based on consent, the platform is designed to associate it with the applicable consent record before the verification is dispatched, rather than leaving that to an operator's judgement.

Consent is one lawful basis under the Act, not the only one. Some processing — security, fraud prevention, records the law requires us to keep — rests on another basis the Act permits.

The notice shown before consent states, for each check: what data is collected, which source it will be verified against, the purpose it serves, how long it is retained, and how to withdraw.

3. Withdrawing consent

In short:As easy to withdraw as to give, and we stop what is within our control.

A candidate may withdraw consent at any time, and the Act requires withdrawal to be as easy as giving it.

Withdrawal in our platform marks the consent record withdrawn, stops any further request to the candidate for inputs, and records the check's outcome as withdrawn — a distinct state from an insufficiency or a failure, and reported as such.

Withdrawal applies to further processing within our reasonable control. Where a request has already gone to a university, an employer, a court-record source or an external verifier, we cannot recall it — we stop what is ours to stop and tell you what had already left. Withdrawal does not unmake a verification already lawfully completed, and it does not override an independent legal obligation to retain a record.

4. Candidate rights

In short:Access, correction, erasure, nomination, and a grievance route.

The Act gives a Data Principal the right to a summary of the personal data processed and the processing activities undertaken; to correction, completion and updating of inaccurate or incomplete data; to erasure where the purpose is served and no legal obligation requires retention; to nominate someone to exercise these rights on death or incapacity; and to grievance redressal.

The Act and the 2025 Rules commence in stages, so which obligations bind whom, and when, depends on the provision. We are building and operating our processes to support these rights as and when they apply — a candidate's record can be produced as a summary, corrections are recorded against the case, and deletion follows a retention policy rather than someone remembering.

Correction and discrepancies. A verified finding that differs from a declared claim is a discrepancy, not an inaccuracy in our records. We store the declared value, the verified value, and the difference, and a candidate may add their explanation to the record. We will not overwrite a verified finding with an unverified assertion, and we will not suppress the candidate's account of it either.

5. Data minimisation and purpose limitation

In short:Only what the check needs, and only for as long as it needs it.

We collect only the data the selected check package requires. A role that does not need a credit check does not produce a credit-check consent request, and the corresponding data is never collected.

Verification findings and the evidence behind them are stored separately with separate retention clocks, because they have genuinely different lifespans. A confirmation that a degree was verified may reasonably outlive the scanned certificate that established it, and holding both under a single long retention period is how organisations accumulate sensitive documents they have no purpose for.

Government-issued identity numbers are subject to access controls, masking and retention controls appropriate to the check. Where a full identity number is no longer required, our systems are designed to limit its continued retention.

Retention is applied under our retention policy. A legal hold can suspend expiry for a specific case where a dispute is live.

6. Reasonable security safeguards

In short:Encryption, least privilege, and a logged trail of every access.

The Act requires reasonable security safeguards to prevent personal data breaches. We apply encryption in transit and at rest, role-based least-privilege access, monitor and periodically review access, and operate a documented incident response process.

Papertrail holds ISO/IEC 27001 (information security) and ISO 9001:2015 (quality management) certification, and is a member of NASSCOM and the Data Security Council of India. Certificate numbers are available on request.

7. Breach notification

In short:We detect, contain, assess and notify — as processor or as fiduciary.

We maintain an incident-response process for detecting, containing, assessing and responding to personal data breaches.

Where we act as a Data Processor, we notify the instructing customer without undue delay, in accordance with applicable law and our contract with them, and give them the assistance they reasonably need to meet their own obligations.

Where we act as a Data Fiduciary, we make the notifications applicable law requires, including to the Data Protection Board of India and to affected Data Principals, in the form and within the time prescribed.

Our internal process covers detection, containment, assessment, notification and post-incident review.

8. What this page is, and is not

In short:A description of how we work — not a certificate, and not legal advice.

This page describes Papertrail's data-protection practices and framework at a high level, for transparency. It is not legal advice, and it is not a representation that every provision of the Digital Personal Data Protection Act, 2023 or the Digital Personal Data Protection Rules, 2025 applies to every processing activity we or our customers undertake.

There is no government-issued "DPDP compliant" certificate, and we do not claim one. Which obligations apply, to whom, and from when depends on the nature of the processing, the parties' respective roles, applicable law, and the staged commencement of the relevant provisions.

Contractual data-protection obligations between Papertrail and a customer are set out in the agreement between them, which may include a data processing addendum. Where that addendum and this page differ, the addendum governs.

9. Contact

In short:A named Grievance Officer, reachable.

Questions about our DPDP posture, requests for our processing terms, or grievances can be addressed to our Grievance Officer:

Shahid Ali, Grievance Officer · [email protected] · B-85, Sector 64, Noida, Uttar Pradesh 201301, India

If you are not satisfied with our response, you may complain to the Data Protection Board of India.