Data Protection & DPDP Act Compliance

1. Commencement status of the Act

1.1 The Digital Personal Data Protection Act, 2023 received Presidential assent in August 2023. The Digital Personal Data Protection Rules, 2025 (the "Rules") were notified in November 2025, together with the establishment of the Data Protection Board of India. Commencement of the Act and the Rules proceeds in three stages.

1.2 The practices described in this document, comprising a hard-enforced consent gate, itemised notice, data masking by default, and a defined process for data-principal-rights requests, are implemented in the Service and in effect as of the date of this document, in advance of the Act's operative commencement date of 14 May 2027. This document describes present operational practice mapped against the Act's provisions. It does not assert a compliance status that the Act does not yet require, and no certification scheme exists under the Act as of this date.

2. Identification of the Data Fiduciary

2.1 In the Service's standard operating model, the recruiting organisation using the Service (the "Customer") determines the purpose of processing, being the screening of a named Candidate for a specific hiring decision, and is the Data Fiduciary in respect of that Candidate's personal data, consistent with Section 2(i) of the Act. PriveSecure processes personal data solely on the Customer's documented instructions, for the purpose of providing the Service, and does not process it for any independent purpose.

2.2 Where a Candidate registers directly with the Service, for example through a Customer's shareable self-service link, prior to formal association with a specific engagement, PriveSecure holds that data pending consent and association with a Customer, and does not process it for any purpose beyond enabling that association and the screening for which it was submitted.

3. Notice and consent

3.1 No verification check is submitted or processed without a recorded, valid consent from the Candidate. This requirement is enforced by the Service's architecture, such that a verification request against a Candidate record with no granted consent is rejected.

3.2 Consent is obtained under one of two modes, consistent with the notice principle in Section 5 and the consent standard in Section 6 of the Act, namely that consent be specific, informed, unconditional and capable of withdrawal as easily as it is given.

• Customer-captured consent. The Customer has obtained the Candidate's consent through its own hiring process and supplies a reference comprising a unique identifier, timestamp and the version of the consent text presented, with each submission.
• PriveSecure-captured consent. The Service transmits to the Candidate a plain-language, itemised request identifying the data source, the purpose and the retention period, confirmed by a one-time code or a typed confirmation. A decline or non-response is recorded and is not processed further.

3.3 The notice presented to a Candidate states, in plain language, the categories of data collected, the purpose, the sources checked, the intended retention period, and the method of withdrawing consent. Re-verification of a previously checked Candidate requires fresh consent. An existing consent record is not reused for a subsequent check.

4. Categories of data processed

4.1 The Service processes the following categories of personal data.

• Name, postal address, phone number and email address, as declared by or on behalf of the Candidate.
• Aadhaar number, subject to masking by default. Clause 6 sets out the precise scope of what is stored.
• Universal Account Number (UAN), where supplied, used to verify employment history against EPFO-linked records.
• The content of an uploaded resume or supporting document, and the structured employment and education details extracted from it.
• Verification results, comprising the outcome and supporting detail of each identity and employment check performed.
• Consent records, comprising mode, status, timestamp, and, where applicable, the evidence file associated with a consent.
• Where identity verification proceeds through a DigiLocker-based flow, the confirmation data returned by that flow, being a verified name and a masked Aadhaar reference. The raw Aadhaar number is not received by PriveSecure in that path.

4.2 These categories constitute the operative data set required to perform the Service's function and are retained accordingly, subject to the retention practice described in Clause 8.

5. Purpose limitation and data minimisation

5.1 Data collected through the Service is used solely for the pre-employment screening purpose for which it was submitted, consistent with the purpose-limitation principle in Section 5 of the Act. Aadhaar handling illustrates minimisation by design.

• Where an Aadhaar number is entered directly by a Customer on a Candidate's behalf, it is masked on receipt. Only the last four digits and a one-way cryptographic hash are stored. The full number is processed transiently, for the single request in which it is submitted, and is not persisted.
• Where identity verification instead proceeds through a DigiLocker-based flow, the Candidate authenticates directly with that government-linked system, and PriveSecure does not receive or process the raw Aadhaar number. Only a verified, masked confirmation is returned to the Service.

5.2 Where a Customer's plan tier does not include a given level of detail, that detail is not generated for display, rather than generated and withheld.

6. Security safeguards

6.1 Consistent with the reasonable-security-safeguards obligation in Section 8(5) of the Act, the following measures are implemented in the Service.

• Mandatory multi-factor authentication. Every account, whether Candidate, Customer or administrator, requires TOTP-based two-factor authentication prior to use. No role is exempt.
• Encryption in transit. All traffic to and from the Service is carried over HTTPS. Plain HTTP requests are rejected and redirected.
• Encryption at rest. Data at rest is encrypted by the managed database platform as a standard platform feature.
• Aadhaar masking by default, as described in Clause 5.
• Application-level tenant isolation, restricting a Customer's access to its own Candidates, enforced on each request, with database-level access restrictions applied as an additional control.
• Role-based access, restricting a Candidate to their own record and a Customer to its own Candidates, with administrative access provisioned through a controlled internal process rather than public registration.

6.2 PriveSecure maintains a written information security programme describing these and related controls in further detail, available to Customers on request.

7. Rights of the Data Principal

7.1 In advance of the commencement of Sections 11 to 14 of the Act, the Service supports the substance of the following rights for a Candidate.

• Right to access information, being a summary of the personal data held and its processing history.
• Right to correction and updating of inaccurate or outdated personal data, on request.
• Right to erasure of personal data no longer necessary for the purpose for which it was collected, subject to an overriding legal or contractual retention requirement, for example a record a Customer is separately required to retain.
• Right to withdraw consent at any time, halting any further check. Withdrawal does not affect a check already completed.
• Right to grievance redressal, addressed under Clause 16, and, upon that avenue becoming operative, escalable to the Data Protection Board under Clause 15.
• Right to nominate another individual to exercise these rights on the Candidate's behalf in the event of death or incapacity.

7.2 PriveSecure targets acknowledgement of a rights request within five business days and resolution within thirty days. Where a request concerns a check performed for a specific Customer, PriveSecure may confirm relevant details with that Customer, as the Data Fiduciary responsible for the underlying hiring decision, prior to acting on the request.

8. Retention and erasure

8.1 The default retention period is 180 days following completion of a Candidate's verification, or immediate deletion upon withdrawal of consent if earlier, communicated to each Candidate as part of the notice presented prior to consent.

8.2 A Customer may configure an alternative retention period appropriate to its own requirements by specifying this in its engagement with PriveSecure. A Candidate may likewise request early deletion under Clause 7.

9. Breach notification

9.1 Upon becoming aware of a confirmed personal data breach affecting data processed through the Service, PriveSecure will notify affected Customers without undue delay, and in any event within seventy-two hours of confirmation, together with the information reasonably available at that time to assist the Customer in meeting its own notification obligations. This standard is reflected in PriveSecure's customer agreements and is stated here as PriveSecure's general practice.

9.2 PriveSecure maintains a written security incident response plan setting out the containment, assessment, notification and remediation steps triggered internally by a confirmed incident.

10. Cross-border processing

10.1 Section 16 of the Act permits transfer of personal data outside India except to a country specifically restricted by notification of the Central Government. No such restriction currently applies to the jurisdictions in which PriveSecure's infrastructure providers operate.

10.2 PriveSecure is undertaking migration of the Service to infrastructure located within India, consistent with the data localisation commitments made to its Customers. This clause will be updated to confirm completion. All data in transit is encrypted, and the safeguards described in Clause 6 apply irrespective of infrastructure location.

11. Sub-processors

11.1 PriveSecure engages licensed third-party providers for identity verification through a DigiLocker-based aggregator and employment verification through an EPFO/UAN-linked aggregator, together with a managed cloud database, application-hosting and content-delivery provider to operate the Service. PriveSecure remains responsible for the acts and omissions of these providers in connection with the Service, does not use Candidate data for any purpose outside providing the Service, and does not use it to train generalised models, as set out in Clause 12. A current list of named sub-processors is available to Customers on request.

12. Use of AI in the Service

12.1 Verification verdicts produced by the Service, comprising the Green, Amber, Red or Grey classification and the associated score, are generated by deterministic, rules-based logic applied to data returned by licensed verification providers. This logic is not a trained machine-learning model and is not produced by any AI system.

12.2 A large-language-model API, being Anthropic's Claude accessed through its commercial API, assists in parsing a resume into structured fields where deterministic extraction alone is insufficient, for example where an employment section follows an atypical format. Anthropic's commercial API terms provide that customer inputs and outputs submitted through the API are not used to train Anthropic's models, by default and without an opt-in or opt-out mechanism. See Anthropic's published policy. PriveSecure's own policy is that Candidate data is not used to train any model, generalised or otherwise, for any purpose beyond providing the Service.

13. Children's data

13.1 The Service is designed for the pre-employment screening of adult job candidates and is not directed at, marketed to, or intended for use by children. PriveSecure does not knowingly process the personal data of a child through the Service, and will delete any such data promptly upon becoming aware of it.

14. Significant Data Fiduciary status

14.1 Section 10 of the Act empowers the Central Government to notify a data fiduciary as a Significant Data Fiduciary, triggering additional obligations, including appointment of a Data Protection Officer based in India, an independent data auditor, and periodic data protection impact assessments. PriveSecure has not been notified as a Significant Data Fiduciary. Should that designation apply in future, PriveSecure will implement the obligations arising from it.

15. Data Protection Board and escalation

15.1 The Data Protection Board of India has been established and is operational in respect of its constituted functions as of the commencement dates set out in Clause 1. Upon the Board's complaint-handling functions becoming operative, a Candidate dissatisfied with PriveSecure's response to a rights request may escalate to the Board. Pending that, the contact route in Clause 16 is the applicable channel for a request.

16. Contact and rights requests

16.1 A request to exercise a right described in this document, a request for a copy of PriveSecure's information security programme or sub-processor list, or any other data-protection query, may be directed to:

16.2 A request should include sufficient detail to identify the relevant record, for example the name and the phone number or email address used at the time of submission, and the Customer involved, if known.

17. Amendment of this document

17.1 This document is reviewed no less than annually, and upon any material change to the Service's processing of personal data or to the applicable law. The date at the top of this document indicates the date of last review.

This document is not a substitute for independent legal advice. A Customer evaluating the Service for its own compliance purposes should have this document reviewed by counsel alongside the applicable services agreement.