Where staffing agencies sit in the DPDPA framework
DPDPA defines three roles: Data Principal (the individual whose data is processed - in your case, the candidate), Data Fiduciary (the entity that determines the purpose and means of processing - typically your client company), and Data Processor (the entity that processes on behalf of the Fiduciary - typically you, the staffing agency). Your obligations depend on which role the Act assigns you in a given processing activity, and it is not always just "processor."
When you source a candidate proactively (they did not apply to a specific role; you are building a talent pool), you are acting as a Data Fiduciary for that processing. You decide the purpose (building a candidate database) and the means (how you source and store). You need a lawful basis (typically consent), you owe the candidate all the Data Principal rights directly, and you bear primary compliance responsibility.
When you process a candidate specifically for a client requirement (the candidate applied to a specific role at Client A, routed through you), you are acting as a Data Processor for that client. The client is the Fiduciary. You process on their written instructions, the data agreement between you defines the terms, and while you still have processor obligations under Section 8, the primary responsibility sits with the client.
Most Indian staffing agencies do both simultaneously. You have a candidate database (Fiduciary) AND you submit candidates to clients against specific requirements (Processor). DPDPA compliance means meeting both sets of obligations, which means two separate data flow maps, two separate lawful basis assessments, and two separate candidate consent mechanisms. This is the single most common thing agencies get wrong: they treat themselves as only a processor and miss the Fiduciary obligations on their own candidate database.
Obligation 1: Consent capture (granular, specific, withdrawable)
Under Section 6, consent must be free, specific, informed, unconditional, and unambiguous, given by a clear affirmative action. That rules out pre-ticked boxes, bundled consent ("by submitting your CV you agree to everything"), and consent buried in terms-of-service. For staffing agencies the practical implication is that the moment a candidate sends you their CV, you need a specific consent record for: (1) inclusion in your talent database, (2) sharing with client companies for specific role submissions, (3) retention period, (4) any cross-border transfer if you use international tools.
The minimum viable implementation: a consent capture form at every candidate entry point (website, WhatsApp, email reply) that asks four specific questions with separate checkboxes, not one bundled "I agree." The form stores the consent record with a timestamp, the IP address, the version of the consent language, and the candidate identifier. The record is immutable and exportable on request.
Candidates must be able to withdraw consent as easily as they gave it (Section 6(5)). That means a visible link on every communication you send them ("update your data preferences") that leads to a self-serve portal where they can toggle off specific processing activities or delete their data entirely. Manual consent withdrawal via email reply is not compliant because it is not as easy as the original opt-in.
The documentation trail matters as much as the mechanism. Agencies that face Board scrutiny in 2026 are being asked for proof of consent for every candidate in their database, at the granularity DPDPA requires. If your database has 10,000 candidates and 3,000 have no consent record or only a bundled consent, you are looking at a remediation exercise that either (a) requires re-consenting those candidates or (b) deleting them. Build the mechanism before you build the database.
Obligation 2: Purpose limitation and retention
Section 8(7) requires that personal data be retained only as long as necessary for the purpose for which it was collected. For staffing, this is operationally tricky because "the purpose" is dynamic: a candidate not hired for Role A at Client X today might be a perfect fit for Role B at Client Y in 18 months, so "for the purpose of placement" could stretch for years. The Act requires you to justify this in writing and build a retention schedule you actually follow.
The defensible default for IT staffing in India is 12-month retention after last candidate interaction, auto-extended by 12 months if the candidate is actively placed or interviewing, with an option for the candidate to request indefinite retention (with refreshed consent annually). This aligns with how real hiring cycles work and how the Board has indicated it will interpret "necessary" in staffing contexts.
The mechanism: every candidate record has a "last interaction" timestamp that updates on CV resubmission, role submission, interview scheduling, or email exchange. A monthly automated job deletes or anonymizes records where the last interaction is over 12 months old and no active placement flag exists. Before deletion, the candidate gets an email ("we are about to delete your profile, click here to keep it active"). If they click, the timestamp refreshes; if not, the record is purged.
Anonymization vs deletion matters. True deletion removes the record entirely. Anonymization strips personally identifiable fields (name, email, phone) but preserves the rest (skills, experience ranges, placement outcomes) for your own analytics. Both are valid under DPDPA; anonymization is useful for training AI screening on your own placement outcomes without retaining PII. Document which you are doing per data category.
Obligation 3: Candidate rights (access, correction, erasure, portability)
Sections 11-13 grant Data Principals four rights: right to access their data, right to correction, right to erasure, and right to grievance redressal. Staffing agencies must have a process to respond to each within a reasonable period, which the Rules (once finalized) are expected to define as 30 days.
Operationally this means building or buying a candidate self-service portal where a candidate can log in with their registered email or phone, see every field you hold on them, correct errors in real time, download their data as a portable file (JSON or CSV), and request full deletion with a single click. Manual processes (candidate emails, ops lead forwards to engineering, engineering pulls data over a week) will not meet 30-day SLAs at scale and will be flagged in a Board audit.
Edge cases matter. If a candidate requests deletion but they are actively in an interview loop with a client, you have to pause the deletion, notify the client, and either complete or abort the placement with the candidate consent. If a candidate requests deletion of data you hold as a Processor on behalf of a client, you have to forward the request to the client Fiduciary because you do not have unilateral authority to delete. Document these decision trees in your internal SOP.
The grievance redressal officer (Section 13) must be named and contactable. For agencies under ₹100 crore revenue this is typically the ops lead or co-founder; for larger agencies it is a dedicated compliance officer. The name, email, and response SLA must be published on your website and on every candidate-facing communication.
Obligation 4: Breach notification
Section 8(6) requires Data Fiduciaries to notify the Data Protection Board and affected Data Principals of any personal data breach, within a timeline the Rules will specify (expected to be 72 hours for the Board, longer for individuals). Breach here includes unauthorized access, loss, alteration, or disclosure - not just hacking. A recruiter emailing 500 candidate CVs to the wrong address is a breach.
The minimum viable incident response: a written playbook that defines (1) what constitutes a breach, (2) who the incident commander is, (3) the 72-hour timeline from discovery to Board notification, (4) the communication template for affected candidates, and (5) the post-incident report template. Run a tabletop exercise quarterly so the team knows the playbook exists.
Tooling support makes the 72-hour SLA achievable. You need audit logs on your ATS that show who accessed what record when, so you can scope the breach quickly. You need email DLP (data loss prevention) that flags CVs being sent to external domains. You need a written data processing agreement with every client that defines breach notification responsibilities on both sides.
The documentation burden after an incident is heavy. Even if the breach is minor (one misrouted CV) you need to document discovery time, containment time, affected individuals, notification timeline, root cause, and remediation. A breach log spreadsheet updated by the ops lead within 48 hours of any incident is the minimum. Agencies that operate on "we do not talk about mistakes" cultures cannot meet this obligation.
Obligation 5: Cross-border data transfer
Section 16 restricts transfer of personal data outside India except to countries or territories the Central Government notifies. As of 2026 the whitelist is still evolving, and staffing agencies with US or European clients or SaaS tools hosted outside India need to track this carefully. Running AI screening on a US-hosted LLM API transfers candidate CV data outside India.
The safe defaults for 2026: (a) use India-hosted processing where it exists (Yotta, Ctrl-S, AWS Mumbai, Azure India) for any candidate data that does not need to leave India; (b) for processing that must use US or EU tools (GPT, Claude, most ATS platforms), disclose the cross-border transfer in the candidate consent form at collection time; (c) enter into appropriate data transfer agreements with any non-India vendor; (d) monitor the Board whitelist for updates.
The documentation you need: a data flow map for every personal data category showing where it is collected, where it is processed, where it is stored, and where it crosses borders. Most agencies do not have this map. Building it takes 2-3 weeks of work with an operations lead and a junior engineer and is the single most valuable compliance artifact to produce first because it feeds everything else.
Obligation 6: Data Processing Agreements with clients
When you act as a Processor for a client Fiduciary (submitting candidates against their specific requirements), the relationship must be governed by a written contract that covers the matters specified in Section 8 - purpose, nature of processing, duration, rights and obligations of both parties, confidentiality, sub-processor arrangements, breach notification, return or deletion of data on contract termination, and audit rights. Most agency-client agreements in India in 2022-2024 do not cover these.
The minimum upgrade: a DPDPA addendum to every existing client contract, signed before renewal, that specifies the above items. Template addendums are available from industry bodies (NASSCOM has one, various law firms have published versions). Customize for your client profile and do not just paste.
The client side matters too. Some clients push back on DPDPA addendums because their legal team has not updated their own vendor templates. The practical negotiation position: you cannot process their candidate data without the addendum because you would be in violation; the addendum is not a commercial ask but a compliance baseline. Clients that still refuse are a red flag for their own compliance posture, and you should price their risk into your fees or decline the work.
A 90-day compliance roadmap
Days 1-30: Data flow map. Sit down with ops and engineering, trace every piece of candidate data from collection through storage through deletion. Document collection points, processing activities, storage locations, access patterns, retention rules, cross-border flows. Deliverable: a one-page data flow diagram and a 5-page data register. This is the foundation for everything else.
Days 31-60: Build the consent mechanism, the candidate self-service portal, and the retention automation. If your ATS has these features, configure them; if not, buy a tool (CVPRO ships these by default) or build minimum viable versions. Deliverable: candidates can give granular consent, access their data, request deletion, and your system auto-deletes on the 12-month schedule.
Days 61-90: Upgrade client contracts with DPDPA addendums, publish the grievance officer and breach notification protocols on your website, run an internal tabletop breach drill. Deliverable: contract coverage across 100% of active clients, a documented incident response plan that the team has rehearsed.
At 90 days you are not "done with DPDPA" - compliance is ongoing - but you have the six operational areas covered at minimum viable depth. Further hardening (external audits, ISO 27701, DPIA processes) comes later and scales with your revenue.
- Days 1-30: Data flow map + data register (foundation)
- Days 31-60: Consent + candidate rights + retention automation
- Days 61-90: DPAs with clients + breach protocol + grievance officer published
- Budget: ₹3-8 lakh for a 90-day rollout (tools + consulting), ongoing ₹50k-1.5 lakh/month for tooling
- Legal review: budget ₹2-4 lakh for a specialized data protection counsel to review the final deliverables