DPDPA Checklist for Data Protection Officers

What must a DPO or privacy lead do for DPDPA compliance?

1. Get your own mandate written down — and know which hat you are wearing. Two different roles are routinely conflated. A formally designated Data Protection Officer is required under Section 10(2) and only of a Significant Data Fiduciary — based in India, representing the SDF under the Act, responsible to the board of directors or equivalent governing body, and the point of contact for grievance redressal. Separately, Rule 9 requires every Data Fiduciary to prominently publish the business contact information of the DPO if applicable, or a person able to answer Data Principals' questions about processing. Until notification, you are almost certainly the second, not the first. Either way, secure in writing: your reporting line, your budget, your authority to halt a launch, and freedom from conflict of interest — you cannot credibly assess processing you also own commercially. If you expect notification, build to the Section 10(2) standard now, because retrofitting board-level reporting after the fact is a governance conversation, not a compliance one.
2. Build the processing inventory, keyed to lawful ground per data element. Not a data map — a ground map. For every processing activity: data classes, Data Principal categories, purpose, lawful ground, source, systems, processors, recipients, retention basis, cross-border flow. Section 7 legitimate uses are a closed list, so most commercial processing lands on Section 6 consent; Section 7(i) covers employment processing for the employer only; Section 7(a) covers data voluntarily provided for a specified purpose without indication of objection, and is tightly bounded by that purpose. Flag three populations explicitly because they carry separate machinery: children under 18 (Section 9, with Rule 10 verifiable parental consent and the Rule 12 / Fourth Schedule carve-outs where you qualify), persons with disability having a lawful guardian (Rule 11 — court, designated authority under s.15 RPwD Act 2016, or local level committee under s.13 National Trust Act 1999), and third parties whose data you collected from someone else — nominees, dependants, referees, emergency contacts — who are Data Principals with their own rights. This inventory is your DPIA skeleton if you are ever notified, and your affected-population query if you are ever breached.
3. Bring the notice estate into Rule 3 conformance, then run Section 5(2). Rule 3 requires the notice to be presented and understandable independently of your other information, to give in clear plain language an itemised description of the personal data and the specified purposes with a specific description of the goods, services or uses enabled, and to give the particular communication link and any other means by which the Data Principal may withdraw consent (with ease comparable to giving it), exercise rights, and make a complaint to the Board. That last element is the one most drafts omit. Separately, Section 5(2) requires that where consent was obtained before commencement, you give those Data Principals the required notice as soon as reasonably practicable — a one-time programme across your legacy base, sized and scheduled now rather than in Q1 2027.
4. Make consent evidentiary, and make withdrawal propagate. The Board's question in an inquiry is not "do you have a policy" — it is "prove the state of consent on 14 March." Capture per consent: notice version served, purposes granted and refused, timestamp, channel, and identity method where a child or guardian is involved. Store it tamper-evidently. Then test withdrawal end to end on a real journey: does it reach the primary database, the CRM, the CDP, the messaging gateway, the ad-audience upload, and each processor and partner? Most organisations can stop the first system and none of the rest. Document the boundaries too — withdrawal does not reach data retained under a legal obligation, and processing done before withdrawal remains lawful.
5. Stand up a processor register and remediate the contracts. Characterise every counterparty deliberately as Data Processor (acts on your instructions; Rule 6(1)(f) requires appropriate security provisions in the contract) or Data Fiduciary in its own right (processes for its own purposes; the transfer to them is a third-party disclosure needing its own ground). Do not leave it to be inferred later. Contract minimums: purpose limits, sub-processing consent, deletion on exit, audit right, and an incident-escalation SLA in hours — their delay consumes your clocks. Liability for a processor's failure stays with you and cannot be contracted away. Priority order for remediation: anything on a click-through plan holding bulk personal data.
6. Map your security baseline to Rule 6(1) line by line, and note the one-year floor.

   Rule 6(1)	Evidence you should be able to produce
   (a)	Encryption, obfuscation, masking, or virtual tokens mapped to the personal data
   (b)	Access control over the computer resources used by you and your processors
   (c)	Logs, monitoring and review giving visibility on access — for detection, investigation and remediation
   (d)	Backups and continuity measures for loss of confidentiality, integrity or availability
   (e)	Retention of logs and personal data for one year, unless another law requires otherwise
   (f)	Security provisions in the processor contract
   (g)	Technical and organisational measures ensuring effective observance

   Item (e) catches people out: it is a retention floor inside the security rule, and it sits alongside Rule 8(3), which requires retaining personal data, associated traffic data and other processing logs for a minimum of one year for Seventh Schedule purposes. Your erasure messaging must be reconciled with both.
7. Instrument rights and grievance operations against the ninety-day ceiling. Rule 14(1) requires prominently publishing the means by which a Data Principal makes a request and any identifier you need — customer ID, application reference, enrolment ID, email or mobile. Rule 14(3) requires a grievance redressal system responding within a period not exceeding ninety days, with appropriate technical and organisational measures to make that effective. Rule 14(4) requires supporting nomination of one or more individuals. Rule 9 requires repeating the contact information in every response to a rights communication. Build the queue with identity verification, SLA timers, and a monthly report to whoever you report to — volume spikes during disputes, exits and after any public incident, and an unmeasured queue is the easiest thing for a regulator to find wanting.
8. Write the retention schedule with the erasure triggers built in. Per data class: purpose, retention basis, period, and disposal method. Purpose limitation plus the erasure duty applies once the purpose is served, qualified where retention is necessary for compliance with a law in force — and you should be able to name the specific obligation, not assert a general business need. Then check whether you fall inside the Third Schedule classes under Rule 8(1): an e-commerce entity with not less than two crore registered users, an online gaming intermediary with not less than fifty lakh, or a social media intermediary with not less than two crore. If so, you must erase after three years from the Data Principal's last approach, for all purposes except enabling account access and access to stored virtual tokens — and Rule 8(2) requires informing them at least forty-eight hours before that erasure. Most organisations are outside these classes; the ones inside frequently do not realise it.
9. Write the breach runbook to four lanes, then rehearse it. The clocks are cumulative, not alternatives:

   Filing	Deadline	Basis
   CERT-In incident report (where the incident is covered)	6 hours of noticing	CERT-In Directions 2022, s.70B(6) IT Act
   Intimation to each affected Data Principal	Without delay	Rule 7(1)
   Initial intimation to the Data Protection Board	Without delay	Rule 7(2)(a)
   Detailed report to the Board	72 hours of becoming aware	Rule 7(2)(b)

   Plus any sectoral regulator — RBI, IRDAI, SEBI — and contractual notification duties to partners. The Board receives two filings, not one; most runbooks have only the 72-hour report. Pre-draft the Rule 7(1) notice to its prescribed contents: nature, extent and timing; consequences relevant to that individual; mitigation implemented and being implemented; safety steps they can take; and business contact information of someone able to respond. The 72-hour report additionally needs broad facts on events, circumstances and reasons, measures implemented or proposed, findings on who caused it, remedial measures against recurrence, and a report on the intimations given to affected Data Principals — so your notification dispatch logs are a filing input, not an afterthought. Run one incident facts register, append-only and timestamped, from T+0: the CERT-In filing is a snapshot at hour six, the Board report a structured export at hour 72, and contradictions between them are exactly what an inquiry notices. Name an owner and an alternate; tabletop it twice before it is live law.
10. Build the SDF dossier voluntarily, and inventory cross-border for everyone. Rule 13 obligations bind Significant Data Fiduciaries: a Data Protection Impact Assessment and audit once every twelve months from the date of notification or inclusion in a notified class; furnishing to the Board a report containing significant observations from that DPIA and audit; due diligence on algorithmic software used for hosting, display, uploading, modification, publishing, transmission, storage, updating or sharing, to verify it is not likely to pose a risk to Data Principals' rights; and localisation of personal data specified by the Central Government on a committee's recommendation. The twelve-month clock runs from notification, so an organisation notified with no artefacts in hand has a year to produce a first DPIA and audit from a standing start. If you are a plausible candidate, build the DPIA template, the audit scope and the algorithmic register now. Separately and for everyone: Rule 15 applies to any Data Fiduciary transferring personal data outside India, subject to requirements the Central Government may specify by general or special order — inventory offshore hosting, global shared services, and any foreign entity able to query Indian records. Rule 13(4) localisation is SDF-only; Rule 15 is not.